Pascal Hambourg writes:
> Donc le côté qui envoie le FIN devrait s'attendre à ce que l'autre côté
> envoie encore des données avant d'envoyer son propre FIN.
Je viens de faire un essai en local (fetchmail vers un pop3s local),
et j'obtiens un comportement normal FIN/FIN-ACK, fin de la connexion.
Nicolas KOWALSKI a écrit :
>
> - fin de la connexion initiée par le serveur distant, FIN:
>
> 08:29:12.000665 IP 74.125.79.109.995 > 192.168.0.1.51542: F 2051:2051(0) ack
> 444 win 106
>
> - mais mon serveur continue à envoyer des choses, le QUIT peut-être:
>
> 08:29:12.001353 IP 192.168.0.1.
fra-duf-no-s...@tourde.org (François TOURDE) writes:
>
> J'imagine que le meilleur moyen de savoir est de faire un dump du
> traffic, pour être sûr. Mais il se peut que la fermeture de la liaison
> soit à l'initiative des deux côtés (ton fetchmailer envoie "QUIT" puis
> un paquet FIN, ton serveur à
Pascal Hambourg writes:
> Nicolas KOWALSKI a écrit :
>> A priori ce classement a dû être changé dans les dernières versions du
>> noyau, car ces erreurs n'apparaissaient pas en 2.6.26. C'est depuis
>> une mise-à-jour en 2.6.32 (backports) que je vois ces drops.
>
> /me fouille dans les changelogs
Nicolas KOWALSKI a écrit :
>
> Normalement on devrait avoir du FIN depuis mon-serveur puis FIN-ACK
> depuis le serveur distant, non ?
Oui, c'est la façon normale de terminer une connexion TCP. RST ne sert
normalement que pour répondre à un paquet TCP inattendu, comme une
demande de connexion SYN
Nicolas KOWALSKI a écrit :
> Pascal Hambourg writes:
>> Ce sont des TCP RST (reset) qui sont classés - à tort ou à raison -
>> comme INVALID par le suivi de connexion de netfilter. Rien de grave a
>> priori s'il n'y a pas d'effet secondaire.
>
> Merci pour ta réponse. Tant mieux si c'est sans dom
Le 14672ième jour après Epoch,
Nicolas KOWALSKI écrivait:
> fra-duf-no-s...@tourde.org (François TOURDE) writes:
>> Ton programme de récupération (fetchmail?) quitte avant d'attendre la
>> fin de la liaison (le paquet RST). Du coup le port 48882 est considéré
>> comme déconnecté, et les paquets de
fra-duf-no-s...@tourde.org (François TOURDE) writes:
>>
>> Mar 4 18:07:07 petole DROP: IN=eth0 OUT=
>> MAC=00:40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRC=74.125.77.109
>> DST=192.168.0.1 LEN=40 TOS=00 PREC=0x00 TTL=53 ID=24852 PROTO=TCP SPT=995
>> DPT=48882 SEQ=1083545547 ACK=0 WINDOW=0 RST UR
Pascal Hambourg writes:
>
>> Mar 4 18:07:07 petole DROP: IN=eth0 OUT=
>> MAC=00:40:ca:17:85:18:00:07:cb:cf:5a:5a:08:00 SRC=74.125.77.109
>> DST=192.168.0.1 LEN=40 TOS=00 PREC=0x00 TTL=53 ID=24852 PROTO=TCP SPT=995
>> DPT=48882 SEQ=1083545547 ACK=0 WINDOW=0 RST URGP=0
>> Mar 4 18:07:07 peto
Le 14672ième jour après Epoch,
Nicolas KOWALSKI écrivait:
> Bonjour,
[...]
> Ce qui m'étonne ce sont les drops visibles dans les logs, qui
> apparemment concernent les paquets retour des serveur pop3s que
> j'interroge, alors que iptables est sensé accepter les connexions
> établies (-A INPUT -m s
Nicolas KOWALSKI a écrit :
>
> Ce qui m'étonne ce sont les drops visibles dans les logs, qui
> apparemment concernent les paquets retour des serveur pop3s que
> j'interroge, alors que iptables est sensé accepter les connexions
> établies (-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT). L
Bonjour,
J'ai quelques règles iptables sur ma machines pour filtrer les
requètes entrantes :
# iptables-save
# Generated by iptables-save v1.4.2 on Thu Mar 4 18:03:12 2010
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [56903:19141251]
-A INPUT -i lo -j ACCEPT
-A INPUT -s 192.1
12 matches
Mail list logo
