Repository navigation
fix(toolkit): pyshark traces TCP behind an IPv4 extension header as the default engine does (#1625) - #1642
Merged
Conversation
…he default engine does (#1625) - tshark dissects TCP behind an AH or IPv6 extension header in IPv4 by its own rules, leaves a Mobility or HIP header's payload out of the PDML, and reads past Shim6, which the default engine leaves raw in IPv4. - For such a frame, tcp_traceflow now reads the TCP from its octets by the rules the other engines share (pypcapfile's _upper_layer and _default_accepts), from the outermost IP layer the default engine dissects: through IP-in-IP tunnels and no other, up to EXTENSION_HEADER_LIMIT headers. Over a link layer the default engine reads no IP over, the frame is read as tshark dissects it. - That layer is found by the frame's link type in the capture file, which the engine reads itself, not by frame.encap_type: tshark reads link types 12 and 14 as raw IP (101), which the default engine leaves raw. - The octets come from a second tshark process (-T ek -x -J frame), started on first use, read forward, and reaped on close. If it or the capture file cannot be read, the engine warns with PySharkWarning and traces such frames as tshark dissects them. - Drop ipv4-33/pyshark/trace from the #1609 Gap row, which this fixes. Tests: new tests/toolkit/test_pyshark_ipv4_extension_headers_1625_unit.py.
JarryShaw
added
fix
Owner
Author
|
Verdict: GOOD TO GO at
In the reviewer's own 12,244-frame sweep, which includes multi-section PCAP-NG, round 3 adds 0 new disagreements and fixes 580. I merged it into |
Contributor
|
Coverage: 89.71% (unit tier, Python 3.14,
Per-file detail: the |
JarryShaw
removed
the
review: good-to-go
This was referenced Oct 13, 2026
Closed
JarryShaw
added a commit
that referenced
this pull request
Oct 14, 2026
Third-party engines are best effort (#1687), so the pyshark code that exists only to match the default engine comes out: - revert #1686, #1670 and #1642: the second tshark pass that read a frame's octets, the link type read from the capture file, the 64-layer bound, reading past tshark's 802.1Q limit, and keying a source-routed segment by ip.cur_rt - revert #1613's tshark preferences that turned IP reassembly off, with its FileCapture assertion in test_runtime_engines.py and its sentence in the engines index - keep #1613's partial-TCP-header guard and #1605's keying by the IP header that carries the segment - re-land #1671's crash fix: a TCP layer whose IP layer lacks ip.src or ip.dst is not traced, rather than raising AttributeError - delete the three test modules those reverts added and the agreement checks in test_pyshark_unit.py; the #1611 and #1671 checks assert constants The pyshark test modules, test_runtime_engines.py, test_engine_runtime.py and the project guards pass on 3.11 (tshark 4.6.9) and 3.14.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Please follow the guide below
You will be asked some questions, please read them carefully and answer honestly
Put an
xinto 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 testpasses, and a test case covers the changeAdded a changelog entry under
docs/source/changelog/and regeneratedCHANGELOG.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) #657What is the purpose of your pull request?
Tick the commit type your subject line carries.
fix— corrects a defectfeat— adds a featureperf— changes performance, not behaviourrefactor— changes neither behaviour nor performancetest— tests onlydocs— documentation onlyci— workflows or build toolingrelease— bumps the version or rolls up a distributionchore— anything elseDescription of your pull request and other information
Replaces #1628, which was closed for conflicts.
ipv6_ext.py:586). So pyshark traced TCP the default engine rejects and missed TCP it reads.tcp_traceflowreads the TCP from the frame's octets by pypcapfile's rules, the same as fix(toolkit): dpkt and scapy find TCP in IPv4 where the default engine does (#1606, #1617) #1624 does for dpkt and scapy (pcapkit/toolkit/pyshark.py:631-1016). The walk starts at the outermost IP layer the default engine dissects (_network_start), so GRE, VXLAN and the 32-header chain bound stop it in the same place. The link type comes from the capture file, not tshark'sframe.encap_type, which reads DLT 12 and 14 as raw IP. That covers both the PCAP header and each PCAP-NG interface (_linktypes,pcapkit/foundation/engines/pyshark.py:75-148).-T pdmlrefuses-x, so the engine starts a secondtshark -T ek -x -J frame, filtered byOCTETS_FILTER(pyshark.py:354). It reaps that process on close. If the pass or the capture file fails, the engine warns once withPySharkWarningand falls back to tshark's dissection, asmaindoes.main, 0 new disagreements and 1,717 fixed.tests/toolkit/test_pyshark_ipv4_extension_headers_1625_unit.py, 28 tests. Withpcapkit/reverted all 28 fail, 144 failures counting subtests. The fix(protocols): a chain of ~80+ IPv6 extension headers exhausts recursion and leaves the payload undissected #1604 table drops itsipv4-33/pyshark/tracerow. Itsipv6-33row stays, so fix(toolkit): the dpkt, scapy and pyshark engines do not stop an extension-header chain at 32 #1609 stays open. Also green with this branch merged intomainatb375656e1, on both 3.11 and 3.14.Not fixed here; each is unchanged from
main:Closes #1625