嵌入式Linux更新后网卡名称变化：让服务绑定正确端口

把产品角色绑定到真实端口

嵌入式Linux升级后，服务本身可能正常，却附着到错误网口。驱动探测顺序改变后，依赖eth0的管理服务可能找不到原端口；防火墙规则若覆盖了另一个连接器，影响更加严重。首先应把物理产品角色映射到可靠接口证据，再决定使用什么名称。

本文固定Buildroot 2025.02，其systemd配方选择256.7，所以命名细节核对systemd 256.7源码文档。仅使用BusyBox或其他设备管理器的产品，需要按自己的流程审查。本文不假设所有Buildroot镜像使用systemd，也没有改名接口或执行硬件测试。

每个连接器记录机壳标签、产品角色、驱动、设备路径、当前接口名和相关MAC身份。区分永久硬件地址与当前工作地址，后者可能被软件或固件修改。有条件时再与原理图及制造记录对应，而不是把一次启动观察当作永久身份。

# 只读检查；IFACE必须是现有接口。
ip -details link show dev "$IFACE"
udevadm info --query=property --path="/sys/class/net/$IFACE"

第二条仅适用于提供udev工具的系统。保存已安装命名规则与内核命令行设置，不采集无关网络凭据。清单应说明重启后怎样识别管理连接器，而不只是记录当时恰好出现了哪个名字。

内核先创建接口名称，配置的设备管理路径随后可能应用另一套命名政策。systemd的.link文件经udev控制链路属性，与networkd中配置地址路由的.network文件不同。产品可以使用.link处理，而不让networkd负责所有网络配置。

systemd 256.7链路文件说明规定按适用字母数字顺序使用第一个匹配文件。评审时应查看有效规则集合，包括管理员覆盖项及早期启动阶段的副本。规则写得正确但永远不是首个匹配，也不会产生效果；验收应保存实际命中的文件。

按路径匹配可以让某个物理槽位在适配器更换后仍承担原角色；按永久MAC匹配可以让同一适配器移动后仍保留身份。这是两个不同产品承诺。先决定“LAN”究竟指连接器还是可移动设备，再选择匹配依据。

两种方式都并非绝对稳定。板卡修订、固件变化或USB集线器布局可能改变拓扑属性；更换模块会改变永久地址，有些设备还无法可靠提供永久地址。没有说明依据时，不要把当前随机化或配置写入的MAC当作硬件身份。若证据不能区分两个端口，应先修复硬件或固件身份模型，再赋予可信服务角色。

在专用.link规则中，同时检查Match条件、NamePolicy与显式Name。256.7说明中NamePolicy优先于Name，只有政策未产生名称时，显式名称才会生效。对于窄范围匹配且明确指定产品名称的规则，清空NamePolicy可能合适，但必须结合已安装规则集合审查。

角色名称应避免与内核常见eth数字分配竞争。OriginalName=eth0这种宽匹配不能证明物理身份。检查板载、USB及可选接口的名称唯一性；冲突或延迟改名可能中断服务，所以策略变更应有计划重启或受控维护流程，并保留本地恢复访问。

在产品配置中查找旧名称，包括地址设置、防火墙、DHCP、策略路由、监控、应用绑定参数和恢复脚本。ip link显示新名称，只能证明一小部分结果，所有消费者都必须在变化后解析到相同的预期角色。

还要检查启动顺序。守护进程可能缓存接口索引，或在目标接口出现前就尝试绑定。网络可用与身份正确是两个独立条件。管理角色无法识别时，明确失败通常比退回“随便存在的接口”更容易控制；任何回退是否安全，都取决于产品网络隔离要求。

实验环境应有串口或其他独立恢复通道，覆盖冷启动、热重启、探测时序变化、可选适配器缺席、模块替换、USB重连和受支持板卡变体。既比较名称，也验证实际流量经过的物理路径。名称保持不变但指向另一连接器，仍然是身份测试失败。

另外测试软件回退与恢复镜像。候选镜像使用lan0而恢复镜像仍假设eth0时，现场说明可能悄悄指错端口。保留新旧映射，并判断是否需要配置迁移。在管理与恢复路径完成受支持组合验证前，不应直接远程推广命名变更。

验收应证明每个受支持端口角色都有身份依据，实际命中预期规则，名称保持唯一，服务连接到正确物理路径。记录可更换模块与拓扑变化的例外，把映射表与Buildroot 2025.02的systemd版本依据及实际镜像配置一起保存。

这套流程验证名称与绑定假设，不能独立证明链路可靠性、吞吐或网络安全。它解决的是具体问题：软件升级不应因为偶然的枚举顺序变化，就让管理流量、现场流量或防火墙政策悄悄转移到另一个连接器。