☰

以太网间歇性无法启动

tag-icon • tag-icon debian networking
以太网间歇性无法启动

我正在使用嵌入式 Debian 系统，但无法让以太网持续工作。每 5 或 10 次 eth0 启动就会出现故障，我无法通过 ssh 连接到它，并且它不响应 ping。解决方案是重新启动或通过串行控制台登录并关闭 eth0，然后再次启动。我可以通过重复重新启动或ifconfig eth0 down && ifconfig eth0 up重复发出直到设备停止响应来复制问题。

我的 /etc/network/interfaces 是：

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
  address 192.168.1.122
  gateway 192.168.1.1
  netmask 255.255.255.0

当网络工作时dmesg说：

[ 2612.775183] PHY found at addr 7
[ 2612.776944] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 2614.414704] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

当它没有dmesg说：

[ 2617.224970] PHY found at addr 7
[ 2617.227005] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

当网络工作时ifconfig输出：

eth0      Link encap:Ethernet  HWaddr 00:d0:69:46:d9:08  
          inet addr:192.168.1.122  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::2d0:69ff:fe46:d908/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1528  Metric:1
          RX packets:3242 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1382 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:300701 (293.6 KiB)  TX bytes:132344 (129.2 KiB)
          Interrupt:22

当它不ifconfig输出时是：

eth0      Link encap:Ethernet  HWaddr 00:d0:69:46:d9:08  
          inet addr:192.168.1.122  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1536  Metric:1
          RX packets:3355 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1430 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:310120 (302.8 KiB)  TX bytes:136800 (133.5 KiB)
          Interrupt:22

当网络工作时ip link show eth0输出：

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1528 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 00:d0:69:46:d9:08 brd ff:ff:ff:ff:ff:ff

当事情不起作用时ip link show eth0给出：

2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1536 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000
    link/ether 00:d0:69:46:d9:08 brd ff:ff:ff:ff:ff:ff

我当前的解决方案是让一个脚本解析 eth0 的输出ip link show eth0并重新启动 eth0 直到它出现，但这看起来很hacky。

知道问题可能是什么或者我应该去哪里寻找吗？

ethtool eth0编辑：事情正常时的输出：

Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                             100baseT/Half 100baseT/Full 
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 7
        Transceiver: internal
        Auto-negotiation: on
        Link detected: yes

ethtool eth0不存在时的输出：

Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Speed: 10Mb/s
        Duplex: Half
        Port: MII
        PHYAD: 7
        Transceiver: internal
        Auto-negotiation: on
        Link detected: no

我还对我一直在使用的系统进行了成像，并在第二台相同的机器上进行了测试，但使用了不同的电缆和不同的路由器，并看到了相同的行为。

编辑 2：根据 ttsiodras 的观察，我做了一些 MTU 测试。我发现当设备启动时，MTU 最初为 1508。每次我关闭 eth0 然后重新启动，MTU 都会增加 4，达到最大值 1540，此后它保持不变。不幸的是，MTU 和我何时失去网络连接之间似乎没有任何关联。我还尝试手动将 MTU 设置为 1508 到 1540 之间的各种值，但无论手动 MTU 设置如何，网络仍然偶尔会出现故障。

答案1

这可能与 Debian 稍微修补 systemd 以实现向后兼容性有关。然而，这是一种解决方法，但也存在一些问题。完整的故事可以在以下位置找到有关该主题的 Debian wiki 页面。我们的目标是通过将特定于 systemd 的代码添加到包含rcSinit 脚本的包中来修复 Stretch（下一个 Debian 版本）的问题。那里的大部分工作已经完成，但仍有少量工作尚未完成。

可能能够解决此问题的事情：

  • 添加一个脚本来rc.local检查最重要的rcS脚本（针对您的情况）是否成功运行，如果没有成功则修复问题（运行systemctl status foo.service可能会有所帮助）
  • 为网络脚本编写一个systemd单元，或者从stretch中获取它（需要一些测试）
  • systemd在您的系统上替换为sysvinit（尽管这可能有点过分）
  • 检查系统日志以找出依赖循环中涉及哪些服务（网络除外），并从系统中删除其中一个或多个服务
  • 安装网络管理器并使用它而不是ifupdown.

相关内容