Ben juste pour dire que je suis en SID amd64 avec une LiveBox Pro Inventel et que tout fonctionne parfaitement 
Merci de ton aide PascalHambourg, problème [Résolu], ici en tout cas…
raf@compaq:~$ telnet google.fr 80
Trying 72.14.221.104...
Connected to google.fr.
Escape character is '^]'.
Connection closed by foreign host.
raf@compaq:~$ telnet -4 google.fr 80
Trying 72.14.221.104...
Connected to google.fr.
Escape character is '^]'.
Connection closed by foreign host.J’ai mis le parametre que tu m’as cité à 1 mais aucune amélioration par contre en mettant le network.dns.disableIPv6 à true c’est déjà beaucoup mieux. L’affichage est encore un chouïa plus lent qu’avec XP mais ça c’est sans doute dû à firefox Windows qui est mieux otpimisé mais en tout cas les pages s’affichent rapidement, comme avant.
Je redémarre de suite pour voir si pidgin se connecte à nouveau correctement au chargement de X, car il mettait plusieurs dizaines de secondes à se connecter avec ce problème…
tc
Pour répondre à ta question, en effet XP n’avait pas le support IPv6.
Et voilà quelques lignes de tcpdump :
10:47:45.552970 IP compaq.52665 > 192.246.40.185.1971: . ack 241664 win 65535
10:47:45.718761 IP 192.246.40.185.1971 > compaq.52665: . 241664:243116(1452) ack 1 win 64240
10:47:45.720458 IP 192.246.40.185.1971 > compaq.52665: . 243116:244568(1452) ack 1 win 64240
10:47:45.720540 IP compaq.52665 > 192.246.40.185.1971: . ack 244568 win 65535
10:47:45.721426 IP 192.246.40.185.1971 > compaq.52665: P 244568:245760(1192) ack 1 win 64240
10:47:45.721489 IP compaq.52665 > 192.246.40.185.1971: . ack 245760 win 65535
10:47:45.887513 IP 192.246.40.185.1971 > compaq.52665: . 245760:247212(1452) ack 1 win 64240
10:47:45.888988 IP 192.246.40.185.1971 > compaq.52665: . 247212:248664(1452) ack 1 win 64240
10:47:45.890170 IP 192.246.40.185.1971 > compaq.52665: P 248664:249856(1192) ack 1 win 64240
10:47:45.891502 IP compaq.52665 > 192.246.40.185.1971: . ack 249856 win 65535
10:47:46.057780 IP 192.246.40.185.1971 > compaq.52665: . 249856:251308(1452) ack 1 win 64240
10:47:46.059474 IP 192.246.40.185.1971 > compaq.52665: . 251308:252760(1452) ack 1 win 64240
10:47:46.059532 IP compaq.52665 > 192.246.40.185.1971: . ack 252760 win 65535
10:47:46.060443 IP 192.246.40.185.1971 > compaq.52665: P 252760:253952(1192) ack 1 win 64240
10:47:46.060514 IP compaq.52665 > 192.246.40.185.1971: . ack 253952 win 65535
10:47:46.185371 IP compaq.60344 > 207.46.111.84.msnp: P 1339306106:1339306111(5) ack 2279548327 win 25392
10:47:46.185709 IP compaq.37699 > HSIB.home.domain: 2312+ PTR? 84.111.46.207.in-addr.arpa. (44)
10:47:46.227021 IP 192.246.40.185.1971 > compaq.52665: . 253952:255404(1452) ack 1 win 64240
10:47:46.228502 IP 192.246.40.185.1971 > compaq.52665: . 255404:256856(1452) ack 1 win 64240
10:47:46.228552 IP compaq.52665 > 192.246.40.185.1971: . ack 256856 win 65535
10:47:46.229683 IP 192.246.40.185.1971 > compaq.52665: P 256856:258048(1192) ack 1 win 64240
10:47:46.229721 IP compaq.52665 > 192.246.40.185.1971: . ack 258048 win 65535
10:47:46.395784 IP 192.246.40.185.1971 > compaq.52665: . 258048:259500(1452) ack 1 win 64240
10:47:46.397035 IP 192.246.40.185.1971 > compaq.52665: . 259500:260952(1452) ack 1 win 64240
10:47:46.397138 IP compaq.52665 > 192.246.40.185.1971: . ack 260952 win 65535
10:47:46.398220 IP 192.246.40.185.1971 > compaq.52665: P 260952:262144(1192) ack 1 win 64240
Merci encore 
Que c’est bon d’avoir à nouveau un net rapide
[quote=“Ralfman68”]
raf@compaq:~$ telnet google.fr 80[/quote]
C’est gentil mais, euh, les copies d’écran ne montrent pas les délais de connexion qui sont l’information pertinente ici. A savoir le délai entre la saisie des commandes et l’affichage de “Connected to xxx”.
Oui, pardon, c’était une erreur de copier/coller de ma part. Je corrige mon message précédent de ce pas.
Et dire qu’il y en a qui réinstallent pour si peu…
Je ne connais pas pidgin, mais s’il est indépendant de Firefox il aura toujours le même problème. Le réglage ci-dessus n’affecte que Firefox.
Ça te dit de l’activer pour tester s’il y a les mêmes problèmes ? Il suffit d’entrer la commande suivante
Il n’y a pas ce que je cherche. Il faudrait restreindre aux paquets DNS, et le lancer juste avant d’exécuter la commande “host -v google.fr”.
[quote=“Ralfman68”]Merci encore
Que c’est bon d’avoir à nouveau un net rapide [/quote]
De rien, mais cette solution n’est qu’un pis-aller. Le réglage n’affecte que la navigation web avec Firefox, pas les autres navigateurs et programmes communicants supportant l’IPv6 par défaut.
[EDIT] Un “solution” plus globale serait peut-être de désactiver l’IPv6 sur la machine, en empêchant le chargement du module ipv6. Mais encore une fois ce n’est qu’un contournement qui n’est acceptable que si on n’utilise pas IPv6.
La source du problème est dans la Livebox ou dans les DNS d’Orange. Donc il faut râler auprès du support technique d’Orange.
Tu peux éventuellement tester si le bug vient de la partie DNS ou d’un filtrage intempestif par le pare-feu de la box en interrogeant un autre DNS qui répond aux requêtes d’enregistrements IPv6 :
(192.134.0.49 est un des serveurs DNS faisant autorité pour la zone ripe.net)
Si tu obtiens une réponse (peu importe le résultat), le problème est dans la partie DNS et pas dans le pare-feu. Dans ce cas, tu peux éventuellement utiliser d’autres DNS que celui de la box, par exemple ceux d’Orange directement (ils doivent figurer dans l’interface de gestion de la box). Si le problème disparaît, alors il vient du relais DNS de la box. Sinon, il y a des chances qu’il vienne des DNS d’Orange.
Désolé si je réponds un peu à coté je suis une bille niveau réseau.
Il y a un délai d’une vingtaine de secondes avant de voir le message “connected to XXX”.
Pidgin est la nouvelle version de Gaim, un client de messagerie instantanée pour Gnome.
Pour le tcdump :
raf@compaq:~$ su
Mot de passe :
compaq:/home/raf# tcpdump -ntvi eth0 port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
IP (tos 0x0, ttl 64, id 14630, offset 0, flags [DF], proto UDP (17), length 64) 192.168.1.2.35852 > 192.168.1.1.53: 29708+ AAAA? nexus.passport.com. (36)
IP (tos 0x0, ttl 64, id 14631, offset 0, flags [DF], proto UDP (17), length 64) 192.168.1.2.35852 > 192.168.1.1.53: 29708+ AAAA? nexus.passport.com. (36)
IP (tos 0x0, ttl 64, id 8585, offset 0, flags [DF], proto UDP (17), length 64) 192.168.1.1.53 > 192.168.1.2.33701: 8847 ServFail- 0/0/0 (36)
IP (tos 0x0, ttl 64, id 8586, offset 0, flags [DF], proto UDP (17), length 64) 192.168.1.1.53 > 192.168.1.2.33701: 8847 ServFail- 0/0/0 (36)
IP (tos 0x0, ttl 64, id 17338, offset 0, flags [DF], proto UDP (17), length 67) 192.168.1.2.43087 > 192.168.1.1.53: 44627+ A? loginnet.passport.com. (39)
IP (tos 0x0, ttl 64, id 17338, offset 0, flags [DF], proto UDP (17), length 67) 192.168.1.2.51734 > 192.168.1.1.53: 36230+ AAAA? loginnet.passport.com. (39)
IP (tos 0x0, ttl 64, id 8587, offset 0, flags [DF], proto UDP (17), length 83) 1
puis [code]compaq:/home/raf# host -v google.fr
Trying “google.fr”
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26643
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;google.fr. IN A
;; ANSWER SECTION:
google.fr. 1365 IN A 66.249.93.104
google.fr. 1365 IN A 216.239.59.104
google.fr. 1365 IN A 72.14.221.104
Received 75 bytes from 192.168.1.1#53 in 89 ms
Trying “google.fr”
;; connection timed out; no servers could be reached
Trying “google.fr”
;; connection timed out; no servers could be reached
[/code]
et
compaq:/home/raf# host -vt aaaa google.fr
Trying "google.fr"
;; connection timed out; no servers could be reached
compaq:/home/raf#
J’espere avoir fait ça correctement.
Puis pour les dns :
compaq:/home/raf# host -vt aaaa www.ripe.net 192.134.0.49
Trying "www.ripe.net"
Using domain server:
Name: 192.134.0.49
Address: 192.134.0.49#53
Aliases:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29833
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 8
;; QUESTION SECTION:
;www.ripe.net. IN AAAA
;; ANSWER SECTION:
www.ripe.net. 900 IN CNAME aquila-www.ripe.net.
aquila-www.ripe.net. 600 IN AAAA 2001:610:240:11::c100:1319
;; AUTHORITY SECTION:
ripe.net. 172800 IN NS ns3.nic.fr.
ripe.net. 172800 IN NS sunic.sunet.se.
ripe.net. 172800 IN NS ns-ext.isc.org.
ripe.net. 172800 IN NS ns-pri.ripe.net.
;; ADDITIONAL SECTION:
ns3.nic.fr. 172800 IN A 192.134.0.49
ns3.nic.fr. 172800 IN AAAA 2001:660:3006:1::1:1
sunic.sunet.se. 54026 IN A 192.36.125.2
sunic.sunet.se. 54026 IN AAAA 2001:6b0:7::2
ns-ext.isc.org. 128 IN A 204.152.184.64
ns-ext.isc.org. 2609 IN AAAA 2001:4f8:0:2::13
ns-pri.ripe.net. 172800 IN A 193.0.0.195
ns-pri.ripe.net. 172800 IN AAAA 2001:610:240:0:53::3
Received 360 bytes from 192.134.0.49#53 in 48 msJe redémarre sur XP et je teste IPv6 install
En effet, après avoir installé ipv6 sur XP je rencontre le même soucis.
Je vais donc installer d’autres dns dans l’interface mais, au risque de paraitre lourd,où est-ce que je choppe les adresses s’il te plait ?
Et avec l’option -4 ?
[quote=“Ralfman68”]Pour le tcdump : […]
J’espere avoir fait ça correctement.[/quote]
Pas tout-à-fait, mais on va améliorer ça. Cette capture ne contient aucun trafic DNS relatif à la commande “host google.fr”, je ne vois que des requêtes dans un domaine qui semble lié à MSN Messenger, donc à pidgin je suppose. D’autre part je ne veux pas la commande “host -t aaaa…”.
Le plus simple est de lancer tcpdump et host dans deux consoles séparées :
- lancer tcpdump dans la première console
- exécuter la commande host dans la seconde
- arrêter tcpdump
Sinon, faire tourner tcpdump en tâche de fond pendant l’exécution de host :
[code]tcpdump -nvi eth0 port 53 & # pour execution en tache de fond
host google.fr
fg 1 # pour faire revenir tcpdump au premier plan
ctrl+c pour l’arreter
[/code]
Et pendant le test, arrêter les programmes générant du trafic DNS, notamment pidgin.
[quote=“Ralfman68”]Puis pour les dns :
compaq:/home/raf# host -vt aaaa www.ripe.net 192.134.0.49
[...]
Received 360 bytes from 192.134.0.49#53 in 48 ms
[/quote]
Un point positif, pas de filtrage dans la box. Tu peux essayer de remplacer l’adresse de la box (192.168.1.1) dans /etc/resolv.conf par celle d’un des DNS d’Orange (que je ne connais pas. Ça doit se trouver dans l’interface de gestion de la box, que je ne connais pas non plus car je n’ai pas de Livebox. [EDIT] Mon paternel en a une chez lui mais c’est une Inventel donc pas forcément la même interface, et il n’y connaît rien en réseau, donc je ne me sens pas de le faire chercher au téléphone).
Euh, j’ai suggéré ça un peu en plaisantant. Si tu n’utilises pas IPv6, ça n’apportera que des ennuis.
[EDIT] Trop tard, je viens de voir ton message…
Et quelle serait l’explication du fait que le problème n’existe pas sous ubuntu 8.04? J’avoue que tout ça m’intrigue fortement. Je ne pense pas que d’appeler le 3900 apportera la moindre explication sinon une crise de nerf et un défilé du 1er mai foiré; alors je n’essaie même pas. Voir le fil Debian? cékoissa??
Ne connaissant pas Ubuntu, je ne peux que formuler des hypothèses.
- Le navigateur web ne supporte pas IPv6 ou a IPv6 désactivé.
- La prise en charge d’IPv6 dans le noyau n’est pas activée par défaut, à vérifier par exemple avec ifconfig. Dans ce cas il me semble que le resolver DNS de la glibc ne fait pas de requêtes de type AAAA (adresse IPv6).
- Le resolver DNS de la glibc se comporte différemment, et ne fait pas de requêtes de type AAAA si la machine n’a pas au moins une adresse IPv6 globale, ce qui indique qu’elle n’a pas de connectivité IPv6 globale et donc que la résolution en adresse IPv6 n’apporterait rien puisqu’une telle adresse serait de toute façon injoignable. Il me semble avoir lu des discussions à ce sujet car c’est un problème récurrent : le serveur DNS de la Livebox n’est pas le premier à foirer avec les requêtes AAAA, et comme les OS ayant IPv6 activé sont de plus en plus courants (y compris chez Microsoft), ça se voit de plus en plus. C’est peut-être une version plus récente de la glibc qui implémente ce fonctionnement.
Et je maintiens que le bug étant chez Orange ou dans la Livebox Sagem (le plus probable étant donné la coïncidence avec l’arrivée d’un nouveau firmware), il faut contacter le support qui fasse remonter l’info aux personnes compétentes afin de remédier au problème. Le tout est de trouver le bon interlocuteur, car effectivement je crains qu’il n’y ait pas grand chose à attendre de la hotline de premier niveau. Mon espoir est que les utilisateurs de Vista rencontrent aussi le problème, Vista ayant IPv6 activé par défaut.
Merci de toutes tes précisions. En fait, si Hardy n’était pas sortie la semaine passée, je n’aurais pas testé et j’en serais toujours à penser que ma ligne téléphonique merdait en dépit des dires de la hotline (ça m’est déjà arrivé). Tu sais, dans mon quartier les lignes téléphoniques se baladent au milieu des branches et feuillages d’arbres.
Faut pas exagérer non plus ; comment une ligne téléphonique aussi foireuse soit-elle pourrait-elle affecter spécifiquement les résolutions DNS ?
Mais au départ, je n’avais que deux debian et n’avait aucune idée d’où venait le problème. Je ne savais même pas que ma Livebox avait eu une mise-à-jour.
Ça doit venir de moi qui suis venu à GNU/Linux par et pour le réseau, j’ai toujours du mal à concevoir que des linuxiens n’aient pas un minimum de culture des mécanismes de base d’internet.
[quote=“PascalHambourg”]
Ça doit venir de moi qui suis venu à GNU/Linux par et pour le réseau, j’ai toujours du mal à concevoir que des linuxiens n’aient pas un minimum de culture des mécanismes de base d’internet.[/quote]
Tu fais exprès ou quoi? Ta connexion internet devient lente sans aucune raison, sans aucun nouveau paramétrage et sans savoir si tu as un problème de ligne téléphonique tu vas directement fouiller dans les DNS ou autres trucs de la sorte?
Viens habiter à la campagne sous les tropiques et quand tu auras un problème d’adsl tu verras si la première chose à faire c’est de se précipiter sur les DNS ou plutôt de vérifier si il n’y a pas de problème de ligne. Et en saison des pluies, je ne t’en parle même pas.
Dernièrement, c’était le concentrateur de France Télécom de mon coin qui avait sauté. Et bien le numéro d’appel pour la ligne ne voulait rien entendre car mon téléphone fonctionnait et la hotline me disait que mon adsl fonctionnait. Ce n’est qu’en discutant avec d’autres personnes des environs que le problème s’est réglé.
Oui, parce que les symptômes orientent dans cette direction, mais encore faut-il savoir les interpréter. Ce n’est pas toute la connexion qui devient lente mais seulement l’accès initial à un site, donc je pense immédiatement à la résolution DNS. Si la ligne était en cause, les symptômes seraient différents.
[quote=“PascalHambourg”]
Ça doit venir de moi qui suis venu à GNU/Linux par et pour le réseau, j’ai toujours du mal à concevoir que des linuxiens n’aient pas un minimum de culture des mécanismes de base d’internet.[/quote]Pauvre PascalHambourg, et la liberté!!!, et les logiciels libres ??? Ce n’est pas la technique qui est intéressant dans GNU/linux mais l’idée de liberté, la technique ne vient qu’après.
Sous ubuntu ifconf me renvoit:
[quote]eth0 Link encap:Ethernet HWaddr 00:1d:09:0e:a7:53
inet adr:192.168.1.10 Bcast:192.168.1.255 Masque:255.255.255.0
adr inet6: fe80::21d:9ff:fe0e:a753/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:15646 erreurs:0 :0 overruns:0 frame:0
TX packets:16003 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:15674151 (14.9 MB) Octets transmis:2186971 (2.0 MB)
Interruption:16
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
Packets reçus:2178 erreurs:0 :0 overruns:0 frame:0
TX packets:2178 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:108900 (106.3 KB) Octets transmis:108900 (106.3 KB)
[/quote]
Je ne sais pas interpréter, je n’ai pas mon permis réseaux.
Au passage, j’ai essayé network.dns.disableIPv6 à true dans about:conf de Iceweasel de ma etch live cd et effectivement, ça baigne pour la navigation.
Sous mes Ubuntu ce n’est pas désactivé dans mes navigateurs. Je voulais vérifier avec une live OpenSuse, mais j’ai oublié ma clé USB.
La présence d’adresses inet6 rapportée par ifconfig indique que la prise en charge d’IPv6 dans le noyau est activée. Il est peu probable que les navigateurs soient compilés sans support d’IPv6. Je ne vois plus que la piste du resolver de la glibc. J’ai trouvé un billet qui parle du patch que j’évoquais : <http://andrew.mcmillan.net.nz/node/78>.
Le patch a été rejeté par Debian à cause d’effets de bords, mais qui sait, il a peut-être été accepté par Ubuntu. Je pense qu’un moyen de tester serait d’affecter une adresse IPv6 globale bidon à la machine sous Ubuntu pour voir si cela cause à nouveau une lenteur de résolution DNS.
[code]ifconfig eth0 inet6 add 3ffe::/64 # pour ajouter l’adresse a eth0
relancer le navigateur avant de tester, ou tester en ligne de commande avec telnet ou nc6 par exemple
ifconfig eth0 inet6 del 3ffe::/64 # pour supprimer l’adresse[/code]
Salut à tous,
Je viens de lire tous les messages depuis le début, si si, je vous assure. Tout ça pour dire merci d’avoir ouvert le sujet. Car, je confirme, il y a bien eu une mise à jour du firmware des livebox Sagem et je rencontre exactement les mêmes problèmes que vous, à savoir lenteur d’accès Internet sur Debian et pas sur Windows. Peut-être que je me trompe mais je crois également que le chiffrement du wifi à changé et on est passé en WPA TKIP, je pense que ce n’était pas le cas avant.
En tout cas, je vais avoir besoin de relire les messages une deuxième fois notament pour la config du navigateur et voir si ça change quelque chose. Il est vrai que c’est une solution provisoire et qu’il faudrait faire remonter l’information à Orange. J’avoue que je ne m’en sens pas le courage vu le nombre d’heures que j’ai passé au téléphone avec mon précédent FAI : Free. Alors s’il faut recommencer avec Orange…
Et puis petite remarque lors de l’échange entre vous que je trouve très intéressante et qui concerne le fait que nous n’habitons pas tous dans les mêmes contrés, Junichirô va regarder si il n’y a pas un problème technique sur la ligne alors que PascalHambourg va bidouiller les DNS. Je sais pas si vous l’avez déjà remarqué mais bien souvent les différences géographiques influencent nos comportements / habitudes. Enfin, je trouve que ça nous apprend que pour se comprendre, il faut être tolérant.
Enfin, bref, pour revenir à notre problème de départ. Je confirme encore une fois (c’est rassurant) qu’il y a un schmilblick avec les livebox Sagem et Debian.
Bon, ben je m’y attèle et puis je vais essayer d’activer le wifi sur mon pc portable (un vrai casse tête) et puis peut-être même recompiler. Un vrai 1er mai quoi!!
Bonne journée à tous, travaillez pas trop
Bye
Re bonjour,
network.dns.disableIPv6 avec la valeur true dans about:config de Iceweasel, c’est la bonne solution. J’ai retrouvé toutes les perfs de la navigation.
Un grand merci 
@+
Confirme: même problème sous OpenSuse 10.3. Mais là, je pense qu’on peut régler le problème en désactvant ipv6 lors de l’installation; l’installateur le demande.