Contrairement à ce que racontent des optimistes invétérés,
l'installation et la configuration du matériel sur
Linux sont souvent très pénibles. Je documente
ici mes aventures avec une carte EthernetRealtek RTL8168, pour en garder trace pour la
prochaine fois et pour que cela puisse servir à d'autres.
La carte venait installée dans un PC Compaq acheté chez
Darty. lspci la voit comme :
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 02)
J'ai
eu à deux reprises à passer du temps pour la configurer, lors de
l'installation initiale de Debian (version « etch ») et lors de la
mise à jour en Debian « lenny ».
Pour l'installation, rien ne marchait et, sans réseau, je ne pouvais donc même
pas facilement copier des fichiers, ou installer les sources du
noyau pour recompiler. Ce que j'ai fini par faire :
Mettre une vieille carte Ethernet 3com
3C905 dans l'unique fente PCI
libre.Installation Debian netinst classique.Installer de quoi compiler et les sources du noyau actuel : aptitude install build-essential linux-headers-$(uname -r).Récupérer le pilote Realtek en
(Aucune idée de sa licence, je ne trouve rien
dans la distribution.)Compilation et installation du pilote : make install.Mise à jour de la liste des modules : depmod -a.
Là, j'ai testé avec modprobe, ça a marché. dmesg affiche :
eth1394: eth0: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
eth1: Identified chip type is 'RTL8168C/8111C'.
eth1: RTL8168B/8111B at 0xf8934000, 00:1e:8c:76:29:b6, IRQ 177
Et j'ai configuré la machine ainsi pour que ce soit permanent :
Empêcher le chargement du (mauvais) module livré avec Debian en
éditant /etc/modprobe.d/blacklist pour y mettre
blacklist r8169.update-initramfs -u (Pas sûr que ce soit
vraiment nécessaire.)
Le fichier de configuration du réseau,
/etc/network/interfaces est ainsi :
allow-hotplug eth1
iface eth1 inet dhcp
# Le module qui marche
pre-up modprobe r8168
et tout est bon au redémarrage. Merci à Jacques L'helgoualc'h pour son
aide ici.
Mais il a fallu recommencer après la mise à jour en Debian
« lenny ». J'étais retourné à la carte 3com puis, voulant repasser en
Ethernet gigabit, je me suis remis à la carte
Realtek, avec exactement les mêmes réglages. Mais, entre temps, le noyau Linux avait changé et le pilote
Realtek ne compilait plus :
% make
...
CC [M] /local/src/Realtek-RTL8168C/src/r8168_n.o
/local/src/Realtek-RTL8168C/src/r8168_n.c: In function 'rtl8168_init_board':
/local/src/Realtek-RTL8168C/src/r8168_n.c:2270: error: implicit declaration of function 'SET_MODULE_OWNER'
/local/src/Realtek-RTL8168C/src/r8168_n.c: In function 'rtl8168_init_one':
/local/src/Realtek-RTL8168C/src/r8168_n.c:2570: error: 'struct net_device' has no member named 'poll'
/local/src/Realtek-RTL8168C/src/r8168_n.c:2571: error: 'struct net_device' has no member named 'weight'
...
Et le pilote livré avec Debian ? Il marchait nettement mieux en
IPv4 mais, en IPv6, le
fonctionnement était assez aléatoire : la carte met plusieurs minutes à configurer son
adresse globale (je vois bien les Router
Advertisement - - avec tcpdump mais on dirait que
la carte ne les voit pas tout de suite). Une fois l'adresse globale (et les routes) configurées, la carte
marche une heure ou deux puis la route par défaut disparait et avec
elle mes espoirs de faire de l'IPv6.
Utiliser tcpdump ou un autre logiciel de
sniffing rétablit la
situation. On a donc un cas classique
d'Heisenbug où observer la bogue la fait
disparaître. La raison est probablement que tcpdump met l'interface
réseau en mode indiscret (promiscuous), ce qui fait
qu'elle reçoit alors tous les paquets
multicast de la RA
IPv6. Un contournement posssible serait donc de forcer le passage en
mode indiscret avec ip link set eth0 promisc on. (Merci à Kim Minh Kaplan pour sa suggestion ici.)
Donc, la solution, trouvée sur
a été de télécharger un patch
du pilote, de l'appliquer avec cd src; patch -p1 <
../r8168-8.005.00.hardy.diff.txt et de recompiler le
pilote. (Le patch est pour la
version 005 du pilote RealTtek, version que j'avais gardée des
manipulations précédentes, pas la toute dernière qui est la 011
mais je suppose que l'adaptation n'est pas trop difficile.) Avec certaines versions
du noyau, les Makefile ne sont pas corrects et il faut faire un lien symbolique
depuis /src (!) vers le répertoire de compilation avec
ln -s $(pwd)/src /src.
Après cela, tout semble marcher. dmesg affiche :
[ 9.028941] eth0: Identified chip type is 'RTL8168C/8111C'.
[ 9.028941] eth0: RTL8168B/8111B at 0xf897e000, 00:1e:8c:76:29:b6, IRQ 18
et IPv4 et IPv6 marchent.
Remerciements à Goldy, cette fois. (Kim Minh Kaplan signale que le
noyau Linux 2.6.28 est une autre solution, il sembel résoudre le problème.)