Archivi tag: kernel

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.

kernel: ntop segfault su sonda backtrack4

Recentemente, tentando di mettere in ascolto ntop sull’interfaccia eth1 di una sonda basata sulla distro Backtrack 4, dopo un tempo totalmente randomico notavo che il servizio in questione si schiantava in modo alquanto brusco. Ad ulteriore conferma di quanto detto individuo un messaggio lapidario su /var/log/messages, ovvero:

Mar 28 16:54:02 sonda-bt4-ext kernel: ntop[4599]: segfault at 41445036 ip b72d6a18 sp b15dd230 error 6 in libc-2.8.90.so[b7265000+158000]
ntop.jpg

Oh che bello, un fantastico sementation fault. Cosa fare quindi? Gira che ti rigira individuo la presunta causa del problema nel file dnsCache.db presente nella dir /var/lib/ntop_eth1

Lancio il comando:

nightfly@bt4:/var/lib/ntop_eth1# cat /dev/null > dnsCache.db

avvio ntop_eth1 digitando:

nightfly@bt4:/var/lib/ntop_eth1# sudo service ntop_eth1 start

ed il problema è stato risolto.

Bye.