lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 18 Apr 2007 16:05:27 -0700
From:	"Laurent Chavey" <chavey@...gle.com>
To:	netdev@...r.kernel.org
Subject: AF_PACKET how to get the original netdev from a packet received from a bonded master

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.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists