Bonjour,

Les logs d'iptables m'indiquent que des paquets RST en provenance d'un
serveur pop3 (en l'occurrence pop.free.fr) sont bloqués. J'ai
découvert que l'erreur se produit quand fetchmail se connecte pour
récupérer les courriels en attente.

La fin de la transaction (m'indique ethereal) se compose de la
séquence suivante:
moi -> pop.free.fr : 1623* > 110 (FIN ACK)
pop.free.fr -> moi : 110 > 1623 (FIN ACK)
moi -> pop.free.fr : 1623 > 110 (ACK)
pop.free.fr -> moi : 110 > 1623 (ACK)
***pop.free.fr -> moi : 110 > 1623 (RST)***

C'est ce dernier paquet qui est bloqué (d'où dans mes logs des
messages du type: Sep 2 05:08:15 goun kernel: ABORTED IN=eth1 OUT=
SRC=212.27.48.3 DST=82.227.203.184 LEN=40 TOS=0x00 PREC=0x00 TTL=246
ID=0 PROTO=TCP SPT=110 DPT=1623 SEQ=2537307165 ACK=0 WINDOW=0
RES=0x00 RST URGP=0).

Cependant, quand j'utilise fetchmail pour récupérer les courriels sur
un autre serveur (ici: pop.infonie.fr), je ne reçois pas ce paquet
RST. La séquence de fin est en effet la suivante:
moi -> pop.infonie.fr : 4886* > 110 (FIN ACK)
pop.infonie.fr -> moi : 110 > 4886 (FIN ACK)
moi -> pop.infonie.fr : 4886* > 110 (ACK)
pop.infonie.fr -> moi : 110 > 4886 (ACK)

et c'est tout.

D'où mes interrogations:
* est-il normal que le serveur pop3 de Free m'envoie un tel paquet?
* Est-il normal que ma machine n'y réponde pas?
* Est-il normal que le serveur pop3 d'Infonie (Tiscali/Libertysurf,
etc.) n'envoie pas un tel paquet?
* Faut-il que je règle fetchmail pour qu'il attende poliement cette
séquence reset (et si oui, comment?)?

Merci de vos conseils.


====Note====
(*) Port > 1024 variable.

--
apt-get moo

[supersedes, grmbl]

Salut,

Vincent Ramos a écrit :
>
> Les logs d'iptables m'indiquent que des paquets RST en provenance d'un
> serveur pop3 (en l'occurrence pop.free.fr) sont bloqués. J'ai
> découvert que l'erreur se produit quand fetchmail se connecte pour
> récupérer les courriels en attente.
>
> La fin de la transaction (m'indique ethereal) se compose de la
> séquence suivante :
> moi -> pop.free.fr : 1623* > 110 (FIN ACK)
> pop.free.fr -> moi : 110 > 1623 (FIN ACK)
> moi -> pop.free.fr : 1623 > 110 (ACK)
> pop.free.fr -> moi : 110 > 1623 (ACK)
> ***pop.free.fr -> moi : 110 > 1623 (RST)***

Je viens d'essayer en telnet sous Linux et Windows 2000, et le serveur
POP de Free me renvoie aussi un RST environ 8 secondes après la
fermeture normale de la connexion par l'échange des FIN, que cette
fermeture ait été à l'initiative du client ou du serveur du point de vue
TCP (premier FIN). Par contre j'ai des variations dans le séquencement
des ACK, mais il est possible que ce soit dû aux différences entre les
piles TCP/IP des OS.

> Cependant, quand j'utilise fetchmail pour récupérer les courriels sur
> un autre serveur (ici : pop.infonie.fr), je ne reçois pas ce paquet
> RST. La séquence de fin est en effet la suivante :
> moi -> pop.infonie.fr : 4886* > 110 (FIN ACK)
> pop.infonie.fr -> moi : 110 > 4886 (FIN ACK)
> moi -> pop.infonie.fr : 4886* > 110 (ACK)
> pop.infonie.fr -> moi : 110 > 4886 (ACK)
>
> et c'est tout.

J'ai essayé avec le serveur POP de Nerim, il n'envoie pas de RST non plus.

> D'où mes interrogations :
> * est-il normal que le serveur pop3 de Free m'envoie un tel paquet ?

Non. La connexion est déjà fermée depuis plusieurs secondes par
l'échange de FIN. Je ne vois pas à quoi peut servir ce RST.

> * Est-il normal que ma machine n'y réponde pas ?

Oui. On ne doit pas répondre à un RST.

> * Est-il normal que le serveur pop3 d'Infonie (Tiscali/Libertysurf,
> etc.) n'envoie pas un tel paquet ?

Oui. Le serveur POP de Nerim n'en envoie pas non plus.

> * Faut-il que je règle fetchmail pour qu'il attende poliement cette
> séquence reset (et si oui, comment ?) ?

AMA Fetchmail n'a pas grand chose à voir là-dedans. C'est la pile TCP/IP
de l'OS qui gère les états de la connexion TCP.

Par contre il y a un détail qui ne me semble pas terrible, mais ça n'a
peut-être pas d'importance. Tu écris dans tes messages publiés dans
fr.comp.securite que fetchmail termine la communication POP par une
commande QUIT. Il me semble que dans ce cas, c'est le serveur qui doit
mettre fin à la connexion TCP en envoyant le premier FIN après le
message de fin. En tout cas j'ai toujours vu faire ainsi. Or apparemment
c'est ton fetchmail qui envoie le premier FIN. C'est peut-être pour cela
que tu as cette séquence bizarre FIN - FIN - ACK - ACK (les FIN étant
envoyés simultanément des deux côtés) au lieu de l'habituel FIN -
ACK/FIN - ACK.

[Note: je copie cette réponse dans fr.comp.reseaux.ip et propose d'y
rediriger la suite (fu2). Répondre dans un seul forum de préférence.]

[supersedes, grmbl]

Salut,

Vincent Ramos a écrit :
>
> Les logs d'iptables m'indiquent que des paquets RST en provenance d'un
> serveur pop3 (en l'occurrence pop.free.fr) sont bloqués. J'ai
> découvert que l'erreur se produit quand fetchmail se connecte pour
> récupérer les courriels en attente.
>
> La fin de la transaction (m'indique ethereal) se compose de la
> séquence suivante :
> moi -> pop.free.fr : 1623* > 110 (FIN ACK)
> pop.free.fr -> moi : 110 > 1623 (FIN ACK)
> moi -> pop.free.fr : 1623 > 110 (ACK)
> pop.free.fr -> moi : 110 > 1623 (ACK)
> ***pop.free.fr -> moi : 110 > 1623 (RST)***

Je viens d'essayer en telnet sous Linux et Windows 2000, et le serveur
POP de Free me renvoie aussi un RST environ 8 secondes après la
fermeture normale de la connexion par l'échange des FIN, que cette
fermeture ait été à l'initiative du client ou du serveur du point de vue
TCP (premier FIN). Par contre j'ai des variations dans le séquencement
des ACK, mais il est possible que ce soit dû aux différences entre les
piles TCP/IP des OS.

> Cependant, quand j'utilise fetchmail pour récupérer les courriels sur
> un autre serveur (ici : pop.infonie.fr), je ne reçois pas ce paquet
> RST. La séquence de fin est en effet la suivante :
> moi -> pop.infonie.fr : 4886* > 110 (FIN ACK)
> pop.infonie.fr -> moi : 110 > 4886 (FIN ACK)
> moi -> pop.infonie.fr : 4886* > 110 (ACK)
> pop.infonie.fr -> moi : 110 > 4886 (ACK)
>
> et c'est tout.

J'ai essayé avec le serveur POP de Nerim, il n'envoie pas de RST non plus.

> D'où mes interrogations :
> * est-il normal que le serveur pop3 de Free m'envoie un tel paquet ?

Non. La connexion est déjà fermée depuis plusieurs secondes par
l'échange de FIN. Je ne vois pas à quoi peut servir ce RST.

> * Est-il normal que ma machine n'y réponde pas ?

Oui. On ne doit pas répondre à un RST.

> * Est-il normal que le serveur pop3 d'Infonie (Tiscali/Libertysurf,
> etc.) n'envoie pas un tel paquet ?

Oui. Le serveur POP de Nerim n'en envoie pas non plus.

> * Faut-il que je règle fetchmail pour qu'il attende poliement cette
> séquence reset (et si oui, comment ?) ?

AMA Fetchmail n'a pas grand chose à voir là-dedans. C'est la pile TCP/IP
de l'OS qui gère les états de la connexion TCP.

Par contre il y a un détail qui ne me semble pas terrible, mais ça n'a
peut-être pas d'importance. Tu écris dans tes messages publiés dans
fr.comp.securite que fetchmail termine la communication POP par une
commande QUIT. Il me semble que dans ce cas, c'est le serveur qui doit
mettre fin à la connexion TCP en envoyant le premier FIN après le
message de fin. En tout cas j'ai toujours vu faire ainsi. Or apparemment
c'est ton fetchmail qui envoie le premier FIN. C'est peut-être pour cela
que tu as cette séquence bizarre FIN - FIN - ACK - ACK (les FIN étant
envoyés simultanément des deux côtés) au lieu de l'habituel FIN -
ACK/FIN - ACK.

[Note: je copie cette réponse dans fr.comp.reseaux.ip et propose d'y
rediriger la suite (fu2). Répondre dans un seul forum de préférence.]