Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

Utilisation de carte Ethernet Realtek 8168 sur Debian

Première rédaction de cet article le 23 mars 2009
Dernière mise à jour le 3 avril 2009


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 Ethernet Realtek 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 :

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 AdvertisementRFC 4862 - 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 https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.24/+bug/141343/comments/21 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.)

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)