tortoiseSVN client errors out on some commits

Whoa, this is very wierd. I was just posting a message about this exact same problem. I found that disabling the SSL cache in the Client SSL Profile fixes it, but my DevCentral post was going to ask the question why?

 

 

In my case, I took a network trace and found the client initiates two TCP connections sequentially. In the first connection, the LTM sends a Server Hello response with a Session ID, the handshake goes on to successful completion, and the client submits a bunch of (wierd) HTTP requests. At some point, the Subversion server responded with a HTTP 409 Conflict which initiates a teardown of the TCP session. The client turns around and tries to open a new TCP session, and sends exactly the same Session ID that was sent by the LTM in the first TCP connection. And that packet is ACKed by the LTM, but then the connection sits idle until the TCP connection times out. Disabling the SSL cache in the Client SSL Profile seems to force the LTM to send the certificates on each new TCP connection. The question is why won't the LTM allow the client to open a new TCP connection using a cached session?

 

 

I have no idea how to troubleshoot this. Does anyone else?

 

 

Also, the iRules forum doesn't seem like the right place for this thread - can the moderators move it to somewhere appropriate?

I changed the Cache Size to zero, and that fixed it. This prevents the LTM from caching SSL sessions, and forces the client to go through the full handshake each time they connect.

So we tried setting cache size to 0 as you suggested, and the developer was able to complete his TortoiseSVN commits for the first time without error.

 

I'm not too happy leaving caching at 0 - but since the SVN SSL sessions are typically sporadic and long running, am I right in thinking cache=0 for this SVN VIP will be less of an impact than if we did cache=0 on the main website VIPs?

 

 

thanks and Go Sharks ;)

 

I'm not too happy leaving caching at 0

 

I am not happy either that I can't explain why the LTM is behaving this way, and that makes the LTM look bad. I have seen mention of TLS-related bugs - I'm wondering if this is somehow related. But I'm not enough of a TLS/SSL expert to diagnose what's happening. To me, it simply looks like the client is attempting to establish a SSH session with valid Session ID, and the LTM is ignoring it. I'm running 10.2.0. Maybe someone else with a bit more TLS knowledge can weigh in.

 

 

The question of impact to your main VIPs is really a dependent on your environment. To give you some context, my busiest LTM pair (6900) averages a sustained 100 SSL TPS, 400-500k active connections, and ~800 HTTP requests/sec, with ~500 :443 VIPs (~1200 total). But our TortoiseSVN user base is a small group of people, so the impact of disabling SSL session cache for their one SSL VIP is minimal. What is more of a headache for me is managing its customized Client SSL Profile.

Just saw "SOL13512 Change in Behavior: The BIG-IP SSL profiles support the TLS Renegotiation Indication Extension". Perhaps that is the answer, if I can figure out the RFC. Not likely.