Journal La fibre orange hoquette ... ou comment devenir fou.

Posté par  . Licence CC By‑SA.
33
19
juin
2022

Sommaire

Cher Journal,

Le Décor

En ces temps post-covid (quoique …), je télétravail beaucoup. Depuis maintenant 8 ans j'ai la fibre chez Orange (à l'époque, j'avais pas le choix, et ça marchait jusqu'à maintenant). Et y a pas à dire, c'est confortable.

Mais voila, depuis environ fin mai, la fibre hoquette … Latences liées à des retransmissions TCP, sur les DNS, sur les long polling, sur le VPN de la boite … Un vrai cauchemar.

Alors, avec la guerre en Ukraine et son lots de cyberattaques, je me suis dit (bêtement) que c'est tout le net qui avait un souci, mais en fait non (ou alors j'ai raté les news).

Au bout d'une semaine difficile, je me suis décidé à appeler le support.

Niveau 0

Un petit tour sur la météo du net, et premiers tests en ligne automatique pour vérifier que tout va bien. C'est le cas … sauf que y a bien un problème.

Niveau 1

Difficile d'expliquer ce ressenti à l'équipe responsable du support du niveau 1, mais j'ai joué le jeu, car c'était aussi ma première idée: problème d'alim de la livebox qui fatigue peut être un peu. Après quelques tests, changement de livebox pour voir si ça améliore les choses. Pas vraiment. Franchement, le suivi de l'incident est «top»: rappels des techniciens pour vérifier que tout va bien (ou pas) … rendez-vous sur les créneaux … bref une bonne surprise, même si au final, retour à la case départ, et passage au niveau 2.

Niveau 2

tâtonnements

Ça se complique un peu. Le technicien parle de mise à jour de la livebox (effectivement y en a quelques unes en ce moment) qui pourrait être à l'origine du problème. Ok pourquoi pas. Il propose un rendez-vous même heure le lendemain, après avoir transmis la requête à l'équipe livebox. Super.

Mais pas de SMS de confirmation du rendez-vous.

Sur la fin du créneau, ne voyant rien venir, je rappelle le support. ticket déjà ouvert, level-up immédiat. Cool.

30mn de tests et échanges plus tard, nouveau verdict: tout va bien, mais on va changer l'ONT au cas ou.

Là je tique, parce que je me souviens de la galère que ça avait été à l'install. Mais la technicienne, me confirme que «c'est plug&play» et me propose un nouveau rendez-vous pour Samedi entre 14 et 15h, sachant que je dois recevoir le nouvel ONT en point relay jeudi ou vendredi, en échangeant le matériel.

Sueurs froides de mon côté car je travaille, et si par malheur ça rate, je perds tout, téléphone et internet …

Bonne surprise, je reçois le nouvel ONT le jeudi midi, A/R à vélo pour pas perdre trop de temps, coupure internet 20mn … cool.

Ah non. ça déraille.

Stress

Du temps de l'adsl, on avait le chenillard pour attendre la synchro de la ligne, et parfois ça durait des jours :). Là, les 3 diodes vertes de l'ONT sont fixes, la livebox clignote de temps en temps, mais elle indique: pas de connexion. Au bout de 20mn, je commence à avoir très peur. Je rappelle le support.

Mauvaise idée. J'ai un rendez-vous de planifié pour Samedi … Merci à bientôt. Je tente différentes approches et au bout du 4e appel, je me dis que mort pour mort, je vais annuler le rendez-vous de samedi, en espérant avoir quelqu'un au bout du fil. Effectivement je passe dans les mains d'un nouveau technicien, ouf.

Après investigation, il me dit que la livebox est coincé entre le mode manuel et le mode automatique et que ça coince aux niveaux des serveurs. Il faut qu'il ouvre un ticket au niveau 3 et que le ticket sera traité sous 24 à 48h … J'ai les cheveux qui se dressent sur la tête. 48h sans le net … Pas de panique me dit le technicien, on peut vous fournir une sim 200Go avec un hotspot wifi pour vous redonner accès au net. Cool, mais comment je me connecte depuis l'extérieur moi ? Ah oui, on peut pas désolé … Et le technicien me dit, dès que j'ai du nouveau, on fixe un nouveau rendez-vous.

Bon, sprint à la boutique orange en vélo, récupération de l'airbox, récupération du net (+-) et bilan: ça fait 2h de taff perdu. Pour rien, car en fait le net s'est rétabli dans mon dos à un moment ou un autre.

Retour à la case départ (car je préfère tout de même utiliser le net via la fibre que via la airbox, qui ne se partage pas vraiment, il faut que je monte un routeur etc, et j'ai vraiment pas le temps).

Et pas de nouveau rendez-vous. Ok tant pis, je rappelle. Mauvaise idée: «Nous avons constaté un grand nombre d'appel de votre part, nous vous proposons qu'un technicien vous rappelle lundi entre 14h et 16h …» Euh non, c'est maintenant que je veux parler, pas dans 4 jours alors que le problème dure depuis déjà 3 semaines … De colère, je raccroche, ras le bol. #coup_de_gueule

Investigations

Bon, je vais faire ce que je fais de mieux: «bidouiller», pour tenter de comprendre d'ou vient le problème.

J'ai fait quelques captures wireshark sur mon PC, qui montrent les retransmissions TCP sur des petits paquets (~199/249 octets, c'est aléatoire mais une fois un paquet en grippe, c'est mort), suivis de RST / SYN au bout de 2 à 3mn.

Depuis le début de mes discussions avec le support, je pense que c'est dans le réseau, mais c'est pas facile à quantifier quand «tout va bien», car le problème est parfois là, parfois pas vraiment là en fonction des heures, mais sans motif très clair.

Je précise que ça fait TOUT planter aléatoirement: les sites web (qui se retrouvent sans les .js ou .css chargés par exemple), sur tous les PCs (en filaire) / tablettes wifi / TV box de la maison (slack, google, teams, gitlab via le VPN de la boite, etc …).

Pour en avoir le cœur net, j'ai sorti le switch avec les conf VLAN et le port mirroring qui vont bien et j'ai fait une capture wireshark entre la livebox et l'ONT. Verdict: les paquets sortent bien de la livebox et sont bien retransmis. C'est pas la livebox qui est coupable.

Mais qui alors?

A votre bon Cœur !

À une époque, je sais que certain dev/techs orange passaient sur le site. Je ne sais pas si c'est toujours le cas, mais si vous avez des idées de ce qui se passe, je vous en serais très reconnaissant. De toute manière le support ne veut plus de moi pour l'instant (alors que le problème de base est toujours là …).

Pour les autres aussi, si vous avez des idées pour surveiller le problème, pour m'aider à trouver ce qui ne marche pas, je suis preneur.

Suis-je le seul à subir ces étrangetés qui me font tourner en bourrique ?

Suis-je prêts à changer de fournisseur? Jusqu'à maintenant j'avais pas de bonnes raisons, surtout que je préfère l'IPv6 d'orange (/56) à celui de Free (/64) (enfin, celui de Free d'il y a 8 ans), Mais là je me pose clairement la question.

On verra si le technicien me rappel effectivement la semaine prochaine, mais j'ai comme un gros doute.

NOTE:
Je passe sous silence un certains nombres d'éléments, car au final ça va faire probablement entre 5 et 6h passé avec le support sur le sujet, donc j'ai fait quelques raccourcis. Je compléterais dans les commentaires si besoin.

NOTE2:
Vous avez vraiment tout lu ? chapeau !

Caeies, vieux fou.

  • # Mode bridge

    Posté par  . Évalué à 7.

    Vous avez vraiment tout lu ? chapeau !

    Oui, car l'accès à Internet à la maison qui marche, ça m'intéresse. Je ne sais pas pourquoi on peut payer un VPS 3€/mois avec un accès Internet complètement sympa, et chez soi, on a de la merde pour 49€/mois. Bref.

    D'après ce que je vois, tu (ah, oui, je tutoie, mais si ça dérange, je peux changer) as l'air de te débrouiller pour router des trucs. Et le grand conseil que j'ai pu glaner, c'est donc d'éviter la Livebox. Elle ne sait pas faire. Il te faut un fournisseur qui accepte le mode bridge sur son modem, et faire soi-même, pour un service qui marche.

    La Livebox, je l'avais mise en mode DMZ, mais dès que je faisais du DHT scraping (quelques centaines de connexions UDP parallèles), elle s'effondrait au bout de 2h.

    C'est vrai que le /56 de Orange IPv6, c'est cool, mais sur les Freebox par exemple, on peut rediriger des /64 sur l'hôte de son choix. Faut le faire une fois manuellement par sous-réseau… C'est clairement pas dans l'idée de l'IPv6, mais disons que pour un réseau personnel, c'est suffisant.

    Mais d'autres fournisseurs ont un mode bridge il me semble…

    En tout cas, merci pour le retour !

    • [^] # Re: Mode bridge

      Posté par  . Évalué à 4.

      sur les Freebox par exemple, on peut rediriger des /64 sur l'hôte de son choix. Faut le faire
      une fois manuellement par sous-réseau…

      Je ne connais pas ipv6, mais l'idée ici est de faire un genre de nat sur réseau privé ipv6 ?

      Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr

      • [^] # Re: Mode bridge

        Posté par  (site web personnel) . Évalué à 10.

        Tu peux spécifier 6 ou 7 "nexthop", par tranche d'IPv6.
        Ton block d'OPv6 est découpé en tranches, et chaque tranche peut alors être directement associé à une machine sur ton réseau local. Une sorte de nat.

        J'ai vite pris un tuto un peu au hasard : https://utux.fr/index.php?article13/free-bridge-ipv6

        Avec "ipv6 nexthop freebox" il y a plein de tutoriels.

        Les Livebox ont toujours eu une mauvaise réputation, et, pendant longtemps certaines plantaient dès qu'elles voyaient passer une requête IPV6 (donc temps de reboot etc.) Problème résolu depuis, certes… mais ça montre le niveau de finition.

        Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

  • # question bête

    Posté par  (Mastodon) . Évalué à 10.

    Tu parles se latences et de lenteurs mais tu ne donnes pas de chiffres.

    Comment c'est quand ça marche bien, et comment c'est quand ça péclote.

    Autre question? As-tu testé avec une seul pc/OS ou as-tu testé avec différents équipememts, et isolés (tous les autres éteints?), via wifi et ethernet?. Parce que bon des problèmes réseau, ça peut venir de l'opérateur et de sa box, mais bien souvent de chez toi comme une imprimante, une chromecast ou smart tv qui péclote, une docking station qui fonctionne mal quand elle surchauffe, un bug ou le comportement imprévu d'un logiciel et ça peut être vraiment pas évident à découvrir.

    • [^] # Re: question bête

      Posté par  . Évalué à 1.

      Effectivement, je ne donnes pas de chiffres directement.

      Avec la fibre que j'ai, en général j'ai une latence de 2 à 5ms sur la plupart des sites «du coin». Quand ça marche.

      Là j'ai des «trous» parfois à 16 ms, voir 60 ou plus. Ça c'est pour l'ICMP.

      Pour les sites web, ben c'est le timeout d'une connection TCP figée en fonction de l'étape qui a gelée (dns, css, javascript, html, …) donc 2mn environ. Un vrai cauchemar :). Et en fonction de la requête en cours, ça «freeze» les navigateurs (pas de cancel possible et/ou fonctionnel).

      Comme dit, j'ai passé les détails, mais j'ai testé sous iphone / Debian / ubuntu / windows 10 et 11, android, ça passe par le filaire (mes PCs et portables) ou par le wifi (iphone / tablette wifi).

      Après, je n'ai pas eu de changement récent dans ma topologie (sinon c'est le premier truc que j'aurais regardé) donc j'ai pas testé en débranchant les éléments un par un. Mais vu que le problème se passe derrière la livebox, j'ai de gros doute sur l'origine interne du problème.
      D'autant plus que c'est pas un paquet TCP random avec le rejeu qui passe (ça serait relou, mais «acceptable»), mais bien un gel total de la connection TCP. Comme si il y avait une sorte de pare-feu transparent sur le réseau d'orange avec un load-balancing et que l'une des nombreuses machine nécessaire à ce pare-feu n'était pas synchrone avec les autres et donc jetais les paquets. Ou un «optimisateur» d'IPv4 dans IPv6 qui planterait de la même façon.

      Il faut que je vérifie si ça concerne seulement l'ipv4 ou l'ipv6 aussi (c'est pas clair d'ailleurs, mais je pense pas que mon traffic vers les gafam soit en ipv4 ou alors y a un autre problème).

      Pour le lien, j'ai pas eu d'upgrade sur l'ensemble de mes machines (une à la rigueur), et j'ai parfois fait des tests avec cette machine en dehors du réseau. Bref c'est une piste, mais pour l'instant elle est close de mon côté.

      Caeies.

      • [^] # Re: question bête

        Posté par  . Évalué à 4.

        En adsl, j'ai rencontré un problème assez similaire. Blocages/gros ralentissements aléatoires wifi comme ethernet alors que la box (vieille freebox v5) me disait que tout allait bien. J'avais des pings de plusieurs secondes et les led clignotaient comme des folles…

        Après investigations, branchements/débranchements/redémarrages, c'était une simple prise CPL qu'il a fallu réinitialiser.

      • [^] # Re: question bête

        Posté par  . Évalué à 5.

        Tu parles de connexions TCP qui "tombent", ce n'est pas très clair.

        Normalement en TCP, il y a des retransmission. Si un paquet n'est pas acquitté, il est retransmis plusieurs fois jusqu'au timeout.

        Est-ce que tu vois ces différentes retransmissions ? Les autres connexions continuent à fonctionner pendant ce temps ?

        Si c'est le cas, cela veut dire que seuls les paquets liés à une connexion TCP spécifique sont jetés ? ça ressemble plutôt à un équipement de filtrage qui ferait du drop…

        • [^] # Re: question bête

          Posté par  . Évalué à 2.

          Alors,

          Je continue les tests, et je peux pas mettre à jour le journal (enfin pas que je sache).

          Pour résumer:

          • J'ai un problème de type «routing» aléatoire ou filtrage déficient ou «limiteur de débit» ou je ne sais quoi d'autre qui «tue» les connexions TCP:

            • un petit paquet tcp est perdu dans le réseau d'orange et le mécanisme de retransmission de TCP fait son boulot
            • MAIS, le paquet rejoué est systématiquement jeté / non transmis (c'est ce que je veux dire par «pris en grippe»): je vois ce comportement, depuis mon PC ET entre la livebox et l'ONT.
            • C'est clairement établi / vérifiable / reproductible sur l'IPv4.
            • Je n'ai pas encore prouvé la chose sur IPv6 (et je découvre que linuxfr.org n'a pas d'adresse ipv6 ?).
            • En fonction de l'état de la connexion au moment ou ce problème arrive ça peut causer de grosses latences pour que le soft qui se connecte retombe sur ses pieds.
          • J'ai, a priori, un voisin d'arbre GPON qui est gourmand et qui le sature régulièrement (je perds mon upload pendant plusieurs 10 aines de secondes régulièrement lorsque je fais des tests de performances réseaux). C'est pour l'instant plus une hypothèse qu'une certitude, mais ça commence à être reproductible.

          Est-ce que tu vois ces différentes retransmissions ? Les autres connexions continuent à fonctionner pendant ce temps ?

          Si c'est le cas, cela veut dire que seuls les paquets liés à une connexion TCP spécifique sont jetés ? ça ressemble plutôt à un équipement de filtrage qui ferait du drop…

          Et oui, les autres connexions fonctionnent, c'est totalement aléatoire (d'ou le fait que je devienne fou), donc je suis d'accord avec toi, ça ressemble à un problème de filtrage quelque part, ou «d'optimiseur TCP buggué» comme il en existe chez les opérateurs de Téléphonie, ou un «convertisseur/encapsulateur» IPv4 dans IPv6 ou autre MPLS qui décide que NON ce paquet là j'en veux pas.

          Mais comment faire pour expliquer ça au support niveau 1 d'orange ? (oui je suis "level down" :(

          Je vais tenter de faire un post sur lafibre.org, sait-on jamais. En passant, certains problèmes remontés sur ce site me font peur tellement ça à l'air d'être la jungle.

          Caeies,

  • # et chez les voisins ?

    Posté par  . Évalué à 4.

    Depuis maintenant 8 ans j'ai la fibre chez Orange (à l'époque, j'avais pas le choix, et ça marchait jusqu'à maintenant). Et y a pas à dire, c'est confortable.

    C'est quel type d'opérateur d'infrastructure (OI) ?

    Mais voila, depuis environ fin mai, la fibre hoquette … Latences liées à des retransmissions TCP, sur les DNS, sur les long polling, sur le VPN de la boite … Un vrai cauchemar.

    J'irais voir sur lafibre.info comment ça marche chez les "voisins" ?

    • [^] # Re: et chez les voisins ?

      Posté par  . Évalué à 3.

      C'est quel type d'opérateur d'infrastructure (OI) ?

      Pour l'OI, je pense que c'est le réseau FTTH d'orange elle-même. Dans ma région/ville a priori c'est rentable :). J'ai jamais eu d'info dans le sens contraire (et j'ai jamais eu à me poser la question), donc c'est peut être autre chose.

      J'irais voir sur lafibre.info comment ça marche chez les "voisins" ?

      mmm, le dernier post dans ma ville sur le forum du département date de 2016 … D'après la meteo du net d'orange, il n'y a pas d'incidents déclarés sur les équipements de ma ligne.

      Et j'ai posé la question aux intervenants sans succès. Bon courage à un «novice» pour décrire le type de problème que j'ai et que la partie en face comprenne.

      Caeies.

  • # Seul?

    Posté par  (site web personnel) . Évalué à 6.

    Est-tu seul sur ton réseau? Il est possible que quelqu'un d'autre sature ta connexion, peut être même avec une machine infectée. Si c'est possible, ça vaudrait peut être le coup d'essayer en s'assurant qu'un seul appareil est connecté à la box.

    Pour exemple, je sais que si je fais un gros téléchargement en BitTorrent chez moi, ma box perd la tête (wifi qui se coupe, voire redémarrage)

    Un LUG en Lorraine : https://enunclic-cappel.fr

    • [^] # Re: Seul?

      Posté par  . Évalué à 2.

      Salut Ted,

      Mon réseau interne n'est pas saturé, et la livebox ne montre pas vraiment de signe de faiblesse ni de gros débits en sortie. C'est vraiment que les connexions tcp gèlent sur un paquet. Je vais tenter de forcer l'IPv6 dès que je peux pour voir si c'est mieux en IPv6 vs IPV4.

      Les tests de perfs que j'ai aligné montrent que je suis à 1Gb/s en download et 400Mb/s en upload la plupart du temps. Parfois ça déraille aussi, mais le test d'après est bon … sans que je vois quoique ce-soit redémarrer.

      Caeies.

      • [^] # Re: Seul?

        Posté par  (site web personnel) . Évalué à 3.

        Avec du P2P, tu peux créer de nombreuses connexions, même s'il y a peu de trafic. Mais ces connexions vont demander des ressources m&moire au routeur.

        S'il tu as une interface pour voir l'état de ta box, ce serait pas mal.

        Coupe le Wifi, afin de mieux contrôler ce qui passe par ta box, et laisse branché qu'une seule machine que tu contrôles, le temps des tests.

        Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

        • [^] # Re: Seul?

          Posté par  . Évalué à 2.

          Pour le P2P je suis trop vieux :).

          Et le problème semble «derrière» la livebox, côté réseau orange, plutôt que avant.

          J'ai accès à la livebox, mais je n'ai pas trouvé d'indicateur de status d'elle même autres que détails réseaux …

          J'ai un des techniciens du support qui m'avait suggéré de descendre le pare-feu en faible plutôt que medium, j'ai fait le test sans succès, ça plantait toujours.

          Pour le test mono machine, faut que je trouve un créneau horaire, et ça va pas être simple.

          Caeies.

  • # MTU ?

    Posté par  (site web personnel) . Évalué à 6.

    Alors le dernière problème que j'ai eu qui se rapproche du tiens, c'était dans mes VM (kVM/libvirtd) où le net était hérratique.

    En fait, mon VPN a une MTU de 1420, et en forcant la MTU à 1420 dans les VM, ca allait mieux.

    Alors peut-être abaisser la MTU à 1420 ? ou une autre valeur.

    Voilà, mes 2 centimes. Je suis pas ingénieur réseau /o\

    • [^] # Re: MTU ?

      Posté par  . Évalué à 2.

      Mmm merci, mais non.

      La taille des paquets impactée c'est de l'ordre de 200 octets … j'espère que c'est pas la MTU max de la fibre :).

      Et ce serait systématique, lorsque la taille atteindrait une certaine valeur … Et dans le VPN, je continue à recevoir des données du serveur en face, mais mon paquet TCP ne passe pas …

      Caeies.

  • # DNS ?

    Posté par  (site web personnel) . Évalué à 3.

    Tu évoque rapidement le DNS au début, mais je ne sais pas à quel point tu as testé ça ? Il y a quelques temps j'ai eu des soucis, pareil c'était très aléatoire au niveau des ralentissements et ping m'affichait des trucs vraiment bizarres (à dire que tout passait mais à mettre trop de millisecondes à répondre). Dans mon cas c'était juste sur un périphérique, ce qui m'a permis de réduire les recherches, et c'était que j'avais laissé dans resolv.conf l'utilisation d'un DNS d'openic qui s'était mis à déconner. Configuration que j'avais activé auparavant quand mon fournisseur avait eu des soucis sur son DNS, et oublié… Bref, je ne suis pas sûre que ce soit utile ou pertinent mais cela fait une piste à explorer si jamais : si le souci vient du DNS d'Orange, essayer de passer outre et voir si ça va mieux ?

    • [^] # Re: DNS ?

      Posté par  . Évalué à 1.

      Mmm,

      J'ai le problème sur tous les PCs / tablettes. Donc j'ai pas oublié un vieux truc du genre. Mais peut être qu'effectivement il faudrait que je me penche plus attentivement dessus.

      Pour moi les navigateurs sont en DNS via TCP (via http ?) et vu que les connections TCP sautent régulièrement je me suis dis que c'était pareil. [et peut être que je me trompe car c'est en fait la livebox qui est le resolveur dns].

      Mais peut être que ça vaudrait le coup de tester avec un autre résolveur DNS, j'ai peut être un double effet kiss-cool avec un DNS d'orange qui me retourne parfois du AAAA et parfois du A et que le problème est lié avec le A uniquement.

      Je vais tester ça. On va voir :)

      Caeies,

      • [^] # Re: DNS ?

        Posté par  (site web personnel) . Évalué à 7.

        Sinon, tu installes ton propre résolveur DNS.

        Certains FAI bloquent les ports DNS, mais dans ce cas, tu fais passer le trafic DNS à travers un tunnel.

        Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

        • [^] # Re: DNS ?

          Posté par  . Évalué à 2.

          Orange est cool.

          Je viens de changer les DNS pour openDNS en IPv6. On va voir comment ça se passe, mais j'ai vu que slack est en IPv4 only et il semblerait que l'ipv4 soit privilégié globalement. Faut que je creuse pour mettre l'IPv6 en priorité haute sur ma machine.

          En passant, je me suis aperçu que l'IPv6 avait sauté lors des tests fait par le technicien ce matin (j'ai forcé le support à m'appeler), pour ceux qui ont besoin, une «simple» désactivation / réactivation de l'ipv6 suffit à remettre tout le monde debout.

          Maintenant, ça «corrigera» une machine, pas les autres.

          Caeies.

          • [^] # Re: DNS ?

            Posté par  (site web personnel) . Évalué à 5.

            Non, Orange n'est pas cool.
            Et, s'il y a une erreur sur leur réseau, et qu'ils finissent par la corriger, jamais ils ne l’admettront.

            Je parlais d'installer sur ont réseau ou ta machine un résolveur DNS, pas d'en utiliser un autre à l'extérieur (sauf si tu as un serveur avec ce qu'il faut).

            Powerdns-reccursor fonctionne très bien pour ça. Sous Linux ça s'installe facilement, et par défaut ça écoute sur le port 53 localement. Après, il faut aussi que tu changes ton /etc/resolv.conf et ta config dhcp-client éventuellement.

            Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

            • [^] # Re: DNS ?

              Posté par  . Évalué à 4.

              Non, Orange n'est pas cool.

              Si, je répondais à :

              Certains FAI bloquent les ports DNS, mais dans ce cas, tu fais passer le trafic DNS à travers un tunnel.

              Et sur ce point, orange ce n'est pas comme d'autres (je bosses avec pas mal d'opérateurs de téléphonies mobile en m2m) et ils te laissent faire ton dns comme tu l'entends.

              Pour ça :

              Et, s'il y a une erreur sur leur réseau, et qu'ils finissent par la corriger, jamais ils ne l’admettront.

              Oui probable, mais en même temps, si j'ai plus de problème, je vais être pragmatique :/.

              Powerdns-reccursor fonctionne très bien pour ça. Sous Linux ça s'installe facilement, et par défaut ça écoute sur le port 53 localement. Après, il faut aussi que tu changes ton /etc/resolv.conf et ta config dhcp-client éventuellement.

              J'ai «l'habitude» de configurer bind/named mais là pour les tests je voyais pas vraiment l'intérêt.

              D'autant que les premiers retours des tests confirment que le souci est vraiment plus au niveau TCP IPV4 qu'au niveau DNS (j'ai le Hello Client du ssl qui se trouve bloqué après le 3 way handshake sur certaines connexions, et je sais que les implems de la libssl aiment pas du tout ce type d'erreur).

              Pour l'IPV6 ça reste un peu plus difficile à quantifier, j'ai moins de cas que je peux clairement reproduire avec certitude.

              Caeies.

  • # Problème local ?

    Posté par  . Évalué à 4.

    Bonjour

    est-ce qu’un matériel dans le réseau interne ne pourrai pas causer de problème ?

    cf ce genre de soucis : https://www.macg.co/materiel/2022/05/les-hubs-usb-c-avec-ethernet-peuvent-toujours-faire-tomber-tout-le-reseau-local-129015

    • [^] # Re: Problème local ?

      Posté par  . Évalué à 3.

      Bonsoir,

      Je n'ai aucun joujou bizarre supplémentaire depuis le début du problème. Et comme je l'indique, le problème est «après» la livebox.

      Mais le lien est intéressant, j'ai des collègues au bureau qui ont ce type de soucis, je vais partager :).

      Merci,

      Caeies,

  • # Ou la folie s'éclaire ...

    Posté par  . Évalué à 2.

    Cher Lecteurs, (oui toi là, celui qui ne contribue pas souvent).

    Du nouveau:
    Sous linux (c'est important, ça ne «marche pas» sous windows car le pattern par défaut du ping est différent, c'est comme ça que je me suis aperçu du problème), si certains pouvaient faire un truc du style:

    for i in $(seq 170 300); do if ! ping -q -c 1 -s $i -A ping.online.net > /dev/null; then echo "Killed for $i"; fi; sleep 0.1; done
    Suivi par:

    for i in $(seq 170 300); do if ! ping -q -p 40414243444546478495051525354555657585960 -c 1 -s $i -A ping.online.net > /dev/null; then echo "Killed for $i"; fi; sleep 0.1; done
    et soumettre les résultats ça m'intéresse. Chez moi ça donne ça (systématiquement):

    for i in $(seq 170 300); do if ! ping -q -c 1 -s $i -A ping.online.net > /dev/null; then echo "Killed for $i"; fi; sleep 0.1; done
    Killed for 173
    Killed for 189
    Killed for 269
    Killed for 285
    et

    for i in $(seq 170 300); do if ! ping -q -p 40414243444546478495051525354555657585960 -c 1 -s $i -A ping.online.net > /dev/null; then echo "Killed for $i"; fi; sleep 0.1; done
    J'aimerais savoir si je suis le seul «encore».

    Merci d'avance,

    Caeies

    • [^] # Re: Ou la folie s'éclaire ...

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Sous Ubuntu 20.04 / Dell E7470 / accès Wifi sur box Sosh fibre livebox4, les deux commandes se terminent sans message sur le terminal.

      • [^] # Re: Ou la folie s'éclaire ...

        Posté par  . Évalué à 3.

        ok top,

        merci. Sosh c'est orange donc c'est probablement localisé sur mon secteur géographique. J'ai identifié l'IP qui pose problème de mon côté, c'est 80.10.236.81 …

        Et je confirme que j'ai un problème similaire pour les connections en ipv6/tcp (similaire à ce qu'il se passe en ipv4).

        Caeies, vieux fou mais qui commence à voir ou ça ne va pas.

      • [^] # Re: Ou la folie s'éclaire ...

        Posté par  (site web personnel) . Évalué à 3.

        Pareil avec Ubuntu 22.04, Wifi, Livebox 5 Orange fibre.

    • [^] # Re: Ou la folie s'éclaire ...

      Posté par  (site web personnel) . Évalué à 2.

      Debain SID : filaire ou WIFI, Orange Fibre, Livebox 5 : aucune sortie visible à tes tests

    • [^] # Re: Ou la folie s'éclaire ...

      Posté par  . Évalué à 2.

      Bonjour

      debian 11 (bullseye) / Free Fibre
      Aucun retour suite à l'exécution des deux lignes de commandes proposées.

    • [^] # Re: Ou la folie s'éclaire ...

      Posté par  . Évalué à 2.

      [Je me réponds à moi-même pour être au même niveau de réponse, j'adore le strip]

      Merci pour vos contributions !

      Voici les dernières infos que j'ai :

      Si des gens ayant une livebox 4 peuvent tester, ça m'intéresse pour le 6, je me demande si c'est du port knocking mal implémenté:

      for j in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do for i in $(seq 1 3); do { echo -n "$j $i "; ping -n -c 1 -t$i -p 0000000000000000001$j -s 173 ping.online.net | grep icmp_seq; }; done; echo; done
      Chez moi ça retourne ça:

      0 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
      0 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
      0 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
      
      1 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
      1 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
      1 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
      
      2 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
      2 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
      2 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
      
      3 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
      3 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
      3 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
      
      4 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
      4 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
      4 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
      
      5 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
      5 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
      5 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
      
      6 1 6 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
      6 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
      
      7 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
      7 2 From 80.10.236.81 icmp_seq=1 Time to live exceeded
      7 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded
      
      8 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
      8 2 8 3 
      9 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
      9 2 9 3 
      a 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
      a 2 a 3 
      b 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
      b 2 b 3 
      c 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
      c 2 c 3 
      d 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
      d 2 d 3 
      e 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
      e 2 e 3 
      f 1 From 192.168.1.1 icmp_seq=1 Time to live exceeded
      f 2 f 3 
      

      Et comme le dit le dicton, plus on est de fous, plus on rit !

      Caeies,

      • [^] # Re: Ou la folie s'éclaire ...

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Même config que décrite plus haut :

        for j in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do for i in $(seq 1 3); do { echo -n "$j $i "; ping -n -c 1 -t$i -p 0000000000000000001$j -s 173 ping.online.net | grep icmp_seq; }; done; echo; done
        0 1 De 192.168.1.1 icmp_seq=1 Time to live exceeded
        0 2 De 80.10.236.45 icmp_seq=1 Time to live exceeded
        0 3 De 193.253.93.58 icmp_seq=1 Time to live exceeded
        
        1 1 De 192.168.1.1 icmp_seq=1 Time to live exceeded
        1 2 De 80.10.236.45 icmp_seq=1 Time to live exceeded
        1 3 De 193.253.93.58 icmp_seq=1 Time to live exceeded
        
        2 1 De 192.168.1.1 icmp_seq=1 Time to live exceeded
        2 2 De 80.10.236.45 icmp_seq=1 Time to live exceeded
        2 3 De 193.253.93.58 icmp_seq=1 Time to live exceeded
        
        3 1 De 192.168.1.1 icmp_seq=1 Time to live exceeded
        3 2 De 80.10.236.45 icmp_seq=1 Time to live exceeded
        3 3 De 193.253.93.58 icmp_seq=1 Time to live exceeded
        
        4 1 De 192.168.1.1 icmp_seq=1 Time to live exceeded
        4 2 De 80.10.236.45 icmp_seq=1 Time to live exceeded
        4 3 De 193.253.93.58 icmp_seq=1 Time to live exceeded
        
        5 1 De 192.168.1.1 icmp_seq=1 Time to live exceeded
        5 2 De 80.10.236.45 icmp_seq=1 Time to live exceeded
        5 3 De 193.253.93.58 icmp_seq=1 Time to live exceeded
        
        6 1 6 2 De 80.10.236.45 icmp_seq=1 Time to live exceeded
        6 3 De 193.253.93.58 icmp_seq=1 Time to live exceeded
        
        7 1 De 192.168.1.1 icmp_seq=1 Time to live exceeded
        7 2 De 80.10.236.45 icmp_seq=1 Time to live exceeded
        7 3 De 193.253.93.58 icmp_seq=1 Time to live exceeded
        
        8 1 De 192.168.1.1 icmp_seq=1 Time to live exceeded
        8 2 De 80.10.236.45 icmp_seq=1 Time to live exceeded
        8 3 De 193.253.93.58 icmp_seq=1 Time to live exceeded
        
        9 1 De 192.168.1.1 icmp_seq=1 Time to live exceeded
        9 2 De 80.10.236.45 icmp_seq=1 Time to live exceeded
        9 3 De 193.253.93.58 icmp_seq=1 Time to live exceeded
        
        a 1 De 192.168.1.1 icmp_seq=1 Time to live exceeded
        a 2 De 80.10.236.45 icmp_seq=1 Time to live exceeded
        a 3 De 193.253.93.58 icmp_seq=1 Time to live exceeded
        
        b 1 De 192.168.1.1 icmp_seq=1 Time to live exceeded
        b 2 De 80.10.236.45 icmp_seq=1 Time to live exceeded
        b 3 De 193.253.93.58 icmp_seq=1 Time to live exceeded
        
        c 1 De 192.168.1.1 icmp_seq=1 Time to live exceeded
        c 2 De 80.10.236.45 icmp_seq=1 Time to live exceeded
        c 3 De 193.253.93.58 icmp_seq=1 Time to live exceeded
        
        d 1 d 2 De 80.10.236.45 icmp_seq=1 Time to live exceeded
        d 3 De 193.253.93.58 icmp_seq=1 Time to live exceeded
        
        e 1 De 192.168.1.1 icmp_seq=1 Time to live exceeded
        e 2 De 80.10.236.45 icmp_seq=1 Time to live exceeded
        e 3 De 193.253.93.58 icmp_seq=1 Time to live exceeded
        
        f 1 De 192.168.1.1 icmp_seq=1 Time to live exceeded
        f 2 De 80.10.236.45 icmp_seq=1 Time to live exceeded
        f 3 De 193.253.93.58 icmp_seq=1 Time to live exceeded
        
        • [^] # Re: Ou la folie s'éclaire ...

          Posté par  . Évalué à 3.

          Cool, merci.

          Donc ça confirme que la livebox voit bien un paquet spécial pour le 16 faudra que je pousse un de ces 4 sur ce sujet.

          Pour les autres, dans ton cas ta «passerelle» (80.10.236.45) ne filtre pas, donc ça semble confirmer qu'il y a un truc anormal dessus. L'ideal serait d'avoir quelqu'un qui est dans le même coin que moi (nord du 92) et qui sortirait par la même «passerelle» et qui aurait ou non le problème, mais là ça devient compliqué :/

          Merci encore pour ton aide.

          Caeies,

  • # Mise à jour ...

    Posté par  . Évalué à 3.

    Pour ceux qui sont intéressés,

    À force de me battre avec le support, j'ai fini par tomber sur quelqu'un qui a compris que quelque chose ne tournait pas rond et qui a pris contact avec un expert. Verdict: des gars du réseau vont venir voir ce qu'il se passe chez moi pour tenter de remonter à la source du problème.

    Pour mémoire, voici le pattern ping qui fait dérailler un des équipements sur la route de mes paquets:

    Il faut: -s 13+$(($N*16)) avec N > 0, et -p $k$j avec k ∈ [0,3]∪[8,b] et j ∈ [8,f].

    Je n'arrive pas à comprendre comment le monitoring réseau qu'effectue Orange sur ses équipements n'a pas remonté le problème «plus haut» vu le nombre de paquets qui doivent être en erreurs sur l'interface.

    J'espère que j'aurais un peu plus d'infos lorsqu'il viendront tester la ligne. Pour rappel, j'ai le problème depuis l'intérieur de chez moi, mais aussi lorsque je passe pas l'extérieur, sur le chemin retour uniquement.

    Merci encore à tous les testeurs !

    Caeies, plus si fou que ça.

    PS: Par exemple:

    for k in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do for j in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do { if ! ping -q -4 -w 1 -n -c 1 -p $k$j -s 173 appliwave.iperf.fr > /dev/null; then echo "$k$j dropped"; fi }; done; done;
    donne chez moi:

    08 dropped
    09 dropped
    0a dropped
    0b dropped
    0c dropped
    0d dropped
    0e dropped
    0f dropped
    18 dropped
    19 dropped
    1a dropped
    1b dropped
    1c dropped
    1d dropped
    1e dropped
    1f dropped
    28 dropped
    29 dropped
    2a dropped
    2b dropped
    2c dropped
    2d dropped
    2e dropped
    2f dropped
    38 dropped
    39 dropped
    3a dropped
    3b dropped
    3c dropped
    3d dropped
    3e dropped
    3f dropped
    88 dropped
    89 dropped
    8a dropped
    8b dropped
    8c dropped
    8d dropped
    8e dropped
    8f dropped
    98 dropped
    99 dropped
    9a dropped
    9b dropped
    9c dropped
    9d dropped
    9e dropped
    9f dropped
    a8 dropped
    a9 dropped
    aa dropped
    ab dropped
    ac dropped
    ad dropped
    ae dropped
    af dropped
    b8 dropped
    b9 dropped
    ba dropped
    bb dropped
    bc dropped
    bd dropped
    be dropped
    bf dropped

    • [^] # Re: Mise à jour ...

      Posté par  . Évalué à 3.

      Le rythme de paquets jetés est tellement régulier que c'est probablement du rate-limiting ICMP. Je crois que c'est une pratique assez courante de jeter volontairement une certaine proportion de paquets ICMP pour soulager les équipements réseau.
      Donc je dirais que la commande ping n'est pas suffisante pour diagnostiquer une problème réseau dans ton cas. Peut-être plutôt "mtr --tcp" par exemple.

      • [^] # Re: Mise à jour ...

        Posté par  . Évalué à 1.

        Salut Seveso,

        La réponse est dans la question :)

        for k in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do for j in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do { if ! ping -q -4 -w 1 -n -c 1 -p $k$j -s 173 appliwave.iperf.fr > /dev/null; then echo "$k$j dropped"; fi }; done; done;
        done chez moi

        08 dropped
        09 dropped
        0a dropped
        0b dropped
        0c dropped
        0d dropped
        0e dropped
        0f dropped
        18 dropped
        19 dropped
        1a dropped
        1b dropped
        1c dropped
        1d dropped
        1e dropped
        1f dropped
        28 dropped
        29 dropped
        2a dropped
        2b dropped
        2c dropped
        2d dropped
        2e dropped
        2f dropped
        38 dropped
        39 dropped
        3a dropped
        3b dropped
        3c dropped
        3d dropped
        3e dropped
        3f dropped
        88 dropped
        89 dropped
        8a dropped
        8b dropped
        8c dropped
        8d dropped
        8e dropped
        8f dropped
        98 dropped
        99 dropped
        9a dropped
        9b dropped
        9c dropped
        9d dropped
        9e dropped
        9f dropped
        a8 dropped
        a9 dropped
        aa dropped
        ab dropped
        ac dropped
        ad dropped
        ae dropped
        af dropped
        b8 dropped
        b9 dropped
        ba dropped
        bb dropped
        bc dropped
        bd dropped
        be dropped
        bf dropped

        Et les tests initiaux que je faisais était d'un paquet de temps en temps. Là j'ai juste automatisé la découverte du pattern de bits qui pose problème à l'équipement.

        Et ça n'arrive QUE sur ces patterns de bits pour les tailles de paquets mentionnés. Ça arrive probablement avec d'autres combinaisons de bits, (d'ou les connexions aléatoirement disfonctionnelles) mais c'est plus complexe à tracer (il me faut un service echo quelque pars sur lequel j'envoie des patterns via tcp de tailles incrémentales … ce qui peut être long.

        Cordialement,

        • [^] # Re: Mise à jour ...

          Posté par  . Évalué à 1.

          Désolé,

          Il fallait lire (le copie paste c'est mal):

          for k in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do for j in 8 9 a b c d e f 0 1 2 3 4 5 6 7 ; do { if ! ping -q -4 -w 1 -n -c 1 -p $k$j -s 173 appliwave.iperf.fr > /dev/null; then echo "$k$j dropped"; fi }; done; done;
          Cordialement,

          • [^] # Re: Mise à jour ...

            Posté par  . Évalué à 3.

            Bonjour,

            J'ai exactement les même symptomes que toi. une connection qui marche à 100Mb/s upload/download (suffisant pour moi)

            Mais régulierement essentiellement sur le Wifi des téléphones. , j'ai des connexions qui sont perdu.

            Je viens de tester ton script , je n'ai aucun paquet de rejeté.

            Enfin, le truc bizarre, c'est que je télétravaille en wifi toute la journée sans soucis avec mon portable en liaison VPN

            Par contre, dès que je suis en Wifi avec les téléphones & tablettes. J'ai régulierement des pertes de connexions.

            Mes enfants en viennent à consommer leur 4G car le Wifi est vraiment trop limite.

            A mon avis, c'est le wifi de la livebox qui est pourri.

            • [^] # Re: Mise à jour ...

              Posté par  . Évalué à 3.

              Salut,

              Oui j'ai connu le même problème au début de mon usage de la livebox. Je suis en milieu extrême pour le wifi, et la solution simple au problème c'est de désactiver le wifi 2.4Ghz, et de ne garder que le 5Ghz. Je n'ai plus de problème de ce type depuis ce changement.

              Bien sûr ça limite les périphériques qui peuvent se connecter, mais au moins, pour les autres, c'est parfait.

              Pour rentrer dans les détails techniques, il y a plusieurs hypothèses:
              * les puces wifi avec lesquelles je travailles ne sont pas capables de faire du 2.4Ghz et du 5Ghz parfaitement en même temps. Du même coup, le temps de commutation nui gravement aux performances car il faut que les drivers réémettent les trames wifi au bout d'un timeout (comme pour le tcp mais au niveau 2).
              * Le 2.4Ghz est pollué par les autres wifi environnant et la puce abaisse sa puissance émise. C'est pas un problème pour ton PC qui peut suivre / à de bonne antennes, mais c'est pas le cas des téléphones / tablettes wifi qui sont très «light» sur le sujet.

              J'ai jamais ouvert de livebox, donc je peux difficilement trancher, mais certains ici sont peux être plus calés que moi sur le sujet :).

              Tiens moi au courant si ça améliore effectivement les choses.

              Caeies,

              • [^] # Re: Mise à jour ...

                Posté par  . Évalué à 3.

                Le 2.4Ghz est pollué par les autres wifi environnant

                Pour le 5Ghz, c'est tout aussi vrais, car souvent les box des FAI, sont configurées par défaut avec les 2 d'activés.
                Je bosse souvent avec des pont radio, et dans certain coin en 5Ghz, c'est une vrais plaie pour trouver des fréquences libre.

                • [^] # Re: Mise à jour ...

                  Posté par  (site web personnel) . Évalué à 5.

                  Les fréquences 5Ghz ont une moins grande portée que les 2.4Ghz, ce qui limite naturellement la pollution dans cette plage. Mais j'imagine bien que dans des lieux densément peuplés ça peut encore poser problème.

                  Un LUG en Lorraine : https://enunclic-cappel.fr

    • [^] # Re: Mise à jour ...

      Posté par  (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 29 juin 2022 à 11:52.

      Merci pour ce retour. Je me demandais comment tu allais pouvoir utiliser toutes ces infos pour obtenir que ça s'améliore.

      Question complémentaire : tu as expliqué au technicien ce que tu étais et précisé tous les tests qui ont été faits pour arriver à le convaincre ? D'ailleurs comment es-tu tombé sur quelqu'un qui prend la peine d'écouter en ne pensant pas par principe que le client est un crétin fini (une impression que me donnent souvent les services d'assistance) ?

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: Mise à jour ...

        Posté par  . Évalué à 1.

        Salut Ysabeau, Salut à tous,

        Bon l'aventure continue. Le technicien qui devait passer ce matin n'est pas passé. J'avais eu l'un de ses collègues qui m'avait dit qu'il ouvrirait un ticket interne chez orange, mais l'optimisation des plannings a frappée et j'ai perdu le contact avec lui.

        Et le nouveau était moins «poilu», mais m'a dit qu'il avait demandé à vérifier l'ouverture du ticket et relancer sur le sujet (mais le ticket n'existant pas ça me parait compliqué).

        Pour répondre plus précisément à Ysabeau:

        Question complémentaire : tu as expliqué au technicien ce que tu étais et précisé tous les tests qui ont été faits pour arriver à le convaincre ? D'ailleurs comment es-tu tombé sur quelqu'un qui prend la peine d'écouter en ne pensant pas par principe que le client est un crétin fini (une impression que me donnent souvent les services d'assistance) ?

        Oui, c'est à peu près ça. Et une grande patience. Pour la deuxième partie, j'hésite entre la chance ou des «experts» qui comprennent qu'il y a un loup et qui aiguillent le ticket vers «les bonnes personnes» … Le système de «scénario» qui cadre les discussions est assez «limité» et certaines personnes connaissent des ruses, mais qui sont parfois non fonctionnelles … Bref, en tout j'ai probablement pas loin de 10h de telephone avec eux … ça va finir par faire sauter leurs indicateurs.

        Et puis, lorsque l'on tombe sur des gens qui sont en FR ou à Madagascar, ça marche mieux que des novices qui débarquent dans d'autres pays …

        Mais, les derniers appels que j'ai eu ont aussi été plus tendus car je commence à avoir épuisé ma patience :(.

        Caeies,

  • # température d'une armoire de fibres

    Posté par  (site web personnel) . Évalué à 4.

    Il y a quelques jours, j'ai vu passer via Nitter une personne mentionnant une armoire de fibre mal orientée, donc en plein soleil, ce qui affecterait les performances aux mauvaises heures. Je n'ai pas retrouvé le lien, je le rappelle juste qu'elle interpelait Orange ou OBS.

    • [^] # Re: température d'une armoire de fibres

      Posté par  . Évalué à 1.

      Ah ça c'est pas de bol.

      C'est vrai que ça dépend aussi un peu des heures de la journée, mais ça dépend surtout de mon activité.

      J'aurais pas de chance s'ils avaient changé "mon" armoire de place sans me le dire :/. (Mais pour moi elle est toujours en face de chez moi à l'ombre).

      En tout cas merci pour l'info, je vais tenter de regarder aussi de ce côté.

      Caeies,

  • # IPv6 ?

    Posté par  . Évalué à 2.

    En désactivant IPv6, ça donne quoi ?

    Ça ne serait pas la première fois qu'on verrait des bugs ou des lenteurs à cause de ça sur un système ou un réseau. Ça vaut clairement la peine de tester. Non pas que ce soit une solution en soi mais ça pourrait peut être aider à isoler l'origine du problème.

    • [^] # Re: IPv6 ?

      Posté par  . Évalué à 1.

      Le problème est principalement sur l'ipv4 (c'est ce qu'utilise mon VPN).

      C'est aussi présent sur tous les autres protocoles.

      Il n'est pas impossible que ce soit un problème de conf du serveur de collecte car ça tombe dans le champ flags TCP IPV6 pour l'ECN et le PUSH, mais c'est peut être juste une coincidence.

      Cf plus bas pour la suite :).

      Caeies,

  • # Suite ?

    Posté par  . Évalué à 3.

    Bonjour, je serais intéressé par la suite, as-tu eu des nouvelles depuis ?

    • [^] # Re: Suite ?

      Posté par  . Évalué à 2.

      Bonjour Sébastien,

      Oui j'ai des nouvelles (pas brillantes pour l'instant, mais l'espoir fait vivre).

      Je vais sauter des étapes sans intérêts, à part pour les amateurs de montagnes russes.

      Pour faire simple, ils sont en train de faire un monitoring d'une machine qui est «trop chargée» sur le chemin. Ils font tourner le robot pendant 8j et ensuite ils agissent. Il me reste donc 6 j à patienter … ou pas, vu que j'ai un gros doute sur le diagnostique qu'ils ont posé (ça expliquerait certains problèmes que j'ai eu sur les performances générales de la ligne de temps en temps, mais pas le drop systématique des paquets «cassés».

      Les dernières analyses que j'ai faites (avec l'aide d'un gars sur lafibre.info) indiquent la chose suivante:
      * il faut que le dernier mot du paquet (quelque soit le protocol) qui à une taille 13+N*16 contienne le pattern x0xx1xxx dans le premier octet (sur les 4): quelque chose comme b8XXXXXX à la fin.

      avec nping (N variant à la valeur que tu veux tant que c'est inférieur à la mtu et que le paquet IP fasse plus de 41 octets):
      - TCP:

      N=10; HEX=B8; nping --tcp --data $(for i in $(seq 1 $[16*N]); do echo -n 00; done ; echo)00000000000000000000000000${HEX}000000 -c1 ping.online.net;

      - IMCP:

      N=1; HEX=B8; nping --icmp --data $(for i in $(seq 1 $[N*16]); do echo -n 00; done ; echo)000000000000000000${HEX}000000 -c1 ping.online.net;

      - UDP:

      N=1; HEX=B8; nping --udp --data $(for i in $(seq 1 $[N*16]); do echo -n 00; done ; echo)000000000000000000${HEX}000000 -c1 ping.online.net;

      Pour IPV6 (attention aux bugs avec nping en mode -6, il faut un wireshark pour vérifier derrière) :
      - TCP:

      N=0; HEX=B8; nping -6 --tcp --data $(for i in $(seq 1 $[16*N]); do echo -n 00; done ;
      echo)000000000000000000${HEX}000000 -c1 appliwave.iperf.fr;

      - (les autres sont plus complexes à mettre en œuvre).

      Caeies.

      • [^] # Re: Suite ?

        Posté par  (site web personnel) . Évalué à 4. Dernière modification le 14 juillet 2022 à 17:30.

        Ça me rappelle une histoire d'un gars qui avait traqué statistiquement un problème dû à certaines valeurs à une position fixe d'un paquet réseau. Et ça finissait en bug du microcode ethernet qui faisait que la carte marchait, se bloquait ou redémarrait suivant les valeurs. Et le redémarrage électrique faisait partie des solutions temporaires (jusqu'à l'identification de la vraie solution : mettre à jour un équipement réseau).

        Bref de ton côté tu pourrais essayer une autre carte réseau surtout ordi ou une autre box… à tout hasard.

        • [^] # Re: Suite ?

          Posté par  . Évalué à 1.

          Ah c'est pas mal ça :).

          Rien d'aussi complexe dans mon cas (même si ça peut le sembler de l'extérieur), même si l'option «mettre à jour un équipement réseau» pourrait être une solution pour orange.

          De mon côté, le problème se reproduit sur tous les PCs / Téléphones / etc, et y compris à l'extérieur du réseau (c'est à dire depuis le net), y compris lors des tests par des tiers …

          Je vais tout de même retenter d'identifier des voisins, vu que j'ai changé d'IP. On verra si le problème est présent aussi.

          Merci.

          Caeies.

        • [^] # Re: Suite ?

          Posté par  . Évalué à 1.

          Bon grande nouvelle,

          Ça y est, le «vrai» net est revenu, je peux enfin surfer sans soucis et ne pas voir mon VPN tomber dès que je tente de charger les sites de la boite :).

          Je n'étais pas fou au final, j'espère sans trop d'espoir un «post-mortem» d'orange, mais je doute d'avoir le fin mot de l'histoire.

          Merci à tous pour votre aide.

          Caeies,

          • [^] # Re: Suite ?

            Posté par  . Évalué à 1.

            En espérant que ce post-mortem soit au final donné, c'est toujours intéressant et ce serait la moindre des choses vu le temps que tu y a passé: Le bug d'un équipement/FW tombé en marche après un upgrade d'équipement ne m'étonnerait guère chez Orange. Ils semblent avoir vraiment des gros pb de ce côté, il n'y a qu'a avoir tenté d'utiliser leurs SMTP en direct (sans passer par un client lourd codé pour s'adapter à tout!) pour constater combien au hasard des load-balancing on se retrouve sur des trucs qui font tousser les configs lib ssl/tls par défaut de moins de 5 ans.

            Pour ma part, avec une LB Play chez Sosh (celle utilisée auparavant en ADSL, qui n'avait jamais posé pb), c'est l'ONT qui coince après les coupures secteur: Il semble y avoir un pb assez fréquent qui fait que cela ne monte alors pas correctement si les deux démarrent ensemble quand l'alimentation est restaurée. Si la LB est démarrée avant l'ONT, cela semble OK à tous les coups (mais je n'ai pas fait une tétra-chiée d'essai non plus), sinon cela merde au moins 3 fois sur 4. Aucune possibilité d'accès à l'interface d'administration LB "pour voir" car le switch côté LAN ne semble en prime pas monter tant que le côté WAN ne monte pas (au démarrage, si on débranche l'ONT après un démarrage OK c'est bon).

            C'est un peu emmerdant pour la domotique/alarme qui se retrouve à la merci d'une panne secteur en vacances, si celle-ci dépasse la durée permise par la batterie tampon (double voltage en sortie) alimentant box+ont (en 20V) et PI3/Domoticz (5V USB).

            C'est au final très pénible, cet ONT. Prévoir une cage SFP sur les box pas trop anciennes aurait permis une meilleure intégration tant niveau matériel (place prise/esthétique, double alim…) que logicielle (la box a le contrôle du démarrage/configuration du SFP).

  • # Mtu / dns

    Posté par  . Évalué à 1.

    Hello,

    est ce que tu a essayer de passer faire des teste sur les mtu qui passe quand cela plante ?

    et sinon est ce que tu a changer le dns d'orange pas celui de opendns par exemple avec l'ipv6 aussi

    Bon chance ;)

    • [^] # Re: Mtu / dns

      Posté par  . Évalué à 1.

      Salut,

      Le problème est présent sur des tailles de paquets de 71 octets … je doute que la mtu soit responsable de ce souci :).

      Pour les DNS, oui ça a fait parti des premiers tests que j'ai fais, avant de comprendre l'origine du problème.

      Caeies,

  • # Et FRnOG (la mailing list) ?

    Posté par  . Évalué à 2.

    Bonjour,

    Votre question pourrait tout à fait être posé sur FRnOG. C'est une mailing-list orienté réseau d'entreprise. On voit cependant des fils sur des sujets "accès Internet fibre de la TPE" ou "accès Internet fibre à la maison pour le télétravail".

    Je vous invite à regarder les archives, des fois que le sujet soit apparu. Il y aussi des personnes qui exploitent, pour leur client, des accès assez "grand public" pour des usages un peu pointu, et qui rencontrent des fois des soucis assez bizarre.

    Mes deux centimes,

    • [^] # Re: Et FRnOG (la mailing list) ?

      Posté par  . Évalué à 1.

      Salut,

      Merci c'est fait :). Le problème a semble t-il été résolu entre la préparation du mail et son envoi … ça a été très très efficace :).

      Merci.

      Caeies.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.