diff options
| author | srdusr <[email protected]> | 2026-05-28 01:23:00 +0200 |
|---|---|---|
| committer | srdusr <[email protected]> | 2026-05-28 01:23:00 +0200 |
| commit | e41dade9ac3bbd7ffbc1eec826801af1a38d8b9e (patch) | |
| tree | ec53e0cc40de194e76da1f5297e37b83cc2d1419 /PLAN.md | |
| parent | 0122045b492f2bd41a74769b8e6a9cefc73f988b (diff) | |
| download | packeteer-e41dade9ac3bbd7ffbc1eec826801af1a38d8b9e.tar.gz packeteer-e41dade9ac3bbd7ffbc1eec826801af1a38d8b9e.zip | |
Decode ICMP embedded flows - show which packet actually triggered an error
Destination Unreachable, Time Exceeded, Redirect, Source Quench, and
Parameter Problem (plus their ICMPv6 equivalents) all carry, after
their own fixed header, as much of the packet that triggered the
error as the network could fit - always at least its IP header plus
the first 8 bytes of payload, exactly enough to recover TCP/UDP port
numbers. That embedded flow is the actual reason an ICMP error shows
up in a capture at all, and wasn't shown before this.
Reuses parse_ipv4()/parse_ipv6() directly on the embedded bytes rather
than a separate parser - it's a genuine (if truncated) IP packet, not
a different format. Two small is_error_type() helpers gate which ICMP
types this is attempted for, since echo/timestamp/Neighbor Discovery
types don't carry an embedded packet at all.
Live-verified with a real traceroute to 8.8.8.8 captured on wlp1s0:
genuine Time Exceeded messages from real intermediate routers - this
machine's own gateway, then real ISP infrastructure several hops out
- all correctly showing the flow that triggered them, matching
traceroute's own hop output.
Diffstat (limited to 'PLAN.md')
| -rw-r--r-- | PLAN.md | 21 |
1 files changed, 21 insertions, 0 deletions
@@ -664,3 +664,24 @@ None currently open. with 8 real IPv6 addresses, all correctly listed), and DNS RR type 65 (HTTPS records, ancount=0 in these captures) correctly producing no answers suffix since there was nothing to list. +- ICMP embedded-flow decoding: Destination Unreachable, Time Exceeded, + Redirect, Source Quench, and Parameter Problem (ICMPv4) / their + ICMPv6 equivalents all carry, after their own fixed header, as much + of the packet that actually triggered the error as the network could + fit - always at least its IP header plus the first 8 bytes of + payload (RFC 792/4443), exactly enough to recover TCP/UDP port + numbers. That embedded flow is the actual reason an ICMP error shows + up in a capture at all, and wasn't shown before this. Reuses + parse_ipv4()/parse_ipv6() directly on the embedded bytes rather than + a separate parser - it's a genuine (if truncated) IP packet, not a + different format, the same insight DNS's answer-record work leaned + on when it reused parse_ipv4's sibling reasoning for name + compression. Two small is_error_type() helpers gate which ICMP + types this is even attempted for (echo/timestamp/Neighbor Discovery + types don't carry an embedded packet at all), rather than relying on + parse_ipv4/parse_ipv6 to just fail gracefully on irrelevant types. + Live-verified with a real traceroute to 8.8.8.8 (traceroute -I, + ICMP-based) captured on wlp1s0: genuine Time Exceeded messages from + real intermediate routers - this machine's own gateway, then real + ISP infrastructure several hops out - all correctly showing "[this + machine -> 8.8.8.8 proto=1]", matching traceroute's own hop output. |