[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

#1671. The fallback _from_layers runs where a frame's octets can't be had: tcp_traceflow gets no captured, or the engine's second tshark pass or capture-file read fails. It read ip.dst unguarded. Behind a route option whose data isn't a whole number of addresses, tshark gives no ip.dst, so extract() raised a bare AttributeError. Behind a live LSRR or SSRR, ip.dst is the last hop. _header_addresses (pcapkit/toolkit/pyshark.py:604) now keys by the header's destination, which is tshark's ip.cur_rt there. It returns no segment where tshark gives no address, since the default engine rejects that option (pcapkit/protocols/internet/ipv4.py:898).

#1609. _from_octets (:908) now starts at the depth _network_start gives and walks through #1667's _walk_upper_layer, so it stops at FRAME_LAYER_LIMIT. tshark dissects at most 20 802.1Q tags, so TCP behind 21–61 tags was never read. _stops_in_vlan_tags (:685) and vlan in OCTETS_FILTER now read those frames from their octets.

Measured on 3.11 with tshark 4.6.9, main (7aeeaf804) → this branch. Trace inputs agreeing with default:

Sweep	main	branch
#1609 cells (37 frames)	23	37
bound/VLAN sweep, DLTs 0, 1, 101, 108, 228, 229 (886 frames)	669	886
fallback, every LSRR/SSRR length × pointer (7,205 frames)	1,641 (540 raise, 183 last hop)	2,364
23 example captures (1,261 traced frames)	1,261	1,261

No new disagreements. dpkt, scapy and pypcapfile agree on all 37 #1609 cells on main.

Unchanged from main, not fixed here (pyshark 0, default 1): an IPv6 jumbogram whose Jumbo Payload Length is ≤ 65535, which tshark flags as malformed (a real one of 70,028 octets agrees), and TCP behind IPv6 Mobility or HIP (#1626). In the fallback sweep, the 4,841 frames whose route options the default engine rejects are still traced as tshark dissects them.

Tests. New tests/toolkit/test_pyshark_fallback_and_layer_bound_1609_1671_unit.py. All 6 tests fail on main (7 failures, 7 errors under unittest) and pass here. Pins in the #1625 and #1639 files are updated for the new filter, warning and _network_start shape.

Closes #1609
Closes #1671

[JarryShaw]

Verdict: GOOD TO GO at 2e1a1c018. A Sonnet cross-review checked the Opus worker's change. I re-ran the new test, the 1639 test and the 1604 agreement test on 3.11 with tshark 4.6.9: 6, 11 and 3 passed.

• fix(toolkit): pyshark's fallback ends the extraction when tshark reports no ip.dst, and keys a source-routed segment by the route's last hop #1671. _from_layers takes the header's destination from tshark's ip.cur_rt when one is reported, otherwise from ip.dst. It hands over no segment when an address is missing. The reviewer's own 1,068 LSRR/SSRR/RR frames:

  	main	this branch
  bare AttributeError	196	0
  keyed by the last hop	78	0
  new disagreements		0

• fix(toolkit): the dpkt, scapy and pyshark engines do not stop an extension-header chain at 32 #1609, pyshark part. The octet walk counts each tag, IP header, AH and extension header, reusing pypcapfile's _walk_upper_layer, and stops at the 64-layer bound. tshark dissects at most 20 802.1Q tags, so a frame that stops in its tag stack now asks for its octets. The reviewer's 137 boundary frames: 54 disagreements on main, 0 on the branch.

Left, all already on main and unchanged here:

• a malformed IPv6 jumbogram (Jumbo Payload Length ≤ 65535) that tshark rejects;
• TCP behind IPv6 Mobility or HIP, which is fix(toolkit): dpkt, scapy and pyshark drop TCP and IPv4 behind some IPv6 extension-header chains #1626's pyshark part, reopened;
• the fallback still trusting tshark where the octets cannot be had.

[github-actions]

Coverage: 89.46% (unit tier, Python 3.14, 2e1a1c018, 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	3034	152	1076	35	94.23%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	17166	226	4580	190	98.07%
pcapkit/toolkit	1433	280	590	6	77.95%
pcapkit/utilities	494	4	146	4	98.75%
pcapkit/vendor	4417	2342	1010	157	43.38%

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