Perte connexion internet suite à une mise à jour

Support Debian
#1

Rebonjour!

Après une mise à jour hier soir, du noyau 2.6.17 au noyau 2.6.18, tout semblait marcher comme avec l’ancien noyau 2.6.17. Hormis un point important : la connexion internet.
J’ai donc essayé la commande
Code:
ifconfig eth0 up
et là j’ai pu avoir une adresse IP. Dès que j’ai redémarré, évidemment, j’ai perdu le réseau.
J’ai donc mis cette commande dans le fichier /etc/rc.local et j’avais à nouveau une connexion internet à chaque redémarrage.
Au premier boot de ce matin, j’ai perdu la connexion internet. Bizarre Question
Ma connexion fonctionne bien avec le noyau 2.6.17 mais plus du tout avec le noyau 2.6.18.

Une idée ? Merci!
P.S.: Je vous collerais ce soir le contenu de mon fichier interfaces.

#2

quote="hsmr"
P.S.: Je vous collerais ce soir le contenu de mon fichier interfaces.[/quote]Ainsi que des éléments de /var/log/messages ou de dmesg, pour voir les messages d’erreur, parceque sans ça, pas grand chose à réflechir :wink:

#3
  • /etc/network/interfaces[code]# This file describes the network interfaces available on your system

and how to activate them. For more information, see interfaces(5).

The loopback network interface

auto lo
iface lo inet loopback

The primary network interface

allow-hotplug eth0
iface eth0 inet dhcp[/code]

  • DMESG# dmesg | grep eth0 eth0: RealTek RTL8139 at 0xffffc2000005a400, 00:dd:10:00:f6:d1, IRQ 233 eth0: Identified 8139 chip type 'RTL-8100B/8139D' eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 eth0: no IPv6 routers present

  • /var/log/messages

# more /var/log/messages | grep eth0 Feb 6 10:45:42 localhost kernel: eth0: RTL8168b/8111b at 0xffffc2000001c000, 00:13:8f:e4:a7:9d, IRQ 177 Feb 6 10:45:42 localhost kernel: r8169: eth0: link down Feb 6 10:45:45 localhost kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready Feb 6 11:29:58 localhost kernel: eth0: RealTek RTL8139 at 0xffffc2000005a400, 00:dd:10:00:f6:d1, IRQ 233 Feb 6 11:29:58 localhost kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E

#4

mets eth0 en auto au lieu de allow-hotplug. Ca va faire la même chose que ce que tu as mis dans rc.local, mais en plus propre.
Ceci etant, si ta carte est vraiment une carte “enfichable” (pcmcia ou usb), ça va bien être actif au boot, mais tu perds la fonctionnalité d’hotplug.

C’est quoi comme carte ?

#5

C’est une carte Realtek RTL-8139/8139C/8139C+

#6

Ca marche!
Edit : ça marchait…

J’ai remplacé dans /etc/network/interfaces allow-hotplug par auto.
Au premier boot, cela n’avait pas été pris en compte. Au second, tout était nickel…

Et maintenant (suite à une mise à jour du BIOS pour resoudre un autre pb), plus rien ne marche avec le nouveau noyau 2.6.18-4-amd64.
Pas de réseau. Voici ce que je note dans /var/log/message23:10:19 localhost kernel: eth0: RTL8168b/8111b at 0xffffc20000036000, 00:13:8f:e4:a7:9d, IRQ 177 Feb 6 23:10:19 localhost kernel: r8169: eth0: link down Feb 6 23:10:23 localhost kernel: ADDRCONF(NETDEV_UP): eth0: link is not readyJe suis toujours à la recherche d’une solution viable et permanente. Merci

P.S.: La connexion marche avec le noyau 2.6.18-3.

#7

au cas ou tu ne l’aurais pas remarqué, tes erreurs indiquent qu’elles se passent sur la carte r8169 (un pilote qui n’a rien à voir avec la 8139 que tu dis avoir).
il semblerait donc qu’il n’utilise pas le bon pilote (mais il faut être sûr de toi quand tu dis que c’est une 8139).
Commences par faire un update-pciids, et rebootes.
Si ca va pas, essayes un truc: dans /etc/modprobe.d/blacklist, tu mets une ligne ‘blacklist r8169’, et dans /etc/modules, tu ajoutes une ligne ‘8139cp’, puis tu rebootes.
Si ça ne marche toujours pas, donnes ici le resultat de lspci -n.

#8

Salut mattop!
Ton intervention m’a mise la puce à l’oreille.
En regardant de près, j’ai trouvé l’erreur.
Je dispose en effet de plusieurs interfaces réseaux et à ma grande surprise, avec le noyau 2.6.17 le pilote r8139 est attaché à l’interface eth0 (celle où le cable est branché) alors qu’avec un noyau > 2.6.17, eth0 utilise un autre pilote (8169 de ma 2e carte réseau), d’où les messages d’erreurs et la perte de connexion.
Bizarre tout de meme cette prise en compte de l’interface en fonction du noyau.
Je crois donc avoir résolu le pb.
Je ferais encore un test ce soir avant de marquer le post comme [RESOLU]. Merci.

#9

non, c’est pas bizarre, c’est juste que les cartes sont par défaut numérotées dans l’ordre ou elles sont détectées, et que les noyaux ne les détectent pas forcément dans le même ordre.
Il y a moyen néanmoins de les fixer en utilisant le fichier /etc/udev/rules.d/z25_persistent-net.rules. personnellement, en modifiant ce fichier z25_persistent-net.rules, dans /etc/network/interfaces, ma 3com ne s’appelle pas eth0 mais 3COM, et ma realtek s’appelle 8139, Comme ça je suis sûr de m’y retrouver.