Repository navigation
fix(protocols): a capture cut inside the IPv4 header rebuilds with a fabricated UDP header - #1169
Conversation
…fabricated UDP header IPv4.read handed the next layer the declared payload length even when the capture held no payload octets, so the next layer was parsed from an empty stream into an all-zero header that from_data then rebuilt. With nothing captured past the header the length is now 0, which makes the payload a NoPayload, as for any other empty payload. Closes #1167
|
Cross-review verdict on
|
|
Coverage: 88.88% (unit tier, Python 3.14,
Per-file detail: the |
make pylint,make mypy,make isort) — pylint and isort run onipv4.pywith nothing new; mypy not runmake testpasses, and a test case covers the change — the new module,test_ipv4_unit,test_ip_runtime,test_internet_unit,test_declared_length_roundtrip_runtime,test_tcp_udp_unit,test_option_roundtrip_unit,tests/projectdocs/source/changelog/and regeneratedCHANGELOG.md, if the change is user-visible — N/A, added centrally after the waveWhat is the purpose of your pull request?
fix— corrects a defectDescription of your pull request and other information
Closes #1167.
Root cause:
IPv4.read, not the rebuild. It passed the declaredlen - hdr_len(280) to_decode_next_layerwhile 0 payload octets were captured._import_next_layerpicksNoPayloadonly whenlength == 0, so UDP was parsed from an empty stream into an all-zero header, andfrom_datarebuilt those 8 octets faithfully. Now, when nothing was captured past the header, the length is 0 and the payload is aNoPayload.test.pcapngframe 3,IPv4.from_data(ip.info).data: before…ffff+0000+ 8 ×00(28 octets, chainIPv4:UDP:Raw), after…ffff0000(20 octets, chainIPv4). The last 2 octets are the zeros the parse already put intodst(255.255.0.0).Sweep over
examples/captures/(from_datavs parsed, header-isolated / full): IPv4 1/1 → 1/1, UDP 1/1 → 0/0 (104 → 103 layers), IPv6 0/183 → 0/183. Nothing new mismatches.Reverting the fix:
2 failed, 1 passed. With it:3 passed.