(Sorry this isn't an actual reply and is missing context -- I wasn't on the list when it was originally posted.)
Simon and I have been in touch about this, and I thought I'd share my findings for what they're worth. The problem is from the commit Simon mentioned (796223f5bc3a4896e6398733c798390158479400). Specifically, it's in netdev-linux.c in netdev_linux_send(). The new version always sends using the "sender" socket made by af_packet_sock() unless the interface is a tap, in which case it sends it using the tap fd. This differs from the old version which sent using whatever was in the fd field of the netdev if it was available. For tap interfaces, this was the tap fd, so the result was the same as it is now. But for other interfaces, this held the socket opened for receiving if the interface was listening (which was maybe never "right" in some sense and isn't convenient anymore since this socket descriptor is no longer stored in the non-rx netdev). The comments indicate that the exception is made for tap interfaces since writing to a tap interface with an AF_PACKET socket results in receiving the packet you just wrote. However, I don't think this behavior is limited to taps. Since the old version of the code sent and received with the same socket descriptor, I think the loop was fixed by the check in dev_queue_xmit_nit() in net/core/dev.c. Since they're two different socket descriptors now, this no longer works and you get the loop. I fixed it (I think) by adding a BPF packet filter on the rx socket so that it only receives incoming packets. There's probably a better fix, but you're welcome to the patch if you want it. -- Murphy _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
