Archivi tag: ethtool

Ubuntu: analisi e debug di un’interfaccia di rete malfunzionante

Di recente, analizzando i log di uno dei server che gestisco, mi sono accorto che una delle sue interfacce di rete continuava a generare tutta una serie di eventi del tipo:

root@linux-box:~$ dmesg | grep eth0
[  184.348573] 8139too 00:40:f4:44:68:8e: eth0: link up
[  190.271409] 8139too 00:40:f4:44:68:8e: eth0: link up
[  196.374125] 8139too 00:40:f4:44:68:8e: eth0: link up
[  201.823936] 8139too 00:40:f4:44:68:8e: eth0: link up
[  208.089862] 8139too 00:40:f4:44:68:8e: eth0: link up
[  212.200536] 8139too 00:40:f4:44:68:8e: eth0: link up
[  216.950829] 8139too 00:40:f4:44:68:8e: eth0: link up
[  221.071493] 8139too 00:40:f4:44:68:8e: eth0: link up
[  226.731134] 8139too 00:40:f4:44:68:8e: eth0: link up
[  230.778527] 8139too 00:40:f4:44:68:8e: eth0: link up
[  234.126353] 8139too 00:40:f4:44:68:8e: eth0: link up
[  238.936576] 8139too 00:40:f4:44:68:8e: eth0: link up
[  244.859427] 8139too 00:40:f4:44:68:8e: eth0: link up
[  250.845563] 8139too 00:40:f4:44:68:8e: eth0: link up
[  256.831661] 8139too 00:40:f4:44:68:8e: eth0: link up
[  262.458027] 8139too 00:40:f4:44:68:8e: eth0: link up
[  266.428794] 8139too 00:40:f4:44:68:8e: eth0: link up
[  271.305659] 8139too 00:40:f4:44:68:8e: eth0: link up
[  277.091885] 8139too 00:40:f4:44:68:8e: eth0: link up
[  282.768241] 8139too 00:40:f4:44:68:8e: eth0: link up
[  287.102103] 8139too 00:40:f4:44:68:8e: eth0: link up
[  290.866316] 8139too 00:40:f4:44:68:8e: eth0: link up
[  294.267496] 8139too 00:40:f4:44:68:8e: eth0: link up

ubuntu

In più, essa risultava completamente “sorda”, nel senso che anche sniffando il traffico mediante tcpdump, non vi era evidenza di frame/pacchetti di alcun genere, nonostante fosse collegata ad un segmento di rete piuttosto popolato.

Alla luce di ciò, le cause del suddetto malfunzionamento sarebbero potute essere 2:

1) guasto hardware;
2) aggiornamento che ha compromesso i driver del kernel che si interfacciano con la scheda (leggasi moduli), rendendola inutilizzabile.

Prima di procedere con l’analisi, però, è opportuno capire come avviene il riconoscimento dell’interfaccia di rete da parte del sistema operativo durante la fase di boot.

Chipset e moduli del kernel

Durante l’accesione (boot) della macchina, il sistema operativo riconosce la scheda di rete “dialongando” con il chipset di cui è dotata. Per individuarlo è sufficiente lanciare il seguente comando (con relativo output):

root@linux-box:~# lspci | grep Ethernet

04:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

Nella fattispecie, il chipset utilizzato dalla scheda è Realtek.

Il modulo del kernel in grado di interfacciarsi con essa prende il nome di r8139too e deve essere caricato in fase di avvio. Per verificare che il suddetto modulo sia effettivamente up è sufficiente lanciare il comando:

root@linux-box:~$ lsmod | grep 8139

il cui output sarà simile al seguente:

8139too                32177  0
8139cp                 27360  0

Udev e nomenclatura

Se il modulo è stato correttamente caricato, la scheda di rete può essere effettivamente “riconosciuta” come tale ed il sistema operativo sarà in grado di assegnarle un nome.

Durante tale fase entra in gioco il demone udev, che “leggerà” il contenuto del file di configurazione dedicato alle interfacce di rete, ovvero /etc/udev/rules.d/70-persistent-net.rules:

root@linux-box:~$ cat /etc/udev/rules.d/70-persistent-net.rules

# PCI device 0x10ec:/sys/devices/pci0000:00/0000:00:1e.0/0000:04:01.0 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:40:f4:44:68:8e", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="eth0"

La suddetta regola di esempio parla chiaro: appena viene identificata una scheda di rete recante come indirizzo MAC 00:40:f4:44:68:8e, come id 0x0 e come tipo 1, le dovrà essere assegnato come nome eth0.

Configurazione

A questo punto la scheda è pronta per essere configurata, secondo quanto definito all’interno del file /etc/network/interfaces:

auto eth0
iface eth0 inet static
address 192.168.11.1
netmask 255.255.255.0

Comandi di diagnostica

Se tutto è filato per il verso giusto, lanciando un semplice ifconfig, la suddetta scheda di rete sarà tra quelle disponibili:

root@linux-box:~$ ifconfig eth0
eth0      Link encap:Ethernet  IndirizzoHW 00:40:f4:44:68:8e
          indirizzo inet:192.168.1.1  Bcast:192.168.11.255  Maschera:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1989751 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3500430 errors:0 dropped:0 overruns:0 carrier:0
          collisioni:0 txqueuelen:1000
          Byte RX:339007498 (339.0 MB)  Byte TX:3756299292 (3.7 GB)
          Interrupt:16 Indirizzo base:0xe800

Inoltre, è possibile visualizzare il modulo in uso per interfacciarsi con la suddetta scheda, avvalendosi di ethtool con l’opzione -k:

root@linux-box:~$ ethtool -i eth0

il cui output sarà simile al seguente:

driver: 8139too
version: 0.9.28
firmware-version:
bus-info: 0000:04:01.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no

Per identificare, invece, alcuni dei suoi parametri di funzionamento, quali autonegoziazione, velocità, duplex, ecc., è sufficiente lanciare il comando:

root@linux-box:~# ethtool eth0

che ci darà un risultato simile al seguente:

Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 32
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

In alternativa, si possono ottenere delle informazioni più sintetiche utilizzando il più datato (e meno completo) mii-tool:

root@linux-box:~$ mii-tool eth0
eth0: negotiated 100baseTx-FD, link ok

Identificazione della causa

A valle delle riflessioni fatte fin’ora, tutto ciò che riguarda la scheda risulta coerente e conforme con quanto ci si aspettava, per cui è stato facile intuire, andando per esclusione, che si trattava, banalmente, di un guasto hardware.

Una volta sostituita la scheda, infatti, tutto ha ripreso a funzionare correttamente.

Alla prossima.

Wake on LAN su minipc ASUS at-3iont-i

Premesso che il BIOS installato sulla mobo in questione presenta numerose limitazioni, ho deciso comunque di provare ad abilitare il Wake On LAN sul mio server casalingo (Debian).

Per prima cosa, ho provato ad individuare la voce del BIOS che mi consentisse di abilitare la suddetta funzionalità. Purtroppo però, la specifica versione di software presente sulla mia scheda madre non consente di attivare esplicitamente il WOL dalla scheda Gigabit Ethernet integrata, cosa che mi ha lasciato a dir poco sbalordito.

Nonostante ciò è comunque possibile:

1) abilitare il Wake dopo la pressione di un determinato tasto della keyboard PS2 (funzione testata da me personalmente e funzionante);

2) abilitare il Wake da mouse PS2;

3) abilitare il Wake da interfaccia PCI-Express;

4) schedulare il Wake in una data/ora ben precisa.

Ma queste opzioni non includono, ovviamente, il WOL da scheda di rete integrata.

Ho dunque creato uno scrip che consentisse di attivare la suddetta funzione, utilizzando un tool esterno, ovvero ethtool.

Per installarlo è sufficiante digitare:

nightfly@nightbox:~$ sudo apt-get install ethtool

Ad installazione completata, creiamo un file di testo vuoto:

nightfly@nightbox:~$ sudo nano autowol

il cui contenuto dovrà essere:

#!/bin/bash
ethtool -s eth0 wol g
exit 0

salviamo il file e rendiamolo eseguibile:

nightfly@nightbox:~$ sudo chmod a+x autowol

Lanciamo lo scrip e verifichiamo che il WOL mediante magic packet (g) sia effettivamente attivo:

nightfly@nightbox:~$ sudo ethtool eth0

Lo stralcio di output che ci interessa dovrà essere simile al seguente:

Supports Wake-on: pumbg
        Wake-on: g

La prima riga ci conferma che la scheda eth0 supporta il WOL, la seconda riga, invece, ci fornisce informazioni sul tipo di WOL attivo (magic packet).

Fatto ciò, è necessario che tale opzione venga attivata automaticamente ad ogni avvio del sistema (e prima dello spegnimento). Per fare questo si può copiare il suddetto scrip nella directory /etc/init.d e successivamente usare il comando:

nightfly@nightbox:/etc/init.d$ update-rc.d -f autowol defaults

Bene, a questo punto ho deciso di dare inizio ai miei test. Per prima cosa ho scaricato un software gratuito (per ambienti Windows e dotato di GUI) in grado di forgiare i magic packet. Il tool a cui mi riferisco è questo:

http://www.depicus.com/downloads/WakeOnLanGui.zip

La cosa bella di questo software è che ci permette di scegliere la porta (UDP) su cui inoltrare il magic packet, riuscendo dunque ad aggirare eventuali restrizioni imposte dal PAT (in questo modo potremo utilizzare il WOL anche da remoto).

wolgui.jpg

Per accendere il nostro server da remoto sarà sufficiente riempire i campi richiesti dal suddetto tool, ovvero:

1) MAC address della macchina che si vuole avviare;

2) indirizzo IP (oppure hostname) pubblico della macchina;

3) porta (UDP).

Solitamente il WOL si avvale della porta 7 o 9 (UDP) ma vi consiglio di forwardare porte più alte in modo da complicare la vita ad eventuali scrip kiddie (sai che piacere lasciare il server spento e ritrovarselo accesso di punto in bianco?).

In definitiva, i test hanno dato questo esito:

1) se il server è spento (S5) il WOL non funziona;

2) se il server è sospeso (S3, con RAM alimentata), il WOL funziona;

3) se il server è ibernato (S4), ovvero il dump della RAM si trova nell’area swap dell’HD, il WOL non funziona.

Quindi, così come stanno le cose il WOL è quasi inutile. Nei prossimi giorni vedrò di aggiornare il BIOS ed eventualmente di acquistare una scheda Ethernet PCI-Express.

Speriamo bene.

PS: per maggiori dattagli sui power state ACPI potete consultare questa pagina.

PPS: potete operare con i power state direttamente da CLI utilizzando il comando pmi action <stato>.

AGGIORNAMENTO del 16/04/2020

Finalmente ho trovato un po’ di tempo per lavorarci e credo di aver risolto il problema. E’ stato sufficiente modificare un’opzione del BIOS, ovvero:

Power -> Control EuP

portandola da “Enabled” a “Disabled”.

In soldoni, tale opzione (Energy Using Products), se abilitata, disattiva il WOL quando il sistema si trova in S4 (hibernate) oppure in S5 (spento).

Ergo, adesso il WOL funziona anche a PC spento.