AF_PACKET how to get the original netdev from a packet received from a bonded master

AF_PACKET how to get the original netdev from a packet received from a bonded master

[Laurent Chavey]

When using PF_PACKET socket with bonded interfaces, there is no
way to get the slave interface (physical interface) the packet was
actually received on.

It looks like  there isn't a way to pass the original device {see
packet_rcv() in ./net/packet/af_packet.c} to the socket reader.
When an interface is bounded, dev, by the time it reaches this function,
points to the the bonding interface not the Ethernet interface the packet
was receive on.  sockaddr_ll does not contain any fields that could be use to
pass the original device in.  As such there is no ways for an application
that is interested on the "physical interface" the packet was received on,
to get the information when running a bond (one that uses the same mac address
for all of its slave).


observation,
if one uses tcpdump on a bonded slave, only egress packets are taped.
if one uses tcpdump on a bonded master, ingress packets are taped, egress
packets are taped

from the above, it would make sense to have the same behavior on ingress/egress
for both slave and master. the later would require the taped packet be
"duplicated"
at packet_rcv() and passed up to the socket layer as two copies
   - one associated with the master dev
   - one associated with the slave dev.

Re: AF_PACKET how to get the original netdev from a packet received from a bonded master

[David Miller]

From: "Laurent Chavey" <chavey@google.com>
Date: Wed, 18 Apr 2007 16:05:27 -0700

> When using PF_PACKET socket with bonded interfaces, there is no
> way to get the slave interface (physical interface) the packet was
> actually received on.

That's right.

There isn't a real good solution to this problem either.
Decapsulation can happen to arbitrary levels, how many
devices should we remember and how to do the reference
counting on that correctly?

As such, I don't think this will ever be provided.

Re: AF_PACKET how to get the original netdev from a packet received from a bonded master

[Chris Leech]

On 4/18/07, David Miller <davem@davemloft.net> wrote:
> Ok, it will give you one level of decapsulation.
>
> What do we tell people who want 2 devices previous? :-)

I can tell you that the intent of PJs patch was to provide the ifindex
of the physical interface that a packet entered the system on,
regardless of how many layers of encapsulation are involved.

Of course it may not actually do that ...

Re: AF_PACKET how to get the original netdev from a packet received from a bonded master

[David Miller]

From: "Chris Leech" <chris.leech@gmail.com>
Date: Wed, 18 Apr 2007 17:17:45 -0700

> On 4/18/07, David Miller <davem@davemloft.net> wrote:
> > Ok, it will give you one level of decapsulation.
> >
> > What do we tell people who want 2 devices previous? :-)
> 
> I can tell you that the intent of PJs patch was to provide the ifindex
> of the physical interface that a packet entered the system on,
> regardless of how many layers of encapsulation are involved.
> 
> Of course it may not actually do that ...

Ok, I'll try to remember to high-priority reviewing PJ's patch
on my next rebase of the net-2.6.22 tree which should be
tonight or tomorrow sometime.

Re: AF_PACKET how to get the original netdev from a packet received from a bonded master

[Chris Leech]

On 4/18/07, David Miller <davem@davemloft.net> wrote:

> Ok, I'll try to remember to high-priority reviewing PJ's patch
> on my next rebase of the net-2.6.22 tree which should be
> tonight or tomorrow sometime.

Thanks Dave, PJ is offline this week so I'm trying to keep an eye out
for discussions related to his various patches :-)

Just to give you an idea of our motivation around this, we're looking
at layer 2 configuration protocols implemented from user space.  As an
example Link Layer Discovery Protocol could be used to detect trunking
misconfiguration, but only if you can track that information for the
underlying interfaces of a bond.  Things like 802.1x authenticated
links in a bond would have a similar issue of needing to configure
each underlying interface before bringing up the bond, but with LLDP
there's the added fun of being able to receive updated notifications
of configuration changes from the link partner at any time.

- Chris

Re: AF_PACKET how to get the original netdev from a packet received from a bonded master

[Chris Friesen]

Chris Leech wrote:

> Just to give you an idea of our motivation around this, we're looking
> at layer 2 configuration protocols implemented from user space.

I'd like to second the intent of this patch.  We've been maintaining a 
patch against 2.6.10 for a while now that exports the original ingress 
device to userspace via ancilliary data.  We use it in combination with 
bonding.

Was never submitted to mainline because we're on an old kernel.

Chris

Re: AF_PACKET how to get the original netdev from a packet received from a bonded master

[Laurent Chavey]

Thank you for the pointer, I am looking at the patch ad
see if it help. In my case, that will do the trick, but as mentioned
by Dave it may not have its place in a general distro.

Perso I would rather "cloning" <-- do not flame me, it is not my intent to
                                                 open a long thread :-)
          the skb received on the bond and pass the clone + original skb
          to the tap. This gives a "symetrical" behavior to the tap...

Some of the point made for LLDP etc... may not require this
patch if one adds the processing as a protocol.

Thank you.

On 4/18/07, Chris Leech <chris.leech@gmail.com> wrote:
> On 4/18/07, David Miller <davem@davemloft.net> wrote:
> > From: "Laurent Chavey" <chavey@google.com>
> > Date: Wed, 18 Apr 2007 16:05:27 -0700
> >
> > > When using PF_PACKET socket with bonded interfaces, there is no
> > > way to get the slave interface (physical interface) the packet was
> > > actually received on.
> >
> > That's right.
> >
> > There isn't a real good solution to this problem either.
> > Decapsulation can happen to arbitrary levels, how many
> > devices should we remember and how to do the reference
> > counting on that correctly?
> >
> > As such, I don't think this will ever be provided.
>
> PJ Waskiewicz posted a patch that introduced a new socket option for
> PF_PACKET sockets to return the orig_dev->ifindex instead of
> dev->ifindex in sockaddr_ll.  He posted the patch on  March 8th.
>
> http://marc.info/?l=linux-kernel&m=117340678318939&w=2
>
> He also re-posted it on March 19th, at which point you (Dave) told him
> that it was in your backlog and he didn't need to keep resending it.
>
> To me it's seem like a decent opt-in solution for applications that
> might care, without changing existing behavior.  Laurent, would that
> change help you?  Dave, is there a reason you can see why this
> wouldn't work?
>
> - Chris
>