Journal Bug dans le TCP/IP de Windows Server 2003

Posté par  (site web personnel) .
Étiquettes : aucune
0
22
avr.
2005
Salut journal,

Dans les 3 derniers mois j'ai mis en lumière un bug dans le TCP/IP de Windows Server 2003.

J'ai écrit un article en anglais que j'aurais voulu voir publié sur Slashdot pour m'aider à résoudre ou contourner ce bug, étant donné que Microsoft n'a rien réussi à faire et ne fera probablement rien.

Voici l'url de l'article :

http://www.dariospagnolo.org/index.php/2005/04/11/1-microsoft-windo(...)

Un court résumé du bug : il se manifeste lors de transferts rapides (plus de 1Mbit/s) entre le serveur et un client relativement éloigné (plus de 80ms). Ce qui ne marche pas, c'est l'algorithme qui est responsable d'envoyer la bonne quantité de données en fonction de la distance du client et de la bande passante disponible. Pour les connaisseurs, le serveur s'arrete d'envoyer des données avant même d'avoir atteint le TCP Window Size annoncé par le client. Ce qui est bien sur contraire au RFC-qui-va-bien et entraine un ralentissement considérable de la vitesse de transfert.

Pourquoi j'écris ce journal ?

- Pour faire part de ce problème à un public technique qui pourra peut-être confirmer ce bug et éventuellement découvrir d'autres facettes.

- Pour faire monter le Google PR de mon article, dans l'espoir qu'il soit rediffusé à plus grande échelle

Pourquoi je fais chier LinuxFr avec un probleme de Windows ?

- Parce que j'ai lu sur http://linuxfr.org/journal/new.html(...) que "les journaux sont destinés à des informations [...] qui sont sans rapport avec Linux ou le libre", donc j'en profite pour les raisons énoncées ci-dessus.

Voilà, bonne lecture à ceux qui voudront bien le lire.

  • # troll ...

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

    je ne suis pas tres douer en tcp/ip mais ca me rassure dans mon idee que microsoft le gere tres mal dans ses OS ...
    depuis 5 ans que j ai decouvert d autre OS que les leur je trouve de plus en plus minable les utilitaire de configuration d outils reseau ...
    le pire dans tout ca pour moi c est qu il ne sont meme pas capable de faire tourner netbios convenablement vu que les perf de samba me parraisse bien meilleur ...

    bref pour moi un windos en reseau c est pas des perf de folie et le pire c est que j avais cru comprendre que la certif tcp/ip de microsoft etait la meilleur dans ce dommaine ...


    voila mon troll de la journee

    ps : le bouton moinsé est juste en dessous ---->[]

    • [^] # Re: troll ...

      Posté par  . Évalué à 2.

      Bof, il me semblait justement que la pile ip de windows venait de bsd. Apres ce qu'ils en ont fait, je sais pas...

      • [^] # Re: troll ...

        Posté par  . Évalué à 5.

        Il ne faut pas se fier aux rumeurs, la stack est 100% MS

        • [^] # Re: troll ...

          Posté par  . Évalué à 2.

          Mais il y a bien des bouts qui viennent de BSD, non ?

          Au hazard, winnt\system32\drivers\etc\host...

          • [^] # Re: troll ...

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

            en meme temps sans aller chercher tres loin : La base de windos nt est OS/2 developper par IBM (oui oui ils leur ont voler officiellement tu peux chercher sur la wikipedia pour plus de detail) et IBM c est aussi AIX un unix base sur BSD il me semble ...
            donc de la a dire qu'il n y a pas des bous de AIX dans OS/2 donc dans windos nt (il suffit de regarder les message d erreur ou les fichier systeme si on en est pas sur)

            • [^] # Re: troll ...

              Posté par  . Évalué à 7.

              Un bon cours d'histoire informatique te ferais du bien je crois.

              a) AIX n'a rien du tout a voir avec OS/2, mais alors rien du tout
              b) OS/2 a ete developpe en commun par Microsoft et IBM, et a un moment ils ont forke
              c) NT n'a rien a voir avec OS/2 non plus, NT etait prevu pour etre le kernel sur lequel l'OS OS/2 serait base, mais quand MS et IBM se sont separes, MS a implemente Win32 par dessus NT (et une personality OS/2 basique pour etre compatible), alors que IBM est parti creer son propre kernel pour baser son OS/2 dessus

          • [^] # Re: troll ...

            Posté par  . Évalué à 5.

            C'est un fichier qui est choisi avec le meme nom histoire que les gens s'y retrouvent plus facilement, de la meme maniere que Winsock implemente les API berkeley afin que les softs soient facilement portables, ca veut pas dire que le code sous jacent est le meme.

            • [^] # Re: troll ...

              Posté par  . Évalué à 2.

              Pas convaincu...

              Je trouve vraiment étrange de voir ce genre de fichier alors que ça ne correspond pas vraiment à la philosophie Windows : pourquoi mettre ces infos dans un fichier texte à la sauce unixienne alors qu'il y a la base de registre ou à la limite un .ini

              Et je ne vois pas quels softs iraient lire ce genre de fichier, même sous les unix classiques personnes ne va lire /etc/hosts, c'est juste à la résolution de noms que le système va d'abord là avant de taper sur le DNS. Et c'est le boulot de l'OS, donc à la limite peu importe comment il fait. Ok pour les APIs communes, mais je ne voyais pas le fichier hosts comme une API...

              M'enfin sinon je suis bien content que ce fichier soit là, parfois ça permer de se simplifier la vie lorsque les modifs de DNS sont trop lente (pbs de bureaucratie... )

              • [^] # Re: troll ...

                Posté par  . Évalué à 2.

                Pour info, ce fichier n'est absolument pas utilise par la stack tcp/ip, ce fichier est utilise par la resolution de noms(DNS client), la stack tcp/ip elle ne traite rien d'autre que des addresses IP. J'ai pris cet exemple pour te faire comprendre la logique dans laquelle des softs sont ecrits, ils peuvent sembler similaires de l'exterieur, et c'est normal car c'est le but, mais sont ecrit de maniere totalement differente de l'interieur.

                Et je ne vois pas quels softs iraient lire ce genre de fichier, même sous les unix classiques personnes ne va lire /etc/hosts, c'est juste à la résolution de noms que le système va d'abord là avant de taper sur le DNS. Et c'est le boulot de l'OS, donc à la limite peu importe comment il fait. Ok pour les APIs communes, mais je ne voyais pas le fichier hosts comme une API...

                Un fichier c'est une API, si tu regardes une fonction exportee, c'est rien d'autre qu'une description du format des donnees a envoyer, un fichier et son format c'est la meme chose. Tu peux prendre un /etc/hosts sur Unix et le transposer sur Windows tres simplement, voila un des avantages.

                • [^] # Re: troll ...

                  Posté par  . Évalué à 4.

                  Pour info, ce fichier n'est absolument pas utilise par la stack tcp/ip, ce fichier est utilise par la resolution de noms(DNS client), la stack tcp/ip elle ne traite rien d'autre que des addresses IP. J'ai pris cet exemple pour te faire comprendre la logique dans laquelle des softs sont ecrits, ils peuvent sembler similaires de l'exterieur, et c'est normal car c'est le but, mais sont ecrit de maniere totalement differente de l'interieur.

                  Il n'empèche que c'est bien curieux de voir ce fichier là - avec le "etc" - alors que ça aurait été plus logique de retrouver ça par exemple dans un onglet de la fenêtre "Paramètres TCP/IP avancés" qui cause DNS (joli mélange des couches au passage).

                  Et pourquoi ne pas mettre aussi un fichier 'interfaces' pour définir les adresses et les routes par défaut ? et un 'nsswitch.conf' ?

                  Tu peux prendre un /etc/hosts sur Unix et le transposer sur Windows tres simplement, voila un des avantages.

                  C'est de l'interopérabilité, c'est ça ? Depuis le temps que Microsoft en parle, ça y'est, on l'a trouvée ! ;-)

                  • [^] # Re: troll ...

                    Posté par  . Évalué à 1.

                    Il n'empèche que c'est bien curieux de voir ce fichier là - avec le "etc" - alors que ça aurait été plus logique de retrouver ça par exemple dans un onglet de la fenêtre "Paramètres TCP/IP avancés" qui cause DNS (joli mélange des couches au passage).

                    Toi tu trouves ca curieux, bcp de gens non, il fallait bien les mettre qqe part, les mettre a travers l'interface graphique c'est bien, mais il faut les stocker qqe part apres, et la registry est pas faite pour ca, resultat, un fichier est l'endroit le plus logique.

      • [^] # Re: troll ...

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

        en fait vu que c est bsd qui a creer le tcp/ip si je me souvient bien ben ils n ont pu que le recopier voir le plagier un peu comme ils semble avoir fait pour iptable et sp2

        • [^] # Re: troll ...

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

          Moi j'avais cru comprendre que la pile TCP/IP ajoutée à Windows du temps de 95 (ou quelque part par là ?) venait des BSD mais qu'elle a été réecrite par la suite. Mais bon je connais pas grand chose à l'histoire de Windows non plus.

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

          • [^] # Re: troll ...

            Posté par  . Évalué à 2.

            La stack du temps de 95 avait ete achetee a une boite, et cette boite s'etait basee sur BSD, mais ensuite MS a reecrit sa propre stack pour resoudre les nombreux problemes de perf et autres qui se trouvaient dans cette vieille stack.

          • [^] # Re: troll ...

            Posté par  . Évalué à 2.

            En ce qui concerne le kernel NT, il s'agit d'un micro-kernel conçu par Microsoft par des personnes débauchées de feu Digital UNIX. Le kernel avait donc à l'origine un design très proche de celui de OpenVMS (qui est d'ailleurs toujours commercialisé par HP).
            Après, on se doute bien que Microsoft n'a pas récupéré la partie TCP/IP sur VMS qui était prévu à l'origine pour fonctionner sur DECnet (même si une pile TCP/IP a été rajoutée depuis).

            Pour les curieux:
            http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=4494(...)

            --
            SK

  • # TCP/IP et XP SP2

    Posté par  . Évalué à 4.

    Quitte à être hors sujet ....

    Quelques connaissances m'ont rapporté que la pile TCP/IP de Windows XP était bridée en appliquant le SP2. Cela, soit disant pour des raisons de sécurité, pour contrer des attaques type Sasser ou Blaster (et accessoirement faire c...é les utilisateurs de P2P). On reconnait bien là, la politique légendaire de Microsoft en matière de sécurité, puisque cette limitation serait contournable via une improbable valeur dans une clé de la fumeuse base de registre.

    J'utilise le conditionnel, parce que d'une part je n'utilise pas Windows et d'autre part ça me parait tellement débile, que j'ai du mal à croire les quelques sites qui relatent ce "problème".

    Une bonne âme pour me confirmer que ce n'est pas un canular ?

    • [^] # Re: TCP/IP et XP SP2

      Posté par  . Évalué à 6.

      On reconnait bien là, la politique légendaire de Microsoft en matière de sécurité, puisque cette limitation serait contournable via une improbable valeur dans une clé de la fumeuse base de registre.

      C'est pas configurable dans la registry, c'est en dur dans la stack.

      • [^] # Re: TCP/IP et XP SP2

        Posté par  . Évalué à 0.

        Je sais pas où tu vois que c'est en dure mais il existe bien une clée pour la base de registre pour contourner ce problème
        (enfin je tatte pas suffisament Windows XP pour rentrer dans les détails)

        • [^] # Re: TCP/IP et XP SP2

          Posté par  . Évalué à 3.

          Je te paries 1 million qu'il n'y a aucune cle de registre pour contourner la chose. Mais a ta place je parierai pas, on est en train de parler du composant sur lequel je bosses tous les jours :+)

          • [^] # Re: TCP/IP et XP SP2

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

            Il y a une clée de registre qui devait s'occuper de ça mais qui dans la version definitive de win xp sp2 est ignoré.

            Tu peux demander aux équipes de dev de réactiver cette clée, svp ?
            J'ai ai marre de lancer nlite pour patcher chaque cd-rom d'installation que je trouve (j'en profite pour virer Internet Explorer mais c'est un autre sujet).

            • [^] # Re: TCP/IP et XP SP2

              Posté par  . Évalué à 2.

              Merci en passant pour m'avoir fait découvir nlite!!!

              Je n'utilise pas Windows ni personnellement, ni professionnellement, mais j'en connais plus d'un que cet outil devrait interesser!!!

              merci donc!!

            • [^] # Re: TCP/IP et XP SP2

              Posté par  . Évalué à 2.

              On a _volontairement_ bloque cette cle de registre, le but de cette feature est d'empecher les worms genre blaster/sasser/... d'infecter un reseau de maniere rapide, si une cle de registre permet de passer outre, t'imagines bien que le worm va changer cette cle de registre lui-meme et elle n'aura alors plus aucun sens.

              • [^] # Re: TCP/IP et XP SP2

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

                Le worms ils peut aussi patcher le tcpip.sys donc cela ne tient pas.
                Et puis, la plupart des utilisateurs qui utilisent un soft demandant des ressources réseau se font brider par ça.

                Et puis le worm, s'il n'est pas ****, il se charge dans le kernel nt de maniere a excuté son code en ring 0 .

                • [^] # Re: TCP/IP et XP SP2

                  Posté par  . Évalué à -1.

                  Selon ce site [1] la clé dans la base de registre existe et microsoft aurait même publié un patch [2] pour corriger le problème...

                  [1] http://www.pyrat.net/Windows-XP-SP2-et-limitation-du.html(...)
                  [2] http://www.microsoft.com/downloads/details.aspx?displaylang=fr&(...)

                  • [^] # Re: TCP/IP et XP SP2

                    Posté par  . Évalué à 2.

                    Ils se sont plantes, le patch en question fixe un probleme relatif au loopback (127.x.x.x), rien a voir avec la limitation en SYN_SENT

                • [^] # Re: TCP/IP et XP SP2

                  Posté par  . Évalué à 3.

                  Pour patcher tcpip.sys le worm doit etre admin, si il est utilisateur il ira nulle part.

                  Et puis le worm, s'il n'est pas ****, il se charge dans le kernel nt de maniere a excuté son code en ring 0 .

                  Il peut, mais ca limite de nouveau le type de worm, ils peuvent pas etre executes par un user simple, ils doivent etre assez complexe pour pouvoir patcher un kernel, etc... bref ca rehausse la difficulte. Le but n'est pas d'empecher totalement les worms, on sait que c'est pas possible, le but est de rendre la chose plus difficile.

              • [^] # Re: TCP/IP et XP SP2

                Posté par  . Évalué à 2.

                Bien sûr que si, sinon des spécifications telles que

                http://www.faqs.org/rfcs/rfc3514.html(...)

                n'auraient jamais vu le jour ! :-)

  • # Plus d'info

    Posté par  . Évalué à 4.

    T'aurais une capture reseau de la chose(filtree pour ne contenir que ce qui est necessaire si possible...) histoire que je jette un coup d'oeil ? Ma preference va a Netmon, mais si c'est du Ethereal je peux vivre avec.

Suivre le flux des commentaires

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