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? If someone wants to reproduce this locally, I can simplify my program and provide it here. I tested this on a Debian 4.15 kernel (x86), but also with the same symptoms on an arm64 with 4.16 and a dsa switch. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |