Connexion reseau impossible

Bonjour tout le monde
je suis un nouveau sous debian, je viens de fedora et je voulais voir un peu ce qui ce passe sous debian.
j’ai donc telecharger debian 5 lenny.
le probleme est le suivant: apres l’installation j’ai tente un apt-get update apres avoir biensure ajouter quelques lignes au fichier /etc/apt/source…
j’ai remarque qu’il n’y avait pas de connections aux serveurs. alors j’ai pinger le router et j’aivais donc host unreachable.
reconfiguratin en manuelle de /etc/network/interfaces j’ai donc ceci:
allow-hotplug eth0 auto eth0 iface eth0 inet static address 192.168.1.99 gateway 192.168.1.1 netmask 255.255.255.0
redemare le reseaux ifconfig me donne donc les meme infos en plus de Bcast 192.168.1.255
je ping 192.168.1.1 toujours unreachable.
je ping depuis d’autre machine, une fedora 11 et une windows XP ca marche donc le probleme n’est pas au niveau du routeur. mieux les machines XP et Fedora se ping entre elle Ok mais ne trouve pas la debian.
la command /sbin/route -n donne:192.168.1.0 0.0.0.0 255.255.255.0 u 0 0 0 eth0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
un ping sur debian elle meme donne une reponse ping 192.168.1.99 depuis la dite machine. j’ai verifier le cable il marche la machine est en dualboot sur fedora 10 donc la carte reseaux marche aussi.
j’ai googlelise en la je suis a cours de ressource donc je viens vous voire histoire d’avoir une reponse pour que je puisse utiliser ma debian.
Merci a vous

ps: installation minimal, donc que du mode teste

Qu’est ce que c’est comme carte réseau ?
Si tu as un serveur DHCP sur ton réseau, essaye de passer en adressage dynamique.

En général “host unreachable” = pas de réponse aux requêtes ARP. Causes possibles (liste non limitative) :

  • problème de liaison ethernet (a priori non si ça marche avec Fedora)
  • mauvaise configuration IP (a priori non si ça marche avec Fedora avec la même config)
  • problème de pilote ethernet
  • pas la bonne interface (pour les système ayant plusieurs interfaces “ethernet” - attention, une interface firewire peut être vue comme une pseudo-interface ethernet)
  • filtrage des paquets ARP avec arptables, mais c’est du vice

Qu’affichent

dmesg | grep -i eth
ifconfig -a

Les voyants d’activité sur le switch (ou le routeur) et l’interface clignotent quand tu fais un ping ?

alors le materiel c’est : Silicon Integrated Systems [SIS] 191 Gigabit Ethernet Adpter.
j’essayerai avec le wifi voir si ca marche. pour le resultat de la command dmeg je suis pas devant la machine, je donnerai plus tard

bon voici le resultat de dmesg:

[ 3.666269] Driver 'sd' needs updating - please use bus_type methods [ 3.666269] sda:<4>Driver 'sr' needs updating - please use bus_type methods [ 7.113751] sis190 Gigabit Ethernet driver 1.2 loaded. [ 7.706068] 0000:00:04.0: SiS 191 PCI Gigabit Ethernet adapter at ffffc20000648c00 (IRQ: 19), 00:23:54:f2:52:ed [ 7.706070] eth0: RGMII mode. [ 7.706076] eth0: Enabling Auto-negotiation. [ 316.448992] eth0: mii ext = 0000. [ 316.464991] eth0: mii lpa = 45e1 adv = 01e1. [ 316.464998] eth0: link on 100 Mbps Full Duplex mode. [ 316.884991] eth0: mii ext = 0000. [ 316.900988] eth0: mii lpa = 45e1 adv = 01e1. [ 316.900994] eth0: link on 100 Mbps Full Duplex mode.

ifconfig -a[code]eth0 Link encap:Ethernet HWaddr 00:23:54:f2:52:ed
inet adr:192.168.1.145 Bcast:192.168.1.255 Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:157 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:14302 (13.9 KiB) TX bytes:252 (252.0 B)
Interruption:19 Adresse de base:0xdead

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:5 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:560 (560.0 B) TX bytes:560 (560.0 B)

wlan0 Link encap:Ethernet HWaddr 00:22:43:07:da:3e
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

wmaster0 Link encap:UNSPEC HWaddr 00-22-43-07-DA-3E-00-00-00-00-00-00-00-00-00-00
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
[/code]

eth0 est bien l’interface ethernet (et la seule), je ne vois aucune erreur la concernant, les flags sont corrects et ifconfig rapporte des paquets émis et reçus. Ça vaudrait le coup de lancer une capture de paquets sur eth0 pour voir quel genre de trafic est reçu. Je reconnais que ça ne va pas être évident sans réseau si tcpdump ou wireshark ne se trouvent pas sur ton support d’installation.

Je remarque que l’OUI de l’adresse MAC appartient à Asus. C’est un portable ou une carte mère de PC normal ? Il a été rapporté un problème avec la carte mère Asus P5SD2-VM qui utilise un PHY (interface physique du contrôleur ethernet) Atheros AR8021 non reconnu par les versions du noyau antérieures à 2.6.27.20. Mais apparemment dans ton cas l’auto-négociation fonctionne et il y a du trafic, donc je doute que ce soit ça. Tu peux néanmoins vérifier avec

Tu peux aussi lancer une capture de paquets sur un autre poste pendant que tu fais un ping depuis celui-ci pour voir ce qu’il émet.

EDIT Il y a quand même un étrangeté : l’adresse IP rapportée par ifconfig est différente de celle spécifiée dans le fichier interfaces. Il y a une raison ?

Bjr,
A essayer.
Existe-t-il un /etc/resolv.conf ? Sinon inscrire dedansnameserver 192.168.1.1

salut
pour les incoerences au niveau des adresse IP c’est normal j’ai changer l’IP de peur qu’une autre machine l’utilise (j’ai l’habitude de taper .99 comme adresse) pour le reste je teste et je vous tiens au courant sinon capture reseaux ca sera forcement avec une autre machine. car la j’ai vraiment systeme debian de base meme pas less, locate … bref j’ai debien ecran noire et rien d’autre.
le cd fait apeine 100MO et poussiere je pense pas qu’il y ai grand chose dessus.

Sinon tu peux télécharger manuellement le paquet tcpdump et les dépendances nécessaires (a priori libssl0.9.8 devrait déjà être installé ou disponible sur le CD-ROM, donc il ne manque que libpcap0.8 ) pour ton architecture depuis un autre système et les installer avec dpkg -i.
<http://packages.debian.org/lenny/tcpdump>
puis

desole une semaine d’absence. je demenagais donc pas le net.
entre temps j’ai telecharger les autres dvd lenny amd64 et j’ai ajoute gnome et wireshark. bon voici la situation:
je suis repasse en DHCP
un cat /etc/resolvf.cong me montre 3 adresses de nameserver dont celle ajouter manuellement 192.168.1.1
ce qui signifi donc que le router a transmit les autres.
Mieux depuis une autre machine je me suis connecte au router, dans la section DHCP j’ai deux machines connecte et je vois bien l’adresse mac de la carte reseau du laptop. donc visiblement connecte au router. cependant aucun ping ne passe ni depuis le laptop ni depuis l’autre machine fedora vers le laptop. le router ne bloque pas le ping car la machine fedora ping bien le router.
j’ai l’impression qu’il y a quelque chose qui m’empeche de communiquer avec le router mais pas de me connecter a celui-ci.

sinon voici ceque TCPDUMP donne(j’ai fait un ping vers le routeur):05:16:45.947070 aa:4d:8c:f2:4b:2a (oui Unknown) > 38:b1:e2:e7:21:2d (oui Unknown), ethertype Unknown (0x0aa7), length 143: 0x0000: 800d 8ef6 f8d1 9883 f152 8cd3 0c89 cc0a .........R...... 0x0010: bc30 debb 6999 0813 39b5 595f 5fcc b84d .0..i...9.Y__..M 0x0020: 8b28 0aa2 7d4b cadf e49f f2e6 da61 6c54 .(..}K.......alT 0x0030: 5bb6 ca75 bdb1 5393 1927 22ba 1659 11e6 [..u..S..'"..Y.. 0x0040: 5831 3d6e b924 4b80 d6b4 28f2 4691 3dd9 X1=n.$K...(.F.=. 0x0050: a2a7 .. 05:16:46.006668 4b:03:04:14:00:08 (oui Unknown) Unknown SSAP 0x12 > 00:dc:11:00:00:50 (oui Unknown) Null Supervisory, Receiver Ready, rcv seq 29, Flags [Final], length 46 05:17:45.945228 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 129 05:18:24.991912 arp who-has 192.168.1.1 tell kakashi10.local 05:18:24.992388 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46 05:18:25.987916 arp who-has 192.168.1.1 tell kakashi10.local 05:18:25.988491 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46 05:18:26.987913 arp who-has 192.168.1.1 tell kakashi10.local 05:18:26.988447 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46 05:18:28.008917 arp who-has 192.168.1.1 tell kakashi10.local 05:18:28.009436 IP truncated-ip - 530 bytes missing! (tos 0x0, ttl 32, id 40520, offset 0, flags [DF], proto UDP (17), length 576) 192.168.1.1.bootps > kakashi10.local.bootpc: BOOTP/DHCP, Reply, length 548, xid 0x8063b44, Flags [none] [|bootp] 05:18:29.008912 arp who-has 192.168.1.1 tell kakashi10.local 05:18:29.009422 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46 05:18:30.008921 arp who-has 192.168.1.1 tell kakashi10.local 05:18:30.009416 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46 05:18:32.012921 arp who-has 192.168.1.1 tell kakashi10.local 05:18:32.013406 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46 05:18:33.012920 arp who-has 192.168.1.1 tell kakashi10.local 05:18:33.013418 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46 05:18:34.012921 arp who-has 192.168.1.1 tell kakashi10.local 05:18:34.013443 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46 05:18:36.016921 arp who-has 192.168.1.1 tell kakashi10.local 05:18:36.017443 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46 05:18:37.016919 arp who-has 192.168.1.1 tell kakashi10.local 05:18:37.017427 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46 05:18:38.016920 arp who-has 192.168.1.1 tell kakashi10.local 05:18:38.017417 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46 05:18:40.020921 arp who-has 192.168.1.1 tell kakashi10.local 05:18:40.021446 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46 05:18:41.020920 arp who-has 192.168.1.1 tell kakashi10.local 05:18:41.021443 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46 05:18:42.020922 arp who-has 192.168.1.1 tell kakashi10.local 05:18:42.021617 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46 05:18:44.008921 arp who-has 192.168.1.1 tell kakashi10.local 05:18:44.009425 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46 05:18:45.007917 arp who-has 192.168.1.1 tell kakashi10.local 05:18:45.008420 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46 05:18:45.943349 75:61:6c:69:74:79 (oui Unknown) > 49:6d:61:67:65:51 (oui Unknown), ethertype Unknown (0x5061), length 143: 0x0000: 6765 0046 696e 6973 6869 6e67 5061 6765 ge.FinishingPage 0x0010: 0043 6f6c 6f72 5061 6765 0047 746b 5072 .ColorPage.GtkPr 0x0020: 696e 7444 6961 6c6f 6745 7874 656e 7369 intDialogExtensi 0x0030: 6f6e 0067 746b 2d00 4774 6b50 7269 6e74 on.gtk-.GtkPrint 0x0040: 556e 6978 4469 616c 6f67 0054 6865 2047 UnixDialog.The.G 0x0050: 746b tk 05:18:46.008923 arp who-has 192.168.1.1 tell kakashi10.local 05:18:46.009401 63:61:74:69:6f:6e (oui Unknown) > 73:65:74:5f:6c:6f (oui Unknown) Null Supervisory, Reject, rcv seq 32, Flags [Poll], length 46 05:18:47.012916 arp who-has 192.168.1.1 tell kakashi10.local 05:18:47.013617 61:6d:65:00:00:00 (oui Unknown) > 5f:66:69:6c:65:6e (oui Unknown) Null Information, send seq 56, rcv seq 57, Flags [Command], length 46 05:18:48.012921 arp who-has 192.168.1.1 tell kakashi10.local 05:18:48.013417 4e:55:4c:4c:00:00 (oui Unknown) > 65:29:20:21:3d:20 (oui Unknown) Null Unnumbered, 2f, Flags [Command], length 46 05:18:49.012922 arp who-has 192.168.1.1 tell kakashi10.local 05:18:49.013425 00:ff:00:00:00:ff (oui Unknown) > ff:ff:ff:ff:00:00 (oui Unknown), ethertype Unknown (0xffff), length 60: 0x0000: ffff 0000 0000 0000 0000 0000 0000 0000 ................ 0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. 05:18:50.024916 arp who-has 192.168.1.1 tell kakashi10.local 05:18:50.025400 00:00:ff:ff:ff:ff (oui Unknown) OSI > 00:00:00:00:00:00 (oui Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Response], length 46 05:18:51.024925 arp who-has 192.168.1.1 tell kakashi10.local 05:18:51.025414 6e:6c:2f:68:6f:6f (oui Unknown) > 2e:6f:73:67:69:2e (oui Unknown), ethertype Unknown (0x6b63), length 60: 0x0000: 6f6e 6669 6775 7261 746f 7273 5f7a 685f onfigurators_zh_ 0x0010: 5457 2e70 726f 7065 7274 6965 7350 4b01 TW.propertiesPK. 0x0020: 0214 0014 0008 0008 00fa 203b 3583 ...........;5. 05:18:52.024920 arp who-has 192.168.1.1 tell kakashi10.local 05:18:52.025391 cd:85:9b:0a:b5:08 (oui Unknown) > 92:21:a4:34:b5:15 (oui Unknown), ethertype Unknown (0xe458), length 60: 0x0000: 680f 0847 1196 91d0 09d6 e2ac 09f1 1672 h..G...........r 0x0010: 8328 b26a 0ff3 3580 9fdc f868 cf9a 255e .(.j..5....h..%^ 0x0020: 5952 1361 37ce 0af4 8aa5 faf3 60f2 YR.a7.......`. 05:18:53.036917 arp who-has 192.168.1.1 tell kakashi10.local 05:18:53.037455 6b:5f:77:69:6e:64 (oui Unknown) > 49:41:5f:5f:67:74 (oui Unknown), ethertype Unknown (0x6f77), length 60: 0x0000: 5f61 6464 5f6d 6e65 6d6f 6e69 6300 0000 _add_mnemonic... 0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0020: 0000 4941 5f5f 6774 6b5f 7769 6e64 ..IA__gtk_wind 05:18:53.116011 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 70) kakashi10.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 1.1.168.192.in-addr.arpa. (42)

bonjour, t’a pas jouer avec le pare feu ?
car hier j’ai un peu joue avec j’ai installe firestarter gaurddog ufw + le tuto du site comme ça et desinstaller celui qui me plaisait pas , ben je me suis retrouver avec un ping vers mon modem ok bonne ip tout connexion impossible . j’ai ete oblige de tout desinstaller avec un apt-get -purge et ensuite reinstaller firstarter et la ça a remarcher .
a+

On voit les requêtes ARP émises mais le contenu des paquets reçus est totalement aberrant… Si ce n’est pas un bug de lecture avec tcpdump (ça peut arriver), alors ça peut expliquer pourquoi rien ne répond. Mais dans ce cas je me demande comment DHCP marche.

Je pense que j’ai trouvé. C’est un bug de DMA du pilote sis190 qui affecte les petits paquets et qui semble toucher particulièrement l’architecture amd64. Ça colle avec les symptômes. Quelqu’un a rapporté que le bug était apparu sur sa machine après le passage de 2 à 4 Gio de RAM. Un patch est intégré dans la prochaine version 2.6.31 du noyau (et peut-être backporté dans une version 2.6.30 du noyau Debian sid).
Un bug Debian a été ouvert : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541169
La Fedora 10 en dual boot est en i386 ou amd64 ?

Si tu te sens de recompiler le module, le patch est trivial.
Sinon, pourrais-tu faire le test suivant ?

  1. Désactiver l’interface (ifdown eth0)
  2. Décharger le module (modprobe -r sis190)
  3. Charger le pilote avec l’option rx_copybreak=14 (modprobe sis190 rx_copybreak=14)
  4. Redémarrer l’interface (ifup eth0) et tester.

la premiere etape me donne deja une erreur

pourtant ifconfig me montre une interface configure.
et voici pour ifup eth0:

j’ai aucune idee sur ce qui ce passe.

ce n’est pas un bug de tcpdump car wireshark (qui au passage me permet de selectionner mes interfaces reseaux qu’en root) donne des resultats de type PACKETS MALFORME.

la machine a bien 4go de ram et en amd64.

je pense que le probleme ne vient pas de l’interface c’est surment comme tu dis PascalHambourg un bug de DMA ou autre car j’ai pas fait de capture des packets envoyes par le wifi mais je constate que je suis connecte au router que quand je configure /etc/network/interfaces a la main, en effet ma machine ne detect aucun reseau a proximite.

eth0 est bien définie dans /etc/network/interfaces ? Sinon comment a-t-elle été configurée ?
De toute façon tu peux la désactiver directement avec “ifconfig eth0 down”.

tcpdump et wireshark utilisent tous les deux la même bibliothèque de capture de paquets libpcap, donc la méthode de capture des paquets aurait pu être en cause.

Si tu pouvais tester aussi en enlevant 2 Gio de RAM, ça serait intéressant pour confirmer ou infirmer le rapport que j’ai lu.

[quote=“PascalHambourg”]
Si tu pouvais tester aussi en enlevant 2 Gio de RAM, ça serait intéressant pour confirmer ou infirmer le rapport que j’ai lu.[/quote]

en plein dans le mille, j’ai le reseau, apres avoir eleve une rame de 2Go. donc le rapport est confirme dans mon cas. il y a t’il un moyen d’avoir 4Go de ram et avoir le reseau?

Oui :

  • réinstaller Debian en i386 au lieu d’amd64 car il semble que le bug se manifeste plutôt en amd64 même si en théorie il pourrait affecter toutes les architectures (je conçois que ce ne soit pas forcément acceptable pour toi mais je me devais de le proposer pour être complet)
  • patcher et recompiler le module sis190
  • attendre qu’un noyau intégrant le correctif soit disponible et l’installer (faudra être patient).

Ça m’intéresserait vraiment si tu pouvais faire le petit test que j’ai décrit. si ifup et ifdown ne marchent pas, tu peux utiliser ifconfig à la place pour gérer l’interface directement.

  • reinstaller debian en 386 c’est hors de question
  • patcher et recompiler le noyau c’est ce que je compte faire mais je sais pas comment t’as un lien ou un tuto quelque part?

pour ton test je m’y mets tout de suite histoire de te faire plaisir.

tu es comme un Dieu pour moi aujourd’hui, ca marche avec mes 4go de ram. donc la reponse a ton test est OPERATION SUCCESSFULL.
cependant aulieu d’ouvrir un autre post je me permet de continuer avec le deuxieme point:
le wifi ne scan rien. je dois configurer /etc/network/interface a la main. j’ai envie d’utiliser networkmanager mais lui ne vois que le cable.

Pour le wifi et network-manager il faudra trouver quelqu’un d’autre parce qu’avec moi ça fait trois. Je n’ai jamais eu de wifi donc je n’ai jamais pu bricoler avec, et je n’utilise pas network-manager, rien que le bon vieux fichier interfaces. Je pense qu’il vaudrait mieux ouvrir un autre fil ou chercher dans les archives du forum (ou d’ailleurs).

Concernant la manipulation que je t’ai fait faire, content qu’elle marche. J’en ai eu l’idée en regardant le code source du module à l’endroit du patch. En gros il se passe un truc différent (ne me demandez pas quoi) selon que la taille du paquet reçu est inférieure ou supérieure à la valeur de ce paramètre. Comme la valeur par défaut est 200 et qu’il est dit que le bug affecte les petits paquets, j’ai supposé que diminuer cette valeur pour qu’elle soit inférieure à la taille du plus petit paquet possible pouvait aider.

Si elle ne provoque pas d’effets secondaires tu peux la rendre permanente en ajoutant une ligne d’option dans un fichier placé dans le répertoire /etc/modprobe.d/ :

Pour la solution de recompiler, c’est un peu plus délicat si tu n’as jamais compilé un noyau ou un module additionnel. Il y a des guides un peu partout. Le souci, c’est que je n’ai aucune installation de lenny sous la main pour tester la procédure.