3

Could it be that the: 

ethtool ethx | grep detected

shows "no link detected" if the bond0 isn't configured yet on OS (linux) side?

isn't ethtool showing a physical state?

Hessnov
  • 143
  • 4
  • Hi, and welcome to ServerFault. Questions should be to-the-point and concerned with a particular issue in a business facing IT environment. This question in its current state lacks any kind context or details as to what you're trying to accomplish, or what your problem really is. If you revise it with more detail, you'll likely get a swift answer. It looks like you're new here, so please take a minute to look at the Tour: https://serverfault.com/tour – Spooler Mar 09 '18 at 21:27

2 Answers2

1

Ethtool will only work against physical ethernet adapters. This means that bond0, tun0, and any other network device that is not a physical network device will not work with ethtool.

$ ethtool <eth?>

For example:

$ ethtool eth0

provides:

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 pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000001 (1)
        Link detected: yes
Saqib Hashmi
  • 141
  • 5
  • ethx is a physical interface and it only got to "Link detected: yes", when the bond was configured (bond is using ethx). Why? The cable was plugged in all the time.. – Hessnov Mar 11 '18 at 07:23
1

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.

Saqib Hashmi
  • 141
  • 5