On Sat, May 5, 2018 at 10:57 AM, Uwe Kleine-König <u.kleine-koe...@pengutronix.de> wrote: > Hello, > > my eventual goal is to implement MRP and for that I started to program a > bit and stumbled over a problem I don't understand. > > For testing purposes I created a veth device pair (veth0 veth1), open a > socket for each of the devices and send packets around between them. In > tcpdump a typical package looks as follows: > > 10:36:34.755208 ae:a9:da:50:48:db (oui Unknown) > 01:15:e4:00:00:01 (oui > Unknown), ethertype Unknown (0x88e3), length 58: > 0x0000: 0001 0212 8000 aea9 da50 48db 0000 0000 .........PH..... > 0x0010: 0000 0589 40f2 6574 6800 0000 0000 0000 ....@.eth....... > 0x0020: 0000 0100 0a80 3d38 4c5e 0000 ......=8L^.. > > The socket to receive these packages is opened using: > > #define ETH_P_MRP 0x88e3 > > struct sockaddr_ll sa_ll = { > .sll_family = AF_PACKET, > .sll_protocol = htons(ETH_P_MRP), > .sll_ifindex = if_nametoindex("veth0") > }; > > fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_MRP)); > bind(fd, (struct sockaddr *)&sa_ll, sizeof(sa_ll)); > > So far everything works fine and I can receive the packets I send. > > If now I add veth0 to a bridge (e.g. > > ip link add br0 type bridge > ip link set dev veth0 master br0 > > ) and continue to send on veth1 and receive on veth0 I don't receive > the packets any more. The other direction (veth0 sending, veth1 > receiving) still works fine. > > Each of the following changes allow to > receive again: > > a) take veth0 out of the bridge > b) bind(2) the receiving socket to br0 instead of veth0 > c) use .sll_protocol = htons(ETH_P_ALL) for bind(2) > > In the end only c) could be sensible (because I need to know the port > the packet entered the stack and that might well be bridged), but I > wonder why .sll_protocol = htons(ETH_P_MRP) seems to do the right thing > for an unbridged device but not for a bridged one. > > Is this a bug or a feature I don't understand?
Packets are redirected to the bridge device in __netif_receive_skb_core at the rx_handler hook. This happens after packets are passed to packet types attached to list ptype_all, which includes packet sockets with protocol ETH_P_ALL. But before packets are passed to protocol specific packet types (and sockets) attached to ptype_base[].