On Mon, Dec 15, 2008 at 05:59:52PM -0500, Victor Duchovni wrote:
> >
> > and the exact corresponding PCAP capture.
>
> In the capture you provide:
>
> 14:52:49.198960 192.168.10.4.4052 > 192.168.10.248.587: P 582:635(53) ack 5831
> 14:52:49.200609 192.168.10.248.587 > 192.168.10.4.4052: . ack 635
>
> Client sends RCPT TO:<...>
> Server TCP ACK
>
> 14:52:49.814719 192.168.10.248.587 > 192.168.10.4.4052: P 5831:5884(53) ack
> 635
> 14:52:49.825203 192.168.10.4.4052 > 192.168.10.248.587: P 635:672(37) ack 5884
> 14:52:49.825214 192.168.10.248.587 > 192.168.10.4.4052: . ack 672
>
> Server responds 250 2.1.5 Ok
> Client ACKS and sends something of the right length to be "DATA"
> Server TCP ACK
>
> 14:52:49.853073 192.168.10.248.587 > 192.168.10.4.4052: R 5884:5884(0) ack 672
>
> The server TCP ACK is directly followed by an unsolicited TCP RST, and
> the most you can expect out of Postfix is FIN, not RST. Where are you
> capturing the session, at the client or the server? What software on
> the server aborts a TCP session with a RST without receiving traffic
> for an already torn-down connection?
Apparently some Linux (and other) systems implement "half-duplex" TCP
close, which sends RST, not FIN when a socket is closed with application
data unread. If so, we must conclude that indeed the server closes the
connection without reading the client's command. I want to see the
"smtpd_tls_loglevel = 4" packet logging.
> I want to see whether Postfix (which version again?) go to see the
> last chunk of client data.
>
> By the way, the successful session you sent, is a "resumed" session,
> that re-used the SSL keys negotiated at the previous session. All
> this changes is the amount of data sent back and forth between client
> and server. I am again puzzled by the unclean 3-way FIN handshake:
>
> 14:53:06.135744 192.168.10.4.4061 > 192.168.10.248.587: P 964:1001(37) ack 942
> 14:53:06.135757 192.168.10.4.4061 > 192.168.10.248.587: F 1001:1001(0) ack 942
> 14:53:06.150498 192.168.10.248.587 > 192.168.10.4.4061: R 942:942(0) ack 1002
>
> Client sends FIN, but server sends RST. In what manner have you "tuned"
> your server TCP stack to cause this?
This too is interesting, what is it that the server leaves unread in
the success case?
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majord...@postfix.org?body=unsubscribe%20postfix-users>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
