diff options
Diffstat (limited to 'PLAN.md')
| -rw-r--r-- | PLAN.md | 24 |
1 files changed, 23 insertions, 1 deletions
@@ -31,7 +31,7 @@ unowned buffers) via a real-world capture pipeline. 4. [done] Bounded channel + drop-on-backpressure between capture and render 5. [in progress] L7 dissector interface, add protocols incrementally -- interface + DNS + HTTP + TLS SNI + mDNS + SSH banner + NTP + DHCP + - FTP + SMTP + TFTP + QUIC done (packeteer/l7/); ARP/VLAN/IGMP done + FTP + SMTP + TFTP + QUIC + SNMP done (packeteer/l7/); ARP/VLAN/IGMP done at the L2/L3 level too (packeteer/net/); more protocols can still be added incrementally, by design @@ -540,3 +540,25 @@ None currently open. This also serves as a real-traffic confirmation that the L7Registry fix works: without it, none of this would have decoded at all, since tls_dissector claims port 443 first. +- SNMP (l7/snmp.hpp), scoped to v1/v2c - the first dissector needing + actual ASN.1 BER decoding, via a small local TLV reader (tag/length/ + value only, not a general ASN.1 decoder: no indefinite-length + encoding, no multi-byte tag numbers, nothing beyond what SNMP's own + SEQUENCE/INTEGER/OCTET STRING structure uses). v3 wraps the PDU in + its own security-parameters header instead of a plain community + string, and the PDU can be encrypted - reported by version alone, + not decoded further, the same "don't take on real crypto" call as + TLS/QUIC. Community strings are shown as-is, not redacted: v1/v2c + send them in the clear regardless, same reasoning as FTP's PASS. + SnmpDissector takes its port in the constructor rather than a fixed + override, so it's registered twice - 161 (agent) and 162 (trap + receiver). Unlike DHCP's 67/68, there's no port shared by both + directions for l7_summarize()'s dst-then-src fallback to land on: a + trap goes from an ephemeral source port straight to 162, touching + 161 nowhere at all, so both had to be registered explicitly rather + than relying on the fallback the way DHCP could. + Live-verified against a real snmpd (net-snmp 5.9.5.2) on loopback: a + real `snmpget` GetRequest/GetResponse exchange on port 161 decoded + correctly with matching request-ids across both directions, and a + real `snmptrap` SNMPv2-Trap on port 162 confirmed the second + registered port actually gets used, not just the first. |