web-dev-qa-db-fra.com

lan ne fonctionne pas après le redémarrage

J'ai installé Ubuntu 14.04 sur mon nouveau portable et j'ai un problème de connectivité Internet. Lorsque je démarre l'ordinateur, tout fonctionne parfaitement, mais après avoir redémarré à l'aide du bouton situé dans le coin supérieur droit (après une mise à jour du noyau, par exemple), la connexion Internet par câble ne fonctionne plus. Il n'y a pas de problème avec le sans fil, cependant (cependant, j'utilise principalement le réseau local). Cela ne peut pas être un problème matériel, car cela fonctionne sous Windows (c'est une machine à double démarrage). Mystérieusement, tout fonctionne parfaitement si je branche simplement le portable avant de redémarrer - même si je redémarre sur batterie (-> cassé) puis une fois de plus sur AC (- corrigé à nouveau).

J'ai fait d'autres tests: rien ne change si je coupe la connexion (physiquement, dans le gestionnaire de réseau ou les deux) avant de redémarrer. Sudo service networking restart n'a également aucun effet sur la sortie

stop: Job failed while stopping 
start: Job is already running: networking

Cependant, Sudo service network-manager restart interrompt la connexion de la même manière qu’un redémarrage, ce qui m’oblige à éteindre l’ordinateur, puis à effectuer un redémarrage à froid pour le rendre opérationnel à nouveau, mais uniquement lorsque le portable fonctionne sur batterie.

J'étais en train de penser_

Quelle pourrait être la cause de ce comportement?

Autres sorties de commande:

lspci -knn | grep Eth -A2:

05:00.1 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 12)
Subsystem: ASUSTeK Computer Inc. Device [1043:200f]
Kernel driver in use: r8169

sur LAN (travaillant ou pas) ainsi que sur le sans fil (à prévoir, je voulais juste m'assurer).

ifconfig:

eth0      Link encap:Ethernet  HWaddr 08:62:66:b5:0f:78  
      inet addr:192.168.1.112  Bcast:192.168.1.255  Mask:255.255.255.0
      inet6 addr: fe80::a62:66ff:feb5:f78/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:9907 errors:0 dropped:0 overruns:0 frame:0
      TX packets:6660 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:9730805 (9.7 MB)  TX bytes:726284 (726.2 KB)

lo        Link encap:Local Loopback  
      inet addr:127.0.0.1  Mask:255.0.0.0
      inet6 addr: ::1/128 Scope:Host
      UP LOOPBACK RUNNING  MTU:65536  Metric:1
      RX packets:2391 errors:0 dropped:0 overruns:0 frame:0
      TX packets:2391 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:0 
      RX bytes:228361 (228.3 KB)  TX bytes:228361 (228.3 KB)
14.04networkinglanwired
3
haemi

J'ai résolu le problème: en raison de l'état de la batterie/secteur, j'ai examiné les paramètres d'économie d'énergie dans powertop et j'ai constaté que le branchement de l'ordinateur portable inversait le réglage de réveil sur réseau.

Quoi qu'il en soit, par essais et erreurs, j'ai découvert que le réseau local fonctionnait après le redémarrage et le Sudo service network-manager restart si le réveil sur réseau local était activé (je ne sais pas pourquoi, depuis que j'ai eu la chance de trébucher dessus). - Je serais heureux si quelqu'un pouvait offrir un aperçu). Par conséquent, ma solution a été d'ajouter

sleep 1
Sudo ethtool -s eth0 wol g

to rc.local (la valeur de la mise en veille peut dépendre de la machine. J'ai remplacé le disque dur fourni avec l'ordinateur par un disque SSD. Il peut donc être plus élevé pour les autres machines. L'astuce, c'est que la commande être exécuté après les interfaces réseau ont été configurées). De cette façon, wol est toujours activé, quel que soit l'état d'alimentation - à une exception près: si vous démarrez l'ordinateur en courant alternatif et que vous débranchez la prise quelque temps plus tard, l'état hors tension est rétabli. Normalement, cela ne devrait pas poser trop de problème car vous devez redémarrer le gestionnaire de réseau via la ligne de commande pour le remarquer - et si cela est vraiment nécessaire, un redémarrage peut également être une bonne idée. Néanmoins, ce comportement peut également être corrigé en ajoutant un petit script à /etc/pm/power.d/ (semblable à celui de la première réponse à cette question ): dans la branche en mode batterie, vous mettez

Sudo ethtool -s eth0 wol g

et la branche en mode alternatif reste vide.

2
haemi