-
Notifications
You must be signed in to change notification settings - Fork 179
Description
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
- I have read the contributing guide lines at https://github.com/opnsense/src/blob/master/CONTRIBUTING.md
- I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/src/issues?q=is%3Aissue
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
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:
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
