Forum Linux.général IPv6 + https + Wikipédia = Mystère!

Posté par (page perso) . Licence CC by-sa
Tags :
3
14
fév.
2016

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…

  • # Localisation du problème

    Posté par (page perso) . Évalué à 1.

    Je l'annonce de suite, je n'ai pas la réponse à ta question.

    Ce qui est rigolo (si je puis dire), c'est que c'est sensible au routeur, mais pas aux interfaces réseaux. On a donc envie de penser que le problème se situe au niveau du routeur.

    Mais ! (car il y a un mais), le fait que cela fonctionne pour certaine VM et pas pour d'autre fait penser à un problème de configuration au niveau de la machine.

    Bref, on est un peu perdu. Mais j'ai une piste pour essayer de comprendre où cela coince. Quand tu utilises Wireshark, tu l'utilises où ? Sur la machine hôte ou sur la machine invitée ?

    Dans mon idée, il faudrait que ce soit sur la machine hôte. Ainsi, en faisant des tests, tu pourras déterminer si la réponse à la requête "Hello" arrive ou non jusqu'à la machine hôte. Si la machine invitée ne la reçoit pas, c'est que le problème se situe plutôt côté machine invitée. Dans le cas contraire (la machine hôte ne reçoit pas la réponse), il faudrait vérifier que les requêtes sont bien identiques entre une VM ok et une VM ko pour accuser le modem. Il restera ensuite à diagnostiquer exactement le problème, mais il sera plus ou moins localisé.

    • [^] # Re: Localisation du problème

      Posté par (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.