搞嵌入式或者物联网的老哥对4G模块应该都不陌生。常规玩法十有八九是串口AT指令拨号PPP拨号脚本一跑把网络拉起来然后上层业务走ppp0。这套路本身没毛病但如果你把4G模块接到网口上让它做数据链路层通信你会发现另一片天地——链路更稳、吞吐更高、业务代码写起来也更接近传统socket编程。我最初接触这个场景是因为一块板子上的串口资源被别的外设占满了没法用AT指令通道刚好那块4G模块板载了一个网口官方资料里写着支持网口数据链路层通信。一开始我挺懵网口接4G模块这数据怎么走后来翻了不少手册、踩了几天坑才搞明白所谓网口链路层通信本质上是把4G模块当作一颗标准的以太网设备挂在主机网口下主机侧跑Linux自带的协议栈4G侧的拨号和数据转发由模块自己内部完成。今天就把这套东西从头到尾拆开讲一讲适合正在调试4G网口方案、或者准备把模块从串口模式迁移到网口模式的朋友。1. 为什么要把4G模块接在网口上链路层通信的适用场景1.1 串口AT与网口链路层的本质区别先理清两个模式的分工。串口AT模式走的是控制平面加数据平面混合通道拨号前用AT指令做上下文配置拨号后数据通道要么走PPP要么走TCP/IP透传。其中TCP/IP透传模式是模块内置协议栈主机通过串口收发数据模块负责和基站侧建立连接。这种模式的问题在于串口本身的波特率就是瓶颈。就算你拉到921600实际有效吞吐也就四五百kbps左右跑个图片流还凑合跑视频或者大文件上行就非常吃力了。另外模块内置协议栈对多路并发连接的支持通常比较弱建五六条TCP长连接就可能有连接被莫名其妙踢掉的情况。网口链路层模式则完全不同。主机把模块网口当成一张普通网卡Linux内核协议栈直接接管TCP/UDP的处理。4G模块只负责把IP包通过蜂窝网络收发不做协议栈层面的干预。主机侧所有对套接字的编程习惯直接沿用几百路并发连接的压力分摊给内核处理吞吐量也突破串口瓶颈。1.2 什么业务场景非它不可我实际接触过的场景里下面几类业务是最需要网口链路层模式的视频监控上传类。摄像头采集的码流动辄2-4Mbps串口AT透传根本扛不住网口模式配Cat.4/Cat.6模块上行吞吐能做到20-60Mbps甚至更高视频不卡顿。多路并发长连接类。比如车联网终端同时要连云端状态通道、报文上传通道、远程控制通道三条以上TCP连接需要长期保持。用模块内置协议栈连接一多就变得不稳定内核协议栈处理这种东西才是老本行。无串口资源的主控方案。很多工业主板的串口都被触摸屏、传感器、扫码枪占光了网口还剩一两个闲置这时候走网口链路层等于白捡一个高速数据通道。工业网关与边缘网关类产品。这类设备本身就需要对外提供以太网接口让下面的 PLC、传感器通过网线接入网关再统一通过4G模块上行。模块若走网口网关内部的以太网数据可以直接桥接上联不需要跨串口做协议转换延迟和数据完整性都好很多。2. 网口链路层通信的硬件拓扑与帧走向2.1 模块内部的MAC/PHY架构与RMII接口搞清楚硬件上网口是怎么接出来的是后面所有调试的基础。主流4G模块的网口方案通常有两种做法。第一种模块内部集成了以太网PHY通过RMII接口把PHY信号引出来主机侧需要自带MAC控制器。这类模块对外的管脚上有TX_EN、TXD[1:0]、RX_DV、RXD[1:0]、REF_CLK这五组信号外加MDC/MDIO管理接口。你在嵌入式平台比如带内部MAC的ARM主控或者独立MAC芯片上把对应管脚接到模块的RMII信号上主机侧就能枚举出一个以太网设备。内核设备树里配好mdio节点和phy节点就能通过MDIO总线读到模块PHY的寄存器。第二种模块内部不仅做了PHY还做了完整的以太网MAC和协议转换对外直接就是一个标准的RJ45座。主机侧不需要MAC控制器只要一根网线插上就能把模块当成一台独立的网络设备来访问。不管是哪种方案RMII接口的参考时钟都是50MHz由主机侧或者模块侧提供两边的REF_CLK必须同源否则链路根本起不来。我调试的那块板子就是主机侧提供50MHz时钟模块侧配置成从模式插上网线后Link灯才亮。2.2 一片网口上的数据帧到底长什么样数据链路层通信核心就是以太网帧。主机和4G模块网口之间流动的是下面这个结构目的MAC地址6字节 源MAC地址6字节 以太网类型字段2字节 数据载荷46到1500字节 FCS校验4字节。以太网类型字段非常关键0x0800代表载荷是IPv4报文0x0806代表载荷是ARP请求或响应报文。在链路层调通阶段你最先看到的应该就是ARP帧然后是ICMP帧最后才是真正的TCP/UDP业务帧。从4G网络侧下来的数据进入模块后模块会把IP包从蜂窝协议栈里剥出来然后封装成上述以太网帧格式发给主机。主机发给模块的数据则是把IP包填进以太网帧的载荷区域模块再拆掉以太网头放进蜂窝协议栈向上层发。整个过程对主机完全透明主机压根感觉不到对端是一张移动通信网卡。2.3 模块MAC地址的来源与坑每一块4G模块的网口都会有一个出厂MAC地址这个地址一般打印在模块的标签上或者通过特定AT指令可以读取例如某些系列模块用ATEAG.ETH.MAC?之类的指令查询。也有部分模块支持修改MAC地址但改了之后要注意不能在同一个二层网络里出现两个相同MAC。我踩过的坑是这样的一开始模块使用默认MAC地址主机侧抓包发现ARP请求能够得到响应源MAC却和标签上的不一样后来一查才知道模块固件在默认模式下会把MAC地址做一次映射转换。这种情况在批量出货时特别容易出现问题涉及MAC地址漂移所以如果产品有多个模块组网的需求最好提前把所有模块的MAC地址记录下来统一写入主机侧白名单或者做地址规划。3. 主机侧网口初始化从驱动到IP配置的完整链路3.1 检查主机是否识别到模块PHY拿到板子以后第一步先确认内核有没有识别到网口对应设备。Linux下直接看dmesg | grep -i eth ifconfig -a如果模块走的是RMII方案一般会在dmesg里看到类似eth1: phy attached的提示走独立网线方案的则会在PCIe或者USB枚举里出现一个网卡设备。ifconfig -a列出来的设备名字可能是eth1、enp3s0之类的取决于内核和设备树里的命名规则。接下来用mii-tool或者ethtool查看链路状态mii-tool eth1 ethtool eth1返回的Link detected: yes、Speed: 100Mb/s、Duplex: Full表示物理链路已经协商成功。如果Link detected: no大概率是RMII信号没接对或者模块PHY没上电检查REF_CLK是否能正常产生模块的供电电压是否达到规格要求。3.2 初始化网口的实际步骤链路物理层通了之后把网口拉起来其实是几行命令的事但顺序有讲究。我推荐的做法# 关闭自动协商协商强制100M全双工原因后面展开 ethtool -s eth1 speed 100 duplex full autoneg off # 启动网口 ip link set eth1 up # 配置IP地址 ip addr add 192.168.111.111/24 dev eth1 # 查看最终状态 ip link show eth1 ip addr show eth1这里有个细节很多4G模块的PHY并不支持千兆问题不大但有些模块PHY的自协商能力并不完善如果主机侧开着autoneg两边能力字对不上最终可能协商出10M半双工甚至协商失败。我的经验是直接两边都固定成100M全双工别让硬件自动协商做决定稳定性和排查问题都省心得多。3.3 动态获取IP还是静态IP这取决于模块的工作模式很多人在这里翻车。如果模块已经完成了拨号并且把自己配置成一台带DHCP服务的路由器主机插上网线就能自动拿到一个IP例如192.168.111.100。这种模式下你用dhclient eth1就完事了主机拿到的IP是模块LAN口分配的。如果模块只是作为一颗透明PHY或者说网卡转发设备拨号的动作是在主机侧完成的例如通过qmi-wwan或者RNDIS方式把拨号虚拟到网口上那么配置思路就完全不同了你面对的可能是一个带公网地址的PDP地址不再需要手工设置私网IP而是由模块把拨号获取的IP动态绑定到网口上。我一般先用一颗模块测试插上USB到电脑枚举成网卡再对比网口方案的枚举信息才能确认模块固件版本里到底是哪种工作模式。这个坑不搞清楚后面所有IP配置都是白搭。4. 链路层调通后的数据通道ARP、ICMP与TCP的验证排查4.1 ARP是链路层通信的第一道关卡网口up起来、IP配好了第一件事不是急着ping对端公网地址而是先确认同一个二层域里的通信。抓ARP包是最直观的方式tcpdump -i eth1 -e arp你会看到这样的过程主机发送广播ARP请求“谁是192.168.111.1请告诉192.168.111.111”对端模块网口回应单播ARP应答。关键在于观察应答帧里的源MAC地址。如果ARP响应始终不来先确认模块网口是否在同一个网段模块是不是开了MAC地址白名单功能或者模块LAN口侧是否配置了VLAN隔离。如果ARP响应来了但源MAC和模块标签上的MAC不一致就按前面说的查查模块有没有做MAC映射。这里分享一个反复验证过的规律链路层是否通的判断标准不是ping的通而是ARP能解析出对端MAC。只要ARP能通二层链路就已经完全打通了IP不通归因为IP配置或者路由问题。4.2 ICMP ping测试链路层时延的真实意义ARP通了之后就可以做ICMP测试ping -I eth1 192.168.111.1 -c 10这里看两个东西通不通和时延是否稳定。如果ping始终有去无回在确认ARP可以解析后大概率是模块侧把ICMP过滤了有些模块固件出于安全默认禁止LAN侧PING需要打开相关选项。如果时延忽高忽低幅度在几百毫秒甚至几秒之间那大概率是4G空口侧信道质量波动跟以太网链路无关你可以对比一下只ping模块LAN口地址和ping公网地址把两类时延分开看。关键经验是区分两条完全不同的通路主机到模块网口LAN口之间的通路本地二层链路和模块通过4G空口到公网的通路。前者延迟通常在1毫秒以内后者在30到100毫秒不等。如果你ping的是模块LAN口IPRTT很好但公网ping不稳问题在运营商网络或者模块天线端如果连模块LAN口IP都有几十毫秒延迟问题就出在模块内部协议转换上。4.3 TCP/UDP业务数据帧大小与MTU的纠缠链路层通了跑业务还会遇到一个经典问题MTU不匹配。以太网默认MTU是1500字节主机发出的帧载荷最大1500字节。但4G空口的承载能力通常只有1428到1480字节左右如果主机发出一个大小为1500字节的IP包在进入4G模块后需要做IP分片分片在公网传输中是非常糟糕的体验可能导致大量重传和乱序。解决办法有两类。第一类把网口MTU调小到1400或者1420ip link set eth1 mtu 1420 ping -M do -s 1392 192.168.111.1第二类在TCP连接维度钳制MSS。如果主机是服务端需要修改对端云服务器的TCP Max Segment Size如果主机是客户端可以在拨号脚本或者iptables里对SYN包做MSS钳制iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu这两个方法看场景选如果你的设备只有4G一条上联我建议直接用mtu 1400一劳永逸省去分片烦恼。实测在1420MTU下TCP下载吞吐能比1500MTU下分片传输高出10%到20%重传率明显下降。5. 实战踩坑网口链路层通信最容易翻车的三个环节5.1 PHY地址冲突导致MDIO读写乱套如果你的主板上除了4G模块还有别的以太网PHY比如另一路工业网口接的是普通PHY芯片那就比较容易遇到PHY地址冲突的问题。PHY地址由硬件管脚的电平决定常见取值0x00到0x1F。很多4G模块默认PHY地址是0x01如果你的板载加速PHY也用了0x01MDIO总线上就会出现两颗相同地址的PHY内核在设备树里配的那个phy节点实际访问的可能是另一颗芯片。表现就是ethtool看到的link状态异常或者速率显示完全不对读到的厂商ID也是另一家的。排查办法很直接用mii-tool或者直接读PHY寄存器0x02/0x03对照厂商ID找出真实设备。确认以后通过模块硬件配置管脚或AT指令把模块PHY地址改到空闲地址同时在设备树里改掉phy节点地址。5.2 模块PHY不支持自适应强制固定才是唯一出路另一个我踩得比较深的是自协商问题。有款模块的PHY芯片在桥接模式下如果主机侧开启自协商经过一段时间后链路会突然跌到10M甚至断开。最后发现根因是模块PHY固件实现的能力字不完整和主机MAC进行自动协商时双方互换能力字后无法收敛到两端都支持的100M Full。解决办法就是我前面说的主机侧强制固定成100M全双工关闭autoneg。模块侧如果也有对应配置项同样固定。这里提醒一句ethtool -s写配置只是内存态重启会丢要持久化得写到启动脚本里或者配到network-manager/ifupdown的配置文件里。# Debian系持久化配置示例 /etc/network/interfaces.d/eth1 auto eth1 iface eth1 inet static address 192.168.111.111 netmask 255.255.255.0 post-up /sbin/ethtool -s eth1 speed 100 duplex full autoneg off5.3 网口名称漂移与udev规则多网口设备最容易遇到的一个问题是板子上有eth0和eth1内存里网口注册顺序偶尔不固定导致4G模块对应的网口在本次开机是eth1下次开机变成eth2。如果你脚本里写死了eth1拔掉网线重插或者重新上电后业务就起不来了。解决方案是写udev规则根据MAC地址给模块网口绑定固定名称。先用ethtool -P ethX查询模块网口的永续MAC地址然后写一条规则SUBSYSTEMnet, ACTIONadd, ATTR{address}xx:xx:xx:xx:xx:xx, NAMEeth4g这样每次开机无论内核注册顺序怎么变模块网口稳定叫eth4g业务脚本直接引用这个接口名即可。量产阶段强烈建议都这么干别图省事省这几行配置。6. 调试工具链与链路层抓包经验6.1 tcpdump的链路层过滤与关键参数链路层调试tcpdump绝对是第一主力。几个参数组合要熟练# 显示帧级别信息包括源/目的MAC、帧类型 tcpdump -i eth4g -e # 只看ARP帧 tcpdump -i eth4g -e arp # 只看特定IP的ICMP帧 tcpdump -i eth4g icmp and host 192.168.111.1 -e # 把帧完整打印出来看载荷 tcpdump -i eth4g -XX -c 10其中-e参数看链路层是排查ARP问题的钥匙。-XX能同时显示十六进制和ASCII适合看你发给模块的IP包里面TCP头部的MSS选项。抓包时建议只开tcpdump不要同时跑iperf之类的压测工具否则缓冲区溢出直接丢包误判成网络故障。6.2 ethtool和mii-tool的输出解读ethtool eth4g只看下面几个字段就够Speed、Duplex、Auto-negotiation、Link detected。Speed是当前协商速率Duplex必须是FullLink detected yes代表物理层连接正常。如果Speed显示10Mb/s或者Unknown回看第5.2节的做法强制固定。mii-tool -v可以查看PHY状态寄存器原始值对排查自协商问题更直观。它显示的基本模式如100baseTx-FD代表固定百兆全双工negotiated代表启用协商。如果你看到basic mode: 10 Mbit, half duplex这种内容八成是自协商没关或者能力字出错。6.3 链路层连通性判定清单这里整理一张自检清单调网口链路层通信的时候照着一个个过检查项命令/方法通过标准PHY物理连接ethtool eth4gLink detected: yes协商速率ethtool eth4g100M Full由业务要求决定网口up状态ip link show eth4gstate UPMAC地址是否异常ethtool -P eth4g非全0非组播地址ARP解析tcpdump -e arp能抓到请求和应答二层连通性ping -I eth4g 模块LAN口IPRTT小于5ms四层连通性nc/iperf3 测试端口或吞吐端口可达且吞吐符合预期空口侧表现ping公网地址RTT和丢包率在可接受范围这张表是我后来每次调试新板卡都默认跑一遍的流程尤其是量产版本升级固件后先过一遍清单再进业务联调能省掉大量时间。6.4 抓包中的进度观察与误判排除最后分享一个抓包时特别容易误判的场景。你抓包看到大量同一IP的ARP请求重复广播第一反应可能是网络风暴但往往原因是对端模块侧的IP地址和另一台设备冲突或者对端没有配置网关导致无法回应。这时候先停下业务流量单独ping一下出问题的IP同时抓包统计响应帧是否来自预期MAC地址。另一种常见的误判是主机侧防火墙规则把ICMP甚至TCP连接拦截了你抓包只看到请求没有响应。链路层看到的是发送正常实际上内容被Netfilter丢掉了。排查时别只盯网口也要看一眼iptables filter表有没有对eth4g接口做DROP策略。调链路层通信这个事最大的经验就是分层排查物理层、链路层、网络层、传输层一层一层过每一层都有明确的判定依据不要想着一把梭把问题全部定位出来。我在实际调试中的习惯是第一步强制100M全双工第二步确认ARP能解析第三步检查IP路由第四步压测吞吐。按这个顺序走绝大多数网口链路层通信问题都能在半小时内定位剩下的大概率是模块固件或者运营商网络的锅那就不是换个网口配置能救得回来的了。