FS-9113, still experiencing TLS crashes
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.ht..., 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 Your lights would be so appreciated, I'm losing my mind over this. Best, Emrah
Can you confirm if the packet is shown in freeswitch tport_log?
On Nov 8, 2016, at 5:02 PM, Emrah <lists@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.ht... <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.
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@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@kavun.ch <mailto:lists@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.ht... <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@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
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@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@jerris.com <mailto:mike@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@kavun.ch <mailto:lists@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.ht... <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.
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@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@kavun.ch <mailto:lists@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@jerris.com <mailto:mike@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@kavun.ch <mailto:lists@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.ht... <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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@jerris.com <mailto:mike@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@kavun.ch <mailto:lists@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@jerris.com <mailto:mike@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@kavun.ch <mailto:lists@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.ht... <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@freeswitch.org <mailto:consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
You could either use a self-signed cert for a nonexistent domain (example.com?) and modify your hosts file or DNS to point to he server. I think that should give you an environment to reproduce the crash which you could share without leaking your private cert.
On 9 Nov 2016, at 20:28, Emrah <lists@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@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@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@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@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.ht..., 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
Your lights would be so appreciated, I'm losing my mind over this.
Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I agree, as long as I get to reproduce it that way. I am suspecting everything here. From the keysize to the CA to the TCP transport getting compromised to openssl not reliably transmitting certain packets to FS. Thanks for the suggestion
On Nov 10, 2016, at 5:58 PM, Alejandro Recarey <ar@cyberfonica.com> wrote:
You could either use a self-signed cert for a nonexistent domain (example.com <http://example.com/>?) and modify your hosts file or DNS to point to he server. I think that should give you an environment to reproduce the crash which you could share without leaking your private cert.
On 9 Nov 2016, at 20:28, Emrah <lists@kavun.ch <mailto:lists@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@jerris.com <mailto:mike@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@kavun.ch <mailto:lists@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@jerris.com <mailto:mike@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@kavun.ch <mailto:lists@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.ht... <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@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
We actually built a test server, but weren't able to reproduce the issue. I can bring it up again if needed. On 10 Nov 2016 20:25, "Emrah" <lists@kavun.ch> wrote:
I agree, as long as I get to reproduce it that way. I am suspecting everything here. From the keysize to the CA to the TCP transport getting compromised to openssl not reliably transmitting certain packets to FS.
Thanks for the suggestion
On Nov 10, 2016, at 5:58 PM, Alejandro Recarey <ar@cyberfonica.com> wrote:
You could either use a self-signed cert for a nonexistent domain ( example.com?) and modify your hosts file or DNS to point to he server. I think that should give you an environment to reproduce the crash which you could share without leaking your private cert.
On 9 Nov 2016, at 20:28, Emrah <lists@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@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@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@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@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, 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
Your lights would be so appreciated, I'm losing my mind over this.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Stan, we were able to reproduce the issue. You even commented on the jira about it. I went MIA after using the fix provided by Ethan so we never really got to the bottom of it. Could you please share the snapshot of that machine with me? We should take that environment as the base and try the same environment updated to the latest unstable also. Best, Emrah
On Nov 12, 2016, at 10:45 PM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
We actually built a test server, but weren't able to reproduce the issue. I can bring it up again if needed.
On 10 Nov 2016 20:25, "Emrah" <lists@kavun.ch <mailto:lists@kavun.ch>> wrote: I agree, as long as I get to reproduce it that way. I am suspecting everything here. From the keysize to the CA to the TCP transport getting compromised to openssl not reliably transmitting certain packets to FS.
Thanks for the suggestion
On Nov 10, 2016, at 5:58 PM, Alejandro Recarey <ar@cyberfonica.com <mailto:ar@cyberfonica.com>> wrote:
You could either use a self-signed cert for a nonexistent domain (example.com <http://example.com/>?) and modify your hosts file or DNS to point to he server. I think that should give you an environment to reproduce the crash which you could share without leaking your private cert.
On 9 Nov 2016, at 20:28, Emrah <lists@kavun.ch <mailto:lists@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@jerris.com <mailto:mike@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@kavun.ch <mailto:lists@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@jerris.com <mailto:mike@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@kavun.ch <mailto:lists@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.ht... <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@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/> _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (4)
-
Alejandro Recarey
-
Emrah
-
Michael Jerris
-
Stanislav Sinyagin