☰

verifique se o cabo de rede está conectado em determinada NIC

tag-icon • tag-icon ethernet ifconfig
verifique se o cabo de rede está conectado em determinada NIC

O servidor possui várias NICs, das quais apenas uma possui cabo conectado.

Como posso testar se determinada porta ethXestá conectada ou não?

encontrei muitos parecidosquestões, mas nem ethtoolnem cat /sys/class/net/eth1/carrierfunciona para mim.

No meu caso, o cabo está realmente conectado eth2, mas ethtoolainda mostraLink 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á nenhum cabo conectado eth3, mas ethtoola saída 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 abro a interface eth2, depois ethtoolmostra Link detected: yes. Depois disso, ethtoolreporta o link como yes, mesmo quando eu desço a interface.

Resumindo, ethtoolnão parece funcionar na primeira vez, antes que a interface seja atualizada.

Como posso testar com segurança se determinada interface tem cabo conectado ou não??

Responder1

Presumo 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 de descobrir.)

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

ifconfig somenic upparece fazer estas duas ioctlchamadas:

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, ele define IFF_UP. Baseado emaqui, essa configuração é o que realmente faz com que o dispositivo seja inicializado:

Em seguida, ele define o IFF_UPbit dev->flagpor meio de ioctl(SIOCSIFFLAGS)(Socket I/O Control Set Interface Flags) para ligar a interface.

O último comando ( ioctl(SIOCSIFFLAGS)), porém, chama o método open para o dispositivo.

No que diz respeito ao código real, o driver precisa executar muitas das mesmas tarefas que os drivers char e block. open solicita quaisquer recursos do sistema necessários e informa a interface para ativar;

Há comentários sobre o efeito semelhante noe1000efonte do driver:

/**
 * 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 de forma significativa o estado do link de uma NIC que não sejaacima, 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 configure IFF_UP, mas isso ainda não ajudaria no caso geral.

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

Em outra máquina (com algumas NICs Realtek incorporadas), as alterações de cima para baixo fazem com que o switch remoto se desconecte brevemente, mas o switch vê o link e depois volta a funcionar. ( ethtoolmas mostra "sem link" no lado do PC.) Isso pode ou não ter algo a ver com a preparação para o Wake-on-LAN ou algo parecido, mas realmente não tenho ideia.

Responder2

Experimente o comando ifplugstatusdo pacoteifplugd

$ ifplugstatus net0
net0: unplugged

$ ifplugstatus wlnet0
wlnet0: link beat detected

Além da saída da tela, você também pode saber pelo status de saída do comando.

(da página de manual)

VALORES DE RETORNO

  0 Success

  1 Failure

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

  3 Unplugged (same here)

Responder3

Examinei o código-fonte do ethertools, mas não consegui encontrar um local onde o estado do link fosse descrito.

Então descobri que esta parece ser uma duplicata exata de uma pergunta no SO:https://stackoverflow.com/questions/808560/how-to-detect-the-physical-connected-state-of-a-network-cable-connector

Tentei a maioria das respostas listadas lá (mii-tools, ethertool, cat the carrier ou operastate, 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 dospossívelas respostas já estão lá.

Meu voto seria que, com as ferramentas padrão do Linux, você não pode verificar a operadora até tentar mencioná-la. Depois disso, mii-toolspareceu funcionar bem para detecção de links e fornecer respostas uniformes.

Eu não tentei o rtnetlink e algumas outras respostas lá, que tratam da detecção demudançasno estado do link, que, presumo, não é o que você queria.

informação relacionada