fix(toolkit): scapy reads IP and TCP only in layers the default engine dissects (#1635, #1636)

[JarryShaw]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly

• Put an x into all the boxes [ ] relevant to your pull request (like that [x])

• Use Preview tab to see how your pull request will actually look like

• Searched for similar pull requests

• Followed the coding style (make pylint, make mypy, make isort)

• make test passes, and a test case covers the change

• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible — N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

Tick the commit type your subject line carries.

• fix — corrects a defect
• feat — adds a feature
• perf — changes performance, not behaviour
• refactor — changes neither behaviour nor performance
• test — tests only
• docs — documentation only
• ci — workflows or build tooling
• release — bumps the version or rolls up a distribution
• chore — anything else

---

Description of your pull request and other information

#1635. ipv6_reassembly took packet['IPv6'], which can sit in an ICMP quote, a later IPv4 fragment, GRE or VXLAN, then IPv6ExtHdrFragment in ipv6 searched past the chain into the packet inside. It now takes the first IPv6 layer the default engine dissects (_first_ipv6, pcapkit/toolkit/scapy.py:492) and a Fragment header only from that layer's own chain (_fragment_header, :520; used at :762). The issue's "within #1609's bound" clause is not met here and stays with #1609: neither function counts headers against the 32 bound. With n Hop-by-Hop headers then a Fragment header, n = 32 or 33, the default engine gives 0 IPv6 inputs and scapy and dpkt give 2, before and after.

#1636. _tcp_carrier and _first_ipv4 stepped over every layer that is not IP. _carries (:389) now lets a walk past the first layer, a VLAN tag, IP or an extension header only, and drops a rejected IPv4 header or a later IPv4 fragment as before. _dissected (:436) feeds _first_ipv4 and _first_ipv6, and _tcp_carrier checks each layer (:634).

Measured on 3.14 (scapy 2.7.0) and 3.11 (scapy 2.8.0): scapy was wrong in 7 of #1635's 9 rows and 9 of #1636's 10; all now match the default engine. A probe of 13 #1609/#1626 rows gives identical scapy cells before and after.

New tests/toolkit/test_scapy_ipv6_fragment_and_encap_walk_1635_1636_unit.py: 21 TCP and 25 IP-fragment cases against the default engine, six link types, and packets built by hand. Reverting pcapkit/ fails 5 of its 6 tests on both Pythons (pytest 10 failed, 2 passed, one subtest per link type). Before the fix scapy disagreed on 14 TCP, 12 IPv6 and 8 IPv4 cases and all six link types.

Also changed, each now matching the default engine:

• 6in6 behind AH with the inner packet fragmented gives no IPv6 input;
• at IEEE802_11 (105), IEEE802_11_RADIOTAP (127), PPI (192), PPP (9) and PPP_HDLC (50) with ff 03, and PPP_ETHER (51), scapy handed TCP over IPv4 and IPv6 to reassembly and tracing, and both fragments of an IPv4 and of an IPv6 datagram to IP reassembly, and now hands over none, as the default engine leaves those link types raw. This is user-visible for Wi-Fi captures. It is a side effect of _carries(root=True) letting exactly one layer through: there scapy dissects a second layer before IP (802.11, LLC or PPP), which is no VLAN tag, IP or extension header. The new test pins all six.

Not fixed here, identical before and after:

• the first layer, which the link type selects, is still taken to carry whatever scapy dissects in it (fix(toolkit): scapy reads link types the default engine leaves raw, and IPv6 at the wrong BSD loopback families #1650). Scapy reads TCP and IP fragments in LINUX_SLL (113), LINUX_SLL2 (276), PPP (9) without ff 03, link type 12, and NULL (0) or LOOP (108) frames carrying IPv6 at the Linux AF_INET6 value 10. The default engine reads none of them. Scapy also misses IPv6 the default engine reads, at the BSD values 24, 28 and 30 in both NULL and LOOP frames;
• IPv4, Hop-by-Hop, IPv6 fragments: default 2 IPv6 inputs, scapy 0.

Closes #1635
Closes #1636

[JarryShaw]

Verdict: GOOD TO GO at f6e6fe60c. Sonnet cross-review, three rounds. Rounds 1 and 2 fixed the PR body and pinned the 802.11/PPI/PPP link-type side effect with a test. Round 3 found nothing wrong in the code or tests and asked only for body text, which I have applied.

Round 3's checks: 10 tests fail with pcapkit/ reverted, on scapy 2.6.1, 2.7.0 and 2.8.0; 83 related test files pass; 47 captures it built itself; 10 of 12 mutants killed. I re-ran the new test and both scapy suites myself on 3.14 and 3.11: all green. I also confirmed the LOOP families on main: at 24, 28 and 30 the default engine reads IPv6 and scapy does not. The first-layer gap this PR leaves is #1650.

[github-actions]

Coverage: 89.61% (unit tier, Python 3.14, f6e6fe60c, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	3	20	3	95.16%
pcapkit/const	18858	954	2366	868	91.06%
pcapkit/corekit	2366	67	760	35	96.48%
pcapkit/dumpkit	275	3	100	3	98.40%
pcapkit/foundation	2884	145	1010	35	94.14%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	17166	226	4580	191	98.06%
pcapkit/toolkit	1063	190	400	5	80.38%
pcapkit/utilities	494	4	146	4	98.75%
pcapkit/vendor	4409	2342	1006	157	43.25%

Per-file detail: the coverage-html artifact of this run.