☰

compruebe si el cable de red está conectado a la NIC dada

tag-icon • tag-icon ethernet ifconfig
compruebe si el cable de red está conectado a la NIC dada

El servidor tiene varias NIC, de las cuales solo una tiene el cable conectado.

¿Cómo puedo comprobar si un puerto determinado ethXestá conectado o no?

encontré muchos similarespreguntas, pero ni ethtoolni cat /sys/class/net/eth1/carrierme funciona.

En mi caso, el cable está realmente conectado eth2, pero ethtoolaún se muestraLink 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

No hay ningún cable conectado eth3, pero ethtoolla salida se ve casi igual:

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

Primero, cuando abro la interfaz eth2, luego ethtoolmuestra Link detected: yes. Después de eso, ethtoolinforma el enlace como yes, incluso cuando inactivo la interfaz.

En resumen, ethtoolno parece funcionar la primera vez, antes de que se haya actualizado la interfaz.

¿Cómo puedo probar de manera confiable si una interfaz determinada tiene un cable enchufado o no??

Respuesta1

Supongo que desea encontrar el estado del enlace de la NIC, no la condición física de tener un cable enchufado en el enchufe. (Eso podría ser imposible de descubrir).

En una búsqueda rápida, creo que ya tienes la respuesta. Abra la interfaz, espere a que encuentre un enlace, si lo hay (eso puede tardar algunos segundos), luego verifique la salida de ethtool, o carriery/o operstateen /sys/class/net/$NIC/.

ifconfig somenic upparece hacer estas dos ioctlllamadas:

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

Es decir, se fija IFF_UP. Residencia enaquí, configurar eso es lo que realmente hace que el dispositivo se inicialice:

Luego configura el IFF_UPbit dev->flagmediante ioctl(SIOCSIFFLAGS)(Indicadores de interfaz de configuración de control de E/S de socket) para encender la interfaz.

ioctl(SIOCSIFFLAGS)Sin embargo, el último comando ( ) llama al método open para el dispositivo.

En lo que respecta al código real, el controlador tiene que realizar muchas de las mismas tareas que los controladores de caracteres y bloques. open solicita todos los recursos del sistema que necesita y le indica a la interfaz que se abra;

Hay comentarios en el mismo sentido en ele1000efuente del controlador:

/**
 * 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)

Eso implicaría que no hay manera de encontrar de manera significativa el estado del enlace de una NIC que no seaarriba, ya que el hardware ni siquiera se inicializaría.

Por supuesto, es al menos teóricamente posible que algunos controladores se comporten de manera diferente e inicialicen el hardware antes de que alguien lo configure IFF_UP, pero eso aún no ayudaría en el caso general.

En una máquina (con una e1000econectada a un conmutador Cisco), bajar la interfaz también hace que el conmutador vea que el enlace se cae.

En otra máquina (con alguna NIC Realtek incorporada), los cambios de arriba a abajo hacen que el interruptor remoto se desconecte brevemente, pero el interruptor ve el enlace y luego vuelve a activarse. ( ethtoolSin embargo, muestra "sin enlace" en el lado de la PC). Esto podría o no tener algo que ver con la preparación para Wake-on-LAN o algo así, pero realmente no tengo idea.

Respuesta2

Pruebe el comando ifplugstatusdel paquetesi está enchufado

$ ifplugstatus net0
net0: unplugged

$ ifplugstatus wlnet0
wlnet0: link beat detected

Además de la salida en pantalla, también puede saberlo por el estado de salida del comando.

(de la página de manual)

VALORES DE DEVOLUCIÓN

  0 Success

  1 Failure

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

  3 Unplugged (same here)

Respuesta3

Miré el código fuente de ethertools, pero no pude encontrar un lugar donde se describa el estado del enlace.

Luego descubrí que esto parece ser un duplicado exacto de una pregunta sobre SO:https://stackoverflow.com/questions/808560/how-to-detect-the-physical-connected-state-of-a-network-cable-connector

Probé la mayoría de las respuestas enumeradas allí (mii-tools, ethertool, cat the carrier u operstate, dmesg) y ninguna funcionó correctamente en el enlace cuando ifconfig estaba inactivo.

Dado que la pregunta SO tiene más de 6 años, creo que la mayoría de lasposiblelas respuestas ya están ahí.

Mi voto sería que con las herramientas estándar de Linux no se puede verificar el operador hasta que se intenta abrirlo. Después de eso, mii-toolspareció funcionar bien para la detección de enlaces y dar una respuesta uniforme.

No probé rtnetlink y algunas otras respuestas allí, que tratan con la detección decambiosen estado de enlace, que supongo que no es lo que querías.

información relacionada