Linux: Problemi di connessione con Realtek r8169 / r8111

Le schede indicate nel titolo vengono spesso riconosciute da Linux come delle r8169 e quindi il sistema provvede a caricare il modulo r8169 che potrebbe darvi qualche problema.

Su una Ubuntu 12.04LTS il driver r8168  e' già compilato all'interno del kernel di default. In questo caso sara' sufficiente bloccare il caricamento del modulo sbagliato inserendo la riga:

blacklist r8169 

nel file:

/etc/modprobe.d/blacklist-network.conf

Per altri sistemi che non avessero il driver r8168 precompilato nel kernel consigliamo di seguire la procedura seguente:

cd /usr/src
wget http://djlab.com/stuff/r8168-8.032.00.tar.bz2
tar jxvf r8168-8.032.00.tar.bz2
cd r8168-8.032.00
make clean modules
make install
depmod -a
echo "blacklist r8169" >> /etc/modprobe.d/blacklist-network.conf
update-initramfs -u

Per poter compilare automaticamente il modulo ad ogni aggiornamento di kernel, e' necessario ricorrere al sistema dkms.
Verifichiamo di avere installato dkms:

apt-get install dkms gcc

Creare il file:

dkms.conf

con il seguente comando:

cat < /usr/src/r8168-8.032.00/dkms.conf
PACKAGE_NAME=r8168
PACKAGE_VERSION=8.032.00
MAKE[0]="'make'"
BUILT_MODULE_NAME[0]=r8168
BUILT_MODULE_LOCATION[0]="src/"
DEST_MODULE_LOCATION[0]="/kernel/updates/dkms"
AUTOINSTALL="YES"
EOF

ed eseguire i comandi seguenti:

dkms add -m r8168 -v 8.032.00
dkms build -m r8168 -v 8.032.00
dkms install -m r8168 -v 8.032.00

Se non avete ricevuto errori, il vostro modulo e' stato installato correttamente e sara' ricompilato in automatico dal sistema ad ogni aggiornamento di kernel.

Se per caso, durante la compilazione del modulo, doveste avere errori del tipo:

root/r8168-8.035.00/src/r8168_n.c:14545: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘rtl8168_init_board’

Sara' necessario applicare la patch seguente:

diff -ruB r8168-8.035.00/src/r8168_n.c r8168-8.035.00/src/r8168_n.c
--- r8168-8.035.00/src/r8168_n.c        2012-12-19 05:38:56.000000000 -0500
+++ r8168-8.035.00/src/r8168_n.c        2013-03-17 12:48:58.693002848 -0400
@@ -14541,7 +14541,7 @@
        spin_unlock_irqrestore(&tp->phy_lock, flags);
 }

-static int __devinit
+static int
 rtl8168_init_board(struct pci_dev *pdev,
                   struct net_device **dev_out,
                   void __iomem **ioaddr_out)
@@ -14711,7 +14711,7 @@
        goto out;
 }

-static void __devinit
+static void
 rtl8168_init_sequence(struct rtl8168_private *tp)
 {
        void __iomem *ioaddr = tp->mmio_addr;
@@ -14964,7 +14964,7 @@
 };
 #endif

-static int __devinit
+static int
 rtl8168_init_one(struct pci_dev *pdev,
                 const struct pci_device_id *ent)
 {
@@ -15128,7 +15128,7 @@
        return 0;
 }

-static void __devexit
+static void
 rtl8168_remove_one(struct pci_dev *pdev)
 {
        struct net_device *dev = pci_get_drvdata(pdev);
@@ -17649,7 +17649,7 @@
        .name           = MODULENAME,
        .id_table       = rtl8168_pci_tbl,
        .probe          = rtl8168_init_one,
-       .remove         = __devexit_p(rtl8168_remove_one),
+       .remove         = rtl8168_remove_one,
 #if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,11)
        .shutdown       = rtl8168_shutdown,
 #endif

e ripetere la compilazione. Tutto qua :)

Re: [RISOLTO] Vista: Rete non identificata.

Faccio seguito a un post del febbraio 2008. Era a proposito del problema, riscontrato da molti su Windows Vista, che impedisce di uscire su internet in quanto la rete a cui si e' collegati (bene e spesso la propria rete di casa/ufficio) viene rilevata come potenzialmente insicura (come faremmo se non ci fosse il vecchio Zio Bill a proteggerci???).

La soluzione che avevo riportato nel vecchio post (modificare il canale utilzzato dal proprio access point wifi) non era affatto risolutiva.

Sembra invece che finalmente si riesca a vedere la luce in fondo a questo tunnel. Spero mi confermerete la cosa che comunque ho gia' avuto modo di testare da diversi clienti. E' sufficiente
fermare e disabilitare il servizio "Riconoscimento presenza in rete".

Successivamente il computer sosterra' di non essere collegato a nessuna rete, ma verificando con il comando ipconfig potrete constatare il contrario.

E' un accrocchio e fa schifo...ma del resto le stesse cose si possono dire di Vista...quindi si tratta di un accrocchio Vista compatibile al 100% ;-)

Se CUPS non vede le stampanti di rete...

Se cercando di stampare un documento vedete solo le stampanti locali e non quelle installate su altri nodi della vostra rete provate a lanciare il comando seguente:

netstat -na | grep 631

Dovreste ottenere qualcosa del genere:

tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:631 0.0.0.0:*

Se non vedete niente del genere significa che probabilmente cups e' partito correttamente, pero' con i servizi di rete disabilitati.
Eseguite il comando:

sudo /etc/init.d/cups restart

Visualizzate subito dopo il file /var/log/cups/error_log: nel mio caso conteneva le seguenti segnalazioni:

E [18/May/2009:16:27:46 +0200] Unable to open listen socket for address :::631 - Permission denied.
E [18/May/2009:16:27:46 +0200] Unable to open listen socket for address 0.0.0.0:631 - Permission denied.
I [18/May/2009:16:27:46 +0200] Listening to /var/run/cups/cups.sock on fd 3...
I [18/May/2009:16:27:46 +0200] Resuming new connection processing...
E [18/May/2009:16:27:46 +0200] Unable to create broadcast socket - Permission denied.

E' un bug conosciuto e deriva dall'interazione tra cups e apparmor. Pare sia stato sistemato nella versione 1.3.9-15 di cups (al momento non disponibile per Intrepid ma gia' presente su Jaunty).
Nel frattempo potete sistemare la cosa con un piccolo workaround:

sudo cd /etc/apparmor.d/force-complain
sudo ln -s /etc/apparmor.d/usr.sbin.cupsd .
sudo /etc/init.d/apparmor restart
sudo /etc/init.d/cups restart

provate di nuovo il comando eseguito all'inizio di questo post:

netstat -na | grep 631

Dovreste ottenere qualcosa del genere:

tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:631 0.0.0.0:*

In caso contrario fatemi sapere che vediamo cosa si puo' fare.

LTSP: ipconfig: eth0: SIOCGIFINDEX: No such device

Il progetto LTSP (Linux Terminal Server Project) consente di utilizzare dei thin-client collegati in rete a un server linux debitamente preparato.

Potete usare thin-client veri e propri o utilizzare un PC, anche vecchio, purche' possa eseguire il boot da rete e abbia una scheda video gestita da linux.

• Che vantaggi abbiamo con questa configurazione?
• Possiamo utilizzare come client dei PC altrimenti obsoleti
• Non e' richiesto che il client abbia un disco rigido, quindi meno dati sparsi, meno rischi di rottura, meno calore generato dai client, maggiore protezione dei dati conservati sul server (che in quanto tale si ritiene ridondato, backuppato e quindi piu' sicuro)

Purtroppo puo' capitare, eseguendo il boot da rete di ricevere questo errore:
ipconfig: eth0: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
/init: .: 1: Can't open /tmp/net-eth0.conf
[] Kernel panic - not syncing: Attempted to kill init!

Questo perche' probabilmente il modulo relativo alla scheda di rete installata sul client non e' presente nel kernel scaricato dalla rete.

Vediamo quindi come aggiungere un driver al kernel distribuito dal server LTSP (nell'esempio faro' riferimento al modulo sis190 relativo alle schede ethernet 190 prodotte dalla SiS):

Loggarsi come amministratore sul server LTSP
Aggiungere al file /opt/ltsp/i386/etc/initramfs-tools/modules il nome del modulo richiesto, in questo caso sis190
Se esiste il file /opt/ltsp/i386/usr/share/initramfs-tools/hook-functions, aggiungere il nome del driver alla linea contenente i riferimenti alle altre schede come nell'esempio seguente:
da

r8169 s2io sis900 skge slhc smc911x starfire \

a

r8169 s2io sis900 skge slhc smc911x starfire sis190 \

Eseguire i comandi seguenti:

chroot /opt/ltsp/i386 update-initramfs -u
ltsp-update-kernels

Sul mio server in questa fase ricevo qualche errore secondario, pero' il driver viene installato correttamente.

Virtualbox: Unknown error creating VM (VERR_HOSTIF_INIT_FAILED)

Questo errore puo' capitare in caso utilizzate Virtualbox con interfacce di rete virtuali in bridge con le interfacce fisiche della macchina.

Soluzione brutta:

sudo chmod 666 /dev/net/tun

LA Soluzione:

Controllate che il vostro utente faccia parte del gruppo vboxusers

Se per caso l'errore fosse ancora li' dopo questa verifica, probabilmente e' necessario ristabilire le corrette permission sul device. Lanciate senza timore (oddio ;-) il seguente comando:

sudo chown :vboxusers /dev/net/tun

iwgetid: a che rete wireless siamo collegati?

Comando utile da usare nei vostri script preferiti.

/usr/sbin/iwgetid

Ecco un esempio di output:

eth1 ESSID:"nome_della_mia_rete_wireless"

Un esempio di utilizzo in uno script? Detto fatto:

MIO_ESSID=`iwgetid | cut -d: -f2 | cut -d\" -f2`

In questo esempio la variabile MIO_ESSID viene valorizzata con
il nome (ESSID) della rete wireless a cui siamo collegati.

Abilitare SNMP su tutta la rete (e non solo da localhost)

In un precedente articolo abbiamo visto come configurare SNMP per consentire di monitorare un server mediante il software cacti.

La configurazione proposta pero', per motivi di sicurezza non consente di monitorare una macchina se non da se stessa. Il demone SNMPD infatti accetta per default solo richieste provenienti dall'indirizzo 127.0.0.1 (localhost).

La maggior parte delle guide indica come abilitare l'accesso al demone snmpd dagli altri host della rete inserendo l'indirizzo della rete (es.: 192.168.1.0/24) nelle dichiarazioni com2sec del file /etc/snmp/snmpd.conf

Purtroppo questa soluzione non sembra funzionare.
E' invece risolutiva questa serie di istruzioni (almeno per le distribuzioni Debian based):

Salvate il file di configurazione di snmp:

sudo mv /etc/snmp/snmpd.conf /etc/snnp/snmpd.conf.orig

Create un nuovo file /etc/snmp/snmpd.conf contenente le linee seguenti:

# sec.name source community com2sec readonly default public # sec.model sec.name group MyROGroup v1 readonly # incl/excl subtree mask view all included .1 80 view system included .iso.org.dod.internet.mgmt.mib-2.system # context sec.model sec.level match read write notif access MyROGroup "" any noauth exact all none none

N.B.: non so se questa configurazione apra falle di sicurezza o cose del genere. Se decidete di utilizzarla siete pregati di verificare o di accettarne il rischio.
In caso sostituite a 'public' il nome della vostra community SNMP.
Fate ripartire il demone snmpd:

sudo /etc/init.d/snmp restart

Se ancora non riuscite a collegarvi da un'altra macchina della vostra rete, probabilmente e' colpa dei parametri di linea di comando con cui viene lanciato snmpd. Questi sono nascosti in /etc/defaults/snmpd. In particolare nella variabile SNMPDOPTS. Bisogna rimuovere dalla sua definizione l'indirizzo 127.0.0.1

Rete a onde convogliate: rete LAN su rete elettrica

Non male l'offerta di Alice Video, digitale terrestre, video on demand e eventualmente Sky (se solo non odiassi Sky....ma tanto a settembre me ne libero)

Non male dicevo...ma solo se hai il televisore vicino alla presa telefonica e possibilmente non incastrato in una specie di mobile antico.

Se non vi trovate nella condizione ideale sopra descritta avrete qualche problema, in quanto vi troverete il router di Alice vicino alla presa telefonica, il decoder vicino al televisore e qualche metro di cavo di rete CAT5 o superiore che attraversa il vostro salotto, piu' o meno nascosto ma pur sempre irrimediabilmente visibili (specialmente mentre scala il mobile antico).

Una condizione sicuramente odiata da qualsiasi massaia (o madre, o moglie, o ...)

La soluzione che ho adottato in una situazione del genere e' quella della rete a onde convogliate.
In pratica si usano due 'scatolini' (nel mio caso i Devolo dLan 200 AVeasy) inseriti in due prese di corrente vicine alle apparecchiature da collegare (router e decoder in questo caso). Queste sono collegate agli 'scatolini' con un semplice cavo di rete.

Il gioco e' fatto. I nostri pacchetti di dati gireranno allegramente sulla rete elettrica, da uno scatolino all'altro. Anzi se avete piu' scatolini potrete collegare insieme piu' apparecchiature.

Il modello 200 e' dichiarato per 200 Mbps e consente un trasferimento decente dello streaming video (il vecchi modelli da 85 Mbps stentavano un po', figurarsi quelli da 14 Mbps)

Purtroppo nel caso di Alice, non e' possibile usare contemporaneamente il collegamento Video e il normale collegamento internet in quanto usano due canali separati del router. Per passare da un tipo di collegamento all'altro e' pero' sufficiente spostare il cavo di rete dalla porta del router dedicata al video (colorata in verde) a una delle altre porte disponibili.

[RISOLTO] Vista: Rete non identificata.

Aggiornamento: altre mirabolanti soluzioni in QUESTO POST

Nel precedente post Vista: Rete non identificata,avevo fatto alcune ipotesi per risolvere un problema presente su centinaia di forum italiani e non: l'impossibilita' di Vista di collegarsi a internet a causa della mancata identificazione della rete locale.

Alla fine il problema e' stato risolto anche se non so darne una spiegazione precisa in quanto ho modificato 2 parametri contemporaneamente:

• Modificato il canale dei miei access point (c'erano altri 5 AP sconosciuti sullo stesso canale)
• Differenziato gli SSID dei miei AP (prima erano tutti uguali...anche se non dovrebbe essere un problema)

Ora le 4 macchine Vista della sala corsi si collegano perfettamente senza lamentarsi.

Resta ancora da risolvere il problema della sparizione momentanea del router descritta nel post Il poltergeist e' ancora tra noi...

Vista: Rete non identificata.

Sono di nuovo alle prese con i 3 portatili della sala corsi. Tutti e 3 carrozzati con un pregevolissimo (?!?) Microsoft Windows Vista Home Basic.

Tutti e 3 presentavano lo stesso problema. Cercando di connetterli alla rete wifi dell'ufficio (wpa2) ricevevo dal sistema queste bellissime indicazioni.

• Segnale Eccellente
• Rete non identificata (SSID)
• Connessione limitata.

Sorgono spontanee le seguenti considerazioni:

• Se il segnale e' eccellente, perche' la connessione e' limitata?
• Se la rete non e' identificata, perche' mi fai vedere il suo SSID?

Beh alla fine della fiera il concetto si riassume cosi': il sistema ha paura che quella rete non sia sicura e affidabile e cosi' impedisce al povero utente di utilizzarla.

Alcune ragioni che possono incutere (erroneamente) questo terrore nel vostro sistema Vista:

• Protocollo IPv6 in assenza di apparecchiature di rete che lo supportino.
• Presenza di prodotti Norton / Symantec non correttamente disinstallati
• Altri motivi sconosciuti

Nel primo caso bisogna controllare di non avere disattivato il servizio di windows Helper IP o in alternativa disabilitare il protocollo IPv6.

Nel secondo non ci si puo' fidare della normale procedura di disinstallazione dei prodotti Norton / Symantec. Bisogna invece utilizzare l'apposito tool di rimozione scaricabile all'indirizzo:

http://service1.symantec.com/SUPPORT/norton2008.nsf/docid/2007082908475279?Open&src=symsug_us&docid=2005033108162039&nsf=tsgeninfo.nsf&view=docid&pid=2007020923124413&pkb=sharedtech

Nel terzo caso una preghierina a San Google potrebbe portare a qualche insperata soluzione.

Nel mio caso la soluzione e' stata curiosa: ho attivato i servizi Helper IP e Routing e accesso remoto (precedentemente disabilitati per alleggerire il carico della macchina)

Ecco che finalmente la rete viene ritenuta sicura, identificata e il computer esce su internet. Per la seconda macchina non ho fatto nulla (i servizi erano gia' attivi): che si sia fidata del giudizio dell'altra? :)

Per la terza (il bieco Acer) stessa cosa: si e' fidata di quello che dicevano i due HP e si e' collegato....pero' solo a uno dei 2 access point (quello con il firmware piu' aggiornato)

Per risolvere questo problema ho aggiornato il firmware del secondo access point.

Ora le tre macchine sono online e pronte a riempirsi di virus e malware di ogni tipo.

Prossimamente verranno dotate di Linux Ubuntu in dual boot.

Il poltergeist e' ancora tra noi...

Vi espongo questo simpatico esercizio di stile che mi sta facendo
diventare matto e che ho gia' esposto anzitempo a diverse persone che non hanno potuto che confermare la presenza di un poltergeist.

Ufficio A

Router ADSL R1 (dhcp server) (10.0.0.1)
Switch
PC1 (10.0.0.3)
Access Point A1 (WEP) (10.0.0.2)
Access Point A2 (wifi bridge) (10.0.0.4)

Ufficio B

Access Point B1 (wifi bridge) (10.0.0.5)
Access Point B2 (WPA-PSK) (10.0.0.6)
Access Point B3 (WPA-PSK) (10.0.0.7)
Switch
PC2 (dhcp)
PC3 (dhcp)
PC4 (dhcp)

I due uffici sono collegati tra loro tramite il bridge wireless A2-B1
Il link e' stabile e mi consente di scaricare da internet all'ufficio B a ben 500 KB/s (massimo raggiungibile dall'ADSL dell'ufficio A)

PC2 e' un Toshiba Satellite M70-166, Ubuntu Gutsy 7.10, wicd 1.4.1,
scheda wifi ipw2200.

Il firmware di B2 e'quello di fabbrica
Il firmware di B3 e'quello piu' aggiornato disponibile in rete

Capita abbastanza spesso che PC2 non veda piu' R1:

- lo conosce perche' R1 e' nella tabella arp
- non lo pinga
- non esce su internet

In compenso PC2 riesce a pingare e dialogare con qualsiasi device IP presente sulla rete (sia wireless che cablata)

Il problema si verifica sia che PC2 sia agganciato a B2 che ha B3

Il problema non sembra (ma va a sapere) imputabile a R1 perche', mentre accade tutto questo, gli altri PC escono tranquillamente.

Prima che cominci a pensare a una operazione di mobbing elettronico nei confronti di PC2, qualcuno ha quache suggerimento?

Ravanando reti in cerca di.....

Cerchiamo gli host attivi su una rete:

nmap -sP 192.168.1.0/24

Ecco cosa viene visualizzato:

Starting Nmap 4.50 ( http://insecure.org ) at 2008-01-30 22:18 CET
Host 192.168.1.70 appears to be up.
Host 192.168.1.71 appears to be up.
Host 192.168.1.72 appears to be up.
Host 192.168.1.73 appears to be up.
Host 192.168.1.74 appears to be up.
Host 192.168.1.75 appears to be up.
Host 192.168.1.76 appears to be up.
Host 192.168.1.77 appears to be up.
Nmap done: 256 IP addresses (8 hosts up) scanned in 1.052 seconds

Se lo stesso comando viene lanciato con le credenziali di root:

sudo nmap -sP 192.168.1.0/24

per ogni host viene visualizzato anche il MAC address.

Per visualizzare solo la lista degli IP address attivi si puo' utilizzare il comando seguente:

nmap -sP -n 192.168.1.0/24 | grep -v "MAC Address" | cut -d\  -f2

Scacchi in rete su Ubuntu

Ci si puo' collegare al server FICS (Free Internet Chess Server), utilizzando il client eboard

sudo apt-get install eboard eboard-extras-pack1

Informazioni e settaggi delle schede di rete

Se volete qualche informazione sulla vostra scheda di rete (o se volete modificarne i parametri di configurazione) potete utilizzare il comando ethtool. Vediamolo in fase di interrogazione:

root@merlo:~# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes

Per l'utilizzo in modifica/scrittura dei parametri potete fare riferimento alla man page del comando:

man ethtool

Unire piu' interfacce di rete (bonding/teaming)

Bonding (o Teaming) = avere due interfacce di rete legate in modo da apparire come una unica interfaccia fisica. Quindi entrambe presenteranno lo stesso indirizzo hardware (MAC). Per ottenere questo con linux possiamo utilizzare il programma ifenslave.

Moduli utilizzati: bonding, mii, modulo_scheda_rete (e100 in questo esempio)
Utility utilizzate: ifenslave, mii-tool

* Autore: BJ Dierkes
* Ultimo aggiornamento: 2 Dicembre 2005
* Traduzione italiana e adattamento a Ubuntu a cura di Francesco Conti

Prima di iniziare, e' altamente raccomandata una verifica sull'integrita' e la funzionalita' delle singole schede di rete. Questo documento assume che voi l'abbiate gia' fatto. Lanciando il comando 'mii-tool' dovreste vedere qualcosa di simile:

mii-tool
eth0: negotiated 100baseTx-FD, link ok
eth1: negotiated 100baseTx-FD, link ok

Per far si' che questo funzioni, il kernel deve avere il supporto per il bonding delle periferiche. Due modi per controllare:

modprobe --list | grep -i bonding
/lib/modules/2.6.20-16-generic/kernel/drivers/net/bonding/bonding.ko

find /lib/modules/`uname -r` -iname bonding*
/lib/modules/2.6.20-16-generic/kernel/drivers/net/bonding/bonding.ko

Utilizziamo anche mii-tool e il modulo mii.o quindi controlliamo anche la sua esistenza sul nostro sistema:

find /lib/modules/`uname -r` -iname mii*
/lib/modules/2.6.20-16-generic/kernel/drivers/net/mii.ko


modprobe --list | grep -i mii
/lib/modules/2.6.20-16-generic/kernel/drivers/net/mii.ko

Installiamo il comando ifenslave:

sudo apt-get update && apt-get install ifenslave
sudo vi /etc/modprobe.d/aliases

Aggiungere o modificare le seguenti righe:

alias bond0 bonding
alias eth0 e100
alias eth1 e100


sudo vi /etc/modprobe.d/options

Aggiungere o modificare le seguenti righe:

options bonding mode=0 miimon=100

sudo vi /etc/modules

Aggiungere o modificare le seguenti righe:

bond0
eth0
eth1
bonding

Dopo aver aggiornato i file di configurazione dei moduli eseguite il seguente comando:

update-modules

vi /etc/network/interfaces

Aggiungere o modificare le seguenti righe:

auto bond0
iface bond0 inet static
address 10.1.100.63
netmask 255.255.255.0
hwaddress ether 00:02:B3:48:50:2C
gateway 10.1.100.1
up ifenslave bond0 eth0 eth1
down ifenslave -d bond0 eth0 eth1

Non avete bisogno di inserire la definizione di eth0 e eth1. D'ora in poi sara' bond0 l'interfaccia di rete utilizzata dal vostro sistema.
Eseguendo il comando 'ifconfig' verranno visualzzate le tre interfacce (bond0, eth0, eth1), tutte con lo stesso indirizzo MAC e lo stesso indirizzo IP.

E' tutto. Ora occorre caricare il modulo per il bonding e far ripartire il supporto di rete:

modprobe bonding
/etc/init.d/networking restart

Se avete problemi provate a fermare il networking e a configurare manualmente l'interfaccia bond0 con ifconfig:

ifconfig bond0 10.1.100.63 netmask 255.255.255.0 up

Supponendo di non avere errori provate a testare la configurazione. Pingate il vostro indirizzo IP da un altro computer. Entrambe le schede di rete risponderanno. Se scollegate eth0 riceverete un errore sulla console: "eth0 has failed, eth1 becoming primary" o qualcosa del genere. E vice versa se scollegate eth1. Comunque non dovreste perdere nessun pacchetto ping (o quantomeno non molti) in quanto si tratta di una connessione di rete ridondante.