Ahoy,
I've encountered some confusing semantics with using PACKET(7) sockets
on bridge-enslaved interfaces. Specifically, if my socket accepts all
types of frame (bind() to ETH_P_ALL) then it gets all packets; but if
it accepts any specific type (e.g. ETH_P_IP), then it receives no
packets at all.
That is how it's coded in net/core/dev.c's netif_receive_skb(). First
ETH_P_ALL handlers are called, then the bridge, and then -- only if
the bridge declines the packet -- the protocol-specific handlers are
called.
My interpretation is that ETH_P_ALL handlers are expected to be
programs like tcpdump which can safely be fed all packets, whereas
more specific handlers are expected to be actual protocol
implementations that shouldn't run directly on enslaved ports.
Is that correct?
In my case I am implementing a specific protocol in userspace (via
PACKET-socket) and this protocol must run directly on enslaved
ports. It's an old layer-2 neighbour-discovery protocol that has to
operate on physical ports, below other abstractions like
bridges. ("don't ask.") It looks like I can't do this today,
unless I
use ETH_P_ALL, perhaps with a BPF filter -- but I'm fearful of
introducing overhead on all packets.
I was thinking of adding an extra hashtable in dev.c, like ptype_base
but processed before offering packets to the bridge. Then an ioctl to
have a PACKET-socket moved into this table if it's supposed to receive
packets on enslaved interfaces.
Does that sound like a good solution?
Cheers,
Luke
On Monday 05 January 2004 23:33, Luke Gorrie wrote:> My interpretation is that ETH_P_ALL handlers are expected to be > programs like tcpdump which can safely be fed all packets, whereas > more specific handlers are expected to be actual protocol > implementations that shouldn't run directly on enslaved ports. > > Is that correct?Well, with the ebtables BROUTING chain it is possible to have an enslaved port as input device for the protocol handlers. In the case of IP, to make any sense, this enslaved port should then have its own IP address.> In my case I am implementing a specific protocol in userspace (via > PACKET-socket) and this protocol must run directly on enslaved > ports. It's an old layer-2 neighbour-discovery protocol that has to > operate on physical ports, below other abstractions like > bridges. ("don't ask.") It looks like I can't do this today, unless I > use ETH_P_ALL, perhaps with a BPF filter -- but I'm fearful of > introducing overhead on all packets.Well, if you're sending all IP packets to userspace I doubt that's faster than an ebtables kernel module...> I was thinking of adding an extra hashtable in dev.c, like ptype_base > but processed before offering packets to the bridge. Then an ioctl to > have a PACKET-socket moved into this table if it's supposed to receive > packets on enslaved interfaces. > > Does that sound like a good solution?I don't know the details, but can't you hook some kernel function onto ETH_P_ALL that only sends IP packets to userspace? cheers, Bart
On Tuesday 13 January 2004 12:41:55 -0800, Bart De Schuymer wrote:> Reading the man page is indeed confusing for a user, w.r.t. bridge ports. > I think it would be more logical if all PF_PACKET > sockets see the frames before the bridge code.I agree. I just ran into this problem trying to read bridge PDUs from a daemon listening on a packet socket. I'm glad I found this thread; it saved me a lot of debugging time.> How about placing the call to __handle_bridge() right after the second > list_for_each? If I'm not mistaken the relevant pt_pre->func that woulddeal> with the packet will not have been executed yet, while those PF_PACKET > functions will already have been called...Has anyone tested this in the two weeks since it was suggested? -- Dan Eble <dane@aiinet.com> _____ . | _ |/| Applied Innovation Inc. | |_| | | "All Protocols MUST be odd" http://www.aiinet.com/ |__/|_|_| -- RFC 1661 (PPP)