Je fais face à un problème bien mystérieux: au démarrage de ma machine, je dois attendre 2-3 minutes avant de pouvoir accéder à Wikipédia (et tous les sites de la fondation) en IPv6 et https. Et après ce délai, hop c'est dispo.
Ma configuration se présente de la manière suivante: j'ai un (tristement célèbre) modem-routeur Thomson TG784n relié à de l'ADSL OVH. Il fait du NAT, du DHCP, supporte l'IPv6 et le wi-fi. Mon ordi a de l'ethernet et du wi-fi (même problème!).
Ma distribution est une Kubuntu 15.10, 64 bits, noyau 4.2.0-27-generic.
Juste après mon login, si je fais un « curl -6 -v 'https://fr.wikipedia.org/wiki/' » et que je sniffe avec Wireshark, je vois:
- Un paquet SYN et son paquet SYN-ACK qui revient.
- Un « Hello » client qui part.
- Et après plus aucun paquet reçu.
J'ai testé avec « wget » et « gnutls-cli » (un équivalent à « openssl s_client ») avec les même résultats.
Si j'attends quelques minutes pour un nouvelle essai, le « Hello » client reçoit une réponse « Hello » serveur.
J'ai testé avec différentes configurations:
- mon téléphone Android (un noyau 3.…), pas de problème.
- des VM 64 bits sur ce même ordi avec VirtualBox:
-- Fedora server 23: ko (c'est quand même plus pratique de rebooter une VM).
-- Ubuntu server 15.10: ok.
-- Ubuntu desktop 15.10: ko.
-- Ubuntu desktop 14.04 en live DVD: ok.
-- Ubuntu desktop 15.10 en live DVD: ko.
- un laptop avec Kubuntu 15.10: ko.
Arrêter et redémarrer les interfaces réseau de ma machine ne change rien. Par contre, arrêter et redémarrer la connexion Internet depuis l'interface web du routeur résout le problème (que ce soit avec mon ordi, les VM ou le laptop).
Pourquoi le problème n'apparaît-il qu'avec certaines distributions, pourquoi le résultat est différent avec des distribs proches et quel peut être le rapport avec la réinitialisation de la connexion ADSL?
Ça ne m'empêchera pas de vivre, mais j'aimerais bien comprendre. Si vous avez des idées de trucs à tester…
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Localisation du problème
Posté par Fabimaru (site web personnel) . Évalué à 2.
J'ai effectivement fait tourner Wireshark sur la machine hôte, et je vois bien passer les paquets de la machine invitée. Je vois bien partir dans tous les cas les « hello client» (enfin, selon Wireshark).
J'ai pensé à comparer les flux dans les trois cas:
* La requête échoue car elle est faite dans les premières minutes.
* La requête réussit car elle est faite après ce délai.
* La requête réussit car elle est faite sur une distrib non problématique.
Je ne l'ai pas encore fait car c'est un peu chiant. Je crois que c'est la prochaine étape: exporter les dumps Wireshark en texte, virer tout ce qui n'est pas intéressant (comme les timestamps) et comparer avec "meld".
Je pourrais aussi essayer de trouver d'autres sites HTTPS qui posent problème (avec Duckduckgo pas de problème par exemple).
[^] # Re: Localisation du problème
Posté par Fabimaru (site web personnel) . Évalué à 2.
Ça avance:
* J'avais mal regardé Wireshark. Sur ma VM Ubuntu Desktop je reçois bien une réponse au « Client Hello », mais le paquet est analysé comme « ETHERNET FRAME CHECK SEQUENCE INCORRECT », et le numéro de séquence TCP est incorrect.
* Pour Fedora Server, Wireshark voit plusieurs paquets en double.
J'ai de quoi analyser pour le moment. Je vous tiens au courant si j'ai une découverte intéressante à partager.
[^] # Re: Localisation du problème
Posté par Fabimaru (site web personnel) . Évalué à 2.
En diminuant le MTU de 1500 à 1400, plus de problème (à la fois au niveau Ethernet ou TCP).
En comparant le contenu des paquets, j'ai vu, outre les numéros de séquence TCP invalides, que ces champs étaient différents entre un essai réussi et échoué: dans ce dernier cas, la "window size" initiale était plus grande avant de diminuer, tout comme le "maximum segment size" (1440, diminuant en dessous de 1400).
Reste plus qu'à comprendre quelle est la raison exacte.
[^] # Re: Localisation du problème
Posté par Fabimaru (site web personnel) . Évalué à 2.
J'ai finalement trouvé la valeur magique de MTU maximale à partir de laquelle mes requêtes réussissent: 1462. Je n'ai aucune idée de la raison (ce qui est dommage).
J'ai aussi remarqué (dans ma grande méconnaissance réseau) qu'à l'arrêt et au démarrage de la connexion ADSL, le routeur envoie un message ICMPv6 « Router Advertisement » contenant une MTU recommandée (1456). Donc je suppose que ma machine/VM doit en tenir compte d'une manière ou d'une autre (la MTU affichée reste la même, par contre le "maximum segment size" sera lui plus bas lors d'une connexion qui suit).
D'autre part, quand la machine démarre, elle envoie un « Router Solicitation » auquel le routeur répondra par un « Router Advertisement ».
Je crois que je vais arrêter mes investigations ici (ah si j'avais le temps, j'essaierais d'étudier en détails ce qu'il se passe sous le capot!).
[^] # Re: Localisation du problème
Posté par ketchupenz . Évalué à 0.
J'ai déjà eu des problèmes de MTU mais avec du NFS…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.