Forum Linux.général Apache: les headers passent, pas les donnees

Posté par  (site web personnel) .
Étiquettes :
0
10
oct.
2006
Hello,

J'ai un probleme etrange, tres etrange meme.

J'ai un serveur tout neuf, tout bien configure. Tout le monde peut y acceder (web), faire ce qu'il y a faire...
Tout le monde? Non, un pc resiste encore et toujours a l'envahisseur: le mien.

Le serveur: Debian stable, Apache 2.0.54

symptomes:
la connection semble se bloquer, sans jamais avoir de timeout.

J'ai fait des essais avec differents navigateurs, inclus lynx, wget, openssl s_client pour le https, sous mon compte habituel, sous le compte d'un utilisateur tout neuf...
Si je passe sous windows: ca marche.
Un autre pc du reseau: ca marche.
A partir de la machine de notre reseau qui fait office de routeur: ca marche.

strace ne donne rien d'interessant.

remarque:
Si je donne l'adresse directe d'une image, je l'obtiens.
Si je donne l'adresse directe d'un css, d'un javascript ou d'un CGI, il n'y a pas de reponse.
Si je donne une fausse url, j'obtiens bien une erreur 404
Ca me fait le coup pour 2 serveurs identiques.

essais un peu plus detailles:
en https: la connexion plante lors du handshake


openssl s_client -connect xxx.xxx.xxx.xxx:443 -state
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
[et la, c'est le drame: plus rien, meme pas de timeout]


en http:

telnet xxx.xxx.xxx.xxx 80
GET / HTTP/1.0
[me donne une bonne reponse: (redirection)]



telnet xxx.xxx.xxx.xxx 80
GET /cgi-bin/admin.cgi HTTP/1.0
[ne plante meme pas, ca fait juste rien du tout]



telnet xxx.xxx.xxx.xxx 80
GET /apache2-default/index.html HTTP/1.0
HTTP/1.1 200 OK
Date: Tue, 10 Oct 2006 11:58:59 GMT
Server: Apache/2.0.54 (Debian GNU/Linux)
Content-Location: index.html.en
Vary: negotiate,accept-language,accept-charset
TCN: choice
Last-Modified: Fri, 28 Jul 2006 08:53:04 GMT
ETag: "68400a-5b1-70c0fc00;974cc940"
Accept-Ranges: bytes
Content-Length: 1457
Connection: close
Content-Type: text/html
Content-Language: en

[et puis plus rien, je n'ai pas les donnees]


Evidemment (ca serait trop facile sinon) les logs d'apache ne me donnent rien d'interessant.
en https, rien n'apparait
en http, j'ai droit au "GET ..." dans les logs, avec le code 200, donc tout semble bien aller.

Si quelqu'un a une idee, une piste, n'importe quoi... Ca m'interesse, Je suis vraiment embete, sur ce coup.

Merci a tout ceux qui ont lu tout ca
  • # Système ?

    Posté par  . Évalué à 2.

    L'erreur ne semble pas venir de la couche HTTP mais plutot du système de ta machine (le client, pas le serveur) (driver carte réseau, couche TCP/IP) ...
    On dirait que tout se bloque au dela d'une certaine quantité de données transmises.

    Essaies de regarder dans les logs du noyau et du coté des trames réseaux.

    Est-ce que tu as des problemes pour acceder aux autres machines de ton réseau ?

    Que se passe-t-il si tu modifie la 404 par default pour la remplacer par un plus gros fichier de test ?

    A force de tout tester tu finiras bien par trouver d'ou ca vient :p

    --
    creber
    • [^] # Re: Système ?

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

      merci pour tes idees, tu m'as en tout cas donne une bonne piste


      On dirait que tout se bloque au dela d'une certaine quantité de données transmises.

      Effectivement, une quantite entre 800 et 1400 octets, a peu pres. Au moins ca donne une piste.

      Pour le reste:
      - logs noyau: rien qui semble se rapporter a ca
      - trames reseaux: wireshark me montre que la connexion se deroule bien jusqu'a ce que ca ne fasse plus rien.
      - pas de souci pour acceder aux autres machines, de mon reseau ou d'ailleurs
      - modifier la 404: j'ai essaye de telecharger un fichier de plus en plus gros (un fichier texte, sans passer par l'erreur 404), c'est ce qui m'a montre que ton idee est sans doute la bonne. La quantite de donnees limite n'est par contre par constante (800 to 1400 octets).

      Je pense que tu m'as donne un piste, mais pourquoi ce ne plante que pour ma machine, et sous linux? Pourquoi avec ce seul serveur, alors qu'un autre quasiment identique (Debian stable aussi, meme appli...) marche parfaitement? Encore pas mal de questions...

      En tout cas merci beaucoup, je continue de creuser.
      • [^] # Re: Système ?

        Posté par  . Évalué à 2.


        - trames reseaux: wireshark me montre que la connexion se deroule bien jusqu'a ce que ca ne fasse plus rien.

        Au niveau de la couche TCP tu as quoi au moment de l'erreur ?
        Une demande de fermeture de connection (FIN / ACK / FIN-ACK) ou vraiment rien du tout ?

        Sinon, est-ce que tu as des firewalls et/ou routeurs entre toi et le serveur ?
        Si oui, t'es-t-il possible de brancher directement ta machine sur le meme segment réseau que le serveur ?

        Enfin si tu peux essayer de brancher une autre carte réseau (modèle différent) sur ta machine et tester avec, cela te permettra de voir si le driver n'est pas en cause.
        (On pourrait imaginer un scénario ou le serveur (Debian stable) modifie les propriété TCP de la connection (Window scalling, ...) a chaud quand il doit transférer une grande taille de donnée et que ton driver perde la boule devant de telles requettes, cela expliquerait pourquoi tu as la meme erreur sur 2 serveurs identiques.)

        --
        creber
        • [^] # Re: Système ?

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

          copier/coller de wireshark:
          (j'ai vire le temps pour fair plus condense [ca se deroule en 2.5secondes]), j'espere que c'est assez lisible.
          Les requetes precedents etaient du samba, donc non pertinente.




          No. Source Destination Protocol Info
          7 10.1.1.6 x.x.x.x TCP 2253 > www [SYN] Seq=0 Len=0 MSS=1460 TSV=21333956 TSER=0 WS=3
          8 x.x.x.x 10.1.1.6 TCP www > 2253 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=19746460 TSER=21333956 WS=0
          9 10.1.1.6 x.x.x.x TCP 2253 > www [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=21333964 TSER=19746460
          10 10.1.1.6 x.x.x.x HTTP GET / HTTP/1.1
          11 x.x.x.x 10.1.1.6 TCP www > 2253 [ACK] Seq=1 Ack=427 Win=6432 Len=0 TSV=19746507 TSER=21333964
          12 x.x.x.x 10.1.1.6 HTTP HTTP/1.1 302 Found (text/html)
          13 10.1.1.6 x.x.x.x TCP 2253 > www [ACK] Seq=427 Ack=587 Win=7016 Len=0 TSV=21333978 TSER=19746507
          14 10.1.1.6 x.x.x.x HTTP GET /apache2-default/ HTTP/1.1
          15 x.x.x.x 10.1.1.6 TCP [TCP segment of a reassembled PDU]
          16 10.1.1.6 x.x.x.x TCP 2253 > www [ACK] Seq=869 Ack=1001 Win=8184 Len=0 TSV=21334026 TSER=19746709

          puis plus rien

          Je pense donc qu'il n'y a vraiment rien du tout.
          Le segment 12 fait une redirection (code 302), jusque la tout va bien. C'est apres qu'il "n'y a rien".
          Il y a le segment 15 qui est peut etre etrange, cependant...

          Entre le serveur et moi il y a 2 routeurs et firewalls.
          Cependant, a partir de ma machine si je boote sous windows tout passe tranquille, comme il faut, comme pour les autres PC sur le meme reseau.

          Je ne sais pas si ca va etre possible de tester une autre carte reseau, mais je vais voir.
          Par contre, je peux faire tout ce que je veux a cote de ca, sur n'importe quel site: telecharger, surfer, ssh... Je serai donc surpris que ca soit un probleme de la carte.

          Merci pour ton aide.
        • [^] # Re: Système ?

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

          D'autres test pour se debarasser de la composante Apache.

          Sur le serveur, je lance:

          perl -e '$i=0;while(1){print $i++ . "\n"}' | nc -v -v -l -p 8000
          => cree un service qui ecoute sur le port 8000 et affiche un compteur.

          du cote client:
          nc serveur 800
          Il faut une cinquantaine de secondes pour que quelque chose s'affiche (compteur ~ 360), 50 de plus pour que ca continue, et apres c'est bon.

          Si je lance le 'service' sur un autre serveur (reseau different), j'obtiens bien le compteur qui s'incremente, tout de suite a la connexion.

          Je continue a creuser...
          • [^] # MTU ?

            Posté par  . Évalué à 3.

            Peut-être une taille de trame max mal configurée sur ton interface, regarde avec ifconfig (1500 pour de l'ethernet, 1492 pour du pppoe.. "Content-Length: 1457" s'en rapproche dangereusement).

            L'outil "tracepath" permet de découvrir la MTU "minimum" entre deux machines (enfin je crois), mais je ne sais pas s'il découvre des erreurs de config

            Aussi dans /proc/net/snmp, la fin de la première ligne IP donne des stats sur les paquets IP fragmentés (plus gros que la MTU, et donc coupés en morceaux), regarde si les "FragFails" ou "ReasmFails" augmentent pendant tes tests (en meme temps, wireshark ne semble rien voir la dessus)
            • [^] # ou ECN

              Posté par  . Évalué à 3.

              Ça me rappelle aussi un probleme que les kernels 2.4.x ont eu il y a quelques années apres avoir implémenté l'ECN (Explicit Congestion Notification) qui est un protocole relativement récent, et qui d'apres ce que j'ai lu utilise des bits sur les paquets IP qui étaient inutilisés. Certaines config de routeur/firewall sur les sites web distants (ou intermédiaires dans le réseau) empéchaient ces paquets "bizarrement formés" de passer.
              C'etait il y a 6 ans, hein; depuis tout le monde a corrigé ses routeurs; mais peut-être que tu es dans ce cas...
              • [^] # Re: ou ECN

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

                Normalement il n'y a que du 2.6, mais je voir ca de plus pret.

                En tout cas merci
            • [^] # Re: MTU ?

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

              Le MTU de mon interface est bien de 1500 (ethernet), tracepath donne 1500 en MTU minimal, donc tout semble bon.

              /proc/net/snmp me donne 0 pour tous les derniers flags, dont tous ceux qui contiennent Frag ou Fail.

              En plus c'est aleatoire: je viens de reussir a me connecter pendant un test... Mais c'est fini, je ne peux plus.

Suivre le flux des commentaires

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