On Tue, Aug 12, 2008 at 05:22:54PM -0400, der Mouse wrote: > I've just run into a case where IFF_SIMPLEX is interacting badly with > bridge(4). > > The setup: 4.0/i386. Two interfaces are in a bridge. One of them > (vr0) is simplex (IFF_SIMPLEX is set). An ARP request is received on > the other interface, generated by an external event. This packet is > bridged through to vr0. But ether_output on vr0 says "oh, this > interface is simplex and this packet is broadcast, we'll loop back a > copy". Thus, the barest instant later, vr0 receives a copy of the very > same packet. > > This causes the bridge to end up with the sending MAC address learnt on > vr0 rather than the interface it really is on. This then causes the > ARP reply, which is aimed at that MAC address, to go unbridged > (because, as far as the bridge is concerned, it was received on the > same interface it should go out on and thus shouldn't be bridged > anywhere). > > This leads to the obvious communication failure. > > Thoughts on what the correct fix is? Too quick and too little coffee for thoughts to that extent, but in the meantime an obvious quick workaround is to disable learning on that bridge port. A better fix might be some way to mark the copied packet for the same treatment, or do the analysis to decide whether its safe not to do the simplex copy in this case - when we know the packet isn't ours. -- Dan.
Attachment:
pgpsVJbmxt496.pgp
Description: PGP signature