La connexion Internet ne fonctionne pas bien qu'il soit dit qu'il est connecté
J'ai un Toshiba Z830 avec Ubuntu 12.04. Je pourrais utiliser sans problèmes la connexion DSL (je n’ai pas de routeur, seulement un modem) à la maison jusqu’à il y a quelques jours:
Il a cessé de fonctionner lorsque, connecté à la connexion DSL via CiscoVPN (sur mon lieu de travail), j'ai dû laisser l'ordinateur portable sans surveillance pendant un moment et je suppose que l'ordinateur portable a essayé de suspendre. À mon retour, il y avait beaucoup de messages sur un écran noir (désolé, je ne peux pas joindre une image à cause de ma mauvaise réputation) et l'ordinateur portable ne répondait pas. Je devais le réinitialiser.
Après le redémarrage, la connexion Internet ne fonctionnait plus comme avant (pas de navigation, pas de ssh, pas de skype, etc.) bien qu’elle indique qu’elle est connectée. Je ne peux que naviguer, etc. lorsque je me connecte à CiscoVPN au même endroit que celui où j'étais connecté au moment de la panne.
Lorsque je suis physiquement là où je me suis connecté via VPN (au travail), je peux utiliser le sans fil, que je ne suis plus en mesure d'utiliser depuis l'incident décrit ci-dessus.
Quelques informations supplémentaires:
martillu @ ubuntu: ~ $ cat /etc/resolv.conf domaine km.icrr.u-tokyo.ac.jp serveur de noms 10.240.12.134 serveur de noms 10.240.12.135 martillu @ ubuntu: ~ $ route -n Tableau de routage IP du noyau Drapeaux de masque de masque de passerelle de destination métriques Référence Utilisation Iface 0.0.0.0 61.127.116.199 0.0.0.0 UG 0 0 0 ppp0 61.127.116.199 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 ppp0 martillu @ ubuntu: ~ $ ifconfig eth0 Encapsulation de la liaison: Ethernet HWaddr e8: e0: b7: 2f: bc: 5a inet6 adr: fe80 :: eae0: b7ff: fe2f: bc5a/64 Portée: lien HAUT DIFFUSION EN COURS MULTICAST MTU: 1500 métrique: 1 paquets RX: 17620 erreurs: 0 omis: 1 dépassements: 0 trame: 0 TX paquets: 13168 erreurs: 0 omis: 0 dépassements: 0 transporteur: 0 collisions: 0 txqueuelen: 1000 octets RX: 19452232 (19,4 Mo) octets TX: 2568218 (2,5 Mo) Interruption: 20 Mémoire: c0700000-c0720000 Lo Link encap: Local L oopback inet addr: 127.0.0.1 Masque: 255.0.0.0 inet6 addr: :: 1/128 Portée: hôte UP LOOPBACK RUNNING MTU: 16436 Métrique: 1 Paquets RX: 134 erreurs: 0 omis: 0 dépassements: 0 image: 0 Paquets TX: 134 erreurs: 0 omis: 0 dépassements: 0 porteuse: 0 Collisions: 0 txqueuelen: 0 Octets RX: 36316 (36,3 Ko) Octets TX: 36316 (36,3 Ko) Ppp0 Protocole de liaison encap-point-de-point Inet addr: 219.167.252.226 PtP: 61.127.116.199 Masque: 255.255.255.255 UP POINTOPOINT EXÉCUANT NOARP MULTICAST MTU: 1454 Métrique: 1 Paquets RX: 17608 erreurs: 0 abandonnées: 0 dépassements: 0 trames: 0 cadre: 0 [. .] Paquets TX: 13129 erreurs: 0 omis: 0 dépassements: 0 porteuse: 0 Collisions: 0 txqueuelen: 3 Octets RX: 18993590 (18,9 Mo) octets TX: 2221195 (2,2 Mo) wlan0 Encapsulation de la liaison: Ethernet HWaddr 9c: b7: 0d: d9: 21: f3 UP BROADCAST MULTICAST MTU: 1500 Métrique: 1 Paquets RX: 0 erreurs: 0 omis: 0 dépassements: 0 image: 0 paquets TX: 0 erreurs: 0 dropp ed: 0 dépassements: 0 transporteur: 0 collisions: 0 txqueuelen: 1000 octets RX: 0 (0.0 B) octets TX: 0 (0.0 B)
Je pense que: domain km.icrr.u-tokyo.ac.jp dans le fichier resolv.conf peut être suspect, car si je ne suis pas connecté via CiscoVPN, je ne sais pas pourquoi il devrait apparaître "km.icrr.u-tokyo.ac.jp" (c'est où je me connecte via VPN).
Tu es sur la bonne piste. le resolv.conf a été modifié pour une utilisation VPN et n'a pas été rétabli pour une utilisation normale à la suite du blocage. La suppression de l'ancien resolv.conf peut aider. Vous pouvez créer une copie de sauvegarde du fichier et supprimer l'original à l'aide de cette commande unique:
Sudo mv /etc/resolv.conf /etc/backup.resolv.conf
Un nouveau resolv.conf sera généré au besoin. Voir la réponse à la question suivante:
Impossible d'accéder à Internet (les noms DNS ne sont pas résolus) après la mise à jour aujourd'hui
Regarde aussi:
http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/
J'espère que cela t'aides.
La réponse de @ user68186 n'a pas fonctionné pour moi, bien que cela puisse être dû à d'autres problèmes. Ce qui a semblé fonctionner, c’est ce qui a été suggéré (supprimer /etc/resolv.conf en créant une sauvegarde)
Sudo mv /etc/resolv.conf /etc/backup.resolv.conf
et ensuite (après la page de manuel de resolveconf de _ (VARIABLE] _ ) en créant un nouveau lien sym vers /run/resolvconf/resolv.conf (que j'ai trouvé mentionné également dans cet Ubuntu 14.04 _ resolvconf rapport de bug )
cd /etc
Sudo ln -s /run/resolvconf/resolv.conf .
Après avoir fait cela et redémarré le gestionnaire de réseau
Sudo /etc/init.d/network-manager restart
les choses semblent fonctionner à nouveau.