|
Quoting Simon Horman <horms@xxxxxxxxxxxx>:
> 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 - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
