TFTP服务端回复无法到达客户端的原因及服务端丢包排查

可能的故障原因 #

• ARP缓存异常：服务端eth0接口的ARP表中缺失客户端10.0.0.2的MAC条目，或条目错误，导致UDP回复包无法找到正确的二层转发路径。重启接口会清空旧ARP缓存，重新学习客户端MAC地址，恢复通信。
• 连接跟踪状态异常：系统的UDP连接跟踪（如nf_conntrack）出现异常，将TFTP回复包判定为无效连接并丢弃。重启接口会重置连接跟踪的相关状态，恢复正常转发。
• 网卡驱动/硬件临时故障：eth0接口的驱动出现队列阻塞、死锁，或网卡硬件临时异常，导致数据包无法正常发送。重启接口会重置驱动与硬件状态，修复发包能力。
• 防火墙规则临时异常：服务端本地防火墙（如iptables）出现规则误匹配，拦截了TFTP的UDP回复包。重启接口可能触发规则重新加载，或清除临时拦截状态。

对应的调试方法 #

排查ARP缓存问题 #

• 执行arp -n查看服务端ARP表，确认10.0.0.2对应的MAC地址是否存在且正确
• 手动刷新ARP缓存：执行arp -d 10.0.0.2删除旧条目，触发客户端重新发起请求，观察是否能重新学习到正确MAC
• 开启ARP调试日志：执行sysctl -w net.ipv4.conf.eth0.log_arp_warnings=1，查看ARP交互过程中的异常告警

排查连接跟踪异常 #

• 查看TFTP相关的连接跟踪条目：执行conntrack -L -p udp --dport 1664或cat /proc/net/nf_conntrack | grep udp | grep 1664，检查是否存在异常状态的条目
• 清除异常连接跟踪条目：执行conntrack -D -p udp --dport 1664，之后测试通信是否恢复
• 检查连接跟踪超时配置：执行sysctl net.netfilter.nf_conntrack_udp_timeout，确认超时时间设置合理，避免过早回收TFTP连接状态

排查网卡驱动/硬件问题 #

• 查看接口统计信息：执行ip -s link show eth0，检查tx_errors、dropped等指标是否异常，判断是否存在发包失败情况
• 查看系统网卡日志：执行dmesg | grep eth0或cat /var/log/messages | grep eth0，寻找驱动报错、硬件异常的日志信息
• 重新加载网卡驱动：执行rmmod <网卡驱动名> && modprobe <网卡驱动名>（如e1000e、igb等，需替换为实际驱动），测试通信是否恢复

排查防火墙规则问题 #

• 查看当前iptables规则：执行iptables -L -n -v，检查是否存在针对UDP 1664端口的DROP/REJECT规则
• 临时关闭防火墙测试：执行systemctl stop iptables（或对应firewalld服务），确认通信是否恢复，验证是否为防火墙拦截导致
• 检查连接跟踪相关规则：执行iptables -L INPUT -m conntrack --ctstate RELATED,ESTABLISHED -n -v，确认是否允许TFTP回复包（属于RELATED状态）通过

内容的提问来源于stack exchange，提问作者Janardha