Poderia ser que nenhum link tenha sido detectado até a ligação ser configurada?

3

Poderia ser que:

ethtool ethx | grep detected

mostra "nenhum link detectado" se o bond0 ainda não está configurado no lado do SO (linux)?

o ethtool não está mostrando um estado físico?

    
por Hessnov 09.03.2018 / 22:21

2 respostas

1

O Ethtool só funciona contra adaptadores Ethernet físicos. Isso significa que bond0, tun0 e qualquer outro dispositivo de rede que não seja um dispositivo de rede físico não funcionará com o ethtool.

$ ethtool <eth?>

Por exemplo:

$ ethtool eth0

fornece:

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
    
por 10.03.2018 / 11:08
1

Suponho que você queira encontrar o estado do link da NIC, não a condição física de ter um cabo conectado ao soquete. (isso pode ser impossível descobrir).

Em uma pesquisa rápida, acho que você já tem a resposta. Aumente a interface, espere encontrar um link, se houver um (isso pode levar alguns segundos) e, em seguida, verifique a saída de ethtool ou carrier e / ou operstate em /sys/class/net/$NIC/ .

ifconfig somenic up parece fazer essas duas chamadas ioctl :

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

Ou seja, define IFF_UP . Com base no aqui , definir isso é o que realmente faz com que o dispositivo seja inicializado:

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;

Há comentários sobre o efeito semelhante no % driver doe1000e :

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

Isso implicaria que não há como encontrar significativamente o estado do link de uma placa de rede que não esteja em cima , já que o hardware nem seria inicializado.

É claro que é pelo menos teoricamente possível que alguns drivers se comportem de maneira diferente e inicializem o hardware antes que alguém defina IFF_UP , mas isso ainda não ajudaria no caso geral.

    
por 11.03.2018 / 12:01