Ethernet falha intermitentemente

Question

Estou trabalhando com um sistema Debian embutido e estou tendo problemas para fazer com que o ethernet funcione de forma consistente. Uma vez a cada 5 ou 10 vezes que a eth0 é criada, algo falha e não consigo me conectar a ela via ssh e ela não responde ao ping. A solução é reinicializar ou logar via console serial e trazer eth0 para baixo e depois para cima novamente. Eu posso replicar o problema reiniciando repetidamente ou emitindo ifconfig eth0 down && ifconfig eth0 up repetidamente até que o dispositivo pare de responder.

Meu / 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

Quando a rede funciona, dmesg diz:

[ 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

E quando isso não acontece, dmesg diz:

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

Quando a rede funciona ifconfig outputs:

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

E quando não a ifconfig output é:

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

Quando a rede funciona ip link show eth0 outputs:

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

Quando as coisas não funcionam, ip link show eth0 dá:

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

Minha solução atual é ter um script analisando a saída de ip link show eth0 e reiniciar a eth0 até que apareça, mas isso parece bastante hacky.

Alguma ideia do problema ou onde mais devo procurar?

Editar: Saída de ethtool eth0 quando as coisas funcionam:

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

Saída de ethtool eth0 quando isso não ocorre:

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

Também imaginei o sistema em que trabalhei e testei em uma segunda máquina idêntica, mas com cabos diferentes e um roteador diferente e vi o mesmo comportamento.

Editar 2: Por observação de ttsiodras fiz alguns testes de MTU. Descobri que quando o dispositivo inicializa o MTU é inicialmente 1508. Toda vez que eu trago eth0 para baixo, então o backup do MTU aumenta em 4, para um máximo de 1540, após o qual permanece o mesmo. Infelizmente, não parecia haver qualquer correlação entre o MTU e quando eu perderia a conectividade de rede. Também tentei configurar manualmente o MTU para uma variedade de valores entre 1508 e 1540 e a rede ainda ocasionalmente falharia independentemente da configuração manual do MTU.

    

Answer 1

Isto pode estar relacionado ao fato de que os patches do Debian funcionavam um pouco para compatibilidade com versões anteriores. Essa é uma solução, no entanto, e uma que é um pouco problemática; a história completa pode ser encontrada em a página wiki do Debian sobre o assunto . O objetivo é corrigir isso para o Stretch (a próxima versão do Debian) adicionando código específico do systemd aos pacotes contendo rcS init scripts. A maior parte do trabalho já foi feito, mas ainda resta uma pequena quantia.

Coisas que podem corrigir esse problema:

• Adicione um script a rc.local , que verifica se os scripts rcS mais importantes (para sua situação) foram executados com êxito e que, se não, corrige as coisas (executar systemctl status foo.service pode ajudar aqui)
• Escreva uma unidade do systemd para o script de rede ou capture-a do alongamento (alguns testes seriam necessários)
• Substitua systemd em seus sistemas por sysvinit (embora isso possa ser um exagero)
• Verifique os logs do sistema para descobrir quais serviços (que não são de rede) estão envolvidos no loop de dependência e remova um ou mais deles do sistema
• Instale o network-manager e use isso em vez de ifupdown .