verificar se o cabo de rede está conectado conforme a NIC

Question

O servidor tem vários NICs, dos quais apenas um possui um cabo conectado.

Como posso testar se a porta ethX está conectada ou não?

Encontrei muitas perguntas semelhantes , mas nem ethtool nem cat /sys/class/net/eth1/carrier funciona para mim.

No meu caso, o cabo está realmente conectado em eth2 , mas ethtool ainda mostra Link detected: no

Settings for eth2:
    Supported ports: [ FIBRE ]
    Supported link modes:   10000baseT/Full 
    Supported pause frame use: Symmetric
    Supports auto-negotiation: No
    Advertised link modes:  10000baseT/Full 
    Advertised pause frame use: Symmetric
    Advertised auto-negotiation: No
    Speed: Unknown!
    Duplex: Unknown! (255)
    Port: Direct Attach Copper
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: off
    Supports Wake-on: d
    Wake-on: d
    Current message level: 0x00000007 (7)
                   drv probe link
    Link detected: no

Não há cabo conectado em eth3 , mas a saída ethtool parece quase a mesma:

diff <(ethtool eth2) <(ethtool eth3)
1c1
< Settings for eth2:
---
> Settings for eth3:
11c11
<   Port: Direct Attach Copper
---
>   Port: Other

Primeiro, quando eu trago a interface eth2 up, então ethtool mostra Link detected: yes . Depois disso, ethtool reporta o link como yes , mesmo quando eu for a interface.

Em suma, ethtool parece não funcionar na primeira vez, antes que a interface tenha sido excluída.

Como posso testar com confiabilidade se determinada interface tem o cabo conectado ou não ?

    

Answer 1

Suponho que você queira encontrar o estado do link da NIC, não a condição física de ter um cabo conectado ao soquete. (isso pode ser impossível descobrir).

Em uma pesquisa rápida, acho que você já tem a resposta. Aumente a interface, espere encontrar um link, se houver um (isso pode levar alguns segundos) e, em seguida, verifique a saída de ethtool ou carrier e / ou operstate em /sys/class/net/$NIC/ .

ifconfig somenic up parece fazer essas duas chamadas ioctl :

ioctl(4, SIOCGIFFLAGS, {ifr_name="somenic", ifr_flags=IFF_BROADCAST|IFF_MULTICAST}) = 0
ioctl(4, SIOCSIFFLAGS, {ifr_name="somenic", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0

Ou seja, define IFF_UP . Com base no aqui , definir isso é o que realmente faz com que o dispositivo seja inicializado:

Then it sets the IFF_UP bit in dev->flag by means of ioctl(SIOCSIFFLAGS) (Socket I/O Control Set Interface Flags) to turn the interface on.

The latter command (ioctl(SIOCSIFFLAGS)), though, calls the open method for the device.

As far as the actual code is concerned, the driver has to perform many of the same tasks as the char and block drivers do. open requests any system resources it needs and tells the interface to come up;

Há comentários sobre o efeito semelhante no % driver doe1000e :

/**
 * e1000e_open - Called when a network interface is made active
 * @netdev: network interface device structure
 *
 * Returns 0 on success, negative value on failure
 *                                                                                                                                                                           * The open entry point is called when a network interface is made
 * active by the system (IFF_UP).  At this point all resources needed
 * for transmit and receive operations are allocated, the interrupt
 * handler is registered with the OS, the watchdog timer is started,
 * and the stack is notified that the interface is ready.
 **/
int e1000e_open(struct net_device *netdev)  

Isso implicaria que não há como encontrar significativamente o estado do link de uma placa de rede que não esteja em cima , já que o hardware nem seria inicializado.

É claro que é pelo menos teoricamente possível que alguns drivers se comportem de maneira diferente e inicializem o hardware antes que alguém defina IFF_UP , mas isso ainda não ajudaria no caso geral.

Em uma máquina (com um e1000e conectado a um switch Cisco), puxar a interface para baixo também faz com que o switch veja o link cair.

Em outra máquina (com alguma placa de rede Realtek incorporada), as alterações de baixo para baixo fazem com que o controle remoto seja desconectado por breves instantes, mas o switch vê o link e volta a funcionar. ( ethtool mostra "no link" no lado do PC, no entanto.) Isso pode ou não ter algo a ver com a preparação para o Wake-on-LAN ou algo semelhante, mas eu realmente não faço ideia.

    

Answer 2

Tente o comando ifplugstatus do pacote ifplugd

$ ifplugstatus net0
net0: unplugged

$ ifplugstatus wlnet0
wlnet0: link beat detected

Além da saída de tela, você também pode dizer a partir do status de saída do comando.

(da página de manual)

RETURN VALUES

  0 Success

  1 Failure

  2 Link beat detected (only available when an interface is specified)

  3 Unplugged (same here)

    

Answer 3

Eu olhei para código-fonte ethertools, mas não consegui encontrar um lugar onde o estado do link é descrito.

Depois, descobri que essa parece ser uma duplicata exata de uma pergunta no SO: link

Eu tentei a maioria das respostas listadas (mii-tools, ethertool, cat the carrier ou operstate, dmesg) e nenhuma delas funcionou corretamente no link quando o ifconfig estava inativo.

Como a pergunta SO tem mais de 6 anos, acho que a maioria das respostas possíveis já existe.

Meu voto seria que, com as ferramentas padrão do Linux, você não pode verificar a operadora até tentar atualizá-la. Depois disso, mii-tools pareceu funcionar bem para a detecção de links e fornecer uma resposta uniforme.

Eu não tentei o rtnetlink e algumas outras respostas, que lidam com a detecção de alterações no estado do link, o que, suponho, não é o que você queria.