Hello Michael,
On 17/07/19(Wed) 08:59, Michael Graves wrote: > I think I have found a possible regression introduced in if_bridge.c at > version 1.323. So the bug is not present at revision 1.322? > Using the following setup > > C1 ----------------- R1 ---------------------+ > (em1 - bridge0 - vxlan0 - em0 ) | > LAN > | > C2 ----------------- R2 ---------------------+ > (em1 - bridge0 - vxlan0 - em0 ) > > See https://marc.info/?l=openbsd-misc&m=156261409204575&w=2 for dmesg and > hostname.* information. > > C1 and C2 are connected to R1 and R2. Both R1 and R2 and OpenBSD 6.5. > vxlan0 on R1 and R2 is configured with a multicast destination address. When > C1 tries to ping C2 the ping succeeds however the encapsulated packet is > sent > to the multicast address address and not directly from R1 to R2. > > Trying to trace the problem down I think the issue is related to when the > mbuf > is passing thru bridgeintr_frame() it is not getting tagged as tunneled > traffic, thus the tunnel information stored in the bridge is not updating > the > destination address when the mbuf is processed by vxlan_output(). I understand your analysis. What I find strange is that bridge_copytag() wasn't call previously in bridgeintr_frame(). So I don't understand which issue/regression we are fixing. Do you? > > The diff below seems to correct this issue and was taken from the 6.5 > source. I am not sure it is the correct way to solve the issue. If there > is > better way to solve the issue I'm happy to assist and/or test. If I'm on > the > right track, I'm happy to submit a patch against 6.5-current. A diff against current would definitively help. > --- if_bridge.c.orig Sun Mar 31 08:59:38 2019 > +++ if_bridge.c Tue Jul 16 10:14:29 2019 > @@ -905,7 +905,7 @@ > * side of the bridge, drop it. > */ > if (!ETHER_IS_MULTICAST(eh.ether_dhost)) { > - dst_if = bridge_rtlookup(sc, dst, NULL); > + dst_if = bridge_rtlookup(sc, dst, m); > if (dst_if == src_if) { > m_freem(m); > return; >
