Überprüfen Sie, ob das Netzwerkkabel an eine bestimmte Netzwerkkarte angeschlossen ist

Der Server verfügt über mehrere Netzwerkkarten, von denen nur eine über ein Kabel verfügt.

Wie kann ich testen, ob ein bestimmter Port angeschlossen ethXist oder nicht?

Ich habe viele ähnliche Fragen gefunden , aber sie funktionieren bei mir weder ethtoolnoch cat /sys/class/net/eth1/carrier.

In meinem Fall ist das Kabel tatsächlich angeschlossen eth2, ethtoolzeigt aber immer nochLink 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

Es ist kein Kabel angeschlossen eth3, aber der ethtoolAusgang sieht fast gleich aus:

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

Erst wenn ich die Schnittstelle eth2aufrufe, dann ethtoolzeigt Link detected: yes. Danach ethtoolmeldet sich der Link als yes, auch wenn ich die Schnittstelle heruntergefahren habe.

Kurz gesagt, ethtoolscheint nicht beim ersten Mal zu funktionieren, bevor die Schnittstelle überprüft wurde.

Wie kann ich zuverlässig testen, ob an einer bestimmten Schnittstelle ein Kabel angeschlossen ist oder nicht ?

Ich gehe davon aus, dass Sie den Verbindungsstatus der Netzwerkkarte ermitteln möchten, nicht den physischen Zustand, in dem ein Kabel an die Steckdose angeschlossen ist. (Das könnte unmöglich herauszufinden sein.)

Bei einer schnellen Suche haben Sie dort wohl schon die Antwort. Rufen Sie die Benutzeroberfläche auf, warten Sie, bis ein Link gefunden wurde. Wenn es einen gibt (dies kann einige Sekunden dauern), überprüfen Sie die Ausgabe von ethtooloder carrierund / oder operstatein /sys/class/net/$NIC/.

ifconfig somenic upscheint diese beiden ioctlAnrufe zu tätigen:

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

Das heißt, es setzt ein IFF_UP. Basierend auf hier , ist diese Einstellung , was das Gerät tatsächlich verursacht initialisiert werden:

Dann setzt es das IFF_UPBit dev->flagmittels ioctl(SIOCSIFFLAGS)(Socket I / O Control Set Interface Flags), um die Schnittstelle einzuschalten.

Der letztere Befehl ( ioctl(SIOCSIFFLAGS)) ruft jedoch die open-Methode für das Gerät auf.

Was den eigentlichen Code betrifft, muss der Treiber viele der gleichen Aufgaben ausführen wie die char- und block-Treiber. open fordert alle benötigten Systemressourcen an und weist die Schnittstelle an, aufgerufen zu werden.

Es gibt Kommentare zu dem ähnlichen Effekt in der e1000eTreiberquelle :

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

Das würde bedeuten , dass es keine Möglichkeit gibt , um sinnvoll den Link Zustand einen NIC zu finden , die nicht ist bis , da die Hardware nicht einmal initialisiert werden würde.

Natürlich ist es zumindest theoretisch möglich, dass sich einige Treiber anders verhalten und die Hardware initialisieren, bevor jemand sie einstellt IFF_UP, aber das würde im allgemeinen Fall immer noch nicht helfen.

Wenn Sie auf einem Computer (mit einem e1000ean einen Cisco angeschlossenen Switch) die Schnittstelle nach unten ziehen, wird beim Switch auch die Verbindung unterbrochen.

Auf einem anderen Computer (mit einer eingebetteten Realtek-Netzwerkkarte) führen Änderungen von oben nach unten dazu, dass der Remote-Switch kurzzeitig getrennt wird. Der Switch sieht jedoch, dass die Verbindung wieder hergestellt wird. ( ethtoolZeigt jedoch "kein Link" auf der PC-Seite an.) Dies hat möglicherweise etwas mit der Vorbereitung auf Wake-on-LAN oder ähnliches zu tun, aber ich habe wirklich keine Ahnung.

Versuchen Sie den Befehl ifplugstatusaus dem Paket ifplugd

$ ifplugstatus net0
net0: unplugged

$ ifplugstatus wlnet0
wlnet0: link beat detected

Neben der Bildschirmausgabe können Sie auch den Beendigungsstatus des Befehls erkennen.

(von manpage)

RÜCKGABEWERTE

  0 Success

  1 Failure

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

  3 Unplugged (same here)

Ich habe mir den Quellcode von ethertools angesehen, konnte aber keinen Ort finden, an dem der Verbindungsstatus beschrieben wird.

Dann stellte ich fest, dass dies ein genaues Duplikat einer Frage zu SO zu sein scheint: /programming/808560/how-to-detect-the-physical-connected-state-of-a-network-cable -Verbinder

Ich habe die meisten der dort aufgeführten Antworten ausprobiert (mii-tools, ethertool, cat der Träger oder operstate, dmesg) und keine von ihnen funktionierte ordnungsgemäß auf dem Link, wenn die ifconfig nicht verfügbar war.

Da die SO-Frage älter als 6 Jahre ist, denke ich, dass die meisten möglichen Antworten bereits vorhanden sind.

Meine Stimme wäre, dass Sie mit Standard-Linux-Tools den Netzbetreiber erst überprüfen können, wenn Sie versuchen, ihn aufzurufen. Danach mii-toolsschien es gut für die Linkerkennung zu funktionieren und eine einheitliche Antwort zu geben.

Ich habe dort nicht rtnetlink und einige andere Antworten ausprobiert, die sich mit der Erkennung von Änderungen im Verbindungsstatus befassen, was vermutlich nicht das ist, was Sie wollten.