Oui c’est un dual boot avec Win Vista, et j’essaierai d’activer le WOL si c’est possible, pour tester.
Pas trouvé d’option WOL dans le BIOS… Une autre idée ? Retour à Wheezy ? C’est balo je le trouve particulièrement rapide ce Jessie, peut être trop pour ma connexion…
Alors le problème vient peut-être de là.
Comme r2mi, j’ai trouvé ça même si je ne sais pas de quand ça date :
Il était temps que tu t’en rendes compte avant de provoquer plus de dégâts.
Une piste était quand même bonne : tester indépendamment la résolution DNS et la connectivité IP avec l’extérieur. Dommage d’avoir abandonné parce que ta box ne répond pas au ping. Il y a d’autres adresses IP qui répondent au ping comme 8.8.8.8 (DNS de Google). [mono]traceroute[/mono] est encore mieux pour visualiser le chemin complet et voir où ça coince, au cas où la destination ne répondrait pas.
Pour tester la résolution DNS des noms de domaine, les classiques [mono]host[/mono], [mono]nslookup[/mono] ou [mono]dig[/mono] du paquet dnsutils. Chacun utilise par défaut les adresses de DNS figurant dans /etc/resolv.conf mais peut être forcé d’interroger un DNS particulier (voir syntaxe dans la page de manuel de chacune). Si 8.8.8.8 répond au ping, on peut l’utiliser pour la résolution DNS.
La box internet ne fait pas serveur DNS ?
ps: pas vu pas pris
Bon je croyais avoir dit une betise mais c’est bien le "reverse mapping qui semble poser un problème. Dans le cas de certaines distros c’est named.conf qui sert de fichier de zone mais sur Debby je ne sais pas.
Bien vu : je ping ou trace 8.8.8.8 sans soucis, mais pas www.google.fr (ou .com)
Que puis-je faire de cette information ? 
Alors le problème vient peut-être de là. [/quote]
Possible, mais le fait que je n’avais aucun soucis avec le même partitionnement sous Debian 7 me semble plutôt militer pour une autre cause…
En tout cas pas de wake on lane dans mon bios 
Quand une commande “ne marche pas”, prends la bonne habitude de recopier intégralement et fidèlement la commande et son résultat. Cela permet de déceler une éventuelle erreur dans la commande, ou de déduire la cause probable de l’échec.
La suite, c’est de tester la résolution DNS d’un nom de domaine quelconque en interrogeant les serveurs DNS dont les adresses figurent dans /etc/resolv.conf ainsi que celui de Google 8.8.8.8 pour comparer. Je vois que ces adresses sont celles de serveurs DNS d’OVH, donc je suppose que ton FAI est OVH.
Par exemple avec [mono]host[/mono] :
Si j’etais lui je referais une install de network manager, je viens de me souvenir d’un pb semblable
Sachant que resolv.conf est généré par networkmanager il a une chance que ca rentre dans l’ordre
Voici mon etc/resolv.com
[code]# Generated by NetworkManager
search lan
nameserver 91.121.161.184
nameserver 188.165.197.144
nameserver 2001:41d0:3:163::1
NOTE : il se peut que le solveur libc ne prenne pas en charge plus de 3 serveurs de noms.
Les serveurs de noms listés ci-dessous peuvent ne pas être reconnus.
nameserver 2001:41d0:1:e2b8::1
nameserver fe80::3291:8fff:fe9e:396e%eth0[/code]
Voici ce que donne la commande proposée en exemple alors que la machine est fraîchement allumée, avec une connexion active :
[code]root@debian:/home/picsou# host www.debian-fr.org 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
www.debian-fr.org has address 104.28.12.4
www.debian-fr.org has address 104.28.13.4
www.debian-fr.org has IPv6 address 2400:cb00:2048:1::681c:d04
www.debian-fr.org has IPv6 address 2400:cb00:2048:1::681c:c04
root@debian:/home/picsou#[/code]
Le résultat est le même quelques minutes plus tard, une fois la connexion désactivée :
[code]root@debian:/home/picsou# host www.debian-fr.org 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
www.debian-fr.org has address 104.28.13.4
www.debian-fr.org has address 104.28.12.4
www.debian-fr.org has IPv6 address 2400:cb00:2048:1::681c:d04
www.debian-fr.org has IPv6 address 2400:cb00:2048:1::681c:c04[/code]
Du coup j’ai tenté avec les autres adresses figurant dans /etc/resolv.com :
[code]ping: unknown host www.debian-fr.org
root@debian:/home/picsou# host www.debian-fr.org 91.121.161.184
Using domain server:
Name: 91.121.161.184
Address: 91.121.161.184#53
Aliases:
www.debian-fr.org has address 104.28.12.4
www.debian-fr.org has address 104.28.13.4
www.debian-fr.org has IPv6 address 2400:cb00:2048:1::681c:d04
www.debian-fr.org has IPv6 address 2400:cb00:2048:1::681c:c04
root@debian:/home/picsou# host 91.121.161.184 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
184.161.121.91.in-addr.arpa domain name pointer dns1.isp.ovh.net.
root@debian:/home/picsou# host 188.165.197.144 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
144.197.165.188.in-addr.arpa domain name pointer dns3.isp.ovh.net.
root@debian:/home/picsou# host 2001:41d0:3:163::1 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.6.1.0.3.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa domain name pointer cdns.ovh.net.
root@debian:/home/picsou#
[/code]
Donc oui, je suis bien chez OVH 
Pour autant, le problème est forcément avant la box, qui fonctionne très bien sous win… Et pour une fois c’est pas (entièrement) la faute de l’utilisateur 
Pour ce qui est de réinstaller network-manager, j’ai tenté l’option -f, sans résultat :
root@debian:/home/picsou# apt-get install -f network-manager
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
network-manager est déjà la plus récente version disponible.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
root@debian:/home/picsou#
J’hésite à “purge” sachant que derrière il me faudra faire la manip avec une clef USB (je n’aurais plus les précieuses minutes de connexion à l’allumage)
Ça tombe bien car dans le lien fourni, il était conseillé de changer la configuration dans Win si possible et non pas dans le BIOS.
Pour la différence entre debian 7 et 8, il y a un mot-clé : regression. Il se peut que le noyau 3.16 ait malheureusement retrouvé un mauvais comportement avec ce module comparé au noyau 3.2.
Encore une fois, sans logs, difficile de pister le présumé coupable.
Quel log serait parlant ? J’ai donné tout le contenu de la console dans mon dernier message, quelle autre commande tester ?
Je chercherai aussi si win Vista me propose un Wake On Lan…
Ce ne sont pas les tests de résolution DNS que j’avais demandé. Tu interroges toujours 8.8.8.8 au lieu des serveurs définis dans resolv.conf.
Au temps pour moi 
Nouveaux tests donc, avec successivement la connexion active (début de session) :
picsou@debian:~$ host 91.121.161.184
184.161.121.91.in-addr.arpa domain name pointer dns1.isp.ovh.net.
picsou@debian:~$ host 188.165.197.144
144.197.165.188.in-addr.arpa domain name pointer dns3.isp.ovh.net.
picsou@debian:~$ host 2001:41d0:3:163::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.6.1.0.3.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa domain name pointer cdns.ovh.net.
picsou@debian:~$ host 2001:41d0:1:e2b8::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.2.e.1.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa domain name pointer dns1.isp.ovh.net.
picsou@debian:~$ host fe80::3291:8fff:fe9e:396e
Host e.6.9.3.e.9.e.f.f.f.f.8.1.9.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa not found: 3(NXDOMAIN)
Ensuite, le temps passe et ma connexion est morte : nouvelle batterie de tests, le résultat ne va pas bien loin :
[code]picsou@debian:~$ host 91.121.161.184
;; connection timed out; no servers could be reached
picsou@debian:~$ host 188.165.197.144
;; connection timed out; no servers could be reached
picsou@debian:~$ host 2001:41d0:1:e2b8::1
;; connection timed out; no servers could be reached
picsou@debian:~$ host fe80::3291:8fff:fe9e:396e
;; connection timed out; no servers could be reached
[/code]
Là, je me rends compte par accident que Le fichier resolv.conf à changé : cerait-ce cette modif qui bloque la connexion ? Pourquoi serait-il modifié en cours de session ?
nameserver 2001:41d0:3:163::1
nameserver 2001:41d0:1:e2b8::1
Du coup, nouveaux tests, mais résultats semblables :
picsou@debian:~$ host 2001:41d0:3:163::1
;; connection timed out; no servers could be reached
picsou@debian:~$ host 2001:41d0:1:e2b8::1
;; connection timed out; no servers could be reached
Du coup j’ai un doute, et je re-test 8.8.8.8 : rien au host, mais je le ping toujours :
picsou@debian:~$ host 8.8.8.8
;; connection timed out; no servers could be reached
picsou@debian:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=51.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=49.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=49.2 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=49.9 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=49.9 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=57 time=50.9 ms
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5006ms
rtt min/avg/max/mdev = 49.207/50.285/51.692/0.822 ms
picsou@debian:~$
La piste d’un processus altérant mon resolv.conf semble la plus intéressante (à moins que ce ne soit normal ? 
), mais par où chercher ?
Ce ne sont toujours pas les tests que j’avais demandés, à savoir interroger explicitement les différents serveurs DNS mentionnés dans resolv.conf. Là, tu ne spécifies pas le serveur DNS à interroger. Rappel de la syntaxe de la commande [mono]host[/mono] :
Si le serveur DNS à interroger n’est pas spécifié, [mono]host[/mono] utilise par défaut un de ceux figurant dans resolv.conf, mais on ne voit pas lequel.
Il y a de fortes chances. Toutes les adresses IPv4 de serveurs DNS ont disparu, il ne reste que deux adresses IPv6 globales. Or dans la sortie d’[mono]ifconfig[/mono] que tu avais fournie, l’interface réseau eth0 n’a pas d’adresse IPv6 globale donc ne peut pas communiquer avec ces serveurs en IPv6. Cette sortie d’[mono]ifconfig[/mono] correspond-elle au moment où la résolution DNS fonctionne encore ou après ?
Est-ce le contenu complet du fichier ? Si oui, a priori ce n’est pas network-manager puisqu’on ne voit plus son commentaire “# Generated by NetworkManager”. J’ai déjà vu le contenu de resolv.conf écrasé avec des adresses IPv6 il y a fort longtemps sur une de mes machines, c’était dû au service [mono]rdnssd[/mono] (qui récupère les DNS IPv6 dans les annonces de routeur IPv6) alors que [mono]resolvconf[/mono] n’était pas installé. Après avoir installé [mono]resolvonf[/mono], les DNS IPv6 ont été ajoutés au fichier existant au lieu de l’écraser. Il faudrait aussi regarder la configuration IPv6 de l’interface réseau dans network-manager.
Bon, je viens de vérifier, pas plus de WOL dans win Vista en dual boot que dans le bios.
C’est ce que je croyais faire dans un précédent message :
[code]root@debian:/home/picsou# host www.debian-fr.org 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
www.debian-fr.org has address 104.28.13.4
www.debian-fr.org has address 104.28.12.4
www.debian-fr.org has IPv6 address 2400:cb00:2048:1::681c:d04
www.debian-fr.org has IPv6 address 2400:cb00:2048:1::681c:c04[/code]
je n’ai donc pas encore compris ce qu’il faut faire, je suis vraiment à la ramasse 
C’est justement après, raison pour laquelle je pense que c’est la clef du problème.
C’est bien le contenu complet, et c’est bien ce qui me chiffonne aussi.
Je vais donc tenter d’installer resolvconf.
Je vais voir ce que je trouve mais… tout n’est-il pas dans /etc/network/interfaces ? Je l’ai copié-collé au début de la file :
[code]# This file describes the network interfaces available on your system
and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
The loopback network interface
auto lo
iface lo inet loopback[/code]
J’ai installé resolvconf ce qui a modifié logiquement mon resolv.conf :
[code]# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
DO NOT EDIT THIS FILE BY HAND – YOUR CHANGES WILL BE OVERWRITTEN
nameserver 2001:41d0:3:163::1
nameserver 2001:41d0:1:e2b8::1
nameserver 91.121.161.184
search lan[/code]
Côté réseau j’ai ceci :
Périphérique réseau : eth0
Adresse matérielle : 00:1c:25:23:03:cd
Multicast : Activé
MTU : 1500
Vitesse du lien : non disponible
État : Actif
Paquets transmis : 1098
Erreurs de transmission : 0
Paquets reçus : 922
Erreurs de réception : 0
Collisions : 0
Pour l’instant tout marche, je vois dans 5 min ce que ça donne…
Note : message écrit avant ta dernière réponse.
Oui, mais il fallait aussi faire la même avec les serveurs inscrits dans resolv.conf au lieu de 8.8.8.8 pour comparer.
Je suis quand même étonné que resolv.conf contienne des adresses IPv6 alors que eth0 n’a pas d’adresse IPv6 globale…
Là aussi je suis un peu surpris que resolvconf ne soit pas installé par défaut.
Est-ce que rdnssd est installé ?
Non. Ce fichier ne définit que les interfaces non gérées par network-manager, ici l’interface de loopback. L’interface eth0 n’étant pas définie dans ce fichier, elle est gérée par network-manager. Il faut aller dans l’applet réseau de l’environnement de bureau, accessible généralement via une icone dans une barre d’outils.
Formidable, on dirait bien que resolvconf a résolu le problème ! 
J’ai quand même été voir du côté de rdnssd qui tourne bien :
[code]root@debian:/home/picsou# service rdnssd status
● rdnssd.service - LSB: IPv6 Recursive DNS Server discovery
Loaded: loaded (/etc/init.d/rdnssd)
Active: active (running) since dim. 2015-08-23 11:45:44 CEST; 18min ago
CGroup: /system.slice/rdnssd.service
├─275 /sbin/rdnssd -u rdnssd -H /etc/rdnssd/merge-hook
└─276 /sbin/rdnssd -u rdnssd -H /etc/rdnssd/merge-hook
août 23 11:45:44 debian rdnssd[234]: Starting IPv6 Recursive DNS Server di…d.
Hint: Some lines were ellipsized, use -l to show in full.
root@debian:/home/picsou# [/code]
Encore quelques minutes et je crois bien que je vais pouvoir passer en résolu et faire un gros bisous à tous 
avec spéciale dédicace à PascalHambourg 
On a contourné le problème (un autre moyen aurait été de désinstaller ou désactiver rdnssd pour qu’il n’écrase pas resolv.conf), mais il y a quand même quelque chose qui ne tourne pas rond. S’il y a des DNS IPv6, eth0 devrait avoir une adresse IPv6 globale. C’est pour cela que je demandais de regarder la configuration de l’interface dans network-manager.