How to detect the physical connected state of a network cable/connector?

LinuxNetworkingConnectionDetection

Linux Problem Overview


In a Linux environment, I need to detect the physical connected or disconnected state of an RJ45 connector to its socket. Preferably using BASH scripting only.

The following solutions which have been proposed on other sites do NOT work for this purpose:

  1. Using 'ifconfig' - since a network cable may be connected but the network not properly configured or not currently up.
  2. Ping a host - since the product will be within a LAN using an unknown network configuration and unknown hosts.

Isn't there some state which can be used in the /proc file system (everything else is in there)?

How is the Linux world suppose to have their own version of the Windows bubble that pop up from the icon tray indicating that you've just unplugged the network cable?


Kent Fredric and lothar, both of your answers satisfy my need... thanks a lot! Which one I'll use... I still don't know.

I guess I can't put you both down as the correct answer? And its probably fair for you that I do choose one. Flip a coin I guess? Again, thanks!

Linux Solutions


Solution 1 - Linux

You want to look at the nodes in

/sys/class/net/

I experimented with mine:

Wire Plugged in:

eth0/carrier:1
eth0/operstate:unknown

Wire Removed:

eth0/carrier:0
eth0/operstate:down

Wire Plugged in Again:

eth0/carrier:1
eth0/operstate:up

Side Trick: harvesting all properties at once the easy way:

grep "" eth0/* 

This forms a nice list of key:value pairs.

Solution 2 - Linux

You can use ethtool:

$ sudo ethtool eth0
Settings for eth0:
    Supported ports: [ TP ]
    Supported link modes:   10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Supports auto-negotiation: Yes
    Advertised link modes:  10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Advertised auto-negotiation: Yes
    Speed: 1000Mb/s
    Duplex: Full
    Port: Twisted Pair
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: on
    Supports Wake-on: umbg
    Wake-on: g
    Current message level: 0x00000007 (7)
    Link detected: yes

To only get the Link status you can use grep:

$ sudo ethtool eth0 | grep Link
    Link detected: yes

Solution 3 - Linux

Use 'ip monitor' to get REAL TIME link state changes.

Solution 4 - Linux

cat /sys/class/net/ethX is by far the easiest method.

The interface has to be up though, else you will get an invalid argument error.

So first:

ifconfig ethX up

Then:

cat /sys/class/net/ethX

Solution 5 - Linux

On the low level, these events can be caught using rtnetlink sockets, without any polling. Side note: if you use rtnetlink, you have to work together with udev, or your program may get confused when udev renames a new network interface.

The problem with doing network configurations with shell scripts is that shell scripts are terrible for event handling (such as a network cable being plugged in and out). If you need something more powerful, take a look at my NCD programming language, a programming language designed for network configurations.

For example, a simple NCD script that will print "cable in" and "cable out" to stdout (assuming the interface is already up):

process foo {
    # Wait for device to appear and be configured by udev.
    net.backend.waitdevice("eth0");
    # Wait for cable to be plugged in.
    net.backend.waitlink("eth0");
    # Print "cable in" when we reach this point, and "cable out"
    # when we regress.
    println("cable in");   # or pop_bubble("Network cable in.");
    rprintln("cable out"); # or rpop_bubble("Network cable out!");
                           # just joking, there's no pop_bubble() in NCD yet :)
}

(internally, net.backend.waitlink() uses rtnetlink, and net.backend.waitdevice() uses udev)

The idea of NCD is that you use it exclusively to configure the network, so normally, configuration commands would come in between, such as:

process foo {
    # Wait for device to appear and be configured by udev.
    net.backend.waitdevice("eth0");
    # Set device up.
    net.up("eth0");
    # Wait for cable to be plugged in.
    net.backend.waitlink("eth0");
    # Add IP address to device.
    net.ipv4.addr("eth0", "192.168.1.61", "24");
}

The important part to note is that execution is allowed to regress; in the second example, for instance, if the cable is pulled out, the IP address will automatically be removed.

Solution 6 - Linux

There exists two daemons that detect these events:

ifplugd and netplugd

Solution 7 - Linux

I use this command to check a wire is connected:

cd /sys/class/net/
grep "" eth0/operstate

If the result will be up or down. Sometimes it shows unknown, then you need to check

eth0/carrier

It shows 0 or 1

Solution 8 - Linux

Most modern Linux distributions use NetworkManager for this. You could use D-BUS to listen for the events.

If you want a command-line tool to check the status, you can also use mii-tool, given that you have Ethernet in mind.

Solution 9 - Linux

Some precisions and tricks
  1. I do all this as normal user (not root)

  2. Grab infos from dmesg

    Using dmesg is one of the 1st things to do for inquiring current state of system:

     dmesg | sed '/eth.*Link is/h;${x;p};d'
    

    could answer something like:

     [936536.904154] e1000e: eth0 NIC Link is Down
    

    or

     [936555.596870] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
    

    depending on state, message could vary depending on hardware and drivers used.

    Nota: this could by written dmesg|grep eth.*Link.is|tail -n1 but I prefer using sed.

     dmesg | sed '/eth.*Link is/h;${x;s/^.*Link is //;p};d'
     Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
    
     dmesg | sed '/eth.*Link is/h;${x;s/^.*Link is //;p};d'
     Down
    
  3. Test around /sys pseudo filesystem

    Reading or writting under /syscould break your system, especially if run as root! You've been warned ;-)

    This is a pooling method, not a real event tracking.

     cd /tmp
     grep -H . /sys/class/net/eth0/* 2>/dev/null >ethstate
     while ! read -t 1;do
         grep -H . /sys/class/net/eth0/* 2>/dev/null |
             diff -u ethstate - |
             tee >(patch -p0) |
             grep ^+
       done
    

    Could render something like (once you've unplugged and plugged back, depending ):

     +++ -   2016-11-18 14:18:29.577094838 +0100
     +/sys/class/net/eth0/carrier:0
     +/sys/class/net/eth0/carrier_changes:9
     +/sys/class/net/eth0/duplex:unknown
     +/sys/class/net/eth0/operstate:down
     +/sys/class/net/eth0/speed:-1
     +++ -   2016-11-18 14:18:48.771581903 +0100
     +/sys/class/net/eth0/carrier:1
     +/sys/class/net/eth0/carrier_changes:10
     +/sys/class/net/eth0/duplex:full
     +/sys/class/net/eth0/operstate:up
     +/sys/class/net/eth0/speed:100
    

    (Hit Enter to exit loop)

    Nota: This require patch to be installed.

  4. In fine, there must already be something about this...

    Depending on Linux Installation, you could add if-up and if-down scripts to be able to react to this kind of events.

    On Debian based (like Ubuntu), you could store your scripts into

     /etc/network/if-down.d
     /etc/network/if-post-down.d
     /etc/network/if-pre-up.d
     /etc/network/if-up.d
    

    see man interfaces for more infos.

Solution 10 - Linux

on arch linux. (im not sure on other distros) you can view the operstate. which shows up if connected or down if not the operstate lives on

/sys/class/net/(interface name here)/operstate
#you can also put watch 
watch -d -n -1 /sys/class/net/(interface name here)/operstate

Solution 11 - Linux

You can use ifconfig.

# ifconfig eth0 up
# ifconfig eth0

If the entry shows RUNNING, the interface is physically connected. This will be shown regardless if the interface is configured.

This is just another way to get the information in /sys/class/net/eth0/operstate.

Solution 12 - Linux

tail -f /var/log/syslog | grep -E 'link (up|down)'

or for me faster gets:

tail -f /var/log/syslog | grep 'link \(up\|down\)'

It will listen to the syslog file.

Result (if disconnect and after 4 seconds connect again):

Jan 31 13:21:09 user kernel: [19343.897157] r8169 0000:06:00.0 enp6s0: link down
Jan 31 13:21:13 user kernel: [19347.143506] r8169 0000:06:00.0 enp6s0: link up

Solution 13 - Linux

Somehow if you want to check if the ethernet cable plugged in linux after the commend:" ifconfig eth0 down". I find a solution: use the ethtool tool.

#ethtool -t eth0
The test result is PASS
The test extra info:
Register test  (offline)         0
Eeprom test    (offline)         0
Interrupt test (offline)         0
Loopback test  (offline)         0
Link test   (on/offline)         0

if cable is connected,link test is 0,otherwise is 1.

Solution 14 - Linux

This command checks for "state UP" in the 2nd interface of the "ip a" command. I have checked in 2 computers running wifi, the 2nd listed is the cable ethernet. Case you want to check a different interface, just change the "2" in the command below to be the correct index position.

astate=`ip a | grep -E -o -m 1 "2:.*state UP"`  
if [ -n "$astat" ]; then
   echo 'cable is on'
else
   echo 'cable is off'
fi

Solution 15 - Linux

On OpenWRT the only way to reliably do this, at least for me, is by running these commands:

# Get switch name
swconfig list

# assuming switch name is "switch0"
swconfig dev switch0 show | grep link:

# Possible output
root@OpenWrt:~# swconfig dev switch0 show | grep link:
        link: port:0 link:up speed:1000baseT full-duplex txflow rxflow
        link: port:1 link:up speed:1000baseT full-duplex txflow rxflow eee100 eee1000 auto
        link: port:2 link:up speed:1000baseT full-duplex txflow rxflow eee100 eee1000 auto
        link: port:3 link:down
        link: port:4 link:up speed:1000baseT full-duplex eee100 eee1000 auto
        link: port:5 link:down
        link: port:6 link:up speed:1000baseT full-duplex txflow rxflow

This will show either "link:down" or "link:up" on every port of your switch.

Solution 16 - Linux

I was using my OpenWRT enhanced device as a repeater (which adds virtual ethernet and wireless lan capabilities) and found that the /sys/class/net/eth0 carrier and opstate values were unreliable. I played around with /sys/class/net/eth0.1 and /sys/class/net/eth0.2 as well with (at least to my finding) no reliable way to detect that something was physically plugged in and talking on any of the ethernet ports. I figured out a bit crude but seemingly reliable way to detect if anything had been plugged in since the last reboot/poweron state at least (which worked exactly as I needed it to in my case).

ifconfig eth0 | grep -o 'RX packets:[0-9]*' | grep -o '[0-9]*'

You'll get a 0 if nothing has been plugged in and something > 0 if anything has been plugged in (even if it was plugged in and since removed) since the last power on or reboot cycle.

Hope this helps somebody out at least!

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionJeachView Question on Stackoverflow
Solution 1 - LinuxKent FredricView Answer on Stackoverflow
Solution 2 - LinuxlotharView Answer on Stackoverflow
Solution 3 - LinuxPeter QuiringView Answer on Stackoverflow
Solution 4 - LinuxMarcoView Answer on Stackoverflow
Solution 5 - LinuxAmbroz BizjakView Answer on Stackoverflow
Solution 6 - LinuxGermanView Answer on Stackoverflow
Solution 7 - LinuxnsvView Answer on Stackoverflow
Solution 8 - LinuxandriView Answer on Stackoverflow
Solution 9 - LinuxF. HauriView Answer on Stackoverflow
Solution 10 - LinuxSkrmnghrdView Answer on Stackoverflow
Solution 11 - Linuxcraig65535View Answer on Stackoverflow
Solution 12 - LinuxDimaView Answer on Stackoverflow
Solution 13 - LinuxkyzrongView Answer on Stackoverflow
Solution 14 - LinuxSergio AbreuView Answer on Stackoverflow
Solution 15 - LinuxjvillasanteView Answer on Stackoverflow
Solution 16 - LinuxJxAxMxIxNView Answer on Stackoverflow