Surf (très lent) sur lenny != XP (rapide) : pb config DNS ?

Eric75 · Février 20, 2016, 11:17pm

Bonjour à tous,

J’ai un PC en dual boot : lenny d’un coté, XP de l’autre.
A priori, la config réseau est la même : même IP, même passerelle, même DNS.
Ce PC est relié à mon routeur (WRT54G) par un seul et unique câble CAT5, et ce routeur communique avec ma Neufbox par Wifi.

Quand je suis sur XP, je surfe avec FireFox à vitesse normale (6 Mb/s) alors que quand je suis sur ma lenny adorée (avec Iceweasel), j’ai l’impression d’avoir une liaison 56 Kb/s !!!

Pourquoi cette différence ?
J’ai comme l’impression d’avoir un souci de config DNS mais je ne vois pas d’où ça viendrait ???

Voici ce que donne un ipconfig /all sur XP :

[code]Configuration IP de Windows

    Nom de l'hôte . . . . . . . . . . : PC01
    Suffixe DNS principal . . . . . . : 
    Type de nœud . . . . . . . . . . .: Inconnu
    Routage IP activé . . . . . . . . : Non
    Proxy WINS activé . . . . . . . . : Non

Carte Ethernet Connexion LAN:

    Suffixe DNS propre à la connexion : 
    Description . . . . . . . . . . . : NVIDIA nForce 10/100/1000 Mbps Ethernet 
    Adresse physique . . . . . . . . .: 00-E0-18-XX-XX-XX
    DHCP activé. . . . . . . . . . . .: Non
    Adresse IP. . . . . . . . . . . . : 192.168.2.12
    Masque de sous-réseau . . . . . . : 255.255.255.0
    Passerelle par défaut . . . . . . : 192.168.2.11
    Serveurs DNS . . . . . . . . . .  : 192.168.1.1

[/code]
Un ifconfig sur ma Debian :

[code]eth0 Link encap:Ethernet HWaddr 00:e0:18:XX:XX:XX
inet adr:192.168.2.12 Bcast:192.168.2.255 Masque:255.255.255.0
adr inet6: fe80::2e0:18ff:XXXX:XXXX/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1436 errors:0 dropped:0 overruns:0 frame:0
TX packets:1710 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:1208879 (1.1 MiB) TX bytes:265180 (258.9 KiB)
Interruption:21

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:560 (560.0 B) TX bytes:560 (560.0 B)[/code]
Mon fichier 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

Quelqu’un aurait une idée d’où viendrait le pb ?
Merci d’avance pour votre aide,
Eric

zodar · Février 20, 2016, 11:17pm

Ptet ça.

Dans iceweasel, tape about:config dans la barre d’adresse

recherche :

network.dns.disableIPv6 false

et double clique dessus pour le passer à true.

Redémarre iceweasel et vois si ça change quelque chose

Eric75 · Février 20, 2016, 11:17pm

Salut zodar,

C’est vrai que j’ai oublié de préciser avec quel browser je navigue… (erreur réparée)
Mais malheureusement cette modif n’a rien arrangé

Sinon, pour info, un petit route print :

[code]===========================================================================
Liste d’Interfaces
0x1 … MS TCP Loopback interface
0x2 …00 e0 18 XX XX XX … NVIDIA nForce Networking Controller - Miniport d’ordonnancement de paquets

===========================================================================
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
0.0.0.0 0.0.0.0 192.168.2.11 192.168.2.12 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.2.0 255.255.255.0 192.168.2.12 192.168.2.12 20
192.168.2.12 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.255.255 255.255.255.255 192.168.2.12 192.168.2.12 20
224.0.0.0 240.0.0.0 192.168.2.12 192.168.2.12 20
255.255.255.255 255.255.255.255 192.168.2.12 192.168.2.12 1
Passerelle par défaut : 192.168.2.11

Itinéraires persistants :
Aucun[/code]
et un petit route -n :

Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.2.11 0.0.0.0 UG 0 0 0 eth0

dric64 · Février 20, 2016, 11:18pm

Essaye de mettre un vrai serveur dns, à la place de l’ip de ta box (ex : 208.67.222.222 celui de opendns)
Ca ne serait pas la première fois qu’on voit sur ce forum des problèmes lorsque c’est la box qui se charge de la résolution dns… D’habitude c’est plutôt les livebox, mais bon…

PascalHambourg · Février 20, 2016, 11:18pm

En premier lieu, il serait bon de caractériser cette “lenteur”. Provient-elle d’un débit de transmission faible ou bien d’un délai initial important ?

Pour mesurer le débit, télécharger un fichier assez gros, que le téléchargement dure au moins 20 secondes, avec un logiciel qui affiche le débit instantané et moyen à la fin, par exemple avec wget en ligne de commande. Si le débit est normal, vérifier que la résolution DNS n’introduit pas un délai initial, en faisant des requêtes DNS de type adresse IPv4 et IPv6 avec dig, host ou nslookup. Par exemple :

dig aaaa ftp.debian.org dig a www.debian.org

Eric75 · Février 20, 2016, 11:18pm

@dric64 : malheureusement aucun changement si je met l’IP d’OpenDNS !
Je ne savais pas que certaines box avaient des soucis de résolutions DNS… mais dans mon cas, ça le ferait aussi avec XP non ?

@PascalHambourg : c’est vrai, tu as raison je ne me suis pas forcement bien expliqué sur ce que j’entends par lenteur…
J’ai donc téléchargé un “truc” bien lourd (pour ce que c’est ou devrait être) :

[code]$ wget http://ardownload.adobe.com/pub/adobe/reader/win/9.x/9.3.3/fra/AdbeRdr933_fr_FR.exe
–2010-08-28 09:54:39-- http://ardownload.adobe.com/pub/adobe/reader/win/9.x/9.3.3/fra/AdbeRdr933_fr_FR.exe
Résolution de ardownload.adobe.com… 77.109.168.10, 77.109.168.26
Connexion vers ardownload.adobe.com|77.109.168.10|:80…connecté.
requête HTTP transmise, en attente de la réponse…200 OK
Longueur: 42643880 (41M) [application/octet-stream]
Saving to: `AdbeRdr933_fr_FR.exe’

100%[=============================================================================================>] 42 643 880 176K/s in 3m 15s

2010-08-28 09:57:59 (214 KB/s) - « AdbeRdr933_fr_FR.exe » sauvegardé [42643880/42643880]

[/code]
Résultat dans la moyenne de ce que j’obtiens d’habitude… (Avec XP, j’ai téléchargé le même “truc” avec un débit moyen de 240 Ko/s d’après DuMeter)
Pour info, pendant le lancement de cette commande, wget est resté 2 à 3 secondes sur “Résolution de ardownload.adobe.com…”
J’ai ensuite essayé :

[code]$ dig aaaa http://ardownload.adobe.com

; <<>> DiG 9.6-ESV-R1 <<>> aaaa http://ardownload.adobe.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12443
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;http://ardownload.adobe.com. IN AAAA

;; Query time: 66 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Sat Aug 28 10:13:43 2010
;; MSG SIZE rcvd: 45

[/code]
Cela semble correct. (et donc en contradiction avec ce que j’ai constaté lors du wget)
Deuxième essai :

[code]dig aaaa http://ardownload.adobe.com

; <<>> DiG 9.6-ESV-R1 <<>> aaaa http://ardownload.adobe.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30195
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;http://ardownload.adobe.com. IN AAAA

;; Query time: 67 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Sat Aug 28 10:13:45 2010
;; MSG SIZE rcvd: 45

[/code]
Étant un peu têtu sur les bords (voir au milieu aussi) une dernière fois :

[code]$ dig aaaa http://ardownload.adobe.com

; <<>> DiG 9.6-ESV-R1 <<>> aaaa http://ardownload.adobe.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31081
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;http://ardownload.adobe.com. IN AAAA

;; Query time: 70 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Sat Aug 28 10:13:55 2010
;; MSG SIZE rcvd: 45

[/code]
Les résultats semble montrer que les temps d’une même requête DNS sont constants… à ceci près : dig à mis cette fois 6 à 7 secondes avant de m’afficher quoi que ce soit !!!

Et ça résume bien ce qui se passe avec ma lenny : parfois l’affichage des pages web est quasi instantané, parfois j’ai le début d’une page qui s’affiche et puis ça semble se figer… puis ça reprends (au bout d’un temps totalement aléatoire) et en plus, ça ne le fait pas forcement sur la même page…

fran.b · Février 20, 2016, 11:18pm

enlève les http:// dans les digs. Pour info:

[quote]francois@totoche:~$ dig aaaa ardownload.adobe.com

; <<>> DiG 9.6.1-P2 <<>> aaaa ardownload.adobe.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31924
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ardownload.adobe.com. IN AAAA

;; ANSWER SECTION:
ardownload.adobe.com. 3600 IN CNAME ardownload.wip4.adobe.com.
ardownload.wip4.adobe.com. 300 IN CNAME ardownload.adobe.com.edgesuite.net.
ardownload.adobe.com.edgesuite.net. 21600 IN CNAME a1953.d.akamai.net.

;; AUTHORITY SECTION:
d.akamai.net. 1000 IN SOA n0d.akamai.net. hostmaster.akamai.com. 1282985321 1000 1000 1000 1800

;; Query time: 835 msec
;; SERVER: 192.168.1.251#53(192.168.1.251)
;; WHEN: Sat Aug 28 10:48:43 2010
;; MSG SIZE rcvd: 203

[/quote]

Quel est ton FAI? N’aurais tu pas par hasard une livebox? [réponse: neuf et non] Essaye en mettant les adresses des DNS de ton FAI plutôt que 192.168.1.1.

En tout cas, c’est un pbm DNS visiblement.

dric64 · Février 20, 2016, 11:18pm

J’ai une suggestion de test : te connecter directement à la neufbox (avec un cable ethernet) si c’est possible, et zapper le routeur qui est actuellement intercalé entre le pc et la neufbox (surtout que ces 2 sont connectés en wifi… c’est p’tet là que ca cloche)
Ou encore : relier le routeur et la neufbox avec un cable ethernet.

Si ton wifi qui interconnecte le routeur et la neufbox a des sautes d’humeurs, à mon avis ca peut donner aléatoirement les problèmes que tu cites…

Peut être lancer un ping en continu sur la neufbox depuis un pc client derriere le routeur et voir s’il y a des pertes de paquets a moment donné, qui coïncideraient avec les moments ou tu constates les lenteurs dont tu parles ?

Eric75 · Février 20, 2016, 11:18pm

Salut fran.b,

Même avec les DNS de Neuf (cf ici) ça change rien !

@dric64 : bonne idée ton ping continu sur la box :

$ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=7.30 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=26.1 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=25.0 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=63 time=10.7 ms 64 bytes from 192.168.1.1: icmp_seq=6 ttl=63 time=8.85 ms 64 bytes from 192.168.1.1: icmp_seq=7 ttl=63 time=13.4 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=63 time=26.2 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=63 time=3.31 ms 64 bytes from 192.168.1.1: icmp_seq=10 ttl=63 time=33.6 ms 64 bytes from 192.168.1.1: icmp_seq=11 ttl=63 time=13.2 ms 64 bytes from 192.168.1.1: icmp_seq=12 ttl=63 time=11.7 ms 64 bytes from 192.168.1.1: icmp_seq=13 ttl=63 time=27.5 ms 64 bytes from 192.168.1.1: icmp_seq=15 ttl=63 time=5.83 ms 64 bytes from 192.168.1.1: icmp_seq=16 ttl=63 time=41.8 ms 64 bytes from 192.168.1.1: icmp_seq=18 ttl=63 time=6.88 ms 64 bytes from 192.168.1.1: icmp_seq=19 ttl=63 time=7.86 ms 64 bytes from 192.168.1.1: icmp_seq=20 ttl=63 time=14.9 ms 64 bytes from 192.168.1.1: icmp_seq=21 ttl=63 time=5.15 ms 64 bytes from 192.168.1.1: icmp_seq=22 ttl=63 time=11.5 ms 64 bytes from 192.168.1.1: icmp_seq=24 ttl=63 time=16.4 ms 64 bytes from 192.168.1.1: icmp_seq=25 ttl=63 time=3.46 ms 64 bytes from 192.168.1.1: icmp_seq=26 ttl=63 time=5.16 ms 64 bytes from 192.168.1.1: icmp_seq=27 ttl=63 time=21.7 ms 64 bytes from 192.168.1.1: icmp_seq=28 ttl=63 time=5.22 ms 64 bytes from 192.168.1.1: icmp_seq=29 ttl=63 time=5.10 ms 64 bytes from 192.168.1.1: icmp_seq=30 ttl=63 time=8.82 ms 64 bytes from 192.168.1.1: icmp_seq=31 ttl=63 time=3.30 ms 64 bytes from 192.168.1.1: icmp_seq=32 ttl=63 time=25.3 ms 64 bytes from 192.168.1.1: icmp_seq=33 ttl=63 time=13.0 ms 64 bytes from 192.168.1.1: icmp_seq=35 ttl=63 time=9.62 ms 64 bytes from 192.168.1.1: icmp_seq=37 ttl=63 time=15.7 ms 64 bytes from 192.168.1.1: icmp_seq=38 ttl=63 time=22.1 ms 64 bytes from 192.168.1.1: icmp_seq=40 ttl=63 time=24.4 ms 64 bytes from 192.168.1.1: icmp_seq=41 ttl=63 time=2.76 ms 64 bytes from 192.168.1.1: icmp_seq=42 ttl=63 time=7.57 ms 64 bytes from 192.168.1.1: icmp_seq=43 ttl=63 time=8.76 ms 64 bytes from 192.168.1.1: icmp_seq=46 ttl=63 time=17.2 ms 64 bytes from 192.168.1.1: icmp_seq=48 ttl=63 time=5.88 ms 64 bytes from 192.168.1.1: icmp_seq=50 ttl=63 time=6.92 ms 64 bytes from 192.168.1.1: icmp_seq=51 ttl=63 time=7.22 ms 64 bytes from 192.168.1.1: icmp_seq=52 ttl=63 time=14.6 ms 64 bytes from 192.168.1.1: icmp_seq=53 ttl=63 time=20.9 ms 64 bytes from 192.168.1.1: icmp_seq=55 ttl=63 time=5.15 ms 64 bytes from 192.168.1.1: icmp_seq=56 ttl=63 time=3.37 ms 64 bytes from 192.168.1.1: icmp_seq=57 ttl=63 time=7.00 ms ^C --- 192.168.1.1 ping statistics --- 57 packets transmitted, 45 received, 21% packet loss, time 56198ms rtt min/avg/max/mdev = 2.765/13.074/41.817/9.068 ms
C’est donc vers là qu’il faut chercher on dirait…
Mais alors pourquoi ça fonctionne correctement sur XP ???

taureau89_9 · Février 20, 2016, 11:18pm

[quote=“Eric75”]
Les résultats semble montrer que les temps d’une même requête DNS sont constants… à ceci près : dig à mis cette fois 6 à 7 secondes avant de m’afficher quoi que ce soit !!![/quote]

A mon avis ta ligne Adsl n’est pas une ligne hyper rapide qui supporte l’ipV6.

Ce qui explique parfaitement le temps de résolution, de façon classique d’environ 5 secondes (à peu près) avant que la requête n’aboutisse, si ton système est paramétré en ipV6 alors que la ligne ne l’est pas.

Tout dépend de ce que tu as comme Grub, Legacy ou Grub2 ou Grub-pc.

Si Grub2 ou Grub-pc

puis remplacer la ligne

par

puis

et reboot, et tes requêtes aboutiront de façon immédiate.

Normal que ça marche sous XP qui est en ipV4.

Si tu as Grub Legacy

et modifier la ligne du kernel

la ligne peut être différente suivant tes paramétrages, c’est ipv6.disable=1 qu’il faut rajouter après ro .

dric64 · Février 20, 2016, 11:18pm

[quote=“Eric75”]Salut fran.b,

Même avec les DNS de Neuf (cf ici) ça change rien !

@dric64 : bonne idée ton ping continu sur la box :

$ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=7.30 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=26.1 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=25.0 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=63 time=10.7 ms 64 bytes from 192.168.1.1: icmp_seq=6 ttl=63 time=8.85 ms 64 bytes from 192.168.1.1: icmp_seq=7 ttl=63 time=13.4 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=63 time=26.2 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=63 time=3.31 ms 64 bytes from 192.168.1.1: icmp_seq=10 ttl=63 time=33.6 ms 64 bytes from 192.168.1.1: icmp_seq=11 ttl=63 time=13.2 ms 64 bytes from 192.168.1.1: icmp_seq=12 ttl=63 time=11.7 ms 64 bytes from 192.168.1.1: icmp_seq=13 ttl=63 time=27.5 ms 64 bytes from 192.168.1.1: icmp_seq=15 ttl=63 time=5.83 ms 64 bytes from 192.168.1.1: icmp_seq=16 ttl=63 time=41.8 ms 64 bytes from 192.168.1.1: icmp_seq=18 ttl=63 time=6.88 ms 64 bytes from 192.168.1.1: icmp_seq=19 ttl=63 time=7.86 ms 64 bytes from 192.168.1.1: icmp_seq=20 ttl=63 time=14.9 ms 64 bytes from 192.168.1.1: icmp_seq=21 ttl=63 time=5.15 ms 64 bytes from 192.168.1.1: icmp_seq=22 ttl=63 time=11.5 ms 64 bytes from 192.168.1.1: icmp_seq=24 ttl=63 time=16.4 ms 64 bytes from 192.168.1.1: icmp_seq=25 ttl=63 time=3.46 ms 64 bytes from 192.168.1.1: icmp_seq=26 ttl=63 time=5.16 ms 64 bytes from 192.168.1.1: icmp_seq=27 ttl=63 time=21.7 ms 64 bytes from 192.168.1.1: icmp_seq=28 ttl=63 time=5.22 ms 64 bytes from 192.168.1.1: icmp_seq=29 ttl=63 time=5.10 ms 64 bytes from 192.168.1.1: icmp_seq=30 ttl=63 time=8.82 ms 64 bytes from 192.168.1.1: icmp_seq=31 ttl=63 time=3.30 ms 64 bytes from 192.168.1.1: icmp_seq=32 ttl=63 time=25.3 ms 64 bytes from 192.168.1.1: icmp_seq=33 ttl=63 time=13.0 ms 64 bytes from 192.168.1.1: icmp_seq=35 ttl=63 time=9.62 ms 64 bytes from 192.168.1.1: icmp_seq=37 ttl=63 time=15.7 ms 64 bytes from 192.168.1.1: icmp_seq=38 ttl=63 time=22.1 ms 64 bytes from 192.168.1.1: icmp_seq=40 ttl=63 time=24.4 ms 64 bytes from 192.168.1.1: icmp_seq=41 ttl=63 time=2.76 ms 64 bytes from 192.168.1.1: icmp_seq=42 ttl=63 time=7.57 ms 64 bytes from 192.168.1.1: icmp_seq=43 ttl=63 time=8.76 ms 64 bytes from 192.168.1.1: icmp_seq=46 ttl=63 time=17.2 ms 64 bytes from 192.168.1.1: icmp_seq=48 ttl=63 time=5.88 ms 64 bytes from 192.168.1.1: icmp_seq=50 ttl=63 time=6.92 ms 64 bytes from 192.168.1.1: icmp_seq=51 ttl=63 time=7.22 ms 64 bytes from 192.168.1.1: icmp_seq=52 ttl=63 time=14.6 ms 64 bytes from 192.168.1.1: icmp_seq=53 ttl=63 time=20.9 ms 64 bytes from 192.168.1.1: icmp_seq=55 ttl=63 time=5.15 ms 64 bytes from 192.168.1.1: icmp_seq=56 ttl=63 time=3.37 ms 64 bytes from 192.168.1.1: icmp_seq=57 ttl=63 time=7.00 ms ^C --- 192.168.1.1 ping statistics --- 57 packets transmitted, 45 received, 21% packet loss, time 56198ms rtt min/avg/max/mdev = 2.765/13.074/41.817/9.068 ms
C’est donc vers là qu’il faut chercher on dirait…
Mais alors pourquoi ça fonctionne correctement sur XP ??? [/quote]

Ben… T’es relié comment entre le pc et le routeur ?
C’est peut être pas le lien routeur/neufbox qui pose problème, mais le lien pc/routeur : pilote ethernet ou wifi qui déconne ? Ca expliquerait que ca marche bien avec XP, et pas avec debian…
C’est pour ça que je suggérais aussi de te connecter directement sur la neufbox, histoire de voir si le problème suit le pc

fran.b · Février 20, 2016, 11:18pm

Le pbm est que la machine est double boute d’où son étonnement. Je pense pour 2 possibilités:

Un souci avec le routeur et l’ipv6.
Un pbm avec le pilote WIFI (vus les pings, je pense que c’est du WIFI)

Eric75 · Février 20, 2016, 11:18pm

Alors…

@dric64 :
J’ai testé de relier mon routeur et la box avec un cable, (j’ai du modifier mes paramètres IP car, sauf erreur de ma part, j’ai l’impression que le WRT54G ne peut que router entre les 4 prises LAN et le WIFI, et pas router seulement entre ses 4 prises LAN… dommage) et voici le résultat :

[code]$ ping -c 50 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.838 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.503 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.530 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.555 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.537 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.559 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.536 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.549 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.536 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.557 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=0.538 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=0.568 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=0.587 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=0.612 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=0.633 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=0.705 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=0.725 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=0.794 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=0.530 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=0.595 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=0.740 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=0.632 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=0.736 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=0.557 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=0.534 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=0.665 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=0.535 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=0.539 ms
64 bytes from 192.168.1.1: icmp_seq=29 ttl=64 time=0.520 ms
64 bytes from 192.168.1.1: icmp_seq=30 ttl=64 time=0.547 ms
64 bytes from 192.168.1.1: icmp_seq=31 ttl=64 time=0.518 ms
64 bytes from 192.168.1.1: icmp_seq=32 ttl=64 time=0.571 ms
64 bytes from 192.168.1.1: icmp_seq=33 ttl=64 time=0.531 ms
64 bytes from 192.168.1.1: icmp_seq=34 ttl=64 time=0.555 ms
64 bytes from 192.168.1.1: icmp_seq=35 ttl=64 time=0.529 ms
64 bytes from 192.168.1.1: icmp_seq=36 ttl=64 time=0.560 ms
64 bytes from 192.168.1.1: icmp_seq=37 ttl=64 time=0.521 ms
64 bytes from 192.168.1.1: icmp_seq=38 ttl=64 time=0.550 ms
64 bytes from 192.168.1.1: icmp_seq=39 ttl=64 time=0.535 ms
64 bytes from 192.168.1.1: icmp_seq=40 ttl=64 time=0.549 ms
64 bytes from 192.168.1.1: icmp_seq=41 ttl=64 time=0.534 ms
64 bytes from 192.168.1.1: icmp_seq=42 ttl=64 time=0.540 ms
64 bytes from 192.168.1.1: icmp_seq=43 ttl=64 time=0.530 ms
64 bytes from 192.168.1.1: icmp_seq=44 ttl=64 time=0.554 ms
64 bytes from 192.168.1.1: icmp_seq=45 ttl=64 time=0.531 ms
64 bytes from 192.168.1.1: icmp_seq=46 ttl=64 time=0.553 ms
64 bytes from 192.168.1.1: icmp_seq=47 ttl=64 time=0.526 ms
64 bytes from 192.168.1.1: icmp_seq=48 ttl=64 time=10.4 ms
64 bytes from 192.168.1.1: icmp_seq=49 ttl=64 time=0.526 ms
64 bytes from 192.168.1.1: icmp_seq=50 ttl=64 time=0.587 ms

— 192.168.1.1 ping statistics —
50 packets transmitted, 50 received, 0% packet loss, time 49004ms
rtt min/avg/max/mdev = 0.503/0.775/10.479/1.388 ms[/code]
J’ai donc bien un soucis avec le WIFI ! (soit celui du routeur, soit celui de la box…)
Hypothèse corroborée par un autre test : un ping via un netbook connecté en WIFI directement à la box… et qui, du coup, ferait pencher la balance vers un pb WIFI de la box ?

[code]PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=7.11 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=5.91 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=37.3 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=15.1 ms
64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=8.80 ms
64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=21.2 ms
64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=6.92 ms
64 bytes from 192.168.1.1: icmp_req=8 ttl=64 time=1.71 ms
64 bytes from 192.168.1.1: icmp_req=9 ttl=64 time=18.4 ms
64 bytes from 192.168.1.1: icmp_req=10 ttl=64 time=88.6 ms
64 bytes from 192.168.1.1: icmp_req=11 ttl=64 time=1.46 ms
64 bytes from 192.168.1.1: icmp_req=12 ttl=64 time=1.51 ms
64 bytes from 192.168.1.1: icmp_req=13 ttl=64 time=1.76 ms
64 bytes from 192.168.1.1: icmp_req=14 ttl=64 time=37.3 ms
64 bytes from 192.168.1.1: icmp_req=15 ttl=64 time=4.39 ms
64 bytes from 192.168.1.1: icmp_req=16 ttl=64 time=3.98 ms
64 bytes from 192.168.1.1: icmp_req=17 ttl=64 time=16.9 ms
64 bytes from 192.168.1.1: icmp_req=18 ttl=64 time=14.2 ms
64 bytes from 192.168.1.1: icmp_req=19 ttl=64 time=15.2 ms
64 bytes from 192.168.1.1: icmp_req=20 ttl=64 time=14.5 ms
64 bytes from 192.168.1.1: icmp_req=21 ttl=64 time=16.6 ms
64 bytes from 192.168.1.1: icmp_req=22 ttl=64 time=36.5 ms
64 bytes from 192.168.1.1: icmp_req=23 ttl=64 time=10.7 ms
64 bytes from 192.168.1.1: icmp_req=24 ttl=64 time=24.9 ms
64 bytes from 192.168.1.1: icmp_req=25 ttl=64 time=2.71 ms
64 bytes from 192.168.1.1: icmp_req=26 ttl=64 time=5.30 ms
64 bytes from 192.168.1.1: icmp_req=27 ttl=64 time=16.9 ms
64 bytes from 192.168.1.1: icmp_req=28 ttl=64 time=6.87 ms
64 bytes from 192.168.1.1: icmp_req=29 ttl=64 time=11.0 ms
64 bytes from 192.168.1.1: icmp_req=30 ttl=64 time=33.6 ms
64 bytes from 192.168.1.1: icmp_req=31 ttl=64 time=36.0 ms
64 bytes from 192.168.1.1: icmp_req=32 ttl=64 time=20.5 ms
64 bytes from 192.168.1.1: icmp_req=33 ttl=64 time=58.7 ms
64 bytes from 192.168.1.1: icmp_req=34 ttl=64 time=20.8 ms
64 bytes from 192.168.1.1: icmp_req=35 ttl=64 time=7.21 ms
64 bytes from 192.168.1.1: icmp_req=36 ttl=64 time=4.22 ms
64 bytes from 192.168.1.1: icmp_req=37 ttl=64 time=65.4 ms
64 bytes from 192.168.1.1: icmp_req=38 ttl=64 time=2.43 ms
64 bytes from 192.168.1.1: icmp_req=39 ttl=64 time=1.34 ms
64 bytes from 192.168.1.1: icmp_req=40 ttl=64 time=23.6 ms
64 bytes from 192.168.1.1: icmp_req=41 ttl=64 time=7.28 ms
64 bytes from 192.168.1.1: icmp_req=42 ttl=64 time=5.47 ms
64 bytes from 192.168.1.1: icmp_req=43 ttl=64 time=18.4 ms
64 bytes from 192.168.1.1: icmp_req=44 ttl=64 time=75.8 ms
64 bytes from 192.168.1.1: icmp_req=45 ttl=64 time=15.9 ms
64 bytes from 192.168.1.1: icmp_req=46 ttl=64 time=31.4 ms
64 bytes from 192.168.1.1: icmp_req=48 ttl=64 time=4.34 ms
64 bytes from 192.168.1.1: icmp_req=50 ttl=64 time=11.5 ms

— 192.168.1.1 ping statistics —
50 packets transmitted, 48 received, 4% packet loss, time 49076ms
rtt min/avg/max/mdev = 1.345/18.729/88.603/19.416 ms[/code]
C’est moins pire (ou plus mieux ) que les résultats des pings du routeur mais bon…

Et pour répondre à ta question, mon PC (dual boot lenny + XP) est connecté à mon routeur en filaire (câble CAT5 que j’ai changé, histoire de)

@taureau89_9 :
J’utilise le Grub classique, je suppose donc que ça doit être “Grub Legacy” : je vais faire la modif dans le menu.lst et je te tiens au jus…

@fran.b :
Effectivement, je penche pour un pb WIFI mais plutôt celui de la box que celui du routeur, non ? (au vu des résultats des pings du netbook [Eeepc 1005PE en squeeze 2.6.32-5-amd64] => l’élément commun pour moi ici est la reception WIFI de la box, non ?)

[edit]
Mon routeur est l’un des premiers WRT54G (v1.1) avec un firmware modifié… (Sveasoft Alchemy-V1.0 v3.37.6.8sv)
Peut-être que, comme tu dis, il gère mal l’ipv6 : comment je peux diagnostiquer ça ???
[/edit]

fran.b · Février 20, 2016, 11:18pm

Ai je bien compris le pbm: la même machine sous debian: mauvaise communication, sous XP ça marche (sous WIFI donc). Ça écarte un souci avec la box. Ou bien sous XP tu as aussi des soucis (essaye un ping -c 10000 192.168.1.1 sous XP)

Eric75 · Février 20, 2016, 11:18pm

Bon… c’est à n’y rien comprendre !

J’ai voulu me remettre dans ma config initiale (liaison Router <-> Box en WIFI au lieu du câble de 10m qui traverse la maison… et que même que ma femme râle à ce propos… ) pour faire les tests demandés par fran.b, et là, impossible de pinguer la Box : à priori d’après elle, la liaison WIFI était OK sauf que si j’essaye de la pinguer depuis mon PC01 :

$ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. From 192.168.1.2 icmp_seq=2 Destination Host Unreachable From 192.168.1.2 icmp_seq=3 Destination Host Unreachable From 192.168.1.2 icmp_seq=4 Destination Host Unreachable From 192.168.1.2 icmp_seq=6 Destination Host Unreachable From 192.168.1.2 icmp_seq=7 Destination Host Unreachable From 192.168.1.2 icmp_seq=8 Destination Host Unreachable ^C --- 192.168.1.1 ping statistics --- 9 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7999ms , pipe 3
et pareil dans l’autre sens, avec l’outil de ping fourni dans la Box (dans Maintenance/Tests) !
Je me suis même connecté en telnet (oui je sais : pas bien ) directement sur le routeur et j’ai obtenu le même résultat !

J’ai donc décidé de remplacer mon routeur par son petit frère (WRT54G v2.2, même firm) et je me suis retapé la config complète afin de pouvoir réutiliser la liaison WIFI entre lui et la Box et là, ô surprise, ô miracle :[code]ping -c 50 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=2.16 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=2.34 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=1.98 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=63 time=2.48 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=63 time=1.97 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=63 time=1.99 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=63 time=2.00 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=63 time=1.97 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=63 time=2.11 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=63 time=1.99 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=63 time=1.94 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=63 time=1.92 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=63 time=1.97 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=63 time=1.94 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=63 time=2.13 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=63 time=1.97 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=63 time=1.97 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=63 time=1.95 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=63 time=1.98 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=63 time=1.96 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=63 time=3.30 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=63 time=1.98 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=63 time=1.97 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=63 time=1.98 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=63 time=1.98 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=63 time=2.31 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=63 time=1.97 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=63 time=1.95 ms
64 bytes from 192.168.1.1: icmp_seq=29 ttl=63 time=1.98 ms
64 bytes from 192.168.1.1: icmp_seq=30 ttl=63 time=2.00 ms
64 bytes from 192.168.1.1: icmp_seq=31 ttl=63 time=1.97 ms
64 bytes from 192.168.1.1: icmp_seq=32 ttl=63 time=1.97 ms
64 bytes from 192.168.1.1: icmp_seq=33 ttl=63 time=1.96 ms
64 bytes from 192.168.1.1: icmp_seq=34 ttl=63 time=2.02 ms
64 bytes from 192.168.1.1: icmp_seq=35 ttl=63 time=2.11 ms
64 bytes from 192.168.1.1: icmp_seq=36 ttl=63 time=1.96 ms
64 bytes from 192.168.1.1: icmp_seq=37 ttl=63 time=1.98 ms
64 bytes from 192.168.1.1: icmp_seq=38 ttl=63 time=5.08 ms
64 bytes from 192.168.1.1: icmp_seq=39 ttl=63 time=2.19 ms
64 bytes from 192.168.1.1: icmp_seq=40 ttl=63 time=2.19 ms
64 bytes from 192.168.1.1: icmp_seq=41 ttl=63 time=2.05 ms
64 bytes from 192.168.1.1: icmp_seq=42 ttl=63 time=1.96 ms
64 bytes from 192.168.1.1: icmp_seq=43 ttl=63 time=2.61 ms
64 bytes from 192.168.1.1: icmp_seq=44 ttl=63 time=2.19 ms
64 bytes from 192.168.1.1: icmp_seq=45 ttl=63 time=1.95 ms
64 bytes from 192.168.1.1: icmp_seq=46 ttl=63 time=1.96 ms
64 bytes from 192.168.1.1: icmp_seq=47 ttl=63 time=2.03 ms
64 bytes from 192.168.1.1: icmp_seq=48 ttl=63 time=1.95 ms
64 bytes from 192.168.1.1: icmp_seq=49 ttl=63 time=2.02 ms
64 bytes from 192.168.1.1: icmp_seq=50 ttl=63 time=1.95 ms

— 192.168.1.1 ping statistics —
50 packets transmitted, 50 received, 0% packet loss, time 49196ms
rtt min/avg/max/mdev = 1.924/2.129/5.080/0.479 ms[/code]
et je suis sur à 200% que la config est exactement la même que celle d’avant !!!

Histoire de, j’ai tenté de pinguer la Box depuis mon netbook et, là aussi à ma grande surprise, les résultats sont comme qui dirait arch’ment plus mieux :

[code]PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=1.49 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=1.34 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=1.53 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=1.35 ms
64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=1.44 ms
64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=1.58 ms
64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=1.34 ms
64 bytes from 192.168.1.1: icmp_req=8 ttl=64 time=1.32 ms
64 bytes from 192.168.1.1: icmp_req=9 ttl=64 time=1.33 ms
64 bytes from 192.168.1.1: icmp_req=10 ttl=64 time=1.36 ms
64 bytes from 192.168.1.1: icmp_req=11 ttl=64 time=1.31 ms
64 bytes from 192.168.1.1: icmp_req=12 ttl=64 time=1.33 ms
64 bytes from 192.168.1.1: icmp_req=13 ttl=64 time=1.33 ms
64 bytes from 192.168.1.1: icmp_req=14 ttl=64 time=1.35 ms
64 bytes from 192.168.1.1: icmp_req=15 ttl=64 time=1.87 ms
64 bytes from 192.168.1.1: icmp_req=16 ttl=64 time=1.35 ms
64 bytes from 192.168.1.1: icmp_req=17 ttl=64 time=1.34 ms
64 bytes from 192.168.1.1: icmp_req=18 ttl=64 time=1.33 ms
64 bytes from 192.168.1.1: icmp_req=19 ttl=64 time=1.34 ms
64 bytes from 192.168.1.1: icmp_req=20 ttl=64 time=1.34 ms
64 bytes from 192.168.1.1: icmp_req=21 ttl=64 time=1.38 ms
64 bytes from 192.168.1.1: icmp_req=22 ttl=64 time=1.34 ms
64 bytes from 192.168.1.1: icmp_req=23 ttl=64 time=1.50 ms
64 bytes from 192.168.1.1: icmp_req=24 ttl=64 time=1.39 ms
64 bytes from 192.168.1.1: icmp_req=25 ttl=64 time=1.36 ms
64 bytes from 192.168.1.1: icmp_req=26 ttl=64 time=1.57 ms
64 bytes from 192.168.1.1: icmp_req=27 ttl=64 time=1.39 ms
64 bytes from 192.168.1.1: icmp_req=28 ttl=64 time=1.37 ms
64 bytes from 192.168.1.1: icmp_req=29 ttl=64 time=1.53 ms
64 bytes from 192.168.1.1: icmp_req=30 ttl=64 time=3.12 ms
64 bytes from 192.168.1.1: icmp_req=31 ttl=64 time=1.34 ms
64 bytes from 192.168.1.1: icmp_req=32 ttl=64 time=1.34 ms
64 bytes from 192.168.1.1: icmp_req=33 ttl=64 time=1.55 ms
64 bytes from 192.168.1.1: icmp_req=34 ttl=64 time=1.39 ms
64 bytes from 192.168.1.1: icmp_req=35 ttl=64 time=1.35 ms
64 bytes from 192.168.1.1: icmp_req=36 ttl=64 time=1.40 ms
64 bytes from 192.168.1.1: icmp_req=37 ttl=64 time=1.38 ms
64 bytes from 192.168.1.1: icmp_req=38 ttl=64 time=1.32 ms
64 bytes from 192.168.1.1: icmp_req=39 ttl=64 time=1.54 ms
64 bytes from 192.168.1.1: icmp_req=40 ttl=64 time=1.32 ms
64 bytes from 192.168.1.1: icmp_req=41 ttl=64 time=1.33 ms
64 bytes from 192.168.1.1: icmp_req=42 ttl=64 time=1.32 ms
64 bytes from 192.168.1.1: icmp_req=43 ttl=64 time=1.35 ms
64 bytes from 192.168.1.1: icmp_req=44 ttl=64 time=1.33 ms
64 bytes from 192.168.1.1: icmp_req=45 ttl=64 time=1.34 ms
64 bytes from 192.168.1.1: icmp_req=46 ttl=64 time=1.55 ms
64 bytes from 192.168.1.1: icmp_req=47 ttl=64 time=1.36 ms
64 bytes from 192.168.1.1: icmp_req=48 ttl=64 time=1.32 ms
64 bytes from 192.168.1.1: icmp_req=49 ttl=64 time=1.38 ms
64 bytes from 192.168.1.1: icmp_req=50 ttl=64 time=1.40 ms

— 192.168.1.1 ping statistics —
50 packets transmitted, 50 received, 0% packet loss, time 49076ms
rtt min/avg/max/mdev = 1.312/1.434/3.127/0.267 ms[/code]
Bon tout ça c’est génial, car j’ai semble t-il retrouvé la vitesse de surf que j’avais perdu mais j’ai quand même plusieurs questions auxquelles je n’arrive pas à trouver de réponse :

[ul]1°) pourquoi avec XP (désolé fran.b, du coup j’ai pas pu faire le test de ping !) je n’avais pas de ralentissement ? (et c’était loin d’être subjectif comme ralentissements ! Le test que je faisais à chaque fois était : Page d’accueil de Google, puis Actualités puis clic sur l’une ou l’autre des brèves : avec XP, c’était toujours quasi instantané, avec Debian ça pouvait mettre jusqu’à 40s !!! Si, si !)

2°) pourquoi, si le souci vient bien du routeur, il y avait perturbation (voir perte) des ping que je faisais à partir du netbook directement relié à la Box ?
Je suis quand même passé de 18.729ms en moyenne (avec 4% de perte !) à 1,434ms (et 0% de perte) !!![/ul]

i_M · Février 20, 2016, 11:18pm

Hello.

Pour désactiver l’ipv6 :

#touch /etc/modprobe.d/blacklist.perso.conf #echo "blacklist ipv6" > /etc/modprobe.d/blacklist.perso.conf

Puis dans /etc/dhcp3/dhclient.conf remplacer la ligne supersede domain-name par:

#OpenDNS supersede domain-name 208.67.222.222 208.67.220.220;

Et reboot.

J’avais ce souci avec une livebox et c’est comme ça que je l’ai réglé.

@+…

fran.b · Février 20, 2016, 11:18pm

Hum, il faudrait voir si il y a des conflits de réseau pour la deuxième questions (Ips du routeurs, etc). Pour la première question, il suffit que XP renvoit les paquets plus vite ou au contraire soit plus patient pour que ça change le comportement (si XP renvoit le paquet après un timeout de 1s, ça change d’un timeout de 60s)

M@N: ça a été évoqué (y compris la livebox) mais ça n’est pas ce pbm.

i_M · Février 20, 2016, 11:18pm

reuh …

@fran.b : j’ai bien lu le fil et j’ai pas l’impression qu’il aie essayé ça exactement…

@+…

Eric75 · Février 20, 2016, 11:18pm

[quote=“fran.b”]Pour la première question, il suffit que XP renvoit les paquets plus vite ou au contraire soit plus patient pour que ça change le comportement (si XP renvoit le paquet après un timeout de 1s, ça change d’un timeout de 60s)[/quote]Comment je peux voir ça, stp ?

Pour info, voici le résultat d’un ping sur XP :

[code]Envoi d’une requête ‘ping’ sur 192.168.1.1 avec 32 octets de données :

Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=1 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=1 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=1 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=1 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=1 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=1 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=1 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=1 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=1 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=1 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=1 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=1 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=1 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=1 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=1 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63
Réponse de 192.168.1.1 : octets=32 temps=2 ms TTL=63

Statistiques Ping pour 192.168.1.1:
Paquets : envoyés = 50, reçus = 50, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 1ms, Maximum = 2ms, Moyenne = 1ms
[/code]

Surf (très lent) sur lenny != XP (rapide) : pb config DNS ?

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

The loopback network interface

The primary network interface

[code]=========================================================================== Liste d’Interfaces 0x1 … MS TCP Loopback interface 0x2 …00 e0 18 XX XX XX … NVIDIA nForce Networking Controller - Miniport d’ordonnancement de paquets

[code]===========================================================================
Liste d’Interfaces
0x1 … MS TCP Loopback interface
0x2 …00 e0 18 XX XX XX … NVIDIA nForce Networking Controller - Miniport d’ordonnancement de paquets