Date: Mon, 10 Apr 2023 07:24:17 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 270559] if_bridge: does not forward packets properly for vlan 1 Message-ID: <bug-270559-7501-ktiapoE0du@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-270559-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-270559-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270559 --- Comment #8 from Philip Paeps <philip@FreeBSD.org> --- Our if_bridge(4) really only implements the learning and forwarding parts of the original 802.1D standard. It's really only aware of VLANs because if_vlan(4) puts the relevant tags in the mbuf. It does not try to be a complete implementation of 802.1Q-2014 (which incorporates bridging, VLANs = and some other stuff). The comment introducing the VLANTAGOF(_m) macro is a little confusing if th= is patch is applied as-is. I'm also not convinced that this change is correct= .=20 VLAN 0 is not a valid VID but it's perfectly possible for a dot1q tag with VID=3D0 to appear on the wire: it indicates untagged traffic with a PCP or = the DEI bit set. I wonder if we should use 0xFFF rather than 0 as the magic number for untag= ged frames. 0xFFF is reserved in 802.1Q-2014 for implementation use. Did either of you test what happens if a packet with a dot1q header that on= ly contains a PCP and not a VID gets forwarded? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-270559-7501-ktiapoE0du>