LV045-网络调试工具与抓包
一、 为什么要会看线上的包
1. 日志只告诉你"自己这一侧看到了什么"
排查网络问题时，最容易陷入的误区是"只看自己这边的日志"。日志的局限在于它只覆盖一个观测点：
- 板子日志说"没收到包"——可能是包根本没发出来，也可能是发出来了但没到达板子；
- PC 说"超时"——可能是请求没到达，也可能是到达了但应答没回来。
这两个观测点之间的事，日志永远看不到。
2. 抓包能看到线上真实发生了什么
抓包（在链路上原样复制一份流量）补的就是这个缺口。它回答的是"线上到底跑过什么包"：
| 问题 | 日志能答吗 | 抓包能答吗 |
|---|---|---|
| PC 到底把 ARP 请求发出去了吗 | 不能 | 能 |
| 板子的应答被交换机转发出来了吗 | 不能 | 能 |
| 请求与应答的间隔有多长 | 板子看不到发端时间 | 能 |
| 包里哪个字段不对 | 只能猜 | 逐字节看 |
嵌入式开发的特殊性在于：板子本身没法装抓包工具，所以抓包点要选在 PC 侧（直连时 PC 网卡就能看到全部流量）或交换机的镜像口上。直连实验的抓包条件其实非常好——所有流量必过 PC 这块网卡。
二、 三件套：ping、arp、ipconfig
1. ping：读输出里的三个数
ping 192.168.16.30输出里值得看的三样东西：
| 输出 | 含义 | 排错用法 |
|---|---|---|
时间=1ms 这类值 | 往返时延 | 第一包明显慢是 ARP 的一问一答，正常现象 |
TTL=128 | 包的剩余跳数 | 板子直连时应该看到初始值；变小说明中间有路由器 |
| 丢包率 | 发了多少、回了多少 | 时通时不通时，先看丢包是不是集中在某几包 |
第一包慢的原理见 LV050-一次ping的完整旅程 第二节。
2. arp -a / ip neigh：看解析结果
| 系统 | 命令 | 看什么 |
|---|---|---|
| Windows | arp -a | 板子的 IP 有没有对应 MAC、MAC 对不对 |
| Linux | ip neigh | 同上，状态为 REACHABLE 才算学到 |
两个典型结论：
（1）表里根本没有板子的 IP：ARP 没通，问题在链路层以下（网线、交换机、中断标志），轮不到 IP。
（2）IP 在但 MAC 不对：学到了错误的映射（IP 冲突或换了板子没清缓存），用 arp -d 192.168.16.30 删掉再 ping。
3. ipconfig / ip addr：先确认你用的是哪块网卡
笔记本上通常同时存在多块网卡：有线、WiFi、虚拟机虚拟网卡。直连实验最常见的低级错误是PC 把地址配到了 WiFi 网卡上，而有线网卡还是自动获取状态。
# Windows
ipconfig
# Linux
ip addr要核对的是"和板子连着的那块网卡"的地址与掩码，而不是"系统里存在这么一条配置"。
三、 快速连通性验证：nc
1. 测 TCP：确认端口能不能握手
nc -v 192.168.16.30 8888这条命令的价值在于把 TCP 与应用层协议解耦：不需要上位机脚本、不需要固件帧，只要握手成功，就说明 DM9000、lwIP、TCP、端口监听这条链全通。
三种结果对应三种结论：
| 结果 | 结论 |
|---|---|
立刻 Connected to ... | 传输层全通，问题在帧协议或上位机 |
| 一直挂起直到超时 | 端口没监听或 SYN 没到达，查 IAP_TCP_EN、端口占用 |
立刻 Connection refused | 到达了对端但端口没开（对 TCP 来说这是个"好消息"：IP 通了） |
本工程是单连接服务器，一个已建立的 nc 会话会占住通道：之后再用升级脚本连接会被 tcp_abort 拒绝。测完记得把 nc 关掉（见 LV020-网络通信实验 第三节）。
2. 测 UDP：确认服务器端口开着
nc -u -v 192.168.16.100 69UDP 没有握手，所以 nc -u 的"连通"不代表什么；它的用法是发一个包出去，看服务器有没有反应。对 TFTP 来说更直接的办法是用 TFTP 客户端实际拉一次文件。
四、 tcpdump 与 Wireshark
1. tcpdump 常用命令
Linux 下抓包的入口是 tcpdump（需要 root 或相应权限）：
# 抓指定网卡上与板子相关的全部流量
sudo tcpdump -i eth0 host 192.168.16.30
# 只看 ARP 与 ICMP（ping 排错最常用的组合）
sudo tcpdump -i eth0 arp or icmp
# 把抓到的包存成文件，之后用 Wireshark 打开慢慢看
sudo tcpdump -i eth0 host 192.168.16.30 -w board.pcap-w 写文件这个组合最值得记住：嵌入式现场往往只有串口和一根网线，先把流量录下来，事后在图形界面里分析。
2. Wireshark 过滤表达式
Windows 或图形环境里用 Wireshark，常用过滤写法：
| 过滤表达式 | 看什么 |
|---|---|
arp | ARP 的一问一答：请求广播、应答单播 |
icmp | ping 的请求与应答是否成对 |
tcp.port == 8888 | 升级通道的三次握手、数据段、重传 |
udp.port == 69 or udp | TFTP 的 RRQ、DATA、ACK |
frame contains "IAPBIN" | 直接在字节里搜帧头魔数 |
看 TCP 流量时特别值得关注的标志：有没有重传（Retransmission）。同一段数据被发两遍，说明 ACK 没回到发送方——直连实验里出现大量重传，多半是对端处理太慢（比如板子在回调里做了耗时操作）。
3. 对照本工程的三种典型包
| 场景 | 线上应该看到什么 | 说明 |
|---|---|---|
| 首次 ping | ARP 请求（广播）→ ARP 应答（单播）→ ICMP 请求 → ICMP 应答 | 四包齐全才算全通 |
| TCP 升级 | SYN → SYN/ACK → ACK → 数据段（每个段有 ACK） | 缺握手先查端口；缺 ACK 看板子回调 |
| TFTP 升级 | RRQ（到 69）→ DATA（从服务器的 TID 端口）→ ACK → … | 服务器会换端口，注意第二条的方向 |
三个包的详细解析分别见 LV050、LV035-传输层端口UDP与TCP 第三节、LV025-基于TFTP的网络升级实验 第五节。
五、 症状到工具的对照表
把前面几篇和本篇合起来，得到一张"先拿什么工具"的对照表：
| 现象 | 第一个工具 | 看什么 | 大概率结论 |
|---|---|---|---|
| 完全不通，灯也不亮 | 肉眼 + ipconfig | 网线、网卡选对没 | 物理层问题 |
| ping 不通，灯亮 | ipconfig | 两边是否同网段、是不是配错了网卡 | 地址配置问题 |
| ping 不通，网段正确 | arp -a | 有没有学到板子的 MAC | ARP 没通，查收包路径 |
| ping 通，TCP 连不上 | nc -v | refused 还是 timeout | 端口没开 vs 链路问题 |
| TCP 连上但升级失败 | Wireshark | 握手正常吗、有没有重传、帧头对不对 | 帧协议问题 |
| TFTP 一直超时 | Wireshark | RRQ 出去了吗、服务器回了吗 | 服务器没起或端口被拦 |
| 时通时不通 | ping -t 长ping + 板子计数 | 丢包有没有规律、主循环是否被堵 | 主循环被长操作挡住 |
这张表与 LV050 第六节的决策树是配套的：决策树解决"按什么顺序查"，这张表解决"每一步用什么工具看"。
六、 小结与参考资料
1. 本篇小结
- 日志只能覆盖一个观测点；抓包才能看到"线上真实发生了什么"，两者要配合用。
ping看时延、TTL 与丢包；arp -a/ip neigh看解析结果；ipconfig/ip addr先确认网卡选对。nc -v把 TCP 与应用层解耦：握手成功 = 传输层全通；refused是"IP 通了、端口没开"的好消息。tcpdump -w录文件、Wireshark里按过滤表达式分析，是嵌入式现场最实用的抓包组合。- 看 TCP 流量重点关注重传；看 TFTP 流量注意服务器会换 TID 端口。
- 排查顺序永远是"先物理、再地址、再 ARP、再传输层"，每一步用对应的工具验证。
2. 参考资料
- 排错决策树与实测输出：LV050-一次ping的完整旅程 第六节
- 驱动计数（主循环被堵的判据）：LV005-DM9000驱动实现 第六节
- 实验中的工具用法：LV020-网络通信实验
- 手册：
STM32F1 LWIP开发手册(DM9000版)_V1.1.pdf第 1.6 节
本文档由 markdowncli 技能辅助生成