fix(toolkit): the pypcapfile engine accepts IPv4 headers whose options the default engine rejects #1596
Description
With engine='pypcapfile', an IPv4 header whose options the default engine rejects still produces IPv4 and TCP input, so TCP reassembly and tracing include the frame.
Repro on main (e9f3340f7), Python 3.11, pypcapfile 0.12.0: Ethernet + IPv4 with IHL 6 + TCP carrying data. I tried three option bytes:
| IPv4 options | Default engine | pypcapfile |
|---|---|---|
valid NOP×4 |
1 TCP datagram | 1 TCP datagram |
| option 7 with length 1 (malformed) | 0 | 1 |
| option 7 whose length runs past the header | 0 | 1 |
Cause: pcapfile's IP decoder never parses the options. _network in pcapkit/toolkit/pypcapfile.py accepts the header as it is, while the default engine's IPv4 option parser rejects these headers.
Expected: the same IPv4 and TCP inputs as the default engine, i.e. none for a header with malformed options. Failing that, a decode warning.
Found by the #1575 round-3 cross-review fuzz, which saw 272–290 TCP cases per 2,500 frames. I reproduced it independently. Blocked until #1575 merges, because the fix is in the same file.
Activity
JarryShaw commentedon Oct 10, 2026
Work has started ahead of #1575 merging, together with #1590–#1593 and #1596 because all five are in the same
pypcapfile.pyheader walk. It is on a branch built on #1575's head1de91947b. The PR opens, rebased ontomain, once #1575 merges.fix(toolkit): pypcapfile checks IPv4 and TCP headers as the default e…
fix(toolkit): pypcapfile checks IPv4 and TCP headers as the default e…
fix(toolkit): pypcapfile checks IPv4 and TCP headers as the default e…