[Freeswitch-users] FS-9113, still experiencing TLS crashes

[Emrah]

Michael and the list,
Without doing anything on the FS side, calls are going through fine today with both TLS and SDES in use on my clients.

When calls started failing, I had to disable SRTP on my clients to be able to be able to make calls again. TLS stayed on. I also disconnected a Polycom phone to switch it to a none TLS environment.
Today, one of the Yealink I had left unchanged (TLS + SRTP), is working fine again. I cannot get it to break, whereas a few hours prior it would crash the TLS session consistently for every single call.

Remember that FS gets the initial packets up to the ACK after the 407 Proxy Authentication Required is sent. It's the following invite that is never received, except if I disable SRTP. This made me conclude that it's a packet size / segmentation issue of my TCP packet.

Are you aware of any network layer control that could be causing this? Buffering on Linux in any way? Any concept of a TCP pool that could be getting full? Anything of that nature, that was flushed or emptied by the reduced number of clients calling using TLS + SRTP?

It's a long shot, but I thought I'd lay it here, see if it sparks something in your bright minds.

Thanks!
> On Nov 9, 2016, at 8:28 PM, Emrah <lists at kavun.ch> wrote:
> 
> It's the "reliably" part that's tricky. 
> I'm using commercial certificates, so let me figure out how to replicate a similar environment. I'll email you the info once I have a setup, and you can circulate where needed.
> 
> Thanks for helping on this
>> On Nov 9, 2016, at 4:25 PM, Michael Jerris <mike at jerris.com <mailto:mike at jerris.com>> wrote:
>> 
>> I need a recipie to reliably reproduce this so I can dig in the code.  Is there a way you can put together an environment where this can be reproduced on demand?
>> 
>>> On Nov 9, 2016, at 3:39 AM, Emrah <lists at kavun.ch <mailto:lists at kavun.ch>> wrote:
>>> 
>>> No Sir, the response packet to the 407 Proxy Authentication Required is never received. So the session then eventually gets abandoned by FS. On the client side, and this is generalized, the packet is sent, except the TLS session breaks.
>>> 
>>>> On Nov 8, 2016, at 11:41 PM, Michael Jerris <mike at jerris.com <mailto:mike at jerris.com>> wrote:
>>>> 
>>>> Can you confirm if the packet is shown in freeswitch tport_log?
>>>> 
>>>>> On Nov 8, 2016, at 5:02 PM, Emrah <lists at kavun.ch <mailto:lists at kavun.ch>> wrote:
>>>>> 
>>>>> Hello List,
>>>>> Thanks to the help provided by Stanislav, I learned of issue #9113, https://freeswitch.org/jira/si/jira.issueviews:issue-html/FS-9113/FS-9113.html <https://freeswitch.org/jira/si/jira.issueviews:issue-html/FS-9113/FS-9113.html>, which seems to be related to the issues I have been experiencing with FreeSWITCH, TLS and failed call setups.
>>>>> Coincidentally, or not, the fix pushed on that issue was aligned with whole months where I did not experience any TLS issues. Calls were going through fine, until all of a sudden they started failing again. This is on 2 distinct servers running a load balanced FS setup, and using Yealink phones.
>>>>> 
>>>>> To sum up, here is what is going on.
>>>>> From the Yealink, calls with TLS work if I don't use SRTP.
>>>>> From the Yealink, calls crash if I use TLS and SRTP.
>>>>> From my laptop softphone, calls only crash sometimes if I use TLS and SRTP.
>>>>> 
>>>>> How can I debug the TLS session on the FreeSWITCH side to see what happens with the TLS thread? I don't mean packet capture.
>>>>> 
>>>>> I have a feeling that the packet size is too large and doesn't make it to the FS box intact after the 407 Proxy Required is received by the client.
>>>>> 
>>>>> Here is the log for the Yealink:
>>>>> http://pastebin.com/smKP286x <http://pastebin.com/smKP286x>
>>>>> 
>>>>> Your lights would be so appreciated, I'm losing my mind over this.
>>>> 
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services: 
>> consulting at freeswitch.org <mailto:consulting at freeswitch.org>
>> http://www.freeswitchsolutions.com
>> 
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://confluence.freeswitch.org
>> http://www.cluecon.com
>> 
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20161110/51382b1e/attachment.html