bridge(4) behaviour

[r***@fdy2.demon.co.uk]

Does anyone know which use cases the following code from
bridge_input() is supposed to handle ?


/* We just received a packet that we sent out. */
if (memcmp(CLLADDR(bif->bif_ifp->if_sadl), eh->ether_shost,
ETHER_ADDR_LEN) == 0
#if NCARP > 0
|| (bif->bif_ifp->if_carp && carp_ourether(bif->bif_ifp->if_
carp,
eh, IFT_ETHER, 1) != NULL)
#endif /* NCARP > 0 */
) {
m_freem(m);
return (NULL);
}

This test is within a loop for all the members of the bridge, there is
a test just before this one that provides a fast path between bridge
members for input packets.

The problem is that the second test can match and the packet will be
dropped if the source interface is earlier in the list than the target
one.

I ran into this as I was sending packets through a tap(4) interface
with the source address that of the tap device itself.

Maybe the man page for tap(4) should be changed to suggest that
changing it's link address is probably a bad idea and that programs
using tap(4) need to pick a different ethernet address from that of
the tap interface.

Robert Swindells

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matthew Mondor]

On Fri, 22 Jul 2011 12:43:12 +0100 (BST)

Post by r***@fdy2.demon.co.uk
Maybe the man page for tap(4) should be changed to suggest that
changing it's link address is probably a bad idea and that programs
using tap(4) need to pick a different ethernet address from that of
the tap interface.

I also had problems with tap(4)+bridge(4) for some configurations, I
should really check if this is also the cause...