Correction du renouvellement IP après la suspension d'un ordinateur portable
J'ai un Macbook Pro 5.5 exécutant Ubuntu 10.04, et j'ai remarqué qu'avec certains réseaux wifi, mais pas tous, je ne peux pas me reconnecter après être sorti de la suspension. J'ai essayé à la fois les démons de gestion Network Manager et Wicd, et les deux passent par la validation, mais je raccroche sur "Acquérir l'adresse IP ...". La seule solution que j'ai trouvée est de redémarrer la machine, après quoi elle acquiert une adresse IP très rapidement.
Quel est le problème sous-jacent ici? Quelle serait une manière plus efficace de résoudre le problème?
EDIT: J'ai remarqué que si j'ouvre Wicd et appuie manuellement sur "Connect", il ne parvient pas à acquérir une IP. Cependant, si je ne fais rien et que je le laisse essayer automatiquement de se connecter, il acquiert une IP et se connecte très bien ...
EDIT: Remarque, ce problème dépend du routeur sans fil auquel j'essaie de me connecter. Je n'ai aucun problème avec un routeur wifi Linksys de base ou le routeur sans fil simulé par une application de connexion sans fil Android sans fil. Cependant, le vieux Cisco/Comcast/Verizon merdique les routeurs sans fil home semblent toujours me donner des maux de tête avec la connexion uniquement après la suspension. Si je redémarre, je peux me connecter pour eux immédiatement.
EDIT: J'ai essayé d'ajuster le paramètre du client DHCP dans Wicd.
À l'origine, il utilisait dhclient, et une tentative de connexion échouée créerait un journal comme:
2011/07/28 20:55:35 :: Listening on LPF/eth2/00:26:bb:1b:90:cc
2011/07/28 20:55:35 :: Sending on LPF/eth2/00:26:bb:1b:90:cc
2011/07/28 20:55:35 :: Sending on Socket/fallback
2011/07/28 20:55:35 :: DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 5
2011/07/28 20:55:40 :: DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 10
2011/07/28 20:55:50 :: DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 11
2011/07/28 20:56:01 :: DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 18
2011/07/28 20:56:19 :: DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 17
2011/07/28 20:56:36 :: No DHCPOFFERS received.
2011/07/28 20:56:36 :: No working leases in persistent database - sleeping.
2011/07/28 20:56:45 :: DHCP connection failed
2011/07/28 20:56:45 :: exiting connection thread
2011/07/28 20:56:45 :: Sending connection attempt result dhcp_failed
2011/07/28 20:56:45 :: attempting to set hostname with dhclient
2011/07/28 20:56:45 :: using dhcpcd or another supported client may work better
2011/07/28 20:56:45 :: attempting to set hostname with dhclient
2011/07/28 20:56:45 :: using dhcpcd or another supported client may work better
Notant la recommandation d'essayer dhcpcd à la place, j'ai installé, redémarré le service wicd et l'ai configuré pour utiliser dhcpcd. Malheureusement, le problème persiste, avec un journal encore moins utile:
2011/08/01 19:44:56 :: Connecting to wireless network CrappyCiscoRouter
2011/08/01 19:44:56 :: Putting interface down
2011/08/01 19:44:56 :: Releasing DHCP leases...
2011/08/01 19:44:56 :: Setting false IP...
2011/08/01 19:44:56 :: Stopping wpa_supplicant
2011/08/01 19:44:56 :: Flushing the routing table...
2011/08/01 19:44:56 :: Putting interface up...
2011/08/01 19:44:58 :: Attempting to authenticate...
2011/08/01 19:45:02 :: Running DHCP with hostname localhost
2011/08/01 19:45:22 :: err, eth2: timed out
2011/08/01 19:45:22 ::
2011/08/01 19:45:22 :: DHCP connection failed
2011/08/01 19:45:22 :: exiting connection thread
2011/08/01 19:45:22 :: Sending connection attempt result dhcp_failed
EDIT: Je suis convaincu à 99% qu'il s'agit d'une sorte de bogue avec le pilote Broadcom STA propriétaire et comment il gère la gestion de l'alimentation (c'est-à-dire la suspension), car le redémarrage de tout mon système le corrige, et je n'ai jamais rencontré le problème sur les appareils Linux avec des pilotes sans fil non Broadcom. Ce qui est frustrant ... car cela ne me laisse pas beaucoup de recours car je ne trouve aucune alternative open source au pilote merdique de Broadcom.
Si vous courez
Sudo dhclient -r
Sudo dhclient
obtenez-vous une nouvelle adresse IP? Cela abandonnera votre bail actuel et tentera d'en acquérir un nouveau.
Vous pourriez également être en mesure de redémarrer la mise en réseau, plutôt que votre machine entière:
Sudo /etc/init.d/networking restart
J'ai eu un problème similaire que je pense avoir finalement résolu. J'ai fait plusieurs choses pour essayer de résoudre le problème, mais je pense que je l'ai finalement compris.
J'ai désinstallé puis réinstallé Network Manager. J'ai pu me connecter sans cela, mais je ne me suis pas vraiment soucié des alternatives ou de l'utilisation de la ligne de commande. J'ai également, sans me souvenir totalement de la raison de cela, supprimé eth0 en tant que connexion réseau filaire (pensez que je l'ai supprimé via Network Manager). L'un ou l'autre semblait faire l'affaire, pas grand-chose d'autre n'avait changé.
Cela a fonctionné pour moi, pour mon LAN:
Sudo dhclient -r
Sudo dhclient eth0
Cela devrait fonctionner pour le Wifi:
Sudo dhclient -r
Sudo dhclient wlan0
Jetez un œil à cette solution Reconnexion sans fil lente après la suspension