Repository navigation
fix(link): Ethernet and VLAN drop trailing bytes beyond an IPv4 payload on rebuild #1209
Description
Describe the bug
ethernet.py:138 and vlan.py:166 hand the whole remainder of the frame to the next layer. IPv4 consumes only its Total Length. The leftover octets, such as the minimum-frame padding, are kept by no info, so from_data drops them. S_Tag takes the same path.
To Reproduce
The 60-octet frame 00112233445566778899aabb0800 + 4500001c000100004011f97d7f0000017f0000010035003500080000 + 18×00 rebuilds as only 42 octets. The same frame behind a C-Tag rebuilds as 46 of its 60.
Expected behavior
The trailer octets are recorded, for example as a trailer field, and re-emitted, so the frame rebuilds byte-exactly. The IPv4 side of this, where the layer's own .data holds 46 octets but rebuilds as 28, may overlap the internet-v4 audit.
Found by the link round-trip audit (#1202) and re-run by me on main at 630f0a581.
Activity
JarryShaw commentedon Oct 7, 2026
Blocked until the internet-v4 round-trip audit reports. The IPv4 half of this (the layer's own
.dataholds 46 octets but rebuilds as 28) may share a root cause, and the fix should land on the right side.JarryShaw commentedon Oct 7, 2026
IPv4 side confirmed by the internet-v4 audit:
45000018…+61626364+ 6×00rebuilds without the 6 octets past Total Length (44 octets in, 38 out). The IPv6 Payload-Length case does the same (50 → 48). Both belong with this issue.JarryShaw commentedon Oct 8, 2026
Unblocked: the internet-v4 audit confirmed this issue's IPv4 case and its IPv6 sibling. Re-measured on
a8cc02594: a 60-octet frame still rebuilds as 42. A worker is on it now, on branchfix/1209-link-trailer-kept.fix(ipv4,ipv6)!: keep the octets past Total Length or Payload Length …
fix(l2tpv2,ospf)!: keep the octets past the Length field as captured (#…
fix(l2tpv2,ospf)!: keep the octets past the Length field as captured (#…
fix(udp)!: keep the octets past the UDP Length field as captured (#1461)