https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270559
--- Comment #15 from b...@desync.com ---
(In reply to Kristof Provost from comment #14)
Sure. My apologies for being overly terse.
Create a bridge with IP address:
# ifconfig bridge create up
bridge0
# ifconfig bridge0 inet 10.0.0.1/30
Add an epair with the other end in a jail so we have something to ping:
# ifconfig epair create up
epair0a
# ifconfig bridge0 addm epair0a
# jail -ic persist vnet=new
1
# ifconfig epair0b vnet 1
# ifconfig -j 1 epair0b inet 10.0.0.2/30 up
# ifconfig -j 1 epair0b | grep ether
ether 02:9d:22:b7:0a:0b
Start a ping and verify that the bridge learns the destination address:
# ping -q 10.0.0.2 &
# ifconfig bridge0 addr
02:9d:22:b7:0a:0b Vlan0 epair0a 1200 flags=0<>
Add some other interface to the bridge:
# ifconfig tap create up
tap0
# ifconfig bridge0 addm tap0
# cat /dev/tap0 >/dev/null &
See that unicast packets are being unexpectedly flooded to tap0 despite the
bridge table entry for the destination MAC:
# tcpdump -eni tap0
00:30:52.296892 58:9c:fc:00:ed:c1 > 02:9d:22:b7:0a:0b, ethertype IPv4 (0x0800),
length 98: 10.0.0.1 > 10.0.0.2: ICMP echo request, id 1572, seq 420, length 64
This fixes it for me:
diff --git a/sys/net/if_bridge.c b/sys/net/if_bridge.c
index d93bddf71ccb..9896c7a57191 100644
--- a/sys/net/if_bridge.c
+++ b/sys/net/if_bridge.c
@@ -2279,7 +2279,7 @@ bridge_transmit(struct ifnet *ifp, struct mbuf *m)
eh = mtod(m, struct ether_header *);
if (((m->m_flags & (M_BCAST|M_MCAST)) == 0) &&
- (dst_if = bridge_rtlookup(sc, eh->ether_dhost, 1)) != NULL) {
+ (dst_if = bridge_rtlookup(sc, eh->ether_dhost, DOT1Q_VID_NULL)) !=
NULL) {
error = bridge_enqueue(sc, dst_if, m);
} else
bridge_broadcast(sc, ifp, m, 0);
Thank you!
--
You are receiving this mail because:
You are the assignee for the bug.
