Ç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.
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.
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).
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.
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.
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 :(.
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,
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é.
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.
À 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
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é :/
[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 !
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.
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».
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.
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.
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.
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.
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.
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 …
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.
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.
[^] # Re: Suite ?
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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: Et FRnOG (la mailing list) ?
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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.
[^] # Re: Suite ?
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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 Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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: Mtu / dns
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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,
[^] # Re: IPv6 ?
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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,
[^] # Re: Mise à jour ...
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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 Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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:
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,
[^] # Re: Mise à jour ...
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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;
[^] # Re: température d'une armoire de fibres
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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,
[^] # Re: Mise à jour ...
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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;
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,
# Mise à jour ...
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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;
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: Ou la folie s'éclaire ...
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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,
[^] # Re: Ou la folie s'éclaire ...
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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
Et comme le dit le dicton, plus on est de fous, plus on rit !
Caeies,
[^] # Re: Ou la folie s'éclaire ...
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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.
# Ou la folie s'éclaire ...
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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
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
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
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
Merci d'avance,
Caeies
[^] # Re: question bête
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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:
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.
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,
[^] # Re: Problème local ?
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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,
[^] # Re: DNS ?
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. Évalué à 4.
Si, je répondais à :
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 :
Oui probable, mais en même temps, si j'ai plus de problème, je vais être pragmatique :/.
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.
[^] # Re: DNS ?
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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: Seul?
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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.
[^] # Re: DNS ?
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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: MTU ?
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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.
[^] # Re: Seul?
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. É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: et chez les voisins ?
Posté par Caeies . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. Évalué à 3.
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.
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.