单板计算机上手之后，最先要打通的外设往往不是屏幕也不是摄像头，而是网口。ArmSoM 基于 Rockchip 芯片的系列板卡，出厂系统里以太网基本都是开箱即用的状态，插上网线、看灯闪烁、拿到地址，三步就能跑起来。但真到项目里，事情就没这么简单了：有人遇到插线不亮灯，有人千兆网口只协商到百兆，有人做工业现场设备需要固定 IP 却每次重启都变，还有人想测吞吐量却不知道该怎么压。这篇内容就围绕 ArmSoM Rockchip 系列板卡的 Ethernet 使用展开，把从硬件识别、系统配置、静态地址设置、性能测试到故障排查的完整链路讲清楚，适合刚拿到板子的新手，也适合正在做产品落地的工程人员参考。文中涉及的命令和配置思路，均基于这类板卡常见的 Linux 系统环境整理，具体型号的接口数量与 PHY 方案以实际板卡为准。

1. 先搞清楚板子上的网口是什么来路

1.1 为什么第一步不是插线而是查硬件

很多人拿到板子第一反应是插网线看能不能上网，这个习惯在 PC 上没问题，在嵌入式板卡上容易吃亏。Rockchip 系列 SoC 的以太网控制器通常是 SoC 内部集成的 GMAC（千兆媒体访问控制器），外部再搭配一颗 PHY 芯片完成物理层收发，两者之间通过 RGMII 或 RMII 接口连接。不同板型可能配一颗或两颗 PHY，也可能通过 PCIe 或 USB 转接出额外网口。你如果不先确认硬件拓扑，后面遇到"两个网口只有一个能用"或者"网口名字是 eth1 不是 eth0"这类问题就会一头雾水。

确认硬件最直接的办法是看设备树和内核日志。板卡出厂系统里，设备树已经把网口节点描述好了，内核启动时会打印 PHY 的识别信息。执行下面这条命令，能看到当前系统识别到的所有网络接口：

ip link show

输出里以eth开头的就是以太网接口，以en开头的命名规则在部分发行版里也会出现。接着看内核日志里跟 PHY 相关的行：

dmesg | grep -i -E "eth|phy|mdio"

正常情况下你会看到类似eth0: PHY [stmmac-0:01] driver [Realtek RTL8211F]这样的信息，说明 SoC 的 MAC 控制器通过 MDIO 总线找到了地址为 1 的 PHY，并且加载了对应驱动。如果这行信息缺失或者显示no PHY found，那问题就出在硬件连接或设备树配置上，跟上层网络配置无关，先别急着改 IP。

1.2 MAC 地址与接口命名的那些坑

Rockchip 平台有一个很常见的现象：板子每次启动 MAC 地址都变。原因是部分板卡没有烧录独立的 MAC 地址存储芯片（比如 EEPROM），系统启动时由内核随机生成一个本地管理地址。这在实验室里无所谓，但接到公司网络或者做设备量产时，MAC 漂移会导致 DHCP 服务器分配混乱、交换机 MAC 表震荡，甚至触发网络准入策略。

判断方法很简单，连续重启两次，对比ip link show eth0输出里的link/ether字段。如果两次不一样，就是随机 MAC。解决办法有两个方向：一是在系统里通过 udev 规则或网络管理工具固定一个地址；二是在支持的情况下把 MAC 写进板载存储。前者改动小、可复现，适合大多数场景。下面是一个固定 MAC 的 udev 规则示例，写入/etc/udev/rules.d/70-persistent-net.rules：

ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth0", RUN+="/sbin/ip link set dev eth0 address 02:11:22:33:44:55"

注意：固定 MAC 时建议使用 locally administered 地址段，也就是第一个字节的第二位为 1，比如02:开头。直接抄一个厂商 OUI 开头的地址，在正规网络环境里可能被判定为冲突。

接口命名方面，部分较新的发行版采用 predictable network interface names，网口可能叫end0或enP4p65s0之类。如果你习惯了eth0，可以在内核命令行加net.ifnames=0关闭这套命名规则，但我不太建议这么做，因为一旦板子上有多个网口，可预测命名反而更容易区分。真正要关注的是配置文件和实际接口名保持一致，别照着旧教程抄eth0结果系统里根本没有这个名字。

2. 系统层面的以太网配置怎么做才稳

2.1 临时配置与永久配置的边界

调试阶段用ip命令临时配地址是最快的，改完立即生效，重启即失效，非常适合验证链路通不通：

ip addr add 192.168.1.100/24 dev eth0 ip link set eth0 up ip route add default via 192.168.1.1

这三条分别做的是：给接口加地址、把接口拉起来、加默认路由。注意顺序不能反，接口没 up 的时候加路由会报Network is unreachable。验证用ping网关，通了说明二层和三层都没问题。

但临时配置有个隐患：很多人调通之后就忘了写永久配置，结果交付给客户或者重启之后设备失联。永久配置的方式取决于系统用的是哪套网络管理栈。ArmSoM 这类板卡常见的系统镜像里，可能用 systemd-networkd、NetworkManager，也可能用传统的 ifupdown。先确认当前用的是哪个：

systemctl status systemd-networkd systemctl status NetworkManager

哪个是 active 就用哪个的配置方式，混用会导致配置互相覆盖，这是新手最容易踩的坑之一。我见过有人同时在/etc/network/interfaces和 NetworkManager 里配了不同网段的地址，结果接口上挂了两个 IP，路由表一团乱。

2.2 用 systemd-networkd 配静态地址的完整示例

以 systemd-networkd 为例，配置文件放在/etc/systemd/network/下，文件名建议带编号前缀保证加载顺序，比如10-eth0.network：

[Match] Name=eth0 [Network] Address=192.168.1.100/24 Gateway=192.168.1.1 DNS=192.168.1.1 DNS=223.5.5.5

写完之后执行：

systemctl restart systemd-networkd networkctl status eth0

networkctl status的输出会明确告诉你接口状态是routable还是degraded，以及地址、网关、DNS 是否都生效了。这个命令比ip addr信息更聚合，排查时优先用它。

如果板子有两个网口，想做一个口接内网、一个口接外网，那就写两个.network文件，分别 Match 不同的接口名，各自配地址和网关。这里有个细节：两个网口都配默认网关会导致路由冲突，系统只会保留其中一条。正确做法是只在一个网口上配Gateway=，另一个网口只配Address=，需要跨网段访问时再手动加明细路由。

2.3 DHCP 场景下如何保证地址稳定

大多数开发场景用 DHCP 就够了，但如果你通过 SSH 远程连板子，地址一变就找不到设备，体验很差。两个思路：一是在路由器或 DHCP 服务器上做静态绑定，把板子的 MAC 和固定 IP 关联；二是在板子侧配置 DHCP 客户端标识，让服务器尽量分配同一个地址。

systemd-networkd 的 DHCP 配置可以这样写：

[Match] Name=eth0 [Network] DHCP=yes [DHCPv4] ClientIdentifier=mac

ClientIdentifier=mac表示用 MAC 地址作为 DHCP 客户端标识，配合服务器侧的租约保持策略，地址稳定性会好很多。但前提还是 MAC 本身要固定，否则标识每次都变，服务器也认不出你。这就又回到了上一节说的 MAC 固定问题，两个环节是联动的。

3. 链路协商与速率问题：千兆跑成百兆怎么查

3.1 从 ethtool 输出读懂协商结果

网口灯亮不代表速率正常。一块千兆板卡插上千兆交换机，理论上应该协商到 1000Mbps 全双工，但实际经常出现只跑 100Mbps 的情况。查协商结果用ethtool：

ethtool eth0

重点看这几行：

Speed: 1000Mb/s Duplex: Full Auto-negotiation: on Link detected: yes

如果Speed显示100Mb/s，而你的交换机和网线都支持千兆，那就要往下查。常见原因按概率排序：网线质量不达标（只用了四对线中的两对）、水晶头压接不良、交换机端口本身是百兆、PHY 与变压器之间的走线受干扰。工业现场还有一种情况是网线走线过长或靠近变频器，信号完整性下降导致高速率协商失败，这时候换屏蔽线或者降低速率反而更稳。

ethtool还能看更底层的自协商能力：

ethtool eth0 | grep -A 5 "Supported link modes"

这里列出的是 PHY 支持的模式，如果连1000baseT/Full都没列出来，那要么 PHY 本身不支持千兆，要么驱动没正确上报能力，需要核对设备树里 PHY 的 compatible 属性。

3.2 强制速率与双工的适用边界

有些现场设备对自协商支持不好，或者链路质量处在临界状态，可以尝试强制指定速率和双工：

ethtool -s eth0 speed 100 duplex full autoneg off

这条命令把接口强制到百兆全双工并关闭自协商。注意，强制模式要求链路两端配置一致，如果对端还是自协商，很可能出现一端全双工一端半双工，结果就是大量冲突和丢包，表现为能 ping 通但吞吐极低。所以强制速率是排查手段，不是常规配置，用完记得恢复：

ethtool -s eth0 autoneg on

提示：强制速率设置在重启后失效。如果确实需要固化，得写进网络管理配置或者开机脚本，但更推荐的做法是解决物理层问题，而不是靠强制参数掩盖。

3.3 用 ethtool -S 看底层统计定位丢包

链路能通但丢包，是最难查的一类问题。ethtool -S eth0会打印 MAC 和 PHY 的详细计数器，比ifconfig里的几个总数有用得多：

ethtool -S eth0

关注这些字段：rx_crc_errors增长说明物理层有误码，多半是线缆或干扰问题；rx_fifo_errors增长说明接收缓冲区溢出，可能是中断处理不及时或者流量突发；tx_carrier_errors说明发送时检测不到载波，链路本身有问题。连续执行两次，看哪个计数器在涨，就能把问题范围缩小到物理层、驱动层还是协议层。

我实际遇到过一次现场设备间歇性丢包，ifconfig看丢包率不到千分之一，但ethtool -S显示rx_crc_errors在持续增长，最后查出来是网线跟动力线捆在一起走线，换了独立线槽就解决了。这种问题光看上层统计根本定位不到。

4. 吞吐量测试：怎么压出真实性能

4.1 测试拓扑与工具选择

评估一块板子的以太网性能，不能只看协商速率，得实际压流量。常用工具是iperf3，一端跑 server 一端跑 client。拓扑上建议板子直连一台性能足够的 PC，中间不要经过低端交换机，避免交换机成为瓶颈。

板子侧启动服务端：

iperf3 -s

PC 侧发起测试：

iperf3 -c 192.168.1.100 -t 30 -P 4

-t 30表示测试 30 秒，-P 4表示开 4 条并行流。单流测试受 CPU 单核性能和 TCP 窗口影响较大，多流更能压出网口真实带宽。千兆口理论上限约 940Mbps（扣除以太网帧开销），实测能到 900Mbps 以上就算正常。

4.2 影响吞吐量的几个关键因素

同样的板子，不同配置下测出来的数字可能差一倍。第一个因素是 CPU 频率调节策略，默认的 ondemand 或 schedutil 在短时测试里可能来不及升频，建议测试前把 governor 设为 performance：

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

第二个因素是中断亲和性。Rockchip 的 GMAC 中断默认可能绑在某个 CPU 核上，多流测试时这个核容易成为瓶颈。可以查看中断分布：

cat /proc/interrupts | grep eth

如果所有队列中断都集中在 CPU0，可以通过修改/proc/irq/<编号>/smp_affinity把不同队列分散到不同核心。这个操作对普通用户来说偏底层，但做性能调优时值得一试。

第三个因素是测试方向。TCP 单向发送和双向同时收发（iperf3加--bidir）结果差别很大，双向测试更能反映实际网关类应用的负载。另外 UDP 测试能看出丢包和抖动，对音视频传输类项目更有参考价值：

iperf3 -c 192.168.1.100 -u -b 900M -t 30

-b 900M表示以 900Mbps 速率发送 UDP 流，观察接收端报告的丢包率。如果丢包明显，说明链路或系统处理能力跟不上这个速率。

4.3 测试结果的解读与记录

测完不要只看最后一行的带宽数字，iperf3的汇总里还有重传次数（Retr）和拥塞窗口信息。重传次数高说明链路有丢包或者缓冲区不足，即使带宽数字好看，实际业务体验也会差。建议把测试条件（内核版本、CPU governor、并行流数、测试时长）和结果一起记录下来，形成板子的性能基线。后续换内核、改驱动、调参数之后，拿新结果跟基线对比，才能判断改动是正向还是负向。

5. 常见故障的排查路径与速查表

5.1 插线不亮灯的分层排查法

网口灯不亮是最直观的故障，但原因可能分布在好几个层次。我习惯按"物理层、链路层、驱动层、配置层"的顺序往下查，避免一上来就改软件配置。

物理层先看灯：网口通常有两个 LED，一个 Link 灯一个 Activity 灯。Link 灯常亮表示链路建立，闪烁表示有数据。灯完全不亮，先换网线、换交换机端口，排除线缆和対端问题。如果换了还不亮，用万用表量一下 RJ45 变压器侧有没有异常，但这步对普通用户偏难，更实际的做法是换一块已知正常的板子对比。

链路层看ethtool eth0的Link detected字段。如果显示no，说明 PHY 没检测到对端信号，问题在物理连接或 PHY 供电。如果显示yes但灯不亮，可能是 LED 极性配置问题，不影响功能。

驱动层看dmesg里有没有 PHY 识别失败、MDIO 读写超时的报错。配置层看接口是不是被ip link set eth0 down关掉了，或者被网络管理工具标记为 unmanaged。

5.2 常见问题速查表

5.3 几个容易被忽略的细节

第一个细节是网口的节能特性。部分 PHY 支持 EEE（Energy Efficient Ethernet），在低负载时降低功耗，但某些交换机对 EEE 兼容性不好，会导致链路间歇性抖动。如果遇到莫名其妙的丢包，可以尝试关闭 EEE：

ethtool --set-eee eth0 eee off

第二个细节是巨型帧。做内网大文件传输或者存储类应用时，开启 MTU 9000 能显著降低 CPU 开销，但要求链路上所有设备都支持并配置一致，否则会出现大包被丢弃、小包正常的情况，表现为"能 ping 通但传文件卡死"。开启命令：

ip link set eth0 mtu 9000

第三个细节是网口指示灯的含义在不同板子上可能不一样，有的 Link 灯是绿色、Activity 灯是黄色，有的反过来。不要凭经验判断，查一下板卡的硬件手册或者原理图更靠谱。

6. 把以太网配置纳入产品化流程

6.1 配置固化与批量部署思路

实验室里手动配一配没问题，产品化阶段就要考虑批量一致性。我的做法是把网络配置做成系统镜像的一部分，出厂即生效，避免现场再手工改。具体来说，静态 IP 场景把.network文件预置进镜像；DHCP 场景确保 MAC 固定规则随镜像下发；需要区分设备身份的，可以在首次启动时读取板载唯一标识，生成对应的配置文件。

Rockchip 平台通常有 OTG 烧录和 SD 卡启动两种方式，批量生产时用烧录工具把配置好的镜像一次性写入，比逐台登录配置效率高得多。配置文件的版本管理也要跟上，建议把网络相关的配置文件单独放一个目录，纳入版本控制，每次改动有记录可追溯。

6.2 远程维护通道的冗余设计

设备部署到现场之后，网络配置出错导致失联是最头疼的事。我的经验是至少保留一条独立的维护通道，比如串口控制台。ArmSoM 这类板子一般都有调试串口，接上 USB 转串口线就能在系统完全失联的情况下登录进去改配置。串口参数通常是 1500000 或 115200 波特率，具体看板卡说明。

另外，如果设备支持双网口，可以让两个网口配不同网段，一个用于业务、一个用于管理，管理口不配默认网关，只做带内管理。这样即使业务网络出问题，管理通道还在。这个设计在工业网关类产品里很常见，成本增加不多，但运维便利性提升明显。

6.3 长期运行下的稳定性观察

以太网接口连续跑几个月不出问题，才算真正稳定。建议在设备上做一个轻量的链路健康检查，定时读取ethtool -S的关键计数器，发现错误计数异常增长时记录日志或者触发告警。这个检查脚本不需要多复杂，一个定时任务加几行 shell 就够：

#!/bin/bash ERR=$(ethtool -S eth0 | grep -E "rx_crc_errors|rx_fifo_errors" | awk '{sum+=$2} END {print sum}') echo "$(date) eth_errors=$ERR" >> /var/log/eth_health.log

日志积累一段时间后，就能看出链路质量的变化趋势。如果错误计数在某次布线调整后明显下降，说明调整有效；如果持续增长，就要考虑更换线缆或者检查接地。这种长期观察的价值，是短时间压测发现不了的。

我在实际项目里踩过最深的坑，是早期没重视 MAC 地址固定，几十台设备部署到同一个网络后地址频繁漂移，DHCP 租约表乱成一团，排查花了两天才定位到根因。从那以后，任何带网口的板卡在量产前，我都会先确认 MAC 是否稳定，这个检查项现在已经是固定流程的一部分。以太网看着是最基础的外设，但基础的东西往往藏着最多细节，把链路层和配置层都摸透了，上层应用才能跑得踏实。