Bart De Schuymer <bdschuym@xxxxxxxxxx> writes: > On Monday 12 January 2004 22:02, Luke Gorrie wrote: > > Still, I find the current semantics of packet sockets on bridged ports > > pretty confusing. It took me a full day to figure out why I wasn't > > receiving the packets I wanted, even though tcpdump did. > > Well, that list for protocol-specific functions contains functions to deal > with the packet, e.g. route it. Obviously we don't want these functions to be > executed before the bridge code can have a look at it, so that's not very > confusing. I agree that dev.c is not confusing, but the PACKET(7) interface is. If you bind to ETH_P_ALL you will receive every packet, but if you bind to any other protocol you will only receive packets the bridge doesn't take. The manpage doesn't say anything about this, and one might actually want different semantics (as in my case). IMO it would be nicer to have an interface that treats "what protocol do I want to see" and "do I want bridged packets" as orthogonal. > If you really want to use the protocol-specific list for packets entering on a > bridge port, you can. Just use the ebtables brouting chain to "broute" the > packet, see the website. I guess you lose a little performance there, but you > shouldn't really feel it. I love ebtables and I'm using it extensively. But there is a limit to how much more logic I can push into it (not to mention iptables) before the whole thing becomes incomprehensible :-) In this case I have a simple program that wants to receive and send 802.3 packets on every physical port on the machine, irrespective of bridging, etc. The modified packet socket interface is a great match. .. but come to think of it, I'd better see what happens with packet sockets and the bonding driver too. Maybe it will spoil my fun. Cheers, Luke
