pbs erreur 104

[thorkym]

Bonjour,

J'utilise 2 Ipcop pour mes 2 fai wanadoo et free, tous marche très bien même si j'ai encore des zones d'ombre pour l'administration d'ipcop, mais pour mon utilité cela tourne bien.

Sauf que depuis quelque temps impossible de consulter le site de la FNAIM et de faire une recherche de biens (sauf par recherche rapide à droite).

Une erreur me revient

read error " (104) Connection reset by peer.

cela ce produit dans plusieurs structure ou j'ai installer 1 ipcop.

et après avoir passer 3 -4 coups de tel avec les informaticien de la FNAIM visiblement cela viendrait de chez moi snif

.

pourriez vous m'aider merci

ps: le site de la FNAIM est primordial dans ma profession....l'immobilier

encore merci de vos retour

[ccnet]

pourriez vous m'aider merci

Cela va être très difficile pour les raisons suivantes :

1. Aucune information technique précise sur votre configuration. Deux connexion, deux ipcop ne croyez vous pas que cela demande quelques précisions ?
2. Manifestement aucune recherche de votre part ici ou bien sur Goggle.

Vous savez ce qu'il reste à faire ...

[Franck78]

c'est pas compliqué de deviner (dommage cependant) l'url www.fnaim.fr

quand au fautif c'est moins certain, loin de la

1) firefox ou konquerror, avec ou sans squid:
Ca marche en raccourciçant l'url

2) konquerror sans squid, ca marche.

Question de longueur quelque part......

[Gesp]

quelle version d'IPCop?

Cela détermine la version de squid utilisée.
Le problème se manifeste-t-il avec et sans le proxy?

[thorkym]

Bonjour,

pour plus de précision j'ai la possibilité sur mon réseau de sortir par deux FAI donc 2 ipcop différent free et wanadoo au cas ou l'un ou l'autre tombe.

Le soucis je le rencontre tant sur l'ipcop de free que sur celui de wanadoo, mes moteurs de recherche sont firefox version 2 et la 3 ie 6 et ie 7.

version ip cop 1.4
squid mis a jour hier pour une 2., quand au problème je ne le rencontre pas quand le proxy est désactiver.

le raccourcis url ne marche seule la recherche rapide (droite sur la page) sur la page www.fnaim.fr marche

konquerror pas essayer.

dsl pour le temps de réponse mais sur en congé paternité depuis hier midi donc je ferais mes test a distance.

en espérant que cela vous donne plus d'explication

[Franck78]

Voila l'URL qui fait délirer le système:

http://www.fnaim.fr/recherche.html?call=results_biens&category=location&type_maison=1&type_appartement=0&type_terrain=0&type_parking=0&type_immeuble=0&type_immobilier=0&FNAIM_Input_Ville_Values=&FNAIM_Input_Ville=&FNAIM_Input_Ville_2=&FNAIM_Input_Ville_3=&FNAIM_Input_Ville_4=&FNAIM_Input_CP=78800&proximite=Exacte&maison_prix_min=&maison_prix_max=&maison_pieces_min=&maison_pieces_max=&maison_surface_min=&maison_surface_max=&maison_terrain_min=&maison_terrain_max=&appartement_prix_min=&appartement_prix_max=&appartement_pieces_min=&appartement_pieces_max=&appartement_surface_min=&appartement_surface_max=&maisonappt_prix_min=&maisonappt_prix_max=&maisonappt_pieces_min=&maisonappt_pieces_max=&maisonappt_surface_min=&maisonappt_surface_max=&maisonappt_terrain_min=&maisonappt_terrain_max=&terrain_prix_min=&terrain_prix_max=&terrain_terrain_min=&terrain_terrain_max=&parking_prix_min=&parking_prix_max=&parking_surface_min=&parking_surface_max=&immeuble_prix_min=&immeuble_prix_max=&immeuble_lots_min=&immeuble_lots_max=&immeuble_surface_min=&immeuble_surface_max=&type_reel=Bureau+-+local+pro.&immobilier_prix_min=&immobilier_prix_max=&immobilier_surface_min=&immobilier_surface_max=&maison_etat=indifferent&appartement_etat=indifferent&maisonappt_etat=indifferent&immeuble_etat=indifferent&x=120&y=18

si quelques un d'entre vous, chers lecteurs, peuvent donner le résultat obtenu (pas forcément avec un IPCop)...

[ccnet]

Freebox. Pfsense 1.2, pas de proxy. Navigateur Firefox 3.0.1 sur XP.
L'url passe sans problème.

[jdh]

Le problème est pas du côté de fnaim ?

Ferait bien de revoir leur formulaire (en method=POST et non en method=GET) ! cf http://www.w3schools.com/tags/tag_form.asp : you MUST use POST !

Il parait clair que la longueur de l'url est en cause ...


(Comme d'hab, on commence par rejeter l'erreur chez l'autre ... sans mettre en cause sa propre expertise ! Plutôt que d'augmenter la puissance du serveur web, un reverse proxy est utile, et déjà le problème aurait été vu chez fnaim. Bien évidemment cela est sous toutes réserves : il est possible qu'il ait des pré-requis donnés, mais une url de cette longueur c'est quant même n'importe quoi et surement la porte ouverte à des "sql injection".)


(dans un camping, avec un hot spot "maison", l'url ne fonctionne pas : je vois qu'est utilisé Squid 2.6.STABLE5 mais je ne connais pas du tout l'archi réseau locale.).


(le manque de renseignement initial est navrant : relisez vous et croyez vous que l'on puisse vous aidez ?)

[Gesp]

version ip cop 1.4
squid mis a jour hier pour une 2., quand au problème je ne le rencontre pas quand le proxy est désactiver.

Ce qui est important, c'est le chiffre après 1.4 pour la version IPCop.
Si ce n'est pas 1.4.21, cela veut dire que vous utilisez une ancienne version d'IPCop (et de squid qui a été mis à jour en 1.4.19/1.4.20).

Je ne sais pas ce que cela veut dire ce que vous avez formulé à propos de squid?

[Poupou94]

Bonjour,

Firefox 3.0, IPCop 1.4.21, proxy transparent, freebox V4, la page est normale.

Pascal.

[Franck78]

1.4.21, bien sur, proxy activé mais avec RED is modem. Différence par rapport à poupou avec sa freebox.

Gilles, tu peux tout à fait essayer...

[Gesp]

Ok je peux reproduire le problème en utilisant l'URL.

Je vais regarder en activant les options de debug de squid (squid -k).

[Franck78]

Peut que le debug t'apprendra quelque chose mais vraiment, ce n'est pas squid qui est en cause.
Il se contente de "présenter l'erreur".

En direct avec firefox, j'obtiens

Code: Tout sélectionner

Connexion interrompue

         

La connexion avec le serveur a été réinitialisée pendant le chargement de la page.

       
La liaison au réseau a été interrompue pendant la négociation d'une connexion. Veuillez réessayer.


       
       
[Ressayer]     
     

Et en supprimant juste un petit bout d'URL, ca passe...

Fait le contraire chez toi, rallonge l'URL, sans squid. Tu es en routeur ou REDisModem?

[Gesp]

Peut que le debug t'apprendra quelque chose mais vraiment, ce n'est pas squid qui est en cause.

Si
Quand squid est désactivé, cela fonctionne chez moi, que ce soit avec IE ou firefox.
Je doute vraiment que cela dépende de la configuration (RED ou RED is modem).

Pas trop sur que ce soit lié à la longueur de l'URL
Celle-ci bloque aussi quand je clique dessus dans une page existante mais pas je tape l'URL dans la barre d'adresse
http://www.fnaim.fr/annonces-immobilier ... -5201.html

tcpdump -src www.fnaim.fr -s 0 -n montre ceci

13:34:53.410177 IP 78.24.128.14.80 > 192.168.x.x.3414: . 1:1461(1460) ack 1858 win 11680
V...Oo...P.-.V...HTTP/1.0 502 Bad Gateway
Server: squid/2.6.STABLE21
Date: Sat, 09 Aug 2008 11:34:52 GMT
Content-Type: text/html
Content-Length: 1208
Expires: Sat, 09 Aug 2008 11:34:52 GMT
X-Squid-Error: ERR_READ_ERROR 104
X-Cache: MISS from ipcop.maison
Via: 1.0 ipcop.maison:800 (squid/2.6.STABLE21)
Connection: close

J'ai trouvé cela bizarre comme trace parce que 78.24.128.14.80 ne connait pas tous les détails du proxy. Donc c'est squid qui insère cela à la volée à partir du moment ou est reçu le Bad Gateway.

Le serveur fnaim est
http://toolbar.netcraft.com/site_report ... w.fnaim.fr

Je vais envoyer un message sur la liste squid-user.

[Franck78]

oublie squid.

voila un tcpdump d'échange fautif:

Code: Tout sélectionner

22:00:14.422468 IP 78.24.128.14.80 > 86.72.26.111.38526: S 1403573:1403573(0) ack 2129896726 win 470 <mss 1460>
22:00:14.422740 IP 86.72.26.111.38526 > 78.24.128.14.80: . ack 1 win 5840
22:00:14.422908 IP 86.72.26.111.38526 > 78.24.128.14.80: . 1:236(235) ack 1 win 5840
22:00:14.422925 IP 86.72.26.111.38526 > 78.24.128.14.80: P 236:471(235) ack 1 win 5840
22:00:14.482472 IP 78.24.128.14.80 > 86.72.26.111.38526: . ack 236 win 470 <mss 1460>
22:00:14.482759 IP 86.72.26.111.38526 > 78.24.128.14.80: . 471:706(235) ack 1 win 5840
22:00:14.492474 IP 78.24.128.14.80 > 86.72.26.111.38526: . ack 471 win 470 <mss 1460>
22:00:14.492668 IP 86.72.26.111.38526 > 78.24.128.14.80: P 706:941(235) ack 1 win 5840
22:00:14.542502 IP 78.24.128.14.80 > 86.72.26.111.38526: . ack 706 win 470 <mss 1460>
22:00:14.542878 IP 86.72.26.111.38526 > 78.24.128.14.80: . 941:1176(235) ack 1 win 5840
22:00:14.552490 IP 78.24.128.14.80 > 86.72.26.111.38526: . ack 941 win 470 <mss 1460>
22:00:14.552831 IP 86.72.26.111.38526 > 78.24.128.14.80: P 1176:1411(235) ack 1 win 5840
22:00:14.602468 IP 78.24.128.14.80 > 86.72.26.111.38526: . ack 1176 win 470 <mss 1460>
22:00:14.602738 IP 86.72.26.111.38526 > 78.24.128.14.80: . 1411:1646(235) ack 1 win 5840
22:00:14.612474 IP 78.24.128.14.80 > 86.72.26.111.38526: . ack 1411 win 470 <mss 1460>
22:00:14.612701 IP 86.72.26.111.38526 > 78.24.128.14.80: P 1646:1881(235) ack 1 win 5840
22:00:14.662467 IP 78.24.128.14.80 > 86.72.26.111.38526: . ack 1646 win 470 <mss 1460>
22:00:14.662712 IP 86.72.26.111.38526 > 78.24.128.14.80: P 1881:1967(86) ack 1 win 5840
22:00:14.672473 IP 78.24.128.14.80 > 86.72.26.111.38526: . ack 1881 win 470 <mss 1460>
22:00:14.931004 IP 86.72.26.111.38526 > 78.24.128.14.80: P 1881:1967(86) ack 1 win 5840
22:00:14.982472 IP 78.24.128.14.80 > 86.72.26.111.38526: R 1403574:1403574(0) win 0



note la retransmission, l'avant dernière ligne. Dès que le serveur la recoit, il balance le RST. normal ou pas ???
Le client attend ~250 millisecondes avant de renvoyer la frame......alors qu'il a recu le ack!

Ca c'était la capture TCPDUMP sur IPCop. Mais je retrouve l'identique sur mon PC. Ce n'est donc pas IPCop à première vue.


L'équivalent capturé sur le PC source:

Code: Tout sélectionner

No.     Time        Source                Destination           Protocol Info
     21 0.296399    10.0.0.2              78.24.128.14          HTTP     Continuation or non-HTTP traffic

Frame 21 (140 bytes on wire, 140 bytes captured)
Ethernet II, Src: AsustekC_bf:29:eb (00:11:d8:bf:29:eb), Dst: CnetTech_26:75:cb (00:08:a1:26:75:cb)
Internet Protocol, Src: 10.0.0.2 (10.0.0.2), Dst: 78.24.128.14 (78.24.128.14)
Transmission Control Protocol, Src Port: 38287 (38287), Dst Port: http (80), Seq: 1881, Ack: 1, Len: 86
    Source port: 38287 (38287)
    Destination port: http (80)
    Sequence number: 1881    (relative sequence number)
    [Next sequence number: 1967    (relative sequence number)]
    Acknowledgement number: 1    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
    Window size: 5840
    Checksum: 0xd898 [incorrect, should be 0xa6f2 (maybe caused by "TCP checksum offload"?)]
    [SEQ/ACK analysis]
Hypertext Transfer Protocol
    Data (86 bytes)

0000  62 35 35 38 37 32 30 63 39 65 37 36 33 63 38 35   b558720c9e763c85
0010  36 34 35 61 31 33 36 38 35 63 66 64 31 35 3b 20   645a13685cfd15;
0020  5f 5f 75 74 6d 62 3d 31 33 32 33 38 35 31 31 33   __utmb=132385113
0030  2e 33 2e 31 30 2e 31 32 31 38 33 31 30 37 30 35   .3.10.1218310705
0040  3b 20 5f 5f 75 74 6d 63 3d 31 33 32 33 38 35 31   ; __utmc=1323851
0050  31 33 0d 0a 0d 0a                                 13....
        Data: 623535383732306339653736336338353634356131333638...

No.     Time        Source                Destination           Protocol Info
     22 0.296412    78.24.128.14          10.0.0.2              TCP      http > 38287 [ACK] Seq=1 Ack=1881 Win=470 Len=0 MSS=1460

Frame 22 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: CnetTech_26:75:cb (00:08:a1:26:75:cb), Dst: AsustekC_bf:29:eb (00:11:d8:bf:29:eb)
Internet Protocol, Src: 78.24.128.14 (78.24.128.14), Dst: 10.0.0.2 (10.0.0.2)
Transmission Control Protocol, Src Port: http (80), Dst Port: 38287 (38287), Seq: 1, Ack: 1881, Len: 0
    Source port: http (80)
    Destination port: 38287 (38287)
    Sequence number: 1    (relative sequence number)
    Acknowledgement number: 1881    (relative ack number)
    Header length: 24 bytes
    Flags: 0x10 (ACK)
    Window size: 470
    Checksum: 0xcb1f [correct]
    Options: (4 bytes)

No.     Time        Source                Destination           Protocol Info
     23 0.555901    10.0.0.2              78.24.128.14          HTTP     [TCP Retransmission] Continuation or non-HTTP traffic

Frame 23 (140 bytes on wire, 140 bytes captured)
Ethernet II, Src: AsustekC_bf:29:eb (00:11:d8:bf:29:eb), Dst: CnetTech_26:75:cb (00:08:a1:26:75:cb)
Internet Protocol, Src: 10.0.0.2 (10.0.0.2), Dst: 78.24.128.14 (78.24.128.14)
Transmission Control Protocol, Src Port: 38287 (38287), Dst Port: http (80), Seq: 1881, Ack: 1, Len: 86
    Source port: 38287 (38287)
    Destination port: http (80)
    Sequence number: 1881    (relative sequence number)
    [Next sequence number: 1967    (relative sequence number)]
    Acknowledgement number: 1    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
    Window size: 5840
    Checksum: 0xd898 [incorrect, should be 0xa6f2 (maybe caused by "TCP checksum offload"?)]
    [SEQ/ACK analysis]
Hypertext Transfer Protocol
    Data (86 bytes)

0000  62 35 35 38 37 32 30 63 39 65 37 36 33 63 38 35   b558720c9e763c85
0010  36 34 35 61 31 33 36 38 35 63 66 64 31 35 3b 20   645a13685cfd15;
0020  5f 5f 75 74 6d 62 3d 31 33 32 33 38 35 31 31 33   __utmb=132385113
0030  2e 33 2e 31 30 2e 31 32 31 38 33 31 30 37 30 35   .3.10.1218310705
0040  3b 20 5f 5f 75 74 6d 63 3d 31 33 32 33 38 35 31   ; __utmc=1323851
0050  31 33 0d 0a 0d 0a                                 13....
        Data: 623535383732306339653736336338353634356131333638...

No.     Time        Source                Destination           Protocol Info
     24 0.606313    78.24.128.14          10.0.0.2              TCP      http > 38287 [RST] Seq=1 Win=0 Len=0

Frame 24 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: CnetTech_26:75:cb (00:08:a1:26:75:cb), Dst: AsustekC_bf:29:eb (00:11:d8:bf:29:eb)
Internet Protocol, Src: 78.24.128.14 (78.24.128.14), Dst: 10.0.0.2 (10.0.0.2)
Transmission Control Protocol, Src Port: http (80), Dst Port: 38287 (38287), Seq: 1, Len: 0
    Source port: http (80)
    Destination port: 38287 (38287)
    Sequence number: 1    (relative sequence number)
    Header length: 20 bytes
    Flags: 0x04 (RST)
    Window size: 0
    Checksum: 0xb64b [correct]


Voila, les spécialistes de tcp répondront à la question suivante: une retransmission d'une frame déjà acknoledgée provoque t'elle un RST de la connexion.....