Quoting Simon Horman <[email protected]>: > On Fri, Jun 04, 2010 at 07:01:41PM -0700, Chris Chen wrote: >> Here's a trace of a recent SSL handshake attempt: >> >> 1 0.000000 CLIENT_IP -> SERVER_IP TCP 49168 > urd [SYN] Seq=0 >> Win=8192 Len=0 MSS=1380 WS=2 8192 52 >> 2 0.000010 SERVER_IP -> CLIENT_IP TCP urd > 49168 [SYN, ACK] >> Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=2 5840 52 >> 3 0.000680 CLIENT_IP -> SERVER_IP TCP 49168 > urd [ACK] Seq=1 >> Ack=1 Win=66240 Len=0 66240 40 >> 4 0.000990 CLIENT_IP -> SERVER_IP SSL Client Hello 66240 209 >> 5 0.001005 SERVER_IP -> CLIENT_IP TCP urd > 49168 [ACK] Seq=1 >> Ack=170 Win=6912 Len=0 6912 40 >> 6 0.009298 SERVER_IP -> CLIENT_IP TLSv1 Server Hello, 6912 1420 >> 7 0.009313 SERVER_IP -> CLIENT_IP TLSv1 Certificate, Server Key >> Exchange, Server Hello Done 6912 1356 >> 8 0.010187 CLIENT_IP -> SERVER_IP TCP 49168 > urd [ACK] Seq=170 >> Ack=2697 Win=66240 Len=0 66240 40 >> 9 0.024244 CLIENT_IP -> SERVER_IP TLSv1 Client Key Exchange, >> Change Cipher Spec, Encrypted Handshake Message 66240 174 >> 10 0.025339 SERVER_IP -> CLIENT_IP TLSv1 Change Cipher Spec, >> Encrypted Handshake Message 7984 99 >> 11 0.225653 SERVER_IP -> CLIENT_IP TLSv1 [TCP Retransmission] >> Change Cipher Spec, Encrypted Handshake Message 7984 99 >> 12 0.226324 CLIENT_IP -> SERVER_IP TCP 49168 > urd [ACK] Seq=304 >> Ack=2756 Win=66180 Len=0 SLE=1597629342 SRE=1597629401 66180 52 > > [snip] > >> 23 25.548536 SERVER_IP -> CLIENT_IP TLSv1 [TCP Retransmission] >> Change Cipher Spec, Encrypted Handshake Message 7984 99 >> 24 25.549373 CLIENT_IP -> SERVER_IP TCP [TCP Dup ACK 12#6] 49168 > >> urd [ACK] Seq=304 Ack=2756 Win=66180 Len=0 SLE=1597629342 >> SRE=1597629401 66180 52 >> 25 29.280023 CLIENT_IP -> SERVER_IP TLSv1 Encrypted Alert 66180 77 >> 26 29.280040 SERVER_IP -> CLIENT_IP TLSv1 Application Data 7984 157 >> 27 29.280109 CLIENT_IP -> SERVER_IP TCP 49168 > urd [FIN, ACK] >> Seq=341 Ack=2756 Win=66180 Len=0 66180 40 >> 28 29.280147 SERVER_IP -> CLIENT_IP TCP urd > 49168 [FIN, ACK] >> Seq=2873 Ack=342 Win=7984 Len=0 7984 40 >> 29 29.280582 CLIENT_IP -> SERVER_IP TCP 49168 > urd [RST, ACK] >> Seq=342 Ack=2873 Win=0 Len=0 0 40 >> >> They seem to get into a retransmit loop right after the client sends >> the Change Cipher Spec message. >> >> If I'm running OpenSSL on the windows box and using s_client with >> -connect, I can make it punch through by hitting a carriage return. > > Hi Chris, > > As the client seems to TCP ACK the server's Change Cipher Spec message, > I am guessing that it's application is ignoring it for some reason. > Does the problem occur if you take LVS out of the equation and simply > connect directly to one of the Real Servers from the Windows 7 machine?
Yes, it does. In that case, I may see one retransmit, but the stream recovers by itself. The problem manifests itself on two sets of LVS hosts--both running ipvsadm 1.24, but one on RHEL4, and the other on RHEL5. The real servers are a set of sendmail relays behind the RHEL4 LVS, and a set of Perdition IMAP proxies running behind the RHEL5 LVS. It almost looks like a buffer isn't getting flushed...? Or read? By the way, thanks for the IMAP proxy! cc _______________________________________________ Please read the documentation before posting - it's available at: http://www.linuxvirtualserver.org/ LinuxVirtualServer.org mailing list - [email protected] Send requests to [email protected] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
