On Tue, Dec 01, 2015 at 10:07:12AM +0100, Kazuya GODA wrote:
> Hi,
>
> It seems to bridge doesn't forward broadcast/multicast frames from gif.
> This pathc will fix this problem, so would you try it?
>
> Thanks,
>
> - Goda
>
that matches the behaviour of -r1.239 before the enqueue changes.
OK reyk@
> Index: net/if_bridge.c
> ===================================================================
> RCS file: /cvs/src/sys/net/if_bridge.c,v
> retrieving revision 1.270
> diff -u -p -r1.270 if_bridge.c
> --- net/if_bridge.c 7 Nov 2015 12:42:19 -0000 1.270
> +++ net/if_bridge.c 1 Dec 2015 08:44:42 -0000
> @@ -1337,18 +1337,21 @@ bridge_process(struct ifnet *ifp, struct
> if (mc == NULL)
> goto reenqueue;
>
> - bridge_ifinput(ifp, mc);
> #if NGIF > 0
> if (ifp->if_type == IFT_GIF) {
> TAILQ_FOREACH(ifl, &sc->sc_iflist, next) {
> if (ifl->ifp->if_type != IFT_ETHER)
> continue;
>
> - bridge_ifinput(ifl->ifp, m);
> - return;
> + bridge_ifinput(ifl->ifp, mc);
> + break;
> }
> - }
> + if (!ifl)
> + m_freem(mc);
> + } else
> #endif /* NGIF */
> + bridge_ifinput(ifp, mc);
> +
> bridgeintr_frame(sc, ifp, m);
> return;
> }
>
>
>
>
> On 2015/11/28 15:33, Rolf Sommerhalder wrote:
> >Using the simple Layer-2 bridge setup below, an ICMP Ping 172.17.1.5
> >from HostA does not get to HostB while using EtherIP encapsulation with
> >gif(4) at its tunnel end points.
> >
> >The Ping's initial Ethernet broadcasts with the ARP Requests make it
> >through the gif tunnel to BridgeB, to both its bridge0 and vio2
> >interfaces (check with tcpdump, tshark).
> >
> >However, vio2 never re-broadcasts those ARP Requests on the wire to
> >HostB!? E.g. the physical egress interface vio2, which is member of a
> >bridge(4) on BridgeB, receives the ARP Requests, but it fails
> >re-broadcast them to HostB so that Host could answer with ARP Reponses.
> >
> >Also, BridgeB does not learn the source MAC from HostA (and of course it
> >can not learn the MAC of HostB, because ARP Requests never get there).
> >
> >However, pinging the (numbered) vio2 on BridgeB succeeds (Ping
> >172.17.1.2 from HostA), e.g. the gif tunnel is OK.
> >
> >Also, HostA can ping HostB after removal of the gif tunnel, e.g. after
> >deleting gif0 from bridge0 on both BridgeA and BridgeB, and adding vio1
> >to them instead.
> >
> >Testing conditions:
> >- default installs of OpenBSD i386 snapshot from yesterday
> >- pf is disabled
> >- no L2 filter rules on the bridge member interfaces
> >- set sysctl net.inet.etherip.allow=1 to enable EtherIP on gif()
> >- the observation is the same on both VirtualBox with vio() interfaces,
> >as well as on a real hardware with APU2 that have em() interfaces.
> >
> >Currently, experimenting with pf enabled on BridgeB, I found that ARP
> >Requests apparently do not generate state with a very basic rule-set,
> >such as 'pass log all'.
> >
> >What did I miss? Or, is there "just a bug" in the gif/bridge combo that
> >is haunting me?
> >Would it be worthwhile to try with -stable or an older version of
> >OpenBSD? Years ago, I had such a setup working with 4.3, and I can make
> >configuration files available (although they are very minimal, mostly
> >running default install) ...
> >
> >Thanks for any hints and suggestions!
> >Rolf
> >
> >
> >*HostA*
> >vio1 172.16.0.5/22
> > |
> > v
> >vio2 172.16.0.2/22
> >*BridgeA*
> >bridge0 add vio2 add gif0
> >gif0 tunnel 10.10.1.2 10.10.1.3
> >vio1 10.10.1.2/24
> > |
> > v
> >vio1 10.10.1.3/24
> >gif0 tunnel 10.10.1.3 10.10.1.2
> >bridge0 add vio2 add gif0
> >*BridgeB*
> >vio2 172.16.1.2/22
> > |
> > v
> >vio1 172.16.1.5/22
> >*HostB*
>
--
