EC20 4G 模组：获取dhcp获取ip失败 与 4G IP连接公网时，出现部分IP地址不通的现象

物联网模组技术问答 4G标准模组
1

项目环境：基于海思soc的嵌入式linux设备上集成移远4G模组
一：4G 模组，获取dhcp获取ip失败:

出现概率：非必现
问题说明：系统启动后，偶发 发现无ip信息后，使用基本 AT指令测试都是正常的:
例如：
《AT+CGREG?》 返回正常
《AT+CGPADDR=1》 返回正常IP，说明4g模组已经被分配了IP的

最后linux侧使用dhcp获取IP时，
协议过程例如：
usb0: offered 11.1.19.170《linux侧》 from 11.1.19.169《模组侧》
usb0: NAK: from 11.1.19.169《模组侧》
可以看到：
模组已经分配有效IP <11.1.19.170>,但最后linux请求使用IP时，模组却返回NAK无效，
若直接使用分配的ip《11.1.19.170》去静态设置网络地址，ip可用的

1：偶现非必现
2：出现异常后:软重启reboot 大概率不会恢复，但断电模组一段时间后再重启，目前测试会恢复

所以分析是否是模组内部相关状态机出现了异常导致请求使用ip时被拒绝；而 断电重启会恢复，是否因为模组完全下电后内部缓存数据被重置，数据状态才会完全恢复重置后，状态机才恢复的？

二：4G模组网络有的网络地址不通
概率：非必现
说明：
当成功使用4G网络时，会出现某些IP地址不通（测试的地址：都是公开的公网IP与我们自己的服务器地址,都是开放的，排除对端服务器地址限制的因素)，
有些IP地址却可以正常连接；正常来说 ，网络正常，除非对方有策略拒绝，否则不会出现这种情况
出现现象时的 地址举例：
ping 通的地址
120.76.240.167、net.xnkiot.com、153.3.238.28

不通地址：
ntp.aliyun.com、153.3.238.127、106.55.184.199
包括我们自己的服务器地址，这里就不写了

IP地址不通的因素:
1： 应排除dns解析问题，因测试过程中 域名地址 是可以正常解析的，例如 www.baidu.com时，测试已验证 成功百度返回ip地址，但是却连接不上的情况
2：应排除 mtc与分片 超出问题，因测试时，仅连接测试，未发送过多数据

2

问题一：DHCP 获取 IP 失败（模组侧返回 NAK）

核心现象：DISCOVER/OFFER 正常，REQUEST 阶段模组侧下发 NAK；异常后软重启不恢复、断电恢复。此特征指向模组运行态 DHCP 服务端租约/状态未随链路复位。

建议排查方向：

  1. Linux 侧抓包，核对完整时序：DISCOVER→OFFER→REQUEST→NAK。重点看 REQUEST 中 requested IP 与 server identifier 是否与 OFFER 一致，确认是客户端请求了非法 IP，还是服务端主动拒绝。
  2. 检查客户端是否残留上次租约文件（如 /var/lib/dhcp 下的 lease），导致重连时仍请求旧地址。
  3. 核对地址段一致性：11.1.19.x 非模组默认网段，需确认模组侧 DHCP 地址池、模组侧 IP（AT+CGPADDR 查询值）与拨号分配网段是否同步。
  4. 若业务允许，可先采用静态 IP 配置规避，稳定性优先。
  5. 断电可恢复、软重启不恢复，佐证为模组内部缓存/状态机异常。请在复现时保留模组侧日志与抓包数据，提交移远 FAE 进一步定位。

问题二：部分公网地址不通

先区分两类问题，不要混为一谈：

  • 域名不通（如 ntp.aliyun.com）：优先查 DNS。先 nslookup/dig 确认解析是否成功，解析失败属 DNS 配置问题，与连通性无关。
  • IP 不通（如 153.3.238.127、106.55.184.199）：属链路/路由/策略问题。

IP 不通建议排查：

  1. MTU 与分片：用 ping -M do -s 1472 逐步减小包长定位。4G 链路 MTU 变化会导致部分站点或大包不通，而小包可通。
  2. 路由表与默认网关：检查 usb0 与其他网卡的优先级（metric）、是否存在多默认路由。
  3. APN 与双栈配置：确认 APN 设置及 IPv4/IPv6 双栈状态，可对比更换 APN 复现情况。
  4. 复现时执行 traceroute，确认丢包发生在哪一跳，用于区分模组侧、运营商侧还是对端。
  5. 部分地址可达、部分不可达且非必现，也可能与运营商侧会话策略有关，建议结合抓包与复现日志提交 FAE 分析。

如需固件、手册或工具包，请提供邮箱地址，以便为您发送对应资料。

本回答仅供参考。若问题已解决，可标记为 :white_check_mark:解决方案 ；若仍有疑问，请等待官方技术人员回复，最终请以专业解答为准。

3

从EC20 4G 模组：获取dhcp获取ip失败 与 4G IP连接公网时，出现部分IP地址不通的现象继续讨论：

4

第一个问题，发生的时候，试下 ps | grep -i dhcp：确认一下链路上只有一个 DHCP 客户端？
如果有两个：udhcpc -R 先释放 / AT+QNETDEVCTL 重新激活 / AT+CFUN=0→1。
如果还有问题，可以打个log看下：tcpdump -i usb0 -n -w /tmp/dhcp.pcap port 67 or port 68
另外， 在 udhcpc 之前打一行日志，echo “$(date) $(cat /sys/class/net/usb0/address)” >> /tmp/mac.log 保存一下MAC，回头确认看有没有变化用

5

【帖子主题】
EC20 4G 模组：获取dhcp获取ip失败 与 4G IP连接公网时，出现部分IP地址不通的现象

【发帖用户】
huis

【用户问题】

  • 项目环境：基于海思 SoC 的嵌入式 Linux 设备上集成移远 4G 模组。
  • 问题一：4G 模组获取 DHCP 获取 IP 失败。出现概率：非必现。问题说明：系统启动后，偶发发现无 IP 信息后，使用基本 AT 指令测试都……（原帖内容过长，未完全展示）。
  • 问题二：4G IP 连接公网时，出现部分 IP 地址不通的现象。
  • 用户补充/前置排查（客服引用）：已明确排除 DNS 解析问题（域名可正常解析、百度返回 IP 但连接不上）及 MTU/分片问题（测试仅连接、未发送大量数据）。
  • 用户诉求：能否安排技术人员支持下。

【客服解答】

  • 实质客服：Quectel_Chat。
  • 结论：可以安排技术人员支持。
  • 为便于官方 FAE 快速定位，请在申请时一并提供以下信息：
    • 问题一（DHCP 失败）：
      1. 复现时的 Linux 侧抓包文件（含完整 DISCOVER→OFFER→REQUEST→NAK 时序）。
      2. 模组型号、固件版本（ATI / AT+QGMR 查询结果）。
      3. 模组侧日志，及 AT+CGPADDR 查询到的模组 IP。
      4. 客户端残留租约文件内容。
    • 问题二（部分公网 IP 不通）：
      1. 复现时的 traceroute 结果（确认丢包跳点）。
      2. 抓包文件与具体不可达 IP、时间点。
      3. APN 配置及 IPv4/IPv6 双栈状态（AT+CGDCONT 查询）。
      4. 对比更换 APN 后的复现情况。
  • 配合事项：请提供邮箱地址，以便发送对应固件、手册与工具包，并对接 FAE 跟进。也可直接前往移远技术社区发帖并附上述完整步骤与环境信息，官方技术人员将及时跟进。
  • 客服声明：本回答仅供参考；如仍有疑问，可在当前对话中继续追问补充信息；如需进一步协助，请前往移远技术社区发帖并附详细步骤与环境信息，最终解答以移远官方专业回复为准。

【处理状态】
已回复。客服表示可安排技术人员支持，当前待用户提供邮箱地址及问题一、问题二所需排查材料，尚未解决。

【备注】

  • 原帖内容显示“内容过长，查看原文”，部分问题描述未完整展示。
  • 群聊中另有 system 分类链接及 Quectel_Chat“请选择人工客服”的引导消息，无实质技术结论，已过滤。
  • 客服参考依据中提及用户已排除 DNS 与 MTU/分片问题。
6

问题二：只是测试通不通的话用我们的connectlab 就好，不要用那些公网的地址，你不知道服务器什么策略，没法分析