diff options
Diffstat (limited to 'PLAN.md')
| -rw-r--r-- | PLAN.md | 38 |
1 files changed, 38 insertions, 0 deletions
@@ -368,3 +368,41 @@ None currently open. pass; summarize's own harness also now exercises the ICMP decode path added earlier this session and the new mDNS/SSH dissectors, since all of that lives inside summarize_packet()'s call graph already. +- Renamed wireframe -> packeteer (packet + -eer). See NAMES.md for the + reasoning and the collisions checked before committing to it. +- ARP (packeteer/net/arp.hpp): the one real-traffic L2 protocol that + had zero treatment until now - an ARP frame's ethertype (0x0806) + just fell through summarize_packet's "not IPv4/IPv6, stop after the + Ethernet line" branch, on traffic that shows up on essentially every + real LAN capture. Scoped to Ethernet hardware addresses (hlen=6) and + IPv4 protocol addresses (plen=4) - the case that accounts for + virtually all real ARP traffic; other combinations still decode the + fixed header (hwtype/protype/opcode) without guessing at a different + address width. Summary phrasing deliberately matches tcpdump's own + "who-has X tell Y" / "X is-at Y" convention rather than inventing new + wording, since that phrasing is already how anyone reading ARP + traffic expects to see it. Verified against real traffic: flushed + this machine's ARP cache entry for its actual default gateway and + captured the resulting request/reply on wlp1s0 - "who-has + 192.168.1.1 tell 192.168.1.104 (28:39:26:71:cd:dd)" followed by + "192.168.1.1 is-at bc:07:1d:ff:54:e9", both addresses matching this + machine's real interface/gateway. +- TUI parity for -c/-a: unlike -x (hex dump, never ported to the TUI), + -c/-a were already being parsed into RenderOptions for every mode -- + main()'s arg parsing doesn't distinguish TUI from plain-text - but + run_tui()'s consumer thread had its own separate loop that never + read opts.verbose_checksums/opts.reassembler, so the flags silently + did nothing in TUI mode despite appearing to be accepted. Fixed by + mirroring plain-text render_packet()'s logic: checksum status + appended inline to the row, a reassembled-HTTP line pushed as a + second row right after, both via the same packeteer::checksum_status/ + reassembled_http_status() the CLI and GUI already share. Caught a + real bug while wiring this in, before it ever ran: pushing up to two + rows per packet against a single `if (rows.size() > kMaxRows) + pop_front()` would let the row deque grow unboundedly under + sustained -a activity, since one pop can't offset two pushes -- + changed to a while loop. Verified under tmux (capture-pane, not raw + pty - see the search-bug methodology note above) against the same + split-segment HTTP scenario used to verify -a on the CLI and GUI: + both "checksums: IP=ok TCP=..." and "[reassembled request: ... Host: + ... (72 bytes so far)]" appeared correctly inline in the packet list. |