7

Server has multiple NICs, only one of which has cable plugged in.

How can I test whether given port ethX is plugged in or not ?

I found many similar questions, but neither ethtool nor cat /sys/class/net/eth1/carrier works for me.

In my case, the cable is actually connected in eth2, but ethtool still shows 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

There is no cable connected in eth3, but ethtool output looks almost the same:

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

First when I bring the interface eth2 up, then ethtool shows Link detected: yes. After that, ethtool reports the link as yes, even when I ifdown the interface.

In short, ethtool does not seem to work first time, before interface has been ifuped.

How can I reliably test whether given interface has cable plugged in or not ?

Martin Vegter
  • 69
  • 66
  • 195
  • 326
  • Using `tcpdump` against each nic, to see if any packets flying by, is my normal approach for this. – steve Dec 02 '17 at 09:48
  • 1
    Why can't you use the actual difference in port description that ethtool *does* report between eth2 and eth3: namely Direct Attach Copper? – Gnudiff Dec 02 '17 at 10:58
  • @Gnudiff - because I need universal solution that works on any machine / nic. Not just "Direct Attach Copper" – Martin Vegter Dec 02 '17 at 11:51
  • Have you tried ifplugd? I posted an answer. Hopefully it is helpful. – Bruce Dec 08 '17 at 18:59

3 Answers3

4

I assume you want to find the link state of the NIC, not the physical condition of having a cable plugged in the socket. (that might be impossible to find out.)

On a quick search, I think you have the answer there already. Bring the interface up, wait for it find a link, if there is one (that might take some seconds), then check the output of ethtool, or carrier and/or operstate in /sys/class/net/$NIC/.

ifconfig somenic up seems to make these two ioctl calls:

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

That is, it sets IFF_UP. Based on here, setting that is what actually causes the device to be initialized:

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;

There's comments to the similar effect in the e1000e driver source:

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

That would imply that there's no way to meaningfully find the link state of a NIC that is not up, since the hardware would not even be initialized.

Of course it's at least theoretically possible that some drivers behave differently and initialize the hardware before anyone sets IFF_UP, but that still would not help in the general case.

On one machine (with an e1000e connected to a Cisco switch), pulling the interface down also makes the switch see the link go down.

On another machine (with some embedded Realtek NIC), changes from up to down make the remote switch se a brief disconnection, but the switch sees the link then come back up. (ethtool does show "no link" on the PC side, though.) This might or might not have something to do with preparing for Wake-on-LAN or such, but I've really no idea.

ilkkachu
  • 133,243
  • 15
  • 236
  • 397
3

Try command ifplugstatus from package ifplugd

$ ifplugstatus net0
net0: unplugged

$ ifplugstatus wlnet0
wlnet0: link beat detected

Besides screen output, you also can tell from the exit status of the command.

(from manpage)

RETURN VALUES

  0 Success

  1 Failure

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

  3 Unplugged (same here)
Bruce
  • 1,181
  • 9
  • 12
0

I looked at ethertools source code, but couldn't find a place where the link state is described.

Then I found that this seems to be an exact duplicate of a question on SO: https://stackoverflow.com/questions/808560/how-to-detect-the-physical-connected-state-of-a-network-cable-connector

I tried most of answers listed there (mii-tools, ethertool, cat the carrier or operstate, dmesg) and none of them worked properly on link when the ifconfig was down.

Since SO question is more than 6 years old, I think most of the possible answers are already there.

My vote would be that with standard Linux tools you can't check carrier until you try to bring it up. After that, mii-tools seemed to work fine for link detection and give uniform answer.

I didn't try rtnetlink and some other answers there, which deal with detection of changes in link state, which is, I assume, not what you wanted.

Gnudiff
  • 955
  • 5
  • 11