Rebonjour Nal !
Je code, je commit, et je fais un push via git vers le dépôt de github… erreur. Erreur ? Je demande à celui avec qui je travaille de faire un pull : ça marche.
Je vais sur le site de github. Inaccessible.
Mon collègue de projet, lui, peut y accéder.
Il est chez Free et moi chez Orange. Tentons via la connexion internet Free d'un voisin généreux, si je peux accéder à Github. La page s'affiche, je peux même envoyer mon coelles mmit…
Retour sur ma connexion internet illimitée par Orange : page inaccessible.
Les petites oranges censureraient-elles le gros geeteub ?
Ceux qui sont chez Orange, testez et twittez vos résultats !
Journal Github caché par de petites oranges ?
17
déc.
2010
# as tu essayé
Posté par imr . Évalué à 2.
[^] # Re: as tu essayé
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
# Chezmwé çamarche
Posté par daimrod . Évalué à 2.
Je viens de tester à l'instant et ça marche. (le pull, le push, le site oueb)
# héhé
Posté par Nal . Évalué à 10.
[^] # Re: héhé
Posté par zebra3 . Évalué à 4.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: héhé
Posté par gst . Évalué à 4.
# çapu ...
Posté par Tonton Th (Mastodon) . Évalué à 9.
hop ------>[]
# Si vous n'avez pas d'ami chez Free
Posté par gUI (Mastodon) . Évalué à 7.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par gUI (Mastodon) . Évalué à 0.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par Thomas Debesse (site web personnel) . Évalué à 1.
je n'ai pas de problème avec http
cela dit tu peux m'en dire plus pour le mtu ? toute chose qui me permettrait d'identifier le problème (même si ce devrait être le taf d'orange).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par gUI (Mastodon) . Évalué à 2.
Baisse le MTU fortement, et regarde si ça marche mieux. Par exemple :
ifconfig eth0 mtu 1000En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par BAud (site web personnel) . Évalué à 2.
Je n'ai jamais trop compris, mais ça marche (il y a le même souci parfois avec le FreeWifi).
Ce qui permet de le diagnostiquer est bizarrement des lenteurs aux (non-) réponses des DNS (des paquets de 56 octets... va comprendre...).
la commande qui fonctionne bien :
ifconfig wlan0 mtu 1400 # pour optimiser... (remplacer wlan0 par eth1 ou eth2 pour certains...), cela permet de retrouver un FreeWifi utilisable pour certains.
Après, que cela fonctionne pour l'Internet par orange n'est qu'un effet de bord...
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par briaeros007 . Évalué à 3.
(C'est arrivé pas plus tard qu'il y a 1,5 ans sur un routeur "pro" pour soho).
2°) la réponse dns ne fait pas 56 octets.
il y a l'ensemble des records dans une réponse dns. D'ailleurs elle peut envoyer une réponse tronquée et indiquer qu'il faut refaire la transaction par tcp pour avoir la réponse complète (cas typique : transfert de zone).
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par Krunch (site web personnel) . Évalué à 3.
> permet souvent de le faire refonctionner lors d'un passage en ATM
> ou des équipements réseau défaillants... (quelques soucis avec des
> ajouts "involontaires" au header...).
> Je n'ai jamais trop compris, mais ça marche (il y a le même souci
> parfois avec le FreeWifi).
Je ne sais pas d'où tu sors le 1496 mais le problème typique que j'ai pu observer c'est le passage par PPPoE qui ajoute 8 octets d'en-tête et pour lequel il est donc utile de diminuer le MTU à 1492. Cela permet de réduire les risques de fragmentations et donc d'augmenter les performances. Sauf qu'avec certains équipement qui ne gèrent pas bien la fragmentation, ça fait perdre des paquets et cause donc des problèmes de connectivité (pas juste de performance) comme décrit par briaeros007.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par briaeros007 . Évalué à 3.
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par BAud (site web personnel) . Évalué à 2.
ce pourquoi j'ai aussi indiqué 1400, vu que 1000 n'a aucune justification...
c'est quand même dément d'en arriver là, autant passer tout de suite à IPv6 dans ces conditions, au moins ce sera plus simple :-)
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
Le plus gros problème rencontré depuis que je suis derrière sur orange (septembre), c'est qu'il est impossible d'utiliser son compte gtalk (c'est un peu gros tout de même).
J'avais identifié que le problème venait du DNS, en septembre, en regardant un tcpdump.
J'ai des vieux logs qui datent, je vais essayer d'en faire des plus à jour
voilà déjà un début…
192.168.1.1, c'est le dns de la box qui a comme source le dns d'orange
127.0.0.1 c'est un cache local d'opendns
Pour le dns orange et pour le dns local, à chaque fois, je le met dans resolv.conf, je lance le tcpdump, et je clique sur "me connecter" dans pidgin, et j'attend.
# echo nameserver 192.168.1.1 > /etc/resolv.conf
# tcpdump -i wlan0 port xmpp-client
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:42:15.343264 IP arwen.53846 > wy-in-f17.1e100.net.xmpp-client: Flags [S], seq 617499497, win 5840, options [mss 1460,sackOK,TS val 570311 ecr 0,nop,wscale 7], length 0
20:42:18.346665 IP arwen.53846 > wy-in-f17.1e100.net.xmpp-client: Flags [S], seq 617499497, win 5840, options [mss 1460,sackOK,TS val 570612 ecr 0,nop,wscale 7], length 0
20:42:24.366700 IP arwen.53846 > wy-in-f17.1e100.net.xmpp-client: Flags [S], seq 617499497, win 5840, options [mss 1460,sackOK,TS val 571214 ecr 0,nop,wscale 7], length 0
20:42:36.386935 IP arwen.50259 > wy-in-f18.1e100.net.xmpp-client: Flags [S], seq 940594492, win 5840, options [mss 1460,sackOK,TS val 572416 ecr 0,nop,wscale 7], length 0
20:42:39.394205 IP arwen.50259 > wy-in-f18.1e100.net.xmpp-client: Flags [S], seq 940594492, win 5840, options [mss 1460,sackOK,TS val 572717 ecr 0,nop,wscale 7], length 0
^C
------- La connexion n'abouti jamais
------- On voit que le serveur ne répond jamais
# echo nameserver 127.0.0.1 > /etc/resolv.conf
# tcpdump -i wlan0 port xmpp-client
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:42:56.267093 IP arwen.44095 > ww-in-f125.1e100.net.xmpp-client: Flags [S], seq 1246344769, win 5840, options [mss 1460,sackOK,TS val 574404 ecr 0,nop,wscale 7], length 0
20:42:56.320053 IP ww-in-f125.1e100.net.xmpp-client > arwen.44095: Flags [S.], seq 110485215, ack 1246344770, win 5672, options [mss 1452,sackOK,TS val 2215540016 ecr 574404,nop,wscale 6], length 0
20:42:56.320104 IP arwen.44095 > ww-in-f125.1e100.net.xmpp-client: Flags [.], ack 1, win 46, options [nop,nop,TS val 574409 ecr 2215540016], length 0
20:42:56.321022 IP arwen.44095 > ww-in-f125.1e100.net.xmpp-client: Flags [P.], seq 1:23, ack 1, win 46, options [nop,nop,TS val 574409 ecr 2215540016], length 22
20:42:56.373020 IP ww-in-f125.1e100.net.xmpp-client > arwen.44095: Flags [.], ack 23, win 89, options [nop,nop,TS val 2215540069 ecr 574409], length 0
20:42:56.373081 IP arwen.44095 > ww-in-f125.1e100.net.xmpp-client: Flags [P.], seq 23:137, ack 1, win 46, options [nop,nop,TS val 574414 ecr 2215540069], length 114
20:42:56.429007 IP ww-in-f125.1e100.net.xmpp-client > arwen.44095: Flags [.], ack 137, win 89, options [nop,nop,TS val 2215540125 ecr 574414], length 0
20:42:56.430488 IP ww-in-f125.1e100.net.xmpp-client > arwen.44095: Flags [P.], seq 1:139, ack 137, win 89, options [nop,nop,TS val 2215540125 ecr 574414], length 138
20:42:56.430507 IP arwen.44095 > ww-in-f125.1e100.net.xmpp-client: Flags [.], ack 139, win 54, options [nop,nop,TS val 574420 ecr 2215540125], length 0
20:42:56.432873 IP ww-in-f125.1e100.net.xmpp-client > arwen.44095: Flags [P.], seq 139:349, ack 137, win 89, options [nop,nop,TS val 2215540125 ecr 574414], length 210
^C
------- La connexion abouti aussitôt
------- Le serveur répond aussitôt
au premier coup d'œil, on voit que ce ne sont pas les mêmes serveurs qui sont interrogés, comme google est une nébuleuse, ce n'est pas forcément significatif, mais…
Faisons un nmap des serveurs :)
# nmap -T4 -n -v wy-in-f18.1e100.net > nmap-orange-dns.log
# nmap -T4 -n -v ww-in-f125.1e100.net > nmap-local-dns.log
# diff nmap-orange-dns.log nmap-local-dns.log
----couic----
7,17c7,23
< Scanning wy-in-f18.1e100.net (209.85.227.18) [1000 ports]
< Discovered open port 80/tcp on 209.85.227.18
< Discovered open port 443/tcp on 209.85.227.18
< Completed SYN Stealth Scan at 21:11, 13.63s elapsed (1000 total ports)
< Nmap scan report for wy-in-f18.1e100.net (209.85.227.18)
< Host is up (0.14s latency).
< Not shown: 997 filtered ports
< PORT STATE SERVICE
< 80/tcp open http
< 113/tcp closed auth
< 443/tcp open https
---
> Scanning ww-in-f125.1e100.net (209.85.229.125) [1000 ports]
> Discovered open port 443/tcp on 209.85.229.125
> Discovered open port 80/tcp on 209.85.229.125
> Discovered open port 5225/tcp on 209.85.229.125
> Discovered open port 5269/tcp on 209.85.229.125
> Discovered open port 5222/tcp on 209.85.229.125
> Completed SYN Stealth Scan at 21:11, 20.18s elapsed (1000 total ports)
> Nmap scan report for ww-in-f125.1e100.net (209.85.229.125)
> Host is up (0.096s latency).
> Not shown: 994 filtered ports
> PORT STATE SERVICE
> 80/tcp open http
> 113/tcp closed auth
> 443/tcp open https
> 5222/tcp open unknown
> 5225/tcp open unknown
> 5269/tcp open unknown
20,21c26,27
----couic----
Les machines ne servent pas les même services !
En septembre, les résolutions par orange étaient du genre mad01s03-in-f83.1e100.net (72.14.235.83) alors que celles d'opendns étaient du genre ww-in-f125.1e100.net .
Aujourd'hui leur tambouille est plus discrète, mais ça ne fonctionne toujours pas.
En septembre, si je faisais nmap talk.google.com
avec le dns orange dans le log j'avais
Host mad01s03-in-f83.1e100.net (72.14.235.83)
avec le dns local j'avais
Host ww-in-f125.1e100.net (209.85.229.125)
Aujourd'hui, toujours en faisant nmap talk.google.com
avec le dns orange
rDNS record for 209.85.229.125: ww-in-f125.1e100.net
avec le dns local
rDNS record for 209.85.229.125: ww-in-f125.1e100.net
Bref, le problème dépend du DNS, mais pas que. En septembre, les DNS ne disaient pas franchement la même chose, et comme une autre moule [http://pankkake.headfucking.net/2009/02/11/suicide-de-groupe(...)] je m'étais dit que c'était peut-être de l'incompétence et qu'ils ne savaient pas faire un DNS correct.
Aujourd'hui je me pose une autre question, le service gtalk est toujours non fonctionnel chez orange MAIS le DNS semble fonctionner, enfin au premier abord.
En septembre un simple ping permettait de voir la différence, l'ip n'était pas la même, aujourd'hui c'est encore plus élaboré : sur un ping la résolution est bonne, sur du http la résolution est bonne, pour du xmpp la résolution n'est pas bonne ! Le dns c'est sensé être indépendant du protocole...
C'est de l'incompétence ou bien du filtrage [mode parano] et je suis betatesteur du DPI français [/mode parano] ?
Je serai en tunisie [http://fr.readwriteweb.com/2010/06/29/nouveautes/opration-ma(...)] j'comprendrai, mais je suis en France, je n'ai rien à craindre. :)
Internet, et internet par orange, sur adsl aussi.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par syj . Évalué à 1.
A ta place ,j'essairai de reset ta box.
La mienne s'est mise à délirer une fois. L'interface Web plantait, la téléphonie était bloqué, ... un reset et elle est reparti.
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Régulièrement aussi, très souvent en fait, le serveur ppp ne répond pas (il suffit d'attendre).
Il faut dire que je suis dans le var, en bout de ligne, et les lignes sont très pourries. Envisager un dégroupage chez un autre opérateur n'est pas possible, en cas de soucis sur le réseau (froudre ou que sais-je), ce serait juste la fin. Ça c'est chez moi.
Quand je dis les lignes sont pourries, sur un des lieux où je taffe à Toulon, il y a 20mb/s au DSLAM, il est à 1km à vol d'oiseau, je ne sais pas ce que font les cuivres, mais au final on a 1m. Sur un autre lieu en sortie d'agglomération j'ai 512k, de l'autre coté de la route il y a 20m (pas le même DSLAM). Je sais aussi que même sur le cap brun dans les villas de millionnaires et que t'es pote avec quelqu'un haut placé chez Orange dans la région, il y a des endroit où si t'as mieux que du 512k c'est bien.
Encore un autre lieu où je taffe, en centre ville de Fréjus, on n'a pas mieux que 1m aussi.
Et ce n'est pas qu'orange, des fournisseurs pro, j'en ai plusieurs… rien à faire. Il faut des années pour ne serait-ce que commencer à faire admettre qu'il puisse y avoir un problème : ils ont leur batterie de tests qui ont le bon goût de ne pas tester ce qui ne fonctionne pas, et sur lesquels ils se focalisent. Le dialogue de sourds ressemble un peu à cela :
Client : J'ai trop de paquets qui se perdent
Opérateur : Quand je fait un ping le paquet arrive, donc ça marche,
Client : Quand je met telle option au ping j'ai tant de paquets perdus,
Opérateur : Quand je fait un ping le paquet arrive, donc ça marche.
ce genre de cas vécu où ils refusent de tester s'il y a des paquets qui se perdent, et se limitent sciemment à tester s'il y a des paquets qui arrivent.
1 les cuivres sont pourris
2 il n'y a personne pour tirer les câbles.
Pour certains usages le numeris est toujours de rigueur. C'est faible, ça coûte cher, mais à l'époque où ça a été mit en place il y avait des compétences chez FT : on peut compter dessus, ça marche. Avoir 6m de temps en temps et une vingtaine de coupures dans la journée ce n'est pas acceptable. Même sur une sdsl à 1m le ping perd des paquets. J'ai des contraintes assez forte aussi, par exemple j'en ai une qui consiste à transporter du son en temps réel 24h/24. Lorsque l'on me démarche pour de la voip ou des trucs comme ça je rigole, le problème n'est même pas le débit, mais la stabilité du réseau.
En règle général ajouter un nouveau service connecté signifie ajouter une ligne adsl ou sdsl, et de jouer sur les routes.
Pour moi le 56k est toujours une réalité, le coté poilu de la chose c'est que ça m'oblige à faire du shell en mode vi et de naviguer avec les touches alphanumériques. Même pour faire le kador je ne m'y serai pas obligé, mais si je veux être efficace en cas de crise je dois savoir travailler ainsi, c'est juste une nécessité, même en 2010.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par Krunch (site web personnel) . Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
N'importe quel autre DNS, un bind des famille, opendns, google… et ça fonctionne.
Faire un tcpdump correct qui identifie leur erreur, c'est leur boulot, pas le mien : ça non plus ce n'est pas de la spéculation.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par benoar . Évalué à 4.
Je décide de vérifier : dig SRV _xmpp-client._tcp.gmail.com (ou tout autre serveur jabber) et… un joli timeout ! Comme pour les AAAA ! Ce qui fait que ton client jabber se rabat sur le A du serveur (comportement pas top mais pour rétrocompatibilité) qui ne sert donc pas de service jabber.
Bref, Orange casse consciemment Internet en faisant ignorer (même pas retourner une erreur, hein, histoire de bien faire chier en faisant attendre le timeout, et tout ça en se basant sur dnsmasq, un logiciel libre qui marche très bien à la base, et en plus sans en filer les sources il me semble) toutes les requêtes DNS pour des enregistrements autres que des A au resolver de sa box. Ça fait des années que c'est le cas (au moins 4 ans que je le constate) et que par exemple ça casse toute migration possible en IPv6 puisque tous les gens qui ont des linux chez orange ont du désactiver la résolution des AAAA (et ça donne une mauvaise image de linux et de l'IPv6). À une époque, l'excuse c'est que c'était sur des vieilles box sagem qui ne seraient plus mises à jour et que ça marchait « assez bien » comme ça, mais là je viens de voir que c'est sur une livebox récente, donc ça ne tient pas.
Bref, chez Orange on a des incompétents notoires, qui sont capables de foutre en l'air un logiciel libre pour servir un service bancal qui fait que ça casse le réseau d'une manière bien chiante, mais juste pas assez pour que ceux qui gueulent depuis tout ce temps se fassent rembarrer sans recours.
Enfin, je me demande si depuis le temps il faudrait pas faire un recours auprès du RIPE ou de l'UE pour qu'ils arrêtent leurs conneries parce que au bout de tant d'années, ce n'est même plus de l'incompétence, c'est un acte criminel.
[^] # Re: Si vous n'avez pas d'ami chez Free
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
C'était déjà évident que c'était de l'incompétence de leur part dans le sens qu'il suffit de se passer de leur DNS et de mettre dans /etc/resolv.conf le premier DNS venu pour que ça marche mieux, mais ça ne donnait pas quel bêtises ils faisaient. Pour certains sceptiques, montrer que se passer d'Orange résoud le problème ne suffit pas à démontrer que le problème vient d'Orange, là maintenant c'est clair ! :) Merci merci.
ce commentaire est sous licence cc by 4 et précédentes
# Tous les chemins mennent a Rome (enfin, ca dépend)
Posté par goof . Évalué à 6.
Depuis quelques temps et chez plusieurs de mes clients, je constate des erreurs de routages.
En effet des paquets a destination de 192.168.0.1 sont routé vers internet a partir d'un réseau dont la livebox est en 192.168.1.1 (en gros, la configuration d'origine)
On passe aussi par des adresses en 10.XXX.XXX.XXX dans le réseau orange/france télécom (d'après ce que j'en ai lut, ce type de réseaux ne devrait pas exister sur internet, mais je peut me tromper)
Nous avons aussi eut une indisponibilité du réseau Atlas a cause d'une erreur de routage similaire (toujours chez orange)
Le plus étonnant, c'est que cette erreur ne survient pas lorsque je fait les mêmes testes de mon bureau (toujours chez orange)
Les IP fixes ne sont pas non plus protégé de ce genre de "magie"
Le pire est que depuis mon accès je n'ait aucun problème. (en tout cas au moment ou mes clients m'appellent.
A++
Goof
[^] # Re: Tous les chemins mennent a Rome (enfin, ca dépend)
Posté par B16F4RV4RD1N . Évalué à 3.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Tous les chemins mennent a Rome (enfin, ca dépend)
Posté par zebra3 . Évalué à 1.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Tous les chemins mennent a Rome (enfin, ca dépend)
Posté par Sebastien (site web personnel) . Évalué à 4.
> On passe aussi par des adresses en 10.XXX.XXX.XXX dans le réseau orange/france télécom (d'après ce que j'en ai lut, ce type de réseaux ne devrait pas exister sur internet, mais je peut me tromper)
Chacun peut faire ce qu'il veut dans son petit jardin secret tant que ça ne dérange pas les autres.
Les adresses désignés dans la RFC 1918 sont à usage privé et ne sont normalement pas amenées à être adressées entre réseaux différents (et sont souvent filtrées sur les gateway), mais rien n'empêche un opérateur de les utiliser pour son infrastructure.
# Problème similaire
Posté par Sébastien B. . Évalué à 1.
Ma connexion ssh avec l'un de mes VPS (serveur privé virtuel) situé en Allemagne se coupe. Impossible de se reconnecter, impossible de le pinguer. Je me connecte à une dédibox en ssh, je ping mon VPS et ça marchait.
Donc ouais, surement un problème de route comme dit plus haut, en tous cas, maintenant, c'est bien réglé ! Pour le moment.
[^] # Re: Problème similaire
Posté par ymorin . Évalué à 2.
Je cherche aussi un prestataire de VPS, et je regarde les offres à l'étranger.
Qui est ton prestataire en Allemagne ?
[^] # Re: Problème similaire
Posté par Sébastien B. . Évalué à 1.
J'aime bien, par contre moi j'ai une ancienne offre qui était plus avantageuses que celles proposées actuellement, je sais pas si ça vaut toujours le coup. 4 go de stockage pour celui a 7$ c'est vraiment light, moi j'ai 8go pour le même prix.
# se plaindre c'est bien, régler le problème, c'est mieux
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: se plaindre c'est bien, régler le problème, c'est mieux
Posté par Zarmakuizz (site web personnel) . Évalué à 6.
Plus sérieusement, entre chercher une solution au problème, et terminer un projet en 24h au lieu de 2 semaines, j'ai choisi que le projet était prioritaire. Maintenant que le projet est bouclé, je peux me pencher sur la résolution du problème.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.