Journal Github caché par de petites oranges ?

Posté par (page perso) .
Tags : aucun
-9
17
déc.
2010
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 !
  • # as tu essayé

    Posté par . Évalué à 2.

    de changer de dns?
    • [^] # Re: as tu essayé

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

      Je vais surtout utiliser la connexion internet illimitée par Free du voisin généreux pour terminer mon projet.

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

  • # Chezmwé çamarche

    Posté par . Évalué à 2.


    Je viens de tester à l'instant et ça marche. (le pull, le push, le site oueb)
  • # héhé

    Posté par . Évalué à 10.

    Rebonjour :)
    • [^] # Re: héhé

      Posté par . Évalué à 4.

      C'est vraiment nal nul comme blague.

      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 . Évalué à 4.

        oui mais c'est à nal..
  • # çapu ...

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

    twittez vos ... cépalibre.

    hop ------>[]

    * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

  • # Si vous n'avez pas d'ami chez Free

    Posté par . Évalué à 7.

    ... ou si votre ami est chez Free mais n'est pas généreux, pour savoir si un site est down pour tout le monde ou si c'est juste chez vous, il faut le tester sur : http://downforeveryoneorjustme.com/
    • [^] # Re: Si vous n'avez pas d'ami chez Free

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

      Non mais ça ne suffit pas, il y a vraiment des choses qui ne marchent pas *quand on passe* par Orange, alors que la résolution dns semble répondre quelque chose d'acceptable, et que le ping répond, ben non ça ne marche pas. En général éviter leurs DNS moisi est déjà une bonne idée. En fait Orange si tu veux que ça marche, faut pas les utiliser comme autre chose qu'un fournisseur de tuyau, le tuyau marchotte quand tu arrive à l'avoir, faut pas en demander plus.

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Si vous n'avez pas d'ami chez Free

        Posté par . Évalué à 0.

        SI le ping répond et pas l'affichage de la page web, il faut jeter un oeil au MTU.
        • [^] # Re: Si vous n'avez pas d'ami chez Free

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

          Internet != Web !
          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 . Évalué à 2.

            Je suis pas spécialiste, mais le MTU est grosso-modo la taille des paquets qui vont transiter. Si tu envoie de gros paquets et qu'ils doivent être tronqués entre-temps, il y a des configuration pourries qui font que... bin ça marche pas. Donc un ping marche (petit paquet par défaut), mais une consultation web (ou d'autres services si ça peut te faire plaisir) ne marche pas.

            Baisse le MTU fortement, et regarde si ça marche mieux. Par exemple :
            ifconfig eth0 mtu 1000
            • [^] # Re: Si vous n'avez pas d'ami chez Free

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

              le MTU est généralement à 1500 en ethernet, le réduire à 1496 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).

              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 . Évalué à 3.

                1°) tous les équipements ne répondent pas forcément "icmp mtu exceeded" quand ils rajoutent des entêtes et dépassent le mtu de sortie -> ils droppent silencieusement le paquet.
                (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 (page perso) . Évalué à 3.

                > le MTU est généralement à 1500 en ethernet, le réduire à 1496
                > 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 . Évalué à 3.

                  AMHA 1496 c'est souvent le rajout de l'entête des vlan (4octets, 802.1q)
                  • [^] # Re: Si vous n'avez pas d'ami chez Free

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

                    1492 est aussi acceptable (Christophe Colomb inside toussa...)
                    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 (page perso) . Évalué à 4.

              j'ai essayé le coup du mtu, ça n'a rien changé
              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 . Évalué à 1.

                Je suis chez Orange. Je viens de tester Gtalk avec pidgin. çà marche

                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 (page perso) . Évalué à 2.

                  En fait la box je la reset au moins une fois par mois (à cause du wifi qui se vautre).
                  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 (page perso) . Évalué à 2.

                    Au passage, faire tenir entre 60 et 90 personnes sur la 512k de secours quand la 1m est en rade, avec ce que les gens font sur Internet aujourd'hui, c'est sportif. :)

                    ce commentaire est sous licence cc by 4 et précédentes

              • [^] # Re: Si vous n'avez pas d'ami chez Free

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

                En attendant tu spécules sans récupérer un tcpdump correct qui permettrait de vérifier les requètes DNS effectuées.

                pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                • [^] # Re: Si vous n'avez pas d'ami chez Free

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

                  En attendant je spécule mais depuis que je suis sur cette ligne, le DNS d'orange n'a jamais fonctionné correctement, quelque soit l'erreur. Ça c'est pas de la spéculation.
                  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 . Évalué à 4.

                Il se trouve que je suis en vacances chez quelqu'un qui a justement un abonnement Orange, et ce problème me rapelle quelque chose… oui, le cassage des AAAA par Orange !

                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 (page perso) . Évalué à 2.

                  Ah ! Chouette, merci d'avoir apporté cette explication !

                  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 . Évalué à 6.

    Salut

    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 . Évalué à 3.

      Aucun problème de mon côté éga

      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 (page perso) . É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 . Évalué à 1.

    Tiens donc, j'ai eu un problème similaire cette après midi.
    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 . Évalué à 2.

      > [...] VPS (serveur privé virtuel) situé en Allemagne [...]

      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 . Évalué à 1.

        Nqhost : http://nqhost.com/
        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 (page perso) . Évalué à 2.

    Et tu as regardé exactement ce qui se passe au niveau réseau (tcpdump est ton ami toussa) ou bien tu préfères juste troller en publique sans faire quoi que ce soit pour essayer de régler le problème ?

    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 (page perso) . Évalué à 6.

      C'est vendredi, c'est donc permis :)

      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 à ceux qui les ont postés. Nous n'en sommes pas responsables.