Good day. The attached patch fixes incoming interface for pf(4) processing in the case of bridging of multiple VLAN interfaces which have the same parent iface and unicast packets destined to the bridge member: we can't rely solely on the destination MAC in determining proper incoming interface.
Can it be reviewed and possibly applied? It was verified in my production environment. Thanks. -- rea
>From b7c4009fc4e85acc7a99a6a5b8a5fbf283137612 Mon Sep 17 00:00:00 2001 From: Eygene Ryabinkin <[email protected]> Date: Thu, 6 Jun 2019 09:40:06 +0300 Subject: [PATCH 1/2] bridge(4): filter locally-destined packets on the proper interface When vlan(4) interfaces are used as the bridge members, they share the MAC of their parent ifs. Thus, when multiple VLANs with the same parent interface are bridged (for filtering), they will all have the same MAC and MAC-based strategy for indentification of locally-destined traffic may pick the wrong interface for pf(4) processing. Actually, it will use the most recently added interface with the packet's destination MAC. As we know the incoming interface for bridge_process(), check if it has the packet's destination MAC and use it for bridge_input() when the check succeeds. Signed-off-by: Eygene Ryabinkin <[email protected]> --- sys/net/if_bridge.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sys/net/if_bridge.c b/sys/net/if_bridge.c index 1d178dc4d22..d64bdc05abb 100644 --- a/sys/net/if_bridge.c +++ b/sys/net/if_bridge.c @@ -1217,7 +1217,13 @@ bridge_process(struct ifnet *ifp, struct mbuf *m) brifp->if_ipackets++; brifp->if_ibytes += m->m_pkthdr.len; - ifp = bif->ifp; + /* + * Give the original input interface + * a chance to be the input one. + */ + if (!bridge_ourether(ifp, eh->ether_dhost)) { + ifp = bif->ifp; + } goto reenqueue; } if (bridge_ourether(bif->ifp, eh->ether_shost)) -- 2.21.0
