toolkit: pyshark layer names are Wireshark filter names, so LinkType lookup misses

[JarryShaw]

Found while applying #838's ruling to raise on an unresolvable link-layer name, and it will bite the moment #838 merges.

pcapkit/toolkit/pyshark.py:87 does Enum_LinkType.get(packet.layers[0].layer_name.upper()). pyshark's layer_name is Wireshark's protocol filter name, passed through unmodified — pyshark/packet/layers/base.py:30-31 is a bare return self._layer_name, and .upper() appears only in __repr__. For a PDML capture the name comes straight from <proto name> (pyshark/tshark/output_parser/tshark_xml.py:93, XmlLayer(proto)).

Three pieces of local evidence that these are filter names, not protocol titles:

• pyshark's Packet.__getattr__ matches layer.layer_name.lower() == item.lower(), documented as "For instance: pkt.ip", and consts.TRANSPORT_LAYERS = ['UDP', 'TCP'].
• pcapkit's own pyshark toolkit relies on exactly that: packet.ip, packet.ipv6, packet.tcp, packet.frame_info.
• The test double in tests/toolkit/test_pyshark_unit.py names its layers 'frame', 'ip', 'tcp', 'ipv6' — all real filter names — and then 'ethernet', which is not one. Wireshark's is eth (hence eth.src, eth.dst, and the fake's own src= field).

So layers[0].layer_name.upper() is 'ETH' for an ordinary Ethernet capture, and 'ETH' is not a LinkType member — 'ETHERNET' is. Once #838 removes the fallback, every Ethernet capture traced through this toolkit raises instead of one odd case.

Fix: map pyshark/Wireshark filter names to LinkType (at least eth → ETHERNET, ip → IPV4, ipv6 → IPV6, null/loop → NULL, raw → RAW) rather than upper-casing a display name and hoping it matches. Same question applies to pcapkit/toolkit/scapy.py:324, where (Ether()/IP()/TCP()).name.upper() happens to be 'ETHERNET' and does resolve — so scapy is correct today by coincidence of naming, not by design.

Caveat, stated plainly: there is no tshark on this host, so the eth spelling is derived from pyshark's source, its documented idiom, and the test double's own internal inconsistency — not from live PDML.

[JarryShaw]

Checkable blocker: #838 merged.

gh pr view 838 -R JarryShaw/PyPCAPKit --json state,mergedAt

The miss is latent today: pcapkit/toolkit/pyshark.py currently passes a default to Enum_LinkType.get(), so an unresolvable 'ETH' silently becomes a member instead of raising. #838 removes that default per the maintainer's ruling — "I say we raise" — and only then does every Ethernet capture through this toolkit start raising.

Fixing it before #838 lands would mean writing the mapping against a call signature that is about to change, so it waits. blocked.

[JarryShaw]

Second-order consequence, found in #838's review: this defect now truncates
tracebacks process-globally.

MissingKeyError is a loud BaseError, and pcapkit/utilities/exceptions.py:194-201
sets sys.tracebacklimit = 0 for any loud error outside DEVMODE. Neither raise
site passes quiet=True (pcapkit/toolkit/pyshark.py:105, scapy.py:339), and
git grep 'except KeyError' -- pcapkit/foundation/** returns nothing, so it
escapes to the caller through pcapkit/foundation/engines/pyshark.py.

Loud is the right choice for a genuine unknown-link-type error, so this is not a
defect in #838 — but because #840 makes the pyshark path raise on every capture
rather than a rare one, the first traceflow frame now strips the traceback from
every later unrelated exception in the host process. BaseError's own docstring
(exceptions.py:176-178) flags exactly this hazard.

Fixing the name mapping here removes the consequence along with the defect.
Only engine='pyshark' with trace=True is affected — traceflow is opt-in
(pcapkit/foundation/extraction.py:781, trace: 'bool' = False).

[JarryShaw]

Relabelled blocked → wip: this is now covered by #838, not queued behind it.

The maintainer ruled on #838, verbatim: "1 then" — option 1 of three, which was
"land the eth → ETHERNET mapping here, closing #840 as part of this PR." So the
fix is in flight on #838's branch rather than waiting for it to merge.

The earlier blocker comment on this issue (#838 merged) is therefore superseded.
Checkable state instead:

gh pr view 838 -R JarryShaw/PyPCAPKit --json headRefOid,files \
  -q '.files[].path' | grep toolkit/pyshark.py     # present == the fix is on the branch

Scope as briefed: a filter-name → LinkType mapping local to
pcapkit/toolkit/pyshark.py, not an alias registered on LinkType. The reason is
whose vocabulary eth is — it is Wireshark's display-filter name from the PDML
<proto name=…> attribute, while LinkType is the IANA/tcpdump DLT registry. Putting
ETH on LinkType would import one engine's naming into a registry that does not own
it, and the next engine would want the same.

The raise stays for a genuinely unknown name, per the original ruling that no real DLT
may stand in for "unknown link type".