Skip to content

axgbe: fragment drops for outbound VLAN-tagged packets #266

@swhite2

Description

@swhite2

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

Describe the bug

In a default OPNsense setup (all hardware offloading disabled), VLAN-tagged packets that need to be fragmented over axgbe will have the first fragment dropped if VLAN tagging is disabled.

The attached packet captures show that the problem isn't necessarily the size of the packets, but rather the fact that they are fragmented, as in both cases the first packet is exactly 1518 bytes (data (1472) + IP (20) + ICMP (8) + ether (14) + VLAN (4)). They also show that the latter fragment is received by the client.

To Reproduce

Consider two hosts routing through OPNsense with a simple 1473 byte ping (WAN on ax0_vlan288 <-> LAN). The request is tagged by a switch and sent up the ax0_vlan288 interface, which routes it to the LAN interface. The reply is handled correctly on the LAN interface, packet captures show the reply both on the VLAN and the physical parent ax0 interface, however the first fragment never reaches the original host.

Expected behavior

For VLAN-tagged fragments to be handled correctly.

Describe alternatives you considered

Enabling VLAN HW tagging (# ifconfig ax0 vlanhwtag) works around this issue.

Screenshots and relevant log files

When fragmenting:

ping 10.0.0.2 -s 1473

Client:
Image

ax0 (parent of ax0_vlan288):

# tcpdump -ni ax0 -e -vvv vlan

13:51:06.728937 mac-a > mac-b, ethertype 802.1Q (0x8100), length 1518: vlan 288, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, id 25503, offset 0, flags [+], proto ICMP (1), length 1500)
    192.168.0.1 > 10.0.0.2: ICMP echo request, id 45329, seq 1, length 1480
13:51:06.728943 mac-a > mac-b, ethertype 802.1Q (0x8100), length 64: vlan 288, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, id 25503, offset 1480, flags [none], proto ICMP (1), length 21)
    192.168.0.1 > 10.0.0.2: ip-proto-1
13:51:06.728970 mac-b > mac-a, ethertype 802.1Q (0x8100), length 1518: vlan 288, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 63, id 21539, offset 0, flags [+], proto ICMP (1), length 1500)
    10.0.0.2 > 192.168.0.1: ICMP echo reply, id 45329, seq 1, length 1480
13:51:06.728975 mac-b > mac-a, ethertype 802.1Q (0x8100), length 64: vlan 288, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 63, id 21539, offset 1480, flags [none], proto ICMP (1), length 21)
    10.0.0.2 > 192.168.0.1: ip-proto-1

No fragmentation:

ping 10.0.0.2 -s 1472:

Client:
Image

ax0 (parent of ax0_vlan288):

# tcpdump -ni ax0 -e -vvv vlan

14:07:54.280673 mac-a > mac-b, ethertype 802.1Q (0x8100), length 1518: vlan 288, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, id 16722, offset 0, flags [none], proto ICMP (1), length 1500)
    192.168.0.1 > 10.0.0.2: ICMP echo request, id 2322, seq 1, length 1480
14:07:54.280692 mac-b > mac-a, ethertype 802.1Q (0x8100), length 1518: vlan 288, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 63, id 10402, offset 0, flags [none], proto ICMP (1), length 1500)
    10.0.0.2 > 192.168.0.1: ICMP echo reply, id 2322, seq 1, length 1480

Additional context

Interestingly, the axgbe driver interprets "VLAN hardware tagging" as VLAN stripping. One would expect stripping to only apply to the receive side.

Environment

Software version used and hardware type if relevant, e.g.:

OPNsense 25.7 (amd64)
DEC840

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions