关键在于用tcpdump -i eth0 -nn -s 0 -a udp port 161抓取完整snmp轮询报文，通过源→161（getrequest）、161→源（getresponse）及community或usmuser字段识别版本与异常。
直接用 tcpdump 抓取并识别 SNMP 轮询报文，关键在于精准过滤 + 正确解码。SNMP 默认使用 UDP 161 端口（代理接收 Get/GetNext 请求），而管理端（NMS）通常从随机高端口发起请求，响应则发回该端口。分析重点不是“看懂所有字段”，而是快速确认轮询是否发出、是否到达设备、是否有响应、响应内容是否合理。
抓取 SNMP 轮询流量的核心命令
推荐组合参数，兼顾可读性与完整性：
- -i any 或 -i eth0：指定监听接口，多网卡环境建议明确指定；
- -nn：不解析主机名和端口名（显示 161 而非 snmp），避免延迟且便于筛选；
- -s 0：捕获完整数据包（SNMPv3 可能含加密/认证字段，截断会导致无法识别）；
- udp port 161：最常用、最可靠的过滤表达式，覆盖绝大多数 SNMPv1/v2c/v3 的 Get/GetNext/Set 请求及响应；
- -A 或 -X：-A 以 ASCII 显示（适合查看明文 OID 和字符串值）；-X 同时显示十六进制与 ASCII（必要时查 ASN.1 结构或调试编码问题）。
示例命令：
sudo tcpdump -i eth0 -nn -s 0 -A udp port 161
识别轮询报文的三个典型特征
在输出中逐行观察，重点关注以下模式：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 源→目标为 161 端口：形如 192.168.1.10.54321 → 192.168.1.100.161，这是 NMS 发出的 GetRequest（轮询请求），其 payload 中通常含 get-request 和具体 OID（如 1.3.6.1.2.1.1.1.0 表示 sysDescr）；
- 目标→源为 161 端口：形如 192.168.1.100.161 → 192.168.1.10.54321，这是 agent 返回的 GetResponse，payload 含 get-response 和对应值（如 Linux Router 5.10 #1 SMP）；
- 无响应或超时迹象：只看到大量去向 161 的请求，但长期（>1–2 秒）无对应返回包，说明 agent 未响应——可能是防火墙拦截、snmpd 未运行、community 不匹配或 OID 不存在。
区分 SNMP 版本与常见错误线索
纯命令行下无需 Wireshark 即可初步判断版本和问题：
- SNMPv1/v2c：-A 输出中可见明文 community 字符串（如 public 或 private），紧跟在 version 字段后；若 community 错误，agent 通常静默丢弃，无响应；
- SNMPv3：-A 输出中 community 字段消失，取而代之的是 usmUser、authProtocol 等关键词；若认证失败，可能收到带 report 的错误响应（如 noAuth、noPriv）；
- “bad length” 或 “truncated” 提示：说明 -s 值过小，需加 -s 0 重试；
- 大量重复 request 无 response：检查 iptables/nftables 是否放行 UDP 161 入向，以及 snmpd 进程是否存活（systemctl status snmpd）。
进阶：保存文件供后续深度分析
现场排查时，建议先保存原始 pcap：
sudo tcpdump -i eth0 -nn -s 0 -w snmp_poll.pcap udp port 161
之后可用 tshark（命令行版 Wireshark）快速统计或过滤：
- tshark -r snmp_poll.pcap -Y "snmp.version == 1" -T fields -e ip.src -e snmp.community → 查 v1 的源 IP 和 community；
- tshark -r snmp_poll.pcap -Y "snmp.error.status != 0" -V → 找出所有带错误码的响应（如 noSuchName、tooBig）。
