RK3588边缘盒子间歇性掉线排查：从PHY配置到IPv6协议的完整复盘

1. 掉线事故现场：现象分级与第一反应

做边缘盒子最怕什么？不是算力不够，不是算法精度差，而是设备在客户现场悄无声息地“失联”。我这边一台基于RK3588的智能边缘盒子，部署在某厂区做视频结构化分析，运行了大概三周，突然开始间歇性掉线。第一回是凌晨两点，值班同事打电话说平台侧显示设备离线，当时以为是网络抖动，远程重启了一下就恢复了。没想到之后几乎每隔一两天就来一次，每次掉线几分钟到十几分钟不等，有时候自己恢复，有时候必须手动断电。

这事的麻烦在于：边缘盒子承载的是实时推理业务，掉线期间所有视频流分析中断，告警漏报是大事。更头疼的是设备本身没有任何物理损坏迹象，系统日志也没有panic或oom的记录，完全不是那种“一眼就能定位”的崩溃型故障。

我开始整理现象特征：

• 掉线发生在业务低峰期，凌晨到清晨居多，白天偶发；
• 盒子的HDMI输出正常，本地界面能操作，只是网络不通；
• 路由器/交换机侧看端口状态，时而是link up，时而是link down；
• 设备IP能ping通的时候延迟正常，一旦掉线，网关都ping不通。

这几条组合下来，基本能排除应用层崩溃、CPU过载、内存泄漏这一类软件问题。问题大概率出在两个层面：要么是物理链路层（从RK3588的GMAC到PHY再到网口变压器和线缆），要么是网络协议栈层面（IPv4/IPv6双栈环境下的路由与邻居发现机制）。后面的事实证明，这两层都埋了雷，而且是我在前期选型和配置时埋下的。

复盘这件事之前，先讲一下这套盒子的硬件构成。主控是RK3588，8核，自带双千兆GMAC（Gigabit Media Access Controller），一个走PCIe转出，一个走内置GMAC+RTL8211F的PHY方案。操作系统是Buildroot裁剪的ARM64 Linux，内核5.10。业务侧跑着RKNN推理服务、视频拉流解码、MQTT上报客户端，还有一个Web后台。整个形态就是典型的智能边缘计算盒子，用网线接入客户的办公网，通过MQTT与云端平台保持长连接。

掉线问题一出，我第一时间想到的是RK3588这颗SoC的GMAC模块在部分板卡设计上存在信号完整性问题，但手头这块板子已经量产过一批，之前没出过类似故障，所以硬件先天缺陷的概率不高。我更怀疑是配置或者协议栈层面的问题，顺着这条线往下摸。

2. 第一轮快速排查：网络侧、供电侧、散热侧全扫了一遍

出问题先查硬件，这是嵌入式排障的铁律。排查顺序是供电—散热—网口物理层，因为这三样最容易快速排除，也最容易掩盖真实原因。

2.1 供电与散热：排除“假死”的物理诱因

RK3588是颗高功耗SoC，满负载场景下整板功耗能冲到15W以上。如果电源适配器余量不足或供电纹波偏大，SoC在负载波动时会出现瞬时电压跌落，轻则外设异常，重则系统重启。我让现场同事测了12V输入电压和核心供电纹波，示波器抓下来纹波在50mV以内，电压稳定在12.05V左右，电源这关基本排除。

散热方面，盒子的外壳是铝挤型材，RK3588通过导热垫贴合到外壳。现场环境温度表显示设备安装位置的温度大概32度，外壳摸上去温热但不烫手，系统内/sys/class/thermal/thermal_zone0/temp读出来在58度上下，远没到85度的降频阈值。散热也没问题。

2.2 网口物理层：测试仪、替换法、示波器三管齐下

接下来是网口链路。现场用的是超五类屏蔽网线，长度大约40米，我让同事换了一根成品六类网线直连核心交换机端口，故障依旧。又拿福禄克测了线缆的衰减和串扰，指标都在合格范围内。

然后我怀疑是RJ45座子和变压器虚焊，这种问题在量产板上时有发生。用示波器在PHY芯片的差分信号对上抓波形，眼图看着没有明显异常。RTL8211F的寄存器状态也通过mdio工具读取过，link状态和速度协商结果都正常。物理层这边花了大半天，没有找到硬伤。

2.3 系统日志与内核告警：一个反常的细节

排查这个阶段时我同步翻看了系统日志。dmesg里没有任何网卡驱动的报错，也没有链路up/down的中断记录。但有个细节引起了我的注意：systemd-networkd的日志里出现过几次IPv6地址的dadfailed（Duplicate Address Detection，地址重复检测失败）信息，时间是凌晨，正好与掉线时段吻合。

这个发现让我把视线从物理层转到了协议栈。IPv6地址重复检测失败通常意味着局域网内有其他设备使用了相同地址，或者路由器下发的RA报文存在冲突。边缘盒子的IPv6建议配置是slaac（无状态自动配置），如果客户网络里存在多个RA源或地址分配策略不一致，就可能出现dad failed，进而引发网络栈异常。

顺藤摸瓜，我再去翻网络侧的日志，发现掉线前后其实有router solicitation和neighbor solicitation的重传记录。也就是说：链路本身是通的，但三层以上的邻居发现和路由解析出了岔子。这个方向值得深挖。

3. 深挖RK3588 GMAC配置：设备树、PHY驱动与协商机制

既然物理层基本排除，我重新回到RK3588这颗SoC的GMAC模块，把设备树配置和PHY驱动逻辑从头捋了一遍。这里要提醒一句：RK3588的双千兆GMAC在设计上很灵活，但对应的设备树参数也很容易配错，很多“掉线”其实是配置和实际硬件不匹配造成的。

3.1 RK3588 GMAC与PHY的工作机制简述

RK3588内置两个千兆以太网控制器，一个支持RGMII/RMII接口，另一个支持RGMII接口。以我用的主网口为例，走的是RGMII接口连接外部PHY（Realtek RTL8211F），MAC和PHY之间通过RGMII总线通信，时钟频率125MHz（千兆模式）。

RGMII最典型的坑是TX和RX的时钟相位问题。RGMII标准规定数据在时钟的双沿采样，但MAC和PHY之间的时钟延迟（clock skew）必须用idelay和odelay参数调整。设备树里对应属性是tx_delay和rx_delay，单位是纳秒。这个参数如果配错，链路虽然能up，但高速数据传输时会出现随机CRC错误，严重时直接掉线。

我的板子设备树配置是：

&gmac1 { assigned-clocks = <&cru CLK_GMAC1>; assigned-clock-rates = <125000000>; phy-mode = "rgmii"; phy-handle = <&rtl8211f>; tx_delay = <0x2a>; rx_delay = <0x22>; status = "okay"; };

tx_delay和rx_delay的取值来自硬件设计时的PCB走线长度，这个参数不是拍脑袋定的，需要对照原理图和PCB的等长设计来计算。我的配置是基于原厂参考设计来的，理论上应该在安全范围内。

3.2 百兆协商下的隐患：千兆模式没问题，降速就出鬼

我排查时做了一个测试：把对端交换机端口强制成百兆模式。结果盒子这边的PHY跟着协商成100Mbps后，大流量传输时CRC错误计数蹭蹭涨，接着就是链路反复up/down。这个现象说明RGMII的时钟延迟参数在千兆和百兆两种模式下表现不一致。

为什么千兆正常百兆反而出问题？因为RGMII在千兆模式下时钟125MHz，在百兆模式下时钟25MHz，时钟频率不同，taps对应的实际延迟时间也不同。设备树里的tx_delay和rx_delay是按千兆模式调优的，切换到百兆时如果PHY内部的延迟补偿策略和MAC侧不匹配，就会出现数据采样窗口偏移。

针对这个问题，我做了两个动作：

• 查了RTL8211F的驱动源码，确认PHY在100Mbps模式下是否启用内部延迟（比如RTL8211F的DLD功能）；
• 把设备树里gmac1的rx_delay调大一档，观察百兆模式下的CRC错误是否下降。

实测下来，rx_delay从0x22调整到0x2a后，百兆模式下的错误包数量大幅减少。但尚未根治，偶尔还是会有个位数CRC错误。

3.3 PHY驱动里被我忽略的EEE功能

继续翻RTL8211F驱动代码时，我注意到一个默认开启的功能：Energy Efficient Ethernet（EEE，绿色以太网）。EEE允许链路空闲时PHY进入低功耗状态，收发器停止部分电路工作，在数据到来时重新唤醒。问题在于：EEE的唤醒过程涉及PHY和MAC之间的握手，如果MAC侧驱动没有正确配置EEE定时器或唤醒序列不兼容，链路会在低流量时段掉线。

Linux内核的phylib框架里，EEE的配置通过phy_eee_init函数实现。我确认了一下内核配置，发现CONFIG_PHYLIB和CONFIG_NETWORK_PHY_TIMESTAMPING都开了，但PHY驱动里没有显式禁用EEE。RTL8211F是支持EEE的，在低功耗模式下唤醒不及时，可能造成几秒到几十秒的通信中断。

处理办法是在设备树里给PHY节点增加eee-broken-100m属性，或者在驱动里强制关闭EEE：

&rtl8211f { compatible = "ethernet-phy-id001c.c915"; reg = <0x1>; eee-broken-100t; };

关于EEE的问题，我需要承认一点：它不一定是这次事故的主因，但绝对是一个隐藏的放大器。它让原本就脆弱不堪的链路在低流量时段更容易“睡死”过去。

4. 网络协议栈层面的元凶：IPv6邻居发现与默认路由老化

GMAC层面调整完之后，掉线频率有所下降，但并没有完全消失。这说明还有另一个独立的问题在叠加。回到之前发现的IPv6 DAD failed日志，我开始系统排查协议栈。

4.1 IPv6地址冲突与DAD机制

RK3588的Buildroot系统里，网络管理用的是systemd-networkd，默认会同时启用IPv4和IPv6。IPv6地址获取依赖RA（Router Advertisement），系统通过SLAAC机制自行生成地址。问题出在：如果客户网络里存在多个路由器或RA源，SLAAC生成的地址可能与其他设备冲突，触发DAD机制。

DAD机制是IPv6的安全策略：新生成的地址要发送neighbor solicitation来探测是否已被占用，如果在重传次数内收到neighbor advertisement回应，说明地址冲突，该地址会被标记为tentative并最终失败。日志里看到的dad failed就来自这个过程。

地址冲突的直接后果是：内核为该接口分配的IPv6地址不可用，依赖该地址的IPv6通信全部失败。如果MQTT或视频流走了IPv6路径，就会体现为“掉线”。

4.2 双栈环境下的路由策略陷阱

进一步排查，我还发现一个更隐蔽的问题：系统默认路由表的metric值设置不太合理。systemd-networkd配置中，IPv4默认路由和IPv6默认路由是分别管理的，但如果IPv6默认路由的metric值小于IPv4，应用层在发起连接时可能优先选择IPv6。客户内网的IPv6路由策略并不稳定，经常出现Ra报文延迟或丢失，导致IPv6链路时好时坏，业务流量也跟着遭殃。

我用ip -6 route命令看了当时的默认路由：

default via fe80::201:5cff:fe7f:9f19 dev eth0 proto ra metric 1024 expires 1624sec hoplimit 64

注意那个expires字段——IPv6默认路由是有生命周期的，由RA报文中的Router Lifetime决定。如果客户的RA发送间隔较长或者路由器出现瞬时故障，路由表条目过期后不会被立即刷新，这段时间内IPv6流量会全部黑洞。

而IPv4的路由是静态或者DHCP下发的，不存在这种老化机制。所以我这边看到的现象就是：业务流量有时走IPv4正常，有时被内核切到IPv6后碰上黑洞，表现为间歇性掉线。

4.3 我们是如何抓到这个元凶的

抓这个问题的过程不算曲折但需要耐心。我用tcpdump在盒子上同时抓了eth0的IPv4和IPv6流量，掉线期间观察到一个典型序列：

1. 盒子发送IPv6 neighbor solicitation（请求网关MAC地址）；
2. 网关没有回复；
3. 内核重传neighbor solicitation（重传间隔1秒，最多3次）；
4. 重传仍无应答，内核判定邻居不可达；
5. 此时IPv6默认路由失效，但IPv6路由条目还在，应用层发起的IPv6连接全部超时；
6. 老化的IPv6路由表一直没有被RA报文刷新，直到路由器下一次周期公告（有时是30分钟甚至更久）。

这就是为什么掉线后有时“自动恢复”需要等很久——不是网络通了，而是路由表终于刷新了。

5. 修复方案与实测验证：从设备树到系统配置的组合拳

定位清楚原因后，修复方案就水到渠成了。整套方案分成三层：设备树层的PHY/链路优化、网络栈层的IPv6策略调整、应用层的自愈机制兜底。每层都有明确的技术考量。

5.1 设备树层：固定千兆全双工，关闭EEE和控制延迟

对于边缘盒子这种固定部署场景，自动协商带来的不确定性远大于它带来的便利。与其让PHY在各种速率和双工模式间折腾，不如直接固定成最优模式。我在设备树里加了如下配置：

&gmac1 { phy-mode = "rgmii"; phy-handle = <&rtl8211f>; tx_delay = <0x2a>; rx_delay = <0x2a>; max-speed = <1000>; status = "okay"; }; &rtl8211f { compatible = "ethernet-phy-id001c.c915"; reg = <0x1>; eee-broken-100t; };

其中max-speed = <1000>让PHY在协商时只接受千兆模式，如果对端不是千兆端口则link不建立，而不是降速到百兆后靠调整延迟参数弥补。这个方案的代价是：现场必须确保交换机端口是千兆口。

关闭EEE则是为了杜绝低功耗唤醒带来的“睡死”现象。边缘盒子没有功耗压力，不需要绿色以太网来省那几瓦电，稳定压倒一切。

5.2 网络栈层：禁用IPv6 SLAAC自动配置或调整RA依赖

IPv6的问题，最彻底的策略是边缘盒子只跑IPv4。目前绝大多数边缘计算场景的业务（MQTT、RTSP、HTTP API）都走IPv4，IPv6不是刚需。与其在一个不可控的客户网络里和IPv6的各种机制搏斗，不如直接关了省心。

在systemd-networkd的配置文件中：

[Network] DHCP=yes LinkLocalAddressing=no IPv6AcceptRA=no

LinkLocalAddressing=no关闭链路本地地址，IPv6AcceptRA=no禁用IPv6前缀通告接收。这样系统完全不会配置IPv6地址，也不会依赖RA维护IPv6路由，所有流量默认走IPv4。

如果确实有IPv6业务无法绕过，退而求其次的做法是调整RA相关sysctl参数，延长邻居不可达检测时间和路由生命周期：

net.ipv6.conf.eth0.router_solicitations=3 net.ipv6.conf.eth0.router_solicitation_interval=4 net.ipv6.conf.eth0.router_solicitation_max_addresses=3 net.ipv6.neigh.eth0.retrans_time_ms=1000 net.ipv6.neigh.eth0.gc_stale_time=60

但说实话，对于边缘盒子这种嵌入式设备，IPv6带来的收益远小于它引入的复杂度，我建议默认关闭。

5.3 应用层自愈兜底：看门狗加业务探活

就算上面两层都做了，网络设备在不可控的客户现场仍然可能发生各种意外。所以应用层必须有自愈机制，不要指望现场有人手动处理。

我做了两件事：

第一，硬件看门狗。RK3588本身有看门狗定时器，用uname查一下/dev/watchdog是否存在。它的作用是：如果系统进入异常状态（比如内核网络栈死锁但进程还活着），看门狗能强制重启整机。这是最后一道防线。

第二，应用层网络探活。我在MQTT客户端之外单独写了一个网络探活脚本，每30秒ping一次网关和云端平台地址，连续5次失败就重启网络服务，重试3次仍然失败就重启系统。重启网络服务用的是ip命令和systemctl restart systemd-networkd，重启系统用的是reboot命令。

这个脚本的伪代码如下：

#!/bin/sh GATEWAY=192.168.1.1 CLOUD=10.10.0.8 fail_count=0 while true; do if ping -c 1 -W 2 $GATEWAY >/dev/null 2>&1 && ping -c 1 -W 2 $CLOUD >/dev/null 2>&1; then fail_count=0 else fail_count=$((fail_count+1)) if [ $fail_count -ge 5 ]; then systemctl restart systemd-networkd fail_count=0 fi if [ $fail_count -ge 15 ]; then reboot fi fi sleep 30 done

5.4 修复后的长期验证

方案落地后，我在实验室模拟现场环境跑了72小时压力测试，同时用pingplotter持续监控延迟和丢包，结果如下：

放到客户现场后，连续运行两周没有再出现掉线告警。这次的事故复盘到这才算画上句号。

6. 越线之后才明白的三条硬经验

每次排障都像一次大考，考完总得留下点东西。这次RK3588掉线事故给我最大的教训是：边缘设备的稳定性从来不是某一个单一环节决定的，它是硬件设计、内核配置、网络环境、应用架构四个层面共同作用的结果。

第一条经验：设备树里PHY的延迟参数和EEE配置，不能再照搬参考设计直接交付。每块板子的PCB走线长度、图层堆叠、PHY型号批次都可能影响最优参数，批量前必须用示波器和网络测试仪做一轮眼图和CRC压力测试。特别是EEE，建议在嵌入式产品里默认关闭，省那点电不值得拿可靠性作赌注。

第二条经验：IPv6不是配置项，是协议栈复杂度。很多客户网络看着是双栈环境，实际上IPv6基础设施做得一塌糊涂。边缘盒子要明确自己的网络依赖边界，不支持IPv6就直接关掉，不要在客户网络里小心伺候一套总是出状况的机制。做产品，减法比加法重要。

第三条经验：排障日志一定要有长期留存的意识。这次能快速定位，很大程度靠的是系统里还留着几周前的systemd-networkd日志。如果当时为了省Flash空间把日志轮转周期压缩到一天，DAD失败这个关键线索就丢了。边缘盒子的log存储别太抠，至少保留两周的完整系统日志。

接下来如果有时间，我会把这次排查中用到的脚本和内核配置整理成一套诊断工具包，方便现场快速定位类似问题。毕竟掉线这种事，谁也不想在凌晨两点被电话吵醒第二次。