嵌入式设备ping不通tcpdump 5分钟找到凶手比加printf快10倍嵌入式开发调试网络问题最常见的画面开发板ping不通网关或者跟服务器连不上。然后呢打着手电筒看网口灯、拿示波器点PHY芯片管脚、在代码里拼命加printk打网络数据——emmm你确定要这样我见过一个兄弟调试一个MQTT断连问题在代码里加了30多行printk打数据包内容编译烧录一次5分钟折腾了一整天没找到原因。我过去敲了一行tcpdump30秒定位是服务器端TLS证书过期了。今天这篇不讲花哨的就跟你聊tcpdump在嵌入式场景下的5种实战用法。随便哪种都能让你少加100行printk。前提你的板子上有tcpdump吗大部分嵌入式Linux系统Buildroot/Yocto出来的默认没有tcpdump。别慌两个办法方案一交叉编译# 下载tcpdump源码交叉编译扔到板子上就行./configure--hostarm-linux-gnueabihf--prefix/opt/tcpdumpmakemakeinstall# 把tcpdump和libpcap.so拷到板子上arm-linux-gnueabihf-strip tcpdump# 减到500K左右scptcpdump root板子IP:/usr/sbin/方案二用Busybox自带的阉割版# 如果Busybox编译时勾选了CONFIG_TCPSUPPORT# 有个阉割版能用功能少但够用tcpdump-ieth0-n如果空间极度紧张Flash只有4MB还有一个骚招把tcpdump编译成静态链接扔到/tmp里反正tmpfs是内存。跑完就没了不占Flash空间。场景一板子ping不通网关——看ARP就知道谁在搞鬼嵌入式设备最常见场景ping 192.168.1.1卡住不动了。# 在板子上抓ARP包tcpdump-ieth0-narp输出长这样12:34:56.789012 ARP, Request who-has 192.168.1.1 tell 192.168.1.100, length 46 12:34:57.789012 ARP, Request who-has 192.168.1.1 tell 192.168.1.100, length 46 12:34:58.789012 ARP, Request who-has 192.168.1.1 tell 192.168.1.100, length 46只发不收——说明网关没理你。这时候原因只有三个IP不在同一网段最常见板子配了192.168.1.100/24但网关是192.168.2.1MAC地址过滤交换机的端口安全功能把陌生MAC拦了物理层没通PHY芯片auto-negotiation失败Link没起来如果看到ARP, Request who-has 192.168.1.1 tell 192.168.1.100 ARP, Reply 192.168.1.1 is-at 00:11:22:33:44:55ARP通了但ping还不行——那就不是链路层问题了查路由表或防火墙。只发不收有回复但ping不通ping 网关不通tcpdump抓ARP包链路层问题网络层问题检查IP网段检查MAC过滤检查PHY Link状态查路由表 route -n查iptables规则检查网关防火墙修复后验证场景二TCP连接被拒——别猜看RST包另一个经典场景板子上的应用连服务器connect返回-1errnoECONNREFUSED。tcpdump-ieth0-ntcp port 8080输出12:34:56.789 IP 192.168.1.100.12345 10.0.0.1.8080: Flags [S], seq 100 12:34:56.790 IP 10.0.0.1.8080 192.168.1.100.12345: Flags [R.], seq 0, ack 101SYN包发出去立刻收到RST——服务器端口没开或者防火墙拦了。不需要猜不需要看代码。如果看到12:34:56.789 IP 192.168.1.100.12345 10.0.0.1.8080: Flags [S], seq 100 12:34:56.790 IP 10.0.0.1.8080 192.168.1.100.12345: Flags [S.], seq 200, ack 101 12:34:56.790 IP 192.168.1.100.12345 10.0.0.1.8080: Flags [.], ack 201三次握手完成——这时如果应用还报错那是应用层的问题协议解析、认证、TLS握手等跟网络无关了。场景三嵌入式设备做服务端——看看谁在扫你你的板子当服务器比如HTTP API有客户端连不上来先抓包看看有没有人来找你tcpdump-ieth0-ntcp port 80如果根本没包——是客户端找不到你跟板子没关系。查DNS解析、查路由可达性。如果有SYN但没回复12:34:56.789 IP 192.168.1.200.54321 192.168.1.100.80: Flags [S], seq 789 # ... 没下文了说明你的服务端程序压根没在监听或者防火墙把入站连接丢了。netstat -tlnp看一眼80端口有没有LISTEN就清楚了。场景四嵌入式设备上网慢——看TCP重传设备联网了但奇慢无比。一条AT指令要等好几秒这就是TCP重传的典型症状。tcpdump-ieth0-ntcp[13] 0x0c ! 0# 只抓RST和SYN包精确定位连接问题或者更直接的# 抓重传包tcpdump-ieth0-ntcp[13] 4 ! 0看到大量重传RST标志位基本可以确定WiFi/4G信号弱嵌入式无线设备最常见服务器太远延迟太高缓冲区太小TCP window满了进一步看看延迟# 带时间戳抓包看延迟tcpdump-ieth0-n-tttthost 服务器IP对比每个包的时间戳如果RTT超过500ms那不管你怎么优化代码都没用——瓶颈在网络本身。场景五嵌入式板子没DHCP地址抓DHCP包tcpdump-ieth0-n-eport67or port68DHCP有四步握手# DISCOVER板子找DHCP服务器 IP 0.0.0.0.68 255.255.255.255.67: DHCP-DISCOVER # OFFER服务器回复 IP DHCP服务器.67 255.255.255.255.68: DHCP-OFFER # REQUEST板子确认 IP 0.0.0.0.68 255.255.255.255.67: DHCP-REQUEST # ACK服务器最终确认 IP DHCP服务器.67 255.255.255.255.68: DHCP-ACK缺了哪一步就查哪一步。没有OFFER网络里没有DHCP服务器或者说DHCP中继没配。有OFFER没ACKIP冲突或服务器拒绝了。网络板子1. DISCOVER 广播2. OFFER 单播/广播3. REQUEST 广播4. ACK 确认DHCP ClientDHCP Server哪个阶段断了无DISCOVER: 网口没UP无OFFER: 没有DHCP服务器无ACK: IP冲突或服务器拒绝几个嵌入式场景下的tcpdump骚操作场景Flash空间只剩2MB# 不要-i eth0全量抓先指定过滤条件缩小# 抓完用-W限制文件大小-C做轮转tcpdump-ieth0-n-C10-W5-w/tmp/capture.pcaphost 目标IP# 最多5个文件每个10MB循环覆盖# 抓完了scp拿下来慢慢分析场景分析之前抓的包# 不在板子上看把pcap拉回PC用Wireshark# 或者在板子上离线读取tcpdump-r/tmp/capture.pcap-n场景板子没屏幕没键盘# 开机自动抓包出问题后分析# 加到/etc/init.d/rcS里tcpdump-ieth0-C5-W10-w/tmp/netlog.pcapnot port 22# 排除SSH端口避免把自己抓进去总结嵌入式网络调试顺序应该是看灯 → 抓包 → 看代码先物理层再链路层再网络层最后才是应用层代码。大多数时候tcpdump在第二三步就把问题解决了根本不需要改代码。我见过太多人一上来就翻代码、加log、反复编译烧录——折腾半天发现是IP配错了或者网线松了。工具先上脑子后用。课后练习你的板子ping不通外网arp回复有默认网关能ping通——怎么排查板子上跑HTTP服务器客户端connect一直超时tcpdump看不到任何SYN包到板子——问题可能在哪嵌入式4G模块上网偶尔断连。怎么用tcpdump抓完整网络日志又不占太多Flash答案我就不写了自己抓两把包就全明白了。