<-FIN <-RST ->FIN,ACK <-RST on SSL connection shutdown
Hello,
a typical connection close, tcpdump'ed on the server side, looks as follows:
21:44:01.168131 IP xxx.xxx.3.101.143 > xxx.xxx.3.96.35518: Flags [FP.], seq 3982457856:3982457959, ack 1570044906, win 243, options [nop,nop,TS val 138698279 ecr 159494908], length 103 21:44:01.172405 IP xxx.xxx.3.101.143 > xxx.xxx.3.96.35518: Flags [R], seq 3982457960, win 0, length 0 21:44:01.172442 IP xxx.xxx.3.96.35518 > xxx.xxx.3.101.143: Flags [F.], seq 32, ack 104, win 342, options [nop,nop,TS val 159494909 ecr 138698279], length 0 21:44:01.172471 IP xxx.xxx.3.101.143 > xxx.xxx.3.96.35518: Flags [R], seq 3982457960, win 0, length 0
The server closes (FIN) the connection, and already 4.274 ms later the server sends a RST to the client. The clients response to FIN arrives some μs later. (On the client side the order of the packages is different (FIN from Server, FIN,ACK from client, RST from Server, RST from Server)
This behaviour seems to be odd (the client side firewall complains about the unexpected packages).
I can reproduce it using openssl -connect … -starttls imap .. on the client side. It happens on IMAP+STARTTLS as well as on IMAPS. It does not happen on plaintext IMAP. There I see the expected shudown handshake FIN - FIN,ACK - ACK.
Dovecot version is 2.2.24 (a82c823)
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
-- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
participants (1)
-
Heiko Schlittermann