以太网链路建立全解析：从PHY自协商到Linux驱动排查

大概在两三年前，我做嵌入式网络方案时遇到过一个很诡异的现象：明明网线是通的、交换机端口也亮着绿灯，但开发板里的Linux系统却一直提示“Link is Down”。更折腾人的是，等我把这套链路从PHY芯片、变压器、RJ45座子一路排查到驱动代码，才发现真正的问题出在“链路建立”这个概念被我想得太简单了。

很多人聊以太网，第一反应就是“插上网线就能上网”。可实际上，以太网从物理层到链路层真正建立起来，要经历一个完整的握手和协商过程。链路UP、协商速率、双工模式、FCS校验、驱动里的carrier状态——这些词背后串联起来，就是一条网线从“插上”到“能用”的全过程。这篇内容我就结合自己的实战经验，把这个过程从头到尾拆开讲清楚，特别适合正在做嵌入式网络开发、调试车载以太网，或者被“未建立以太网连接”这类提示折腾过的人。

1. 一条网线插下去，链路层到底发生了什么

很多人对以太网链路建立的理解停留在“看灯”——插上网线，网口灯亮，就以为链路通了。但从协议栈的角度看，网口灯亮只是PHY芯片层面的物理连接指示，离“链路建好”还差得远。

我把整个过程拆成了四个阶段，这样排查问题时才有清晰的方向：

第一阶段：物理信号的建立（物理层）
网线两端接好后，PHY芯片开始发送脉冲信号检测对方是否存在。普通100M/1000M以太网用的是“自协商”机制，PHY会不断发送被称为FLP（Fast Link Pulse）的快速链路脉冲，直到对面设备响应。这个阶段做的事情，通俗讲就是两个网口互相对暗号：你是什么速率？支持全双工还是半双工？能不能开流控？双方对完暗号，才能把物理层参数定下来。

第二阶段：链路同步（链路层底层）
物理参数协商好后，MAC控制器开始向对端发送空闲帧和同步码。对端接收到连续的合法空闲信号后，会锁定时钟并同步接收状态机。这个阶段如果出了问题，表现通常是PHY已经报告Link Up，但设备就是收不到任何有效数据，或者网络时通时断。

第三阶段：协议栈感知（驱动层）
物理链路和MAC层的同步都就绪后，网卡驱动程序会通过MDIO/MDC管理接口读取PHY寄存器，确认链路状态，然后向操作系统协议栈上报carrier on事件。Linux下这条路径就是netif_carrier_on()，协议栈收到这个信号，才会认为“物理网络已连接”，进而触发DHCP等上层流程。

第四阶段：IP层配置（网络层）
链路建立只是底层通了，真正要通信还得有IP地址。不管是用DHCP自动获取还是手工配置静态IP，这一步都依赖前三个阶段全部正常。所以“未建立以太网连接”这个提示，可能发生在任意一个阶段，绝对不只有网线断了这一种原因。

展开说一个实际案例。我用STM32F407配合外挂LAN8720A PHY芯片做项目时，遇到过“PHY寄存器显示Link Up，但Ping不通网关”的情况。后来查代码发现，我虽然等到了Link Up中断，但MAC的MACCR寄存器里配置的全双工模式没有跟随自协商结果更新——PHY协商出来是100M Full Duplex，MAC却还在用10M Half Duplex的配置，等于两边的收发时序完全对不上。这就是典型的“物理层到位，链路层没跟上”的坑。

所以，链路的建立不光是插线亮灯，而是物理层协商、MAC层同步、驱动确认、协议栈接管四个环节全部打通的结果。排查问题的时候按这个链路逐层往下看，效率比乱猜高得多。

2. 物理层握手：自协商、双工模式与“暗语”细节

链路建立过程里最容易出问题、也最让人头疼的，就是物理层自协商环节。我先讲讲自协商的底层逻辑，再讲几个常见的坑。

2.1 自协商是怎么“对暗号”的

IEEE 802.3规定，双绞线以太网（10/100/1000BASE-T）的设备在链路空闲时，PHY会以约16ms的间隔发送一组FLP脉冲。FLP里包含一组被称为“Next Page”的数据字段，里面描述了本端支持的速率、双工模式、流控能力、是否为Master时钟等关键参数。

协商过程简单来讲是这样的：

1. 设备A发送FLP，宣告自己支持“10M半双工、10M全双工、100M半双工、100M全双工、1000M全双工”。
2. 设备B接收到FLP后，echo一串响应脉冲，同时把自己的能力也发过去。
3. 两端各自把双方的能力做交集，选取优先级最高的 common mode，完成协商。
4. 协商完成后，PHY内部状态机会进入Link Up状态，并通过硬件引脚或寄存器通知主控。

这里要注意一个细节：自协商优先级是明确写在协议里的。比如对于1000BASE-T，全双工优先级高于半双工；100M全双工高于100M半双工；10M全双工又高于10M半双工。也就是说，只要两边都支持全双工，就一定会协商成全双工，不会出现“明明都支持全双工却协商成半双工”的情况。

但现实中的坑在于：自协商不是必选的。如果你的设备或对端被强制在固定速率和双工模式（也就是关闭自协商，强制设为100M Full），而另一端还开着自协商，问题就会变得非常隐晦。

2.2 速率与双工不匹配的典型症状

强制双工+自协商这种组合，除了协商不到一致参数外，最典型的后果是“能通，但很痛苦”。

• 速率不匹配时：链路可能根本无法建立，或者建立后立刻断开重协商，表现为网口灯亮一下灭一下，反复横跳。

• 速率一致但双工不匹配时：一端是全双工，另一端是半双工。全双工端认为自己随时都可以收发，半双工端却会因为“检测到冲突”而退避。带来的结果就是丢包率奇高、延迟抖动剧烈，传输大文件时尤为明显，但Ping小包可能只丢几包甚至不丢。

这个现象很有迷惑性，尤其是排查基础网络问题时，ping个几百包只丢几个，很容易让人怀疑是网线干扰而不是配置问题。我在测试车载以太网节点的时候就遇到过这种情况：两个ECU之间Ping小包几乎全通，但一上视频流或者批量诊断数据就疯狂重传，最后发现是测试台架的交换机端口被人手工强制成了100M Half，而ECU侧自协商成了100M Full，两边都在“自以为能发”，冲突和丢弃自然不可避免。

2.3 时钟协商与Master/Slave

千兆以太网的协商里还多了一层“谁做主时钟”的问题。1000BASE-T使用的是四对线同时双向传输，需要一对时钟源，所以协议里通过自协商确定一端是Master，另一端是Slave。

如果两端的PHY在自协商时都把自己配成Master（或者因为某种原因无法协商出主从关系），千兆链路的时钟就会错乱，表现为永远无法Link Up。这个问题在自研硬件时很常见——很多国产PHY芯片缺省配置是“Master Prefer”，如果两端都用默认值，本来应该自动协商出主从，但某些片子固件实现不完善，就会卡在这个环节。

我调试RK3399和RTL8211搭配的板卡时，反复出现“百兆能链上，千兆链不上”的怪问题。排查到最后，就是PHY的Master/Slave配置问题。解决方式是手动设置一个Port作为Slave，或者调整AN的Advertised能力值让优先级分配更合理。类似这种看起来“玄学”的问题，根因往往都在自协商机制的这些边边角角。

2.4 PHY芯片状态寄存器怎么反映协商过程

排查链路建立问题时，不要只盯着网口灯，要学会直接读PHY寄存器。IEEE 802.3定义了一系列标准寄存器，其中几个跟自协商/链路状态强相关：

调试时最常用的判断逻辑是：

1. 读0x01寄存器的第2位，判断链路是否在物理层已经建立。
2. 读第5位，判断自协商是否完成。
3. 读0x05寄存器，看对端宣告的能力，核对和自己的期望是否一致。
4. 如果0x05读出来全是0，说明对端根本没在协商——很可能是对端关闭了自协商或硬件异常。

我在排查很多“灯亮但网络不通”的问题时，都是靠这条寄存器读链直接定位的。比如有一次客户反馈某工控机开机有概率连不上网络，读0x01发现Link状态在第2位反复跳变，再进一步抓FLP波形，发现是电源纹波过大导致PHY芯片复位不稳定。寄存器读出来的现象，比看灯可靠得多。

3. 链路层的信封规则：前导码、MAC地址与FCS校验

物理层协商完成、链路同步建立后，数据开始在MAC层以“帧”为单位传输。这部分的封装规则值得仔细讲讲，因为很多上层应用的疑难杂症，最后都能追溯到帧格式上。

3.1 以太网帧的标准结构

传统以太网帧（DIX Ethernet II）的标准结构是：

• 前导码（Preamble）：7字节，内容为10101010…交替的比特序列，用于接收端时钟同步。严格说前导码不属于帧的一部分，但它是接收端能够开始解析数据的前提。很多基带抓包工具里看不到这段，因为它已经在PHY层被剥离了。
• 帧起始定界符（SFD）：1字节，内容为10101011，表示“帧真正开始了，后面的就是目标地址”。
• 目的MAC地址：6字节。
• 源MAC地址：6字节。
• 类型/长度字段：2字节。大于等于0x0600视为类型字段（如0x0800代表IPv4、0x0806代表ARP），小于这个值视为长度字段（这是802.3标准用法）。
• 数据：46~1500字节。不足46字节时需要填充（Padding），保证整帧长度满足最小帧长要求。
• 帧校验序列（FCS）：4字节，采用CRC32算法，覆盖从目的MAC到数据区结尾的全部内容。

3.2 FCS/CRC32到底校验了什么

FCS字段是很多人容易忽略、但实际非常重要的一环。接收端的物理层或MAC控制器会重新计算收到的数据（目的地址到数据末尾）的CRC32，和帧尾的FCS做比对，不一致就丢弃该帧并计入“CRC Error”统计。

这个机制是链路可靠性的最后一道防线。PHY层可能因为信号干扰、串扰、阻抗不匹配等原因导致比特翻转，如果只有数据链路层而不做CRC校验，错误数据就会被上层当成有效数据使用，后果会很严重。所以FCS可以说是以太网帧“验货盖章”的环节。

在测试中，我经常用打流仪或者FPGA构造CRC错误的帧注入网络，检测交换机和网卡的纠错行为。一个合格网卡会把坏帧直接丢弃，不会上报给上层协议栈；但有些质量较差的PHY或MAC实现，会出现“坏帧漏检”，导致上层收到CRC不对的数据包。这种故障在汽车以太网测试中尤其要严格把关，因为它直接影响ECU的诊断可靠性和安全机制。

需要补充的是，千兆以太网还增加了“前向纠错”机制，但那是物理层编码层面的事，和链路层的FCS检查是两套互相独立、又互相配合的机制。物理层尽量保证0和1传对，链路层负责发现漏网之鱼。

3.3 最小帧长、冲突域与填充的由来

以太网帧为什么数据部分最短要46字节？这跟半双工模式下的CSMA/CD机制有关。早期以太网是共享总线结构，设备发送数据时要监听信道，发送过程中如果检测到冲突，必须立刻停止并发送阻塞信号。为了保证发送端在发出最后一个比特前能感知到远端冲突，最小的帧长必须保证“覆盖整个冲突域的两倍传播时延”。

10M以太网的冲突域最大约2500米，算下来最小帧长就是64字节（不含前导码和SFD），所以数据段最短就是64-18=46字节。现在全双工交换网络已经很普遍，这种限制的原始意义弱化了不少，但帧格式一直沿用至今。

理解这一点对排查问题有帮助——如果你用FPGA自研MAC发送短帧，不填充到46字节就发出去，很多交换机和网卡会直接丢弃，因为从它们看来这根本不是合法帧。我就见过同事用IP核发UDP包，数据只有几个字节，没做Padding，结果抓包软件能看到，但对端协议栈一概不理，查了很久才找到原因。

3.4 实践中的帧格式偏移：VLAN标签与巨型帧

实际抓包时看到的帧，往往和理论帧格式有出入，最常见的就是VLAN标签。802.1Q会在源MAC和类型字段之间插入4字节的Tag（包括TPID和TCI），这样内核和交换机就能识别帧所属的VLAN。

这意味着CRC计算时要把VLAN Tag一并纳入计算范围。对抓包工具来说，VLAN Tag的存在会影响解析器判断“哪一段是有效载荷”。排查“明明ARP能通、Https不通”这类诡异问题时，可以优先看看是不是VLAN ID配置不一致，或者某个端口被TAG成奇怪的VLAN ID。

还有巨型帧（Jumbo Frame），超过1500字节的载荷需要两端网卡和交换机都支持，并且统一设置MTU。如果链路一端MTU是1500，另一端是9000，数据包会在转发过程中被丢弃，产生“小包正常、大包全丢”的经典故障。

4. 从PHY到MAC：MDIO寄存器、中断与驱动配置

物理层协商完成只算链路建立了一半，MAC控制器必须通过管理接口感知到PHY的状态，并且正确配置自己的收发参数，链路才真正被“操作系统”承认。这一节重点讲PHY和MAC之间怎么交互，以及驱动里那段“感知链路建立”的代码逻辑。

4.1 MII、RMII、RGMII接口怎么选

MAC和PHY之间的数据传输接口主要有MII、RMII、GMII、RGMII几种。选择哪种接口会影响链路建立时的时钟配置和引脚占用。

• MII：100M时用25MHz时钟，数据位宽4位，收发各用4根线，加上时钟和控制线，引脚数约16根。
• RMII：50MHz时钟，数据位宽2位，收发各2根，引脚数大幅减少，是STM32这类MCU常用方案。
• GMII：千兆接口，数据位宽8位，125MHz时钟，引脚多。
• RGMII：千兆接口，数据位宽4位，DDR方式上下沿都采样，125MHz时钟，引脚数介于MII和GMII之间。

这里有一个选型上的关键点：PHY芯片的时钟来源。

以STM32F407搭配LAN8720A为例，RMII接口需要一个50MHz的参考时钟。这个时钟可以由MCU提供，也可以由外部有源晶振提供，但两边的电气规格必须匹配。很多新手画板时图省事，随便接了个50MHz晶振，结果PHY芯片的REF_CLK输出脚和MCU的RMII时钟输入信号相位对不上，导致MAC和PHY的采样时钟不同步——链路层能物理UP但通信就是异常。

我个人做F407方案时，选的路径是让LAN8720A的时钟从外部晶振输入，MAC侧用MCU的RMII模式，并把50MHz时钟从PHY芯片的CLKOUT引脚回给MCU的ETH_RMII_REF_CLK。这样的话MCU和PHY共享同一个50MHz参考源，时钟天然同源，链路建立后的数据收发帧时序比较稳定。实测下来比“MCU单独给PHY喂时钟”的接法少了很多莫名其妙的偶发丢包。

4.2 MDIO管理接口：读PHY状态的门把手

MDIO（Management Data Input/Output）是MAC侧用来配置和监控PHY寄存器的串行管理接口，通常带一条MDC时钟线，最高速率2.5MHz。

MDIO的帧格式很有意思：前导码、起始码、操作码、PHY地址、寄存器地址、数据等字段一应俱全。操作码2表示读操作，1表示写操作。驱动代码里只要按时序往MDIO接口写地址字和命令字，就可以拿到任意寄存器的当前值。

驱动初始化PHY的标准流程一般是：

1. 复位PHY（拉低RESET引脚或写BMCR的第15位）。
2. 等待PHY复位完成（一般需要几十毫秒）。
3. 读PHY ID寄存器（寄存器2和3），确认PHY芯片型号，防止板级兼容性问题。
4. 配置ANAR（0x04寄存器），设置本端要通告的速率和双工能力。
5. 写BMCR，启动自协商（置第12位为1，同时清零第15位）。
6. 轮询BMSR（0x01寄存器），等待自协商完成和Link Up。

这套流程几乎是所有以太网驱动的标准操作，不管你是用Linux下的PHYLIB框架还是裸机开发，底层要处理的寄存器顺序大差不差。

4.3 中断还是轮询：链路状态变化怎么被感知

链路建立是个“事件”，不是个“常态”。网线被拔掉、对端断电、速率被重新协商，这些都要让CPU第一时间知道。

常见的感知方式有两种：

• 轮询：周期性地读PHY的状态寄存器，发现Link状态位变化，就触发相应处理。
• 中断：PHY芯片的INT引脚在Link状态变化时拉低（或拉高，取决于配置），MCU收到外部中断后去读寄存器确认。

我在Linux设备树里调驱动时，更倾向于用中断方式，因为轮询会让驱动的延迟不确定，而且如果网线抖动频繁，轮询在检测速度上会明显滞后。但中断也有坑：如果PHY的中断引脚被复用到其他外设，或者INT引脚浮空导致乱触发，反而比轮询更折腾。所以硬件设计时一定要给PHY的INT引脚留默认上拉，并检查是电平触发还是边沿触发，避免一上电就疯狂进中断。

4.4 驱动里“网线插上了”是谁上报的

在Linux环境下，PHY驱动检测到链路建立后，会通过PHYLIB框架调用phy_attach和phy_start，然后触发netdev->netdev_ops->ndo_open之类的回调，最终调用netif_carrier_on(dev)函数。

netif_carrier_on这个函数名翻译过来就是“网络设备载体（也就是物理链路）已建立”，它让协议栈认为“物理连接可用”，可以开始尝试DHCP或者发送数据。反过来，当检测到链路断开（Link Down），PHYLIB会调用netif_carrier_off，协议栈立即停用该接口，路由表也会相应调整。

所以如果你在嵌入式设备上“插上网线但ifconfig看不到link”，不要先去查DHCP，优先看看ethtool eth0输出的Link detected: yes/no。如果显示yes但系统还是不通，再查IP和路由；如果显示的no，证明问题在PHY层或更底层，上层怎么配都没用。

4.5 硬件电路设计中的链路建立相关细节

接口电路设计里，变压器、共模电感、下拉电阻这些细节，也会直接影响链路能否建立。比如STM32F407参考设计里，RJ45座子的中心抽头通常要接一个75Ω的电阻到地，或者接电源，具体要看PHY芯片要求的共模电压。

另外，很多PHY芯片都支持通过外部电阻配置PHY地址（RX_ER/RXD0等引脚的上/下拉）。如果PHY地址配置错了，MDIO命令里的PHY地址就对不上，驱动会一直读不到PHY ID，链路自然建立不起来。这类问题很隐蔽，因为硬件看起来完全正常，灯也会亮（灯是PHY自己驱动的，和MAC是否访问无关），但就是无法通信。

调试时可以先用示波器量MDC和MDIO波形，确认有没有读写操作在跑；如果波形都没有，说明驱动根本没探测到PHY，重点检查PHY地址和复位引脚时序；如果波形有但读出来全FF，检查PHY的供电和时钟是否正常。

5. 实战排查：Linux终端里一条链路断连的完整诊断链路

无论跑在服务器上还是嵌入式板卡上，Linux都是以太网调试最趁手的工具环境。我从实际踩坑的路径出发，串一条完整的排查链路，遇到“网络不通”时照着这个顺序走，能省大量时间。

5.1 用ethtool一键看穿物理层和链路层

ethtool是排查以太网物理链路和协商状态的第一工具。常用命令如下：

bash复制# 查看端口基本信息、速度、双工、link状态
ethtool eth0

# 查看网卡驱动和固件信息
ethtool -i eth0

# 查看统计计数器（丢包、CRC错误等）
ethtool -S eth0

输出里最关键的几行：

如果Link detected: no，说明问题在物理层：检查网线、PHY芯片供电、对端端口是否UP。如果Link detected: yes但ping不通，就把注意力放到MAC/驱动/协议栈上。

ethtool -S的统计信息里，rx_crc_errors、rx_frame_errors、rx_missed_errors这几项尤其值得关注。如果CRC错误数持续增长，基本可以断定网络上存在坏帧源，可能是网线质量差、电磁干扰、或者某个端口在发畸形帧。

5.2 从系统路由到ARP再到协议栈的逐层确认

物理链路OK之后，按下面顺序逐步确认：

bash复制# 1. 确认网卡没有被管理员禁用
ip link set eth0 up

# 2. 确认网卡拿到了IP
ip addr show eth0

# 3. 确认路由表存在
ip route show

# 4. 确认能ping通网关
ping -c 3 192.168.1.1

# 5. 确认ARP表项存在
arp -n

这里有一个常见的坑：Linux把“有没有插网线”和“接口是否被启用”看作是两回事。即使ip link set eth0 down，物理层一样会协商并Link Up，因为PHY的电源和自协商是常开的；但此时系统不认为这个接口可用，上层报你也看不出来。所以排查前先确认接口是UP的。

5.3 为什么Windows会提示“未建立以太网连接”

Windows下的提示其实对应到Linux就是Link detected: no加上接口未就绪的状态。我遇到过的触发原因主要有几类：

• 物理层没通：网线断、接触不良、对端设备被断电。
• 自协商失败：一端强制速率、一端自动协商，导致两边互相识别不了。
• 网卡被禁用：设备管理器里网卡处于停用状态。
• 系统策略或服务异常：比如DHCP Client服务没启动，IP一直拿不到，系统会误报“未识别网络”。
• 驱动异常：网卡驱动没有正确启动，PHY状态读不到，链路状态一直为Down。

针对这些，Windows下可以按顺序操作：先查设备管理器网卡是否正常，再用ping 127.0.0.1确认TCP/IP协议栈，再ipconfig /all看是否有IP，最后用驱动自带的诊断工具检查物理层。

5.4 一个完整的“线是好的但网络不通”排查实录

我举个之前处理过的案例。客户反馈一块工控板在特定批次网线上出现Ping延迟飙升、偶发掉线。我当时的排查路径是：

1. 先看ethtool eth0，Link、Speed、Duplex都没问题。
2. 看ethtool -S eth0，发现rx_crc_errors在几个小时内累计了几千个。
3. 换一条知名品牌的成品网线，CRC错误大幅下降但仍有增加。
4. 用网络分析仪抓波形，发现发送端信号的上升沿存在明显过冲和振铃。
5. 最终定位到PHY芯片的驱动电流配置偏高，加上PCB走线阻抗偏大，导致信号的反射叠加。

解决方案是在PHY寄存器里调低了输出驱动强度，并修改PCB设计增加共模电感。这类问题属于“物理层能建立链路、但信号质量不过关”的典型，链路建立只是门槛，真正决定稳定性的还是信号完整性。

5.5 用tcpdump和Wireshark验证链路层与网络层的衔接

当链路和IP都正常，但业务依旧不通时，抓包是唯一能确定真相的手段。Linux下用tcpdump抓包非常直接：

bash复制# 抓取eth0上所有报文
tcpdump -i eth0 -nn

# 只抓ARP
tcpdump -i eth0 -nn arp

# 只抓特定主机的ping
tcpdump -i eth0 -nn icmp and host 192.168.1.100

抓包看到的报文如果只有发出、没有回应，重点排查对端有没有收到；如果对端有回应、但本机收不到，重点查防火墙和路由；如果抓包完全没有任何报文，问题在驱动或物理层的概率更高。

举个例子，有一次我调试两块开发板直连，ping不通。抓包发现本机一直在发ARP请求，但对端板子也抓不到ARP请求——这意味着ARP请求压根没出本机网卡，最后查出来是网卡驱动里的环形缓冲区配置太小，系统把数据包都丢了。这类问题不抓包根本无从下手，因为每一层的状态看起来都正常。

6. 链路建立后的进阶场景：车载以太网、故障注入与AUTOSAR

链路建立的概念，放到车载以太网这个场景里会有不小的变化。很多做传统以太网的人第一次接触车载以太网时，都会因为100BASE-T1的机制差异而踩坑。

6.1 车载以太网和普通以太网的物理层差异

传统以太网是点对多点或通过交换机互联，而车载以太网（如100BASE-T1）使用单对双绞线，物理层编码从曼彻斯特编码换成了PAM3，传输方式也从“差分信号双向同时”变成了“单对线半双工回波抵消”。这意味着以下几点：

• 链路建立的协商方式不一样。100BASE-T1虽然没有传统意义上的FLP，但也有一套基于PHY的同步机制，包括Master/Slave确定、信号振幅校准、回声消除自适应等步骤。
• 连接方式几乎都是点对点，不经过交换机（除非是带有交换功能的网关）。
• 电磁兼容要求更高，所以物理层测试标准和安全要求也更多。

如果你用普通百兆以太网的思路去调100BASE-T1，会发现PHY Link Up的时间明显更长，因为多了信号校准阶段。而且它对线缆质量非常敏感，双绞线的绞距、屏蔽层、连接器工艺都可能决定链路能不能建立。

6.2 车载以太网里的AUTOSAR协议栈怎么管理链路

AUTOSAR针对以太网定义了一套完整的分层：

• EthDriver：最底层的以太网驱动，负责硬件收发和中断处理。
• EthIf（Ethernet Interface）：对上层提供统一的接口，并管理多个EthDriver。
• EthTrcv：PHY收发器驱动，负责链路建立、唤醒/睡眠等。
• TcpIp模块：实现TCP/IPv4和IPv6协议栈。
• SoAd（Socket Adaptor）：做Socket层适配，为上层服务提供通信通道。
• DoIP（Diagnostic over IP）：基于以太网的诊断协议。

在车载ECU中，链路建立的过程通常体现为EthTrcv驱动初始化PHY、等待Link Up、唤醒网络协议栈这一套流程。AUTOSAR的EcuM状态管理也会参与进来，比如在睡眠/唤醒状态转换时，重新初始化PHY并完成链路协商。

调试车载以太网时有个实用的技巧：直接用CANoe的以太网接口连接ECU和PC，在CANoe里配置好“以太网会话”后，它会把内部当做一对虚拟网卡和物理网卡桥接。如果你配置后CANoe里显示Link为Up，但PC侧网络不可达，多半是DoIP或者TCP/IP路由的问题，而不是物理链路问题。如果CANoe显示Link为Down，才需要回头查PHY、线束或唤醒信号。

6.3 在测试中向链路注入异常：制造CRC错误帧

车载电子电气开发中，有一种合法的测试手段叫“故障注入”，用来验证ECU对网络异常的处理是否足够健壮。比如通过CANoe或其他专业工具，在以太网帧里人为篡改数据、破坏FCS校验、删除前导码、构造超大帧，模拟真实线束环境中可能出现的错误帧。

这类测试是台架试验、产线验证和整车测试中必不可少的一环，目的是确保ECU在信号被干扰时能够安全降级，而不是直接进入非预期状态。测试流程一般是：

1. 在实验室台架上，用可编程故障注入设备串联在ECU的以太网链路上。
2. 让其透明传输正常流量，统计基线错误率和时延。
3. 开启注入功能，按设定的频率和概率篡改特定报文、破坏CRC、或插入错误VLAN Tag。
4. 观察ECU的协议栈行为，是否出现丢帧、复位、错误上报、安全降级等。
5. 对照需求规范，验证ECU的诊断策略是否按预期触发。

我在实际执行这类测试时发现，很多ECU能正确处理普通CRC错误帧，但一旦错误帧伪装成“带合法IP头的畸形TCP报文”，就会让某些协议栈实现出现CPU占用飙升甚至死锁。这也是为什么故障注入不能只做物理层，要把链路层和网络层的异常系统性覆盖。

需要特别说明的是，故障注入是行业通用的开发验证手段，在受控的实验室环境中用以测试和验证系统可靠性，而不是用于攻击或破坏任何外部网络。做这类工作时一定要清楚自己用在什么环境、目的何为。

6.4 车载以太网的链路建立超时与唤醒

车载以太网还有场景和普通以太网显著不同：网络不是在车一上电就全部建立等待。ECU会通过“唤醒”机制来按需建立网络链路，比如用户在车门外按了解锁键，才唤醒一部分ECU并建立以太网连接。

所以车载以太网的链路建立是有严格的“时序预算”的——从唤醒信号到PHY Link Up再到IP层可用，通常要求在几百毫秒内完成。如果PHY的初始化时间太长或者自协商超时，就会影响整车的网络启动时间，导致相关功能启动慢或诊断超时。

我在调一台域控制器的以太网启动时序时，就发现PHY的复位时序写得太激进：驱动在PHY复位完成前就去写寄存器，导致PHY配置丢失，链路建立一直不成功。后来在复位后增加了至少50ms的延时，再轮询PHY的ID寄存器确认就绪，问题才解决。这类细节在量产项目中非常关键，因为每次上电都要“卡点”完成链路建立。

7. 链路建立踩坑记录：从灯亮到真正常的最后一公里

链路建立这个话题，说到底是“从物理信号到协议栈感知”的最后一公里。这一节我不打算做总结，就分享几个我在多个项目里反复踩过、后来变成固定排查习惯的点，希望对你有直接帮助。

7.1 “MTU不一致”导致的长帧丢包

有次调试两个设备互传文件，小文件正常，几MB以上的文件必失败。抓包发现TCP层在传输大文件时会发满1500字节的帧，而这两个设备的MTU一个默认1500，另一个却设成了1400。结果超过1400的帧在MTU较小的设备上被直接丢弃，TCP重传反复超时，最终连接断开。

排查思路很简单：ping -M do -s 1472 测试大包能不能穿过去，逐级递减包长找上限。两端的MTU统一后，问题立即消失。链路建立后，MTU是比大多数人预想中更隐蔽的坑。

7.2 交换机端口安全策略把链路“半掩”住

有些交换机默认开启了端口安全或风暴控制策略，如果端口接了过多MAC地址，或检测到广播风暴，会自动关闭该端口或限制转发速率。这时链路从物理层看是UP的，但业务报文会被交换机拦截，表现就是“插着网线但上层怎么都ping不通”。

排查方法是在交换机上查看端口状态和丢弃计数器。如果无法登录交换机，可以换个普通无管理交换机对比测试。工业现场这类策略配置导致的问题非常常见，链路层、物理层都正常，但交换机在中间“卡了一刀”。

7.3 网线质量与屏蔽层接地对链路稳定性的影响

最后再提一下线缆这个“最便宜也最容易被忽视”的环节。我做过一次简单试验：同一台设备，分别用三类网线测试，结果显示劣质网线在较短距离内也能满足基本通信，但一旦进入百兆以上速率并传输大数据包，丢包率差异会急剧扩大。

• 超五类和六类线在100米内的性能差异不明显，但六类线的串扰余量更大，更适合有一定干扰源的工业环境。
• 屏蔽网线的屏蔽层必须正确接地，否则反而会成为天线，把干扰耦合进信号里。
• 网线弯折半径过小、压线钳压得不好，都会导致近端串扰超标，链路建立虽然没问题，但长期稳定性堪忧。

我在车载环境下调试时，还遇到过线束被座椅支架压损、导致PHY经常重新协商的案例，外表看线皮完好，但内部的线对已经断裂。遇到“链路反复up/down”而又查不到软件原因时，强烈建议把怀疑重点放到线束上。

链路建立是网络通信中最基础、也最容易被轻视的一环。我把这些年在物理层协商、MAC/PHY交互、Linux驱动诊断和车载以太网测试方面的经验都整理出来了，希望能帮你少走些弯路。尤其是刚开始做嵌入式网络功能的朋友，建议先把文中的寄存器读链和ethtool排查流程跑熟，再遇到“灯亮但网络不通”这类问题，就不会再靠玄学猜了。