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. 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
