On Thu, Oct 01, 2026 at 10:19:55AM +0000, [email protected] wrote: > For an untagged packet this helper saves vlan_proto = 0. The consumer only > ever sets a tag and never clears one: [...] > So would fragments 2..N reach br_nf_push_frag_xmit()->br_dev_queue_push_xmit() > with their ingress 802.1Q/802.1ad tag still set, while the first fragment > goes out untagged?
Yes. Conntrack defrag keeps the original fragments on frag_list for both IPv6 and IPv4 here (ip_frag_coalesce_ok() is true only for local delivery), each with its ingress tag, and br_handle_vlan() clears the tag of the head skb only. On the fast path those skbs are sent as the fragments. I extended my reproducer with a port that is untagged in VLAN 10 and a static FDB entry, so the packet is not cloned. With this patch applied, 6/9 IPv6 and 6/9 IPv4 fragments left that port with "vlan 10"; only the first fragment of each packet was untagged. This is not introduced by this patch, but it means the changelog claim was too broad. v2 will add a second patch that clears the tag in br_nf_push_frag_xmit() when none was saved, as nf_ct_bridge_frag_restore() does, and narrow the changelog of this one to the fragments ip6_fragment() builds. The BR_VLAN_TUNNEL case does not reach the refragmentation code: br_handle_egress_vlan_tunnel() attaches a metadata dst, so br_nf_dev_queue_xmit() drops the packet at the !skb_valid_dst() check. > Also, the comment "Fragments may not inherit the MAC header or VLAN tag" > does not seem accurate for reused frag_list skbs, which keep their own tag. Agreed, v2 rewords it. pw-bot: cr Thanks, Andrea
