# [NET] scheda di rete fantasma?![RISOLTO]

## drumpaul

La premessa di tutto ciò è un esperimento con il wake-on lan, il risultato è che la mia gentoo non vede la scheda di rete, o meglio la situazione è questa:

la schede di rete è installata e funzionante sul pc in questione (che per la cronaca è all'interno di una lan) ma su un altro sistema operativo (windows) e sul livecd gentoo, invece con la mia installazione gentoo desktop non funziona: nella fattispecie rilevo la scheda solo con lspci, per il resto (per intenderci con ifconfig) della scheda di rete non c'è traccia nonostante abbia caricato nel core del kernel il driver 8139too, tra l'altro avevo provato anche con l'8139cp ma niente lo stesso (per continuare la cronaca la mia scheda di rete è una realtek RTL-8139/8139C/8139C+).

In conclusione la scheda di rete non ha problemi di collegamento o altro perché su un altro pc montata allo stesso modo funziona e tra l'altro come già detto funziona sullo stesso pc tranne che su gentoo desktop.

L'unica 'discrepanza' che ho rilevato è che dando un:

```
dmesg | grep net
```

ottengo:

```
audit: initializing netlink socket (disabled)
```

di seguito una voce relativa al driver, mentre su un altro pc la stessa scheda presenta la voce relativa al driver ma non quella al ...netlink socket... (che non ho idea di cosa sia).

Può essere questa la strada?

C'è anche da dire a corredo di tutto ciò che il problema l'ha dato successivamente ad un'aggiornamento del sistema... "e dici poco direte voi"... il fatto sta che tutto il resto sembra funzionare e la scheda di rete inspiegabilmente sembri scomparsa (e per finire la cronaca si accende la lucina verde del link status, quindi la scheda di rete è attiva o così dovrebbe essere).

Qualcuno di voi sa darmi qualche consiglio?

Grazie in anticipo

CiaoLast edited by drumpaul on Sun Feb 25, 2007 5:51 pm; edited 2 times in total

----------

## Kernel78

Prova a vedere se c'è  qualcosa di significativo dando

```
# dmesg  |  grep -i net

# dmesg | grep  -i eth
```

 se puoi prova  a lanciare un altro  live cd  (magari  knoppix)  e  controlla  se  la  scheda viene vista  e  nel caso guarda quali moduli vengono caricati.

----------

## drumpaul

dmesg | grep -i net da poco di più, quello che è strano è che col grep -i eth sembra che abbia identificato un'interfaccia eth0 e il macaddress appropriato

sull'altro pc (scheda di rete identica) carica i 8139too o 8139cp ma non come moduli nel core del kernel, comunque sia funziona anche su gentoo, è solo la gentoo del mio desktop che mi da problemi.

----------

## Kernel78

Scusa  ma come al solito i tuoi discorsi mi confondono  :Wink: 

Fammi capire meglio la situazione ...

Riferiamoci solo alla macchina su cui hai il problema ignorando  ogni  altra  macchina  e ogni altra scheda di rete.

Ho capito che la scheda funziona sotto win ... 

... ma non ho capito se hai problemi con la  live di gentoo o con una gentoo installata.

----------

## drumpaul

ho problemi solo con la mia gentoo desktop, su un'altra gentoo installata (quella che uso sul server su cui ho una scheda identica) funziona.

----------

## Kernel78

 *drumpaul wrote:*   

> ho problemi solo con la mia gentoo desktop, su un'altra gentoo installata (quella che uso sul server su cui ho una scheda identica) funziona.

 

Quindi non ti  ha  dato problemi durante l'installazione della gentoo ma solo dopo l'installazione ha  iniziato a  non funzionare  o ha funzionato per un  certo  periodo e  poi ha smesso ?

P.S. ti ho detto  che parliamo  solo  della  macchina  su cui non funziona  :Wink: 

----------

## drumpaul

praticamente ho sostituito la scheda precedente con una che supportasse il WOL e quest'ultima, nonostante il background finora spiegato, non vuol saperne di farsi rilevare, per lo meno completamente.

E' più chiaro ora?comunque il risultato non cambia.

----------

## Peach

e lspci cosa dice?

(se non c'è: emerge -av pciutils)

----------

## drumpaul

Non voglio essere scortese (il rispetto innanzitutto) però questo l'ho scritto nel primo post...

 *Quote:*   

> ...nella fattispecie rilevo la scheda solo con lspci...

 

Ieri provando a rismanettare ho provato ricompilando il kernel...

praticamente stavo usando gcc 4 son passato a gcc 3.X.X (per compilare qemu) e poi essendomi dimenticato di ritornare a gcc 4 ho per sicurezza ricompilato il kernel con quest'ultima ma niente... in fatti per quanto ne possa dire sembra un problema di kernel o giù di li...boh?!

----------

## Peach

 *drumpaul wrote:*   

> però questo l'ho scritto nel primo post...
> 
>  *Quote:*   ...nella fattispecie rilevo la scheda solo con lspci... 

 

scusa, mi era sfuggito. Comunque potresti riportare l'output di lspci ?

----------

## drumpaul

Figurati.

Ora non ho possibilità di postare l'output preciso comunque spero basti sapere che rileva la periferica giusta e lo stesso output lo da su un'altra macchina con la stessa scheda di rete su cui il problema non sussiste.

----------

## Peach

vabé... la scheda ha chipset 8139 o 8139C+ ? le schede sono diverse (e per la seconda i drivers sono marcati come sperimentali). hai confrontato l'output di lspci sulle due macchine?

inoltre che kernel stai usando?

posteresti l'output di:

```
# grep -i ^[^#].*net .config
```

magari, giusto per stare sicuri, anche 

```
# dmesg | grep -i pci
```

----------

## drumpaul

Posterò ciò che mi hai chiesto.

Per ora ti posso dire che ho provato i driver 8139too e 8139cp che con la stessa scheda funzionano ma su un'altro sistema...

Gli lspci sono identici sia sulla macchina su cui funziona che su quella che non funziona.

Il kernel che sto usando è il gentoo-2.6.18-r6 .

Così a naso direi che è qualcosa nel mio linux che non permette il rilevamento e inizio a sospettare (anche se mi hai preceduto tu) che sia il kernel la causa di tutto.

Per gli output posterò al più presto.

Per ora grazie per il supporto, spero di venirne a capo.

Ciao

PS

tra l'altro ricordo che sul pc su cui ho questo problema la scheda non fa una piega e funziona alla perfezione se avvio una gentoo livecd (quello minimale)

----------

## Peach

magari... se hai modo, proverei a fare uno stupido esperimento per eliminare possibili problemi hardware: scambia le schede dei due pc e vedi... se non cambia niente è un problema kernel (al 90%)

----------

## drumpaul

mmm..già, mi sa che è quello che mi rimane da fare... non ho altre idee e la situazione è inverosimile.

Grazie ancora per l'aiuto.

Vi farò sapere cosa succede, ciao

----------

## drumpaul

confermo...scambiando le schede la situazione non cambia il mio desktop non 'vede' la scheda invece il pc con cui ho fatto lo scambio non ha fatto una piega.

confrontando i comandi:

```
dmesg | grep -i net
```

e

```
dmesg | grep -i eth
```

le differenze sono che riguardo al primo comando nel pc su cui ho il problema c'è una riga in più rispetto all'altro e cioè:

```
audit: initializing netlink socket (disabled)
```

per il resto tutto uguale, mentre per quanto riguarda l'altro comando ho una riga in più sul pc su cui non ho problemi che enuncia:

```
eth0: link up, 100Mbps, half-duplex, lpa 0x40A1
```

Per quanto riguarda il kernel cosa mi consigliate di fare?l'ho già ricompilato e aggiornato ma il problema persiste... ora non so cosa implichi "initializing netlink socket (disable)" ma penso che l'errore sia quello o comunque collegato a quest'ultimo mentre mi pare ovvio che la dicitura "eth0: link up..." stia ad indicare che la scheda oltre ad essere rilevata è funzionante.

Mi sembra di non aver cavato un ragno dal buco e odio l'eventualità di reinstallare gentoo con la metodologia winzozz (problema -> format C :Smile: ... spero che abbiate altre idee o quantomeno indicazioni su come ripristinare un kernel sicuramente funzionante.

Grazie

Ciao[/quote]

----------

## Kernel78

Prova a dare su entrambe le macchine un 

```
grep -E '^C.*(NET|PCI)' /usr/src/linux/.config
```

 e fai un diff dei risultati.

----------

## drumpaul

Sono quasi sicuro che tutto sia a posto comunque appena ne ho la possibilità posto l'output.

----------

## drumpaul

Allora ho ripulito il sistema da tutti i sorgenti del kernel e ne ho ricompilato uno ex-novo, come da prima installazione con i driver per la scheda di rete; questo è il risultato per il pc che ha problemi:

```
CONFIG_PCI=y

CONFIG_PCI_GOANY=y

CONFIG_PCI_BIOS=y

CONFIG_PCI_DIRECT=y

CONFIG_PCI_MMCONFIG=y

CONFIG_NET=y

CONFIG_INET=y

CONFIG_NET_IPIP=y

CONFIG_NET_IPGRE=y

CONFIG_INET_TUNNEL=y

CONFIG_INET_XFRM_MODE_TRANSPORT=y

CONFIG_INET_XFRM_MODE_TUNNEL=y

CONFIG_INET_XFRM_MODE_BEET=y

CONFIG_INET_DIAG=y

CONFIG_INET_TCP_DIAG=y

CONFIG_NETFILTER=y

CONFIG_BRIDGE_NETFILTER=y

CONFIG_BLK_DEV_IDEPCI=y

CONFIG_IDEPCI_SHARE_IRQ=y

CONFIG_BLK_DEV_IDEDMA_PCI=y

CONFIG_IDEDMA_PCI_AUTO=y

CONFIG_NETDEVICES=y

CONFIG_NET_ETHERNET=y

CONFIG_NET_PCI=y

CONFIG_SERIAL_8250_PCI=y
```

invece questo è l'output per il pc che funziona

```
CONFIG_PCI=y

CONFIG_PCI_GOANY=y

CONFIG_PCI_BIOS=y

CONFIG_PCI_DIRECT=y

CONFIG_PCI_MMCONFIG=y

CONFIG_NET=y

CONFIG_INET=y

CONFIG_NET_IPIP=y

CONFIG_NET_IPGRE=y

CONFIG_INET_TUNNEL=y

CONFIG_NETFILTER=y

CONFIG_BRIDGE_NETFILTER=y

CONFIG_NETFILTER_XTABLES=y

CONFIG_NETFILTER_XT_MATCH_LIMIT=y

CONFIG_NETFILTER_XT_MATCH_MAC=y

CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y

CONFIG_NETFILTER_XT_MATCH_STATE=y

CONFIG_NET_SCHED=y

CONFIG_NET_SCH_CLK_GETTIMEOFDAY=y

CONFIG_NET_SCH_HTB=y

CONFIG_NET_SCH_INGRESS=y

CONFIG_BLK_DEV_IDEPCI=y

CONFIG_IDEPCI_SHARE_IRQ=y

CONFIG_BLK_DEV_IDEDMA_PCI=y

CONFIG_IDEDMA_PCI_AUTO=y

CONFIG_NETDEVICES=y

CONFIG_NET_ETHERNET=y

CONFIG_NET_PCI=y

CONFIG_SERIAL_8250_PCI=y

```

Questo dovrebbe essere il diff anche se non sono sicuro, magari voi riuscite a capirlo meglio (infatti per sicurezza ho postato anche i rispettivi output delle singole macchine):

 *Quote:*   

> 11,15d10
> 
> < CONFIG_INET_XFRM_MODE_TRANSPORT=y
> 
> < CONFIG_INET_XFRM_MODE_TUNNEL=y
> ...

 

in breve ho fatto # diff [file output fake] [file output ok]

Spero questo aiuti... ah dimenticavo, a questo punto è inutile che vi dica che il problema sussiste, nonostante abbia reinstallato il kernel, ripulito il sistema da quelli precedenti e ricompilato da zero...  :Sad: 

Attendo news

Grazie ancora

Ciao

PS

per la cronaca le rispettive versioni dei kernel sono:

per il pc 'ok' 2.6.17-gentoo-r8

per il pc 'fake' 2.6.19-gentoo-r5

----------

## Peach

dal diff non sembra ci sia niente d particolare (nella macchina in cui va hai QoS attivo e poche altre cose mentre nell'altra qualche filtro ipsec che non so se usi)

quindi niente che faccia pensare ad un problema di configurazione di rete (almeno... sempre che non sia il bus pci o l'host bridge cannato, controlla, non si sa mai)

ora però resta da vedere un paio di cose.

la prima: avvia la macchina senza fare l'autoload del driver di rete, caricalo a mano e vedi se in dmesg appare qualcosa.

secondo: come prenderebbe l'ip la macchina? via dhcp? oppure è un ip statico? posteresti la configurazione della scheda?

proverei a fargli caricare l'ip a mano (a meno che tu non lo faccia già)

e vedere l'output di

```
# ip addr ethX show && route -n
```

poi vediamo

ciao

----------

## drumpaul

E' proprio quello il bello i driver della scheda li carco nel core del kernel quindi non come moduli e teoricamente (ma anche praticam, per lo meno così pare da dmesg [vedi output precedenti post]) automaticamente all'avvio del sistema e poi la configurazione della scheda... intendi quello che dovrebbe apparire digitanto 'ifconfig' ? beh è proprio questo il problema non la trova proprio e dice che la periferca eth0 non esiste quindi a parte 'lo' non visualizzo altro tra le periferiche di rete configurabili, comunque per la cronaca davo gli indirizzi statici e giuro non andavano in conflitto con gli altri della rete (tutti altrettanto statici e impostati da me personalmente).

boh mi pare una cosa assurda questa situazione...ma ci sarà una spiegazione logica a tutto ciò? ...sto sempre di più pensando alla soluzione winzozziana (format) ma mi scazza parecchio, senza contare che non ho molto tempo e già ne ho dedicato tanto a cercar di capire cos'ha... nonostante tutto sta diventando una questione di principio quindi attendo altri suggerimenti.

Domanda: a parte dal lato kernel e dal lato hardware c'è qualcosa che può 'rompere le scatole' alla scheda di rete? tipo configurazioni o versione di gcc o che so...(sto sparando a caso), magari ho casinato troppo con gli aggiornamenti.

Per quanto riguarda questo invece:

 *Quote:*   

> (almeno... sempre che non sia il bus pci o l'host bridge cannato, controlla, non si sa mai) 

 

ti chiedo di essere un po' più esplicito e di dirmi cosa intendi a livello pratico che io faccia

Grazie

Ciao

----------

## macca75

Consiglio da Gentuista alle prime armi:

prova a spostare la scheda in un altro slot pci.............

Ciao

----------

## Peach

 *drumpaul wrote:*   

> E' proprio quello il bello i driver della scheda li carco nel core del kernel quindi non come moduli e teoricamente (ma anche praticam, per lo meno così pare da dmesg [vedi output precedenti post]) automaticamente all'avvio del sistema e poi la configurazione della scheda...

 

Sarebbe il caso, per avere un migliore controllo sul problema, di compilare nel kernel tutti i driver che hai abilitato come MODULI. (possibile anche che udev capisca da solo quale caricare), però al massimo puoi sempre scaricarli e ricaricarli per monitorare l'output del kernel.

 *drumpaul wrote:*   

> intendi quello che dovrebbe apparire digitanto 'ifconfig' ? beh è proprio questo il problema non la trova proprio e dice che la periferca eth0 non esiste

 

si, quindi dando il comando che ti ho scritto sopra ti dice "scheda di rete inesistente"?

 *drumpaul wrote:*   

> Domanda: a parte dal lato kernel e dal lato hardware c'è qualcosa che può 'rompere le scatole' alla scheda di rete? tipo configurazioni o versione di gcc o che so...(sto sparando a caso), magari ho casinato troppo con gli aggiornamenti.

 

potrebbe anche essere una leggerezza in fase di configurazione della macchina lato kernel.. oppure sempre un problema hardware (tipo del bus pci, prova anche a cambiare slot come suggerito)

 *drumpaul wrote:*   

> Per quanto riguarda questo invece:
> 
>  *Quote:*   (almeno... sempre che non sia il bus pci o l'host bridge cannato, controlla, non si sa mai)  
> 
> ti chiedo di essere un po' più esplicito e di dirmi cosa intendi a livello pratico che io faccia

 

Chiaramente io sto continuando a pensare che tu abbia compilato il kernel a mano (sbaglio???)

Comunque verifica che i vari bus siano stati selezionati correttamente, sarebbe a dire, dall'output di lspci confronti e verifichi se i supporti sono stati abilitati (era anche una delle ragioni per cui ti chiedevo di postare l'output di lspci.) e non duplicati. Giusto per farti un esempio: se hai dischi sata e selezioni tutt'e due i driver sata presenti nel kernel la macchina fa le bizze.

EDIT: aggiungo: se hai problemi a selezionare i dispositivi giusti fammi sapere.

----------

## drumpaul

Provo a rispiegare la situazione più dettagliatamente:

- all'avvio del sistema mi dice che l'interfaccia eth0 non esiste e infatti con 'ifconfig' visualizza solo l'interfaccia di loop

- provo a modularizzare i driver della scheda a turno cioè ho provato sia il 8139too che il 8139cp (...si il kernel me lo smazzuolo a mano e fino ad ora son sempre riuscito a far funzionare tutto...) ma ciò non da risultato

- provando a scambiare le 2 schede rispettivamente quella che funziona e quella no ho lo stesso risultato senza contare che la stessa scheda, quella che non sembra funzionare, con un livecd sul pc problematico va come una lippa quindi non penso sia lo slot

- infine visto che siete uomini di poca fede  :Wink:   vi posto il mio lspci che è sempre stato così e a mio avviso sembra rilevi tutto correttamente:

```
00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4)

00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP]

00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)

00:04.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)

00:04.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 16)

00:04.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 16)

00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)

00:05.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)

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

00:0a.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 08)

00:0a.1 Input device controller: Creative Labs SB Live! Game Port (rev 08)

01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2)

```

Ora che faccio mi sparo o sparo alla scheda di rete?

Spero di uscirve vivo   :Shocked: 

----------

## Peach

 *drumpaul wrote:*   

> Provo a rispiegare la situazione più dettagliatamente:
> 
> --CUT--
> 
> 

 

ora, per favore, potresti rispondere alle domande e suggerimenti che ti sono stati rivolti? in particolar modo:

hai provato a spostare di uno slot la scheda come suggerito da macca75?

hai controllato che il kernel avesse il supporto ai vari bus (in particolar modo host e pci) abilitato builtin?

potresti postare l'output di 'ip addr eth0 show'?

cosa ti mostra il kernel in dmesg quando inserisci uno dei due moduli (mi pare che ora tu li abbia come tali) della scheda di rete?

 *drumpaul wrote:*   

> - infine visto che siete uomini di poca fede   vi posto il mio lspci che è sempre stato così e a mio avviso sembra rilevi tutto correttamente:

 

come ho cercato di spiegarti nel post mio precedente, la richiesta di lspci non è per mancanza di fede nei tuoi confronti, ma per sapere se eri in grado, confrontando l'output di lspci, di verificare correttamente che le varie interfaccie hardware fossero attivate nel kernel, infatti l'output di lspci non è strettamente legato alla configurazione del kernel. Che uno la veda e l'altro no, è possibile. Tutto qui.

anzi ancora meglio

dopo aver caricato uno dei due moduli posta il risultato del seguente comando:

```
# ls -l /sys/bus/pci/devices/0000\:00\:08.0/net*
```

----------

## Kernel78

A parte spostare la scheda in un altro slot (se il live cd la riesce ad usare non vedo perchè spostarla) gli altri suggerimenti hanno il mio pieno supporto.

Ancor prima di quelli vorrei puntualizzare una cosa: dici che ifconfig ti mostra solo l'interfaccia di loopback ma tu hai lanciato solo ifconfig o 

```
ifconfig -a
```

 senza opzioni ti vengono mostrate solo le interfacce attive, quindi potrebbe essere che la scheda sia anche riconosciuta dal kernel ma che qualche errore nella configurazione non la faccia attivare ...

Magari non è questo il caso ma sappiamo benissimo che a volte sono proprio le cose più banali a dare i grattacapi più grandi  :Wink: 

----------

## drumpaul

Argh.... bastava quel benedetto 'ifconfig -a' per svelare il mistero e poi mi devi spiegare 'peach' da dove arriva quel comando...

Penso che abbiate risolto il mistero!anzi, ne son sicuro e ho testato!

In effetti, la colpa è mia perché avevo tralasciato un particolare: ho messo la 'nuova' scheda su uno slot differente rispetto alla precedente. Infatti dando quel comando ho scoperto che la mia scheda di rete non è eth0... bensì è stata 'promossa' a eth2.

Infatti modificando l'init script di rete a eth2 tutto va tutto come una lippa... mi dispiace, giuro!

Anzi vorrei capire come funziona il rilevamento dell'hardware su linux relativamente agli slot pci & co. e/o magari più nel dettaglio la struttura/significato della directory /sys e/o il significato di quegli indirizzi 'xxxx:xx:xx.x'.

Magari semplicemente fatemi sapere dove reperire tale documentazione...

Quindi parlando da ignorante, è giusto dire che se non risposto la scheda di rete sullo slot 'precedente' non otterrò mai che la mia interfaccia sia identificata come eth0?

Umilmente grazie

PS

Scusate per il tono dell'ultimo post e in particolare mi scuso con 'peach', il fatto è che non ne potevo più di questo problema assurdo che non si riusciva a risolvere... ma tutto è bene quel che finisce bene

----------

## Kernel78

La mia scheda pci è eth1 (eth0 è quella integrata) a prescindere da quale sia lo slot a cui la collego, penso che il tuo sia un "problema" di udev.

----------

## Peach

 *Kernel78 wrote:*   

> La mia scheda pci è eth1 (eth0 è quella integrata) a prescindere da quale sia lo slot a cui la collego, penso che il tuo sia un "problema" di udev.

 

teoricamente (non ho ancora indagato in profondità, ma dai vari post sembrerebbe così) udev registra la scheda in base alla posizione nel bus pci così ai prossimi riavvii ricorda l'id della periferica indipendentemente dalla sua posizione (questa cosa è ottima specialmente sui bus usb).

@drumpaul: nessun problema, so che può essere snervante, ma non avendo output la cosa risulta sempre difficile da risolvere. Magari la prossima volta posta gli output dei comandi che ti vengono suggeriti e magari chiedi la spiegazione se non ne capisci il motivo.

Per quanto riguarda il comando che "ho tirato fuori" diciamo che ho semplicemente pensato che da qualche parte il sistema deve collegare la periferica del kernel all'hardware (e sotto linux tutto è un file bene o male). Il "numero" (nel tuo caso 0000\:00\:08.0) è stato semplicemente dedotto dall'output di lspci (00:08.0) relativo alla tua scheda di rete.

that's all folks  :Cool: 

PS: aggiungi [RISOLTO] al titolo del thread modificando il primo post.

----------

## drumpaul

infatti non avevo fatto caso che quegli strani numeri dati da lspci o che comunquer avessero qualche significato che potessi dedurne, ora mi è tutto più chiaro, grazie della dritta e dei consigli, poi vedrò di sistemare quella cosa con udev per quanto riguarda il numero dell'interfaccia (se veramente quello è il punto).

Ancora grazie a tutti, ciao (e a buon rendere ovviamente)! :Smile: 

----------

