Em Thu, Mar 01, 2001 at 07:02:41PM +0100, J.R. de Jong escreveu:
> Well, I've tested the patch and Petr's suggestion. I'm testing for
> broadcasts with
>
> tcpdump | grep -i '0:D0:B7:18:62:E3'
>
> since 0:D0:B7:18:62:E3 is my hardware adress. Broadcasts show up as:
>
> 18:52:26.807269 0:d0:b7:18:62:e3 > Broadcast sap e0 ui/C
>
> Now, I've looked at the following cases:
>
> kernel 2.2.15: No broadcasts.
> kernel 2.4.2-ac6 with Arnaldo's patch: Broadcasting.
> kernel 2.4.2-ac6 with Arnaldo's patch and including '&& 0' in the pprop
> code: No broadcasts.
humm, I'll look further and see if this is indeed a problem... Maybe its
real NetBios broadcasts being sent and normally broadcasted, Ok, I'll try
to cook up a patch later today and resend it here, if needed
> I started out with a clean 2.4.2 tree, applied the ac6 patch and Arnaldo's
> patch.
>
> - J.R. (Johannes Rinse de Jong btw. =) )
>
>
> > Em Thu, Mar 01, 2001 at 03:31:24PM +0000, Petr Vandrovec escreveu:
> > > On 28 Feb 01 at 21:22, Arnaldo Carvalho de Melo wrote:
> > > > Em Wed, Feb 28, 2001 at 09:54:52PM +0100, J.R. de Jong escreveu:
> > >
> > > > > phone call from the IT ppl. isn't very efficient. Moreover, I prefer
> > > > > testing at night so I won't be a bother to the network when ppl. are
> > > > > actually using it. I guess I need some monitoring tool like tcpdump
> > > > > (doesn't really provide any useful IPX output) or netdiag. Suggestions?
> > >
> > > Send 64 bytes of zeroes packet with source XXXXXXXX:YYYYYYYYYYYY/0455 to
> > > 00000000:FFFFFFFFFFFF/0455 [sipx_type=0x14]. All machines which respond
> > > and are not routers should be verified. And if broadcast storm does not
> > > cease to exist in few seconds, it is time to visit your routers and
> > > switches and hit poweroff button... And then ban all machines which
> > > participated as senders of these frames...
> >
> > Nice, I'm putting this on my TODO list: to create simple test utilities to
> > detect these cases, as a binary or as scripts that use existing packet
> > generating utilities coupled with tcpdump, of course, if there are
> > volunteers to do this, they're more than welcome 8)
> >
> > > > into account of Petr told us earlier, I think that I'm getting the grasp on
> > > > this pprop thing, sorry for being so slow 8)
> > >
> > > Patch looks OK.
> >
> > thanks for the review
> >
> > > > packet to make the protocol smart (the shared skb thing, related to tcpdump
> > > > being able to get the packet as they come thru the wire, with the protocol
> > > > stacks not changing it while in transit), now we don't change nothing in
> > >
> > > Can't we use skb_unshare()?
> >
> > probably, I'll check later today, after daytime job
> >
> > > > the received packets, maybe we need to change it before handing it up to
> > > > sock_queue_rcv_skb in ipxitf_def_skb_handler, well, I'm learning, lets see
> > > > if I manage to fully understand this before commiting any mistake 8) As
> > > > always, I'm all ears to people with more insight on net stacks, like Petr,
> > > > thats helping me a lot, thank you!
> > >
> > > I do not think that I have more insight on the net stacks in Linux.
> >
> > ok, ok, at least better than me at this point :) Anyway, thank you again
> > for the reviews and suggestions.
> >
> > > Best regards,
> > > Petr Vandrovec
> > > vandrove@vc.cvut.cz
> > >
> >
> > --
> >
> >
> > - Arnaldo
> >
>
> -
> : send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.kernel.org
--
- Arnaldo
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
