【背景说明】

近期，在公司新项目中，需要实现在Amlogic S905D5平台上导入驱动联芸千兆PHY芯片MAE0621A-Q3C。根据PHY芯片应用手册，已经成功加载原厂的芯片驱动，和PC连接测试Iperf速率也正常，但是接入公司网络环境，发现无法获取IP。

复杂网络环境下 DHCP 获取 IP 失败排查
图片素材来自免费商用图库（pixabay），非本站项目实拍。

【调试记录】

PHY驱动加载正常，和PC连接测试Iperf速率也正常，单独对接路由器也可正常获取IP。认为和公司复杂的网络环境有关，和 S905D5之间存在一些兼容性问题。

咨询Amlogic原厂，FAE经过现场确认盒子在此复杂网络环境DHCP获取IP失败的过程：

1. 盒子发DISCOVER → 交换机转发延迟；

2. DHCP服务器回OFFER，OFFER先抵达盒子；

3. 旧代码收到OFFER，直接删除CMD_KICK重传定时器；

4. 盒子发REQUEST请求分配IP，但REQUEST在交换机队列被限流丢弃；

5. 无CMD_KICK定时触发重传REQUEST，盒子永久等待ACK，DHCP流程中断，无IP。

 

为何简单网络无此问题：

路由器本地转发，OFFER和ACK几乎同时到达，不会出现REQUEST丢包且无重试的情况。

【解决方案】

针对在此类复杂网络环境下无法获取IP问题，Amlogic原厂提供如下解决方案patch：

From bbc842ee5d448811fa009d81cd497e6c58cc341f Mon Sep 17 00:00:00 2001
From: hao.zhang <hao.zhang@amlogic.com>
Date: Wed, 22 Apr 2026 08:52:23 +0000
Subject: [PATCH] networkstack: fix remove CMD_KICK. [1/1]

PD#IPTV-40519

Problem:
1, Don't send request when remove CMD_KICK.

Solution:
Don't remove CMD_KICK.

Verify:
D5

Change-Id: Ie0cdef146733733e98248eae30b220665db1a280
Signed-off-by: hao.zhang <hao.zhang@amlogic.com>
---

diff --git a/src/android/net/dhcp/DhcpClient.java b/src/android/net/dhcp/DhcpClient.java
index ab3db44..a6220a6 100644
--- a/src/android/net/dhcp/DhcpClient.java
+++ b/src/android/net/dhcp/DhcpClient.java
@@ -1229,7 +1229,6 @@
                 case CMD_RECEIVED_PACKET:
                     receivePacket((DhcpPacket) message.obj);
                     Log.d(TAG, "PacketRetransmittingState CMD_RECEIVED_PACKET!!!" );
-                    removeMessages(CMD_KICK);
                     return HANDLED;
                 case CMD_STOP_DHCP:
                     Log.d(TAG, "PacketRetransmittingState CMD_STOP_DHCP!!!" );

  关键定义：

 CMD_KICK ：DhcpClient 内部定时重传触发器，作用是超时重发DHCP请求包（DISCOVER/REQUEST），防止设备发完报文后服务器无响应、卡死在等待状态；

PacketRetransmittingState ：DHCP重传等待状态，设备发送DHCP报文后进入该状态，等待服务器回复，同时靠 CMD_KICK 定时重试发包。

原代码逻辑：

收到DHCP服务器报文（ CMD_RECEIVED_PACKET ）时，删除所有待执行的 CMD_KICK 定时重发消息

补丁改动：

删掉  removeMessages(CMD_KICK); ，不再清除 CMD_KICK 定时任务。

【总结】

原代码在复杂办公网失败的根因:

（1）复杂办公网特征（企业多层交换机、ACL、DHCP中继、VLAN、限速、报文延迟大）

  • a. DHCP服务器回复报文延迟高、丢包概率大、报文分片/转发慢；
  • b. 存在DHCP中继代理，DISCOVER/REQUEST/ACK跨多设备转发，往返时延远大于家用路由器；
  • c. 部分交换机对广播DHCP报文限流，服务器ACK报文送达终端会滞后几百ms~数秒。

 

（2）旧代码逻辑缺陷

设备发送DHCP DISCOVER后进入重传等待状态：

  • a. 服务器延迟回复了半程报文/中间过渡报文（比如OFFER，但ACK还在路上）；
  • b.  一收到任意  CMD_RECEIVED_PACKET ，立刻执行  removeMessages(CMD_KICK) ，清空所有定时重传任务；
  • c.  此时计时器被删掉，不会再自动重发REQUEST；
  • d.  若后续ACK报文因网络拥堵丢失/延迟超时，DhcpClient 不再重试发包，直接卡死，最终拿不到IP。

工程化排障框架：先分层，再定位

网络故障排查忌”东试试西试试”。建议建立固定套路：物理层（线缆/光模块/端口灯）→ 数据链路（协商速率/双工/VLAN）→ 网络层（IP/网关/路由）→ 传输层（端口/NAT）→ 应用层（DNS/认证/业务）。每步用对应工具固化证据：cable tester、ping/traceroute、telnet/nc 测端口、tcpdump/Wireshark 抓包。

工具箱与案例

traceroute/mtr 看路径与逐跳丢包；netsh（Win）/ip/ss（Linux）看接口与连接；打印机等外设先确认拿到 IP、与终端同网段、未被 VLAN 隔离。把”故障现象→影响范围→变更历史”三要素记下来，多数问题能在复盘中定位到某次配置或某台设备故障。

相关阅读

本文为转载作品。版权归原作者所有；本站仅作技术学习与方案参考，如涉侵权请联系我们删除。