[OpenSIPS-Devel] [ opensips-Bugs-3580526 ] NATHELPER and OPTIONS ping for tcp proto
Bugs item #3580526, was opened at 2012-10-26 05:52 Message generated for change (Comment added) made by nikbyte You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3580526group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Nobody/Anonymous (nobody) Summary: NATHELPER and OPTIONS ping for tcp proto Initial Comment: nathelper don't want to ping abonents with TCP transport. Here is a small patch: Index: modules/nathelper/nathelper.c === --- modules/nathelper/nathelper.c (revision 9391) +++ modules/nathelper/nathelper.c (working copy) @@ -1228,8 +1228,6 @@ continue; } } - if (curi.proto != PROTO_UDP curi.proto != PROTO_NONE) - continue; if (curi.port_no == 0) curi.port_no = SIP_PORT; proto = curi.proto; -- Comment By: Nick Altmann (nikbyte) Date: 2012-10-29 23:29 Message: Uploaded patch to add sipping_tcp option. -- Comment By: Nick Altmann (nikbyte) Date: 2012-10-29 01:00 Message: I think you disable OPTIONS because we can use tcp keepalives. But sometimes we need exactly OPTIONS pings via tcp protocol. I suggest to add a module option to enable/disable OPTIONS pings via tcp. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3580526group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3552688 ] opensips crash with TLS
Bugs item #3552688, was opened at 2012-07-31 09:28 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3552688group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: 1.7.x Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Dragos Oancea (dragosoancea) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: opensips crash with TLS Initial Comment: Hi all, opensips 1.7.2 crashes when using TLS with create_dialog(Pp) in the routing script - that would send OPTIONS (nat ping) both to caller and callee during a dialog . The TLS-related relevant lines in the routing script are: tls_verify_server = 1 tls_verify_client = 0 tls_require_client_certificate = 0 tls_method = TLSv1 tls_certificate = /etc/pki/CA/certs/x.crt tls_private_key = /etc/pki/CA/private/x.key tls_ca_list = /etc/pki/CA/certs/ca.crt listen = tls:X.X.X.X:5061 listen = tcp:X.X.X.X:5060 syslog: http://pastebin.com/Kkdns7Cr backtrace: http://pastebin.com/7P4ADL9y Apparently it crashes just after trying to send an OPTIONS or BYE to a device that is not there anymore (it's not on the socket opensips expects it to be - opensips usually generates a 477 SendFailed reply in situations like this) . and interesting enough, if I add an udp port to listen to with listen=udp:X.X.X.X:5060 does not crash anymore. Regards, Dragos -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-10-30 01:54 Message: Hi Dragos, Is this still happening with the latest code from 1.8 SVN branch ? Regards, Bogdan -- Comment By: Dragos Oancea (dragosoancea) Date: 2012-08-29 06:25 Message: Hi It happened again. This time I had only two phones registered via TLS and I was just making a call between them. gdb: http://pastebin.com/1miGb7ct log (stderr): http://pastebin.com/bvDjLzPh can someone confirm it is related to 3522861 ? Cheers, Dragos -- Comment By: Dragos Oancea (dragosoancea) Date: 2012-08-16 04:00 Message: Hi I think there is only one problem. so because the OPTIONS is sent to the wrong interface , no reply will come back , and opensips will generate and send a BYE bothways. but in my case everything is running fine..with OPTIONS being sent to the right places at first , then something happends (memory corruption) , and maybe the function that does the pinging is first to access some unallocated memory. The crash could also happen when the callee or the caller sends BYE. Some extra informations: There are mobile devices under NAT running on TCP or TLS involved in this whole scenario. So when the mobile device is not there anymore (it ran out of battery durring a call for example) , the crash is most likely to happen. Also , I noticed that there is no problem if I only listen to tls (not listening on tcp, not listening on udp). But I need tcp , so I cannot disable it. another gdb backtrace : http://pastebin.com/aXgABJtE I hope to replicate this in a controlled environment with memlog/memdump soon and let you. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-08-15 06:16 Message: Probably related to 3522861 -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-08-08 08:55 Message: Hi, I see here 2 issues - one is the crash itself (which seems to be a memory corruption) ; second one is related to pinging, which seems not to choose the right interface (selects a UDP one instead TLS). I suggest first trying to identify the mem issue, and for this you need to recompile with memory debugging support (http://www.opensips.org/Resources/DocsTsMem , set memlog=6, memdump=1) . most probably the interface issues triggers some bogus mem ops.. Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3552688group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3574453 ] b2b_logic: too small setup timeout when topology hiding
Bugs item #3574453, was opened at 2012-10-04 05:25 Message generated for change (Comment added) made by nikbyte You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3574453group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open Resolution: Fixed Priority: 7 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: b2b_logic: too small setup timeout when topology hiding Initial Comment: When b2b creates topology hiding scenario, it setups too small call setup time: /* if it will not be confirmed - delete */ tuple-lifetime = 60 + get_ticks(); When alice calls bob and bob don't answer for 60 seconds, b2b send CANCEL to both sides. I think we should give possibility to configure this parameter, either in AVP or b2b_init_request flags like b2b_init_request(top hiding/t300). I'd can to write the patch after discussion about what method to use. -- Comment By: Nick Altmann (nikbyte) Date: 2012-10-30 02:27 Message: Trunk - patch works as expected. 1.8 - docs patch uploaded (opensips_1.8_b2bl_th_init_timeout_docs.patch) -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-10-29 05:10 Message: Nick, Please do not forget to provide patch for docs for patch v1 (used on 1.8). Thanks and regards, Bogdan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-10-26 03:39 Message: Hi Nick, Thank you for your patches - for 1.8 I uploaded the fix with the minimal change (v1) - but please provide a small patch with the corresponding docs. For trunk I used the v3 patch, with some changes - please let me know if still works ok :). Regards, Bogdan -- Comment By: Nick Altmann (nikbyte) Date: 2012-10-22 04:34 Message: Look at new patch please (opensips_b2bl_tc_init_time_v3.patch). -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-10-21 08:01 Message: Hi Nick, I will go for v2, but I have some objection regarding your approach - I see you moved the scenario lookup from the fixup function to runtime part, which is totally inefficient - instead of doing the lookup once, you do it for each call. What I suggest here is to do both the scenario lookup and the flag detection in the fixup function. You can simply do that by replacing the param 1 (after fixup) with a structure (pkg) holding the scenario ID (as originally) plus the flag string. Or even better, the structure can already parse expend the flags, so that at runtime you have everything prepared. If you have doubts on how to do this, just let me know and I will do it as soon as I'll get available time. Regards, Bogdan -- Comment By: Nick Altmann (nikbyte) Date: 2012-10-15 05:10 Message: Here are two patches: 1. opensips_b2bl_tc_init_time_v1.patch Adds module param b2bl_th_init_timeout with default value 60 to setup initial b2b timeout for topology hiding scenario. 2. opensips_b2bl_tc_init_time_v1.patch Adds module parameter as previous patch, but also adds per b2b session flag t[number] for b2b_init_request. Usage examples: b2b_init_request(top hiding/t60), b2b_init_request(top hiding/t300). Number length is not fixed. You may choose. :-) If one or another patch will be applied, I'll add documentation patch for it. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-10-12 07:04 Message: Hi Nick, Normally the lifetime is controlled via the scenario XML, so it is per scenario. Of course, the TH does not have a scenario XML. I would go for a module param or by a flag-like approach - depending if we want to control this per scenario (like for other cases) or per instance of scenario. Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3574453group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3571806 ] Non-printable Characters in Via Host
Bugs item #3571806, was opened at 2012-09-25 23:25
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3571806group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.8.x
Status: Open
Resolution: Fixed
Priority: 7
Private: No
Submitted By: David Sanders (dmsanders)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Non-printable Characters in Via Host
Initial Comment:
RFC 3261 doesn't allow non-printable characters (minus CRLF ending the Via
header) in the host portion of the Via header.
However, OpenSIPs seems to tolerate them. PJSIP has a bug that sends gibberish
for a host in the Via on some unregisters. This is tolerated by OpenSIPs on
receive, but causes issues later on in the reply, which goes out with a blank
host. In particular nat_traversal can't parse the reply because the host is
blank.
It seems that the parsing of the Via header should be tightened to only allow
printable characters as a host.
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-30 03:03
Message:
Hi David,
Please check the third additional patch. Let me know asap if ok, as I want
to include these fixes into the new 1.8.2 release (in 2 days from now)
Regards,
Bogdan
--
Comment By: David Sanders (dmsanders)
Date: 2012-10-26 13:48
Message:
Hi Bogdan,
The patch does correctly trigger the error_route for me, so that part works
nicely.
However, I am not able to use send_reply from the error_route without a
segmentation fault.
Here is the simple error_route I used for testing:
error_route
{
send_reply($err.rcode, $err.rreason);
}
And here is the info from GDB extracted from the core dump:
#0 0x2b6dbe01192f in sl_send_reply_helper (msg=0x2b6dbd3e1c00,
code=400, text=0x7fffee255180) at sl_funcs.c:155
155 update_sock_struct_from_ip( to, msg );
(gdb) bt
#0 0x2b6dbe01192f in sl_send_reply_helper (msg=0x2b6dbd3e1c00,
code=400, text=0x7fffee255180) at sl_funcs.c:155
#1 0x2b6dbdbf0311 in sig_send_reply_mod (msg=0x2b6dbd3e1c00, code=400,
reason=0x7fffee255180, to_tag=0x0) at signaling.c:192
#2 0x2b6dbdbf072b in sig_send_reply (msg=0x2b6dbd3e1c00, str1=value
optimized out, str2=0x2b6dbd3dbd50 xO:\275m+) at signaling.c:149
#3 0x00411955 in do_action (a=0x2b6dbd3a5010, msg=0x2b6dbd3e1c00)
at action.c:1486
#4 0x00416c85 in run_actions (msg=0x2b6dbd3e1c00, force_reset=1)
at action.c:157
#5 run_error_route (msg=0x2b6dbd3e1c00, force_reset=1) at action.c:144
#6 0x0045fb60 in receive_msg (buf=0x0, len=727, rcv_info=value
optimized out) at receive.c:115
#7 0x004b63ad in udp_rcv_loop () at udp_server.c:424
#8 0x0043050b in main_loop (argc=value optimized out,
argv=value optimized out) at main.c:881
#9 main (argc=value optimized out, argv=value optimized out) at
main.c:1528
(gdb) frame 0
#0 0x2b6dbe01192f in sl_send_reply_helper (msg=0x2b6dbd3e1c00,
code=400, text=0x7fffee255180) at sl_funcs.c:155
155 update_sock_struct_from_ip( to, msg );
(gdb) print *text
$1 = {s = 0x782440 bad Via header, len = 14}
(gdb) frame 0
#0 0x2b6dbe01192f in sl_send_reply_helper (msg=0x2b6dbd3e1c00,
code=400, text=0x7fffee255180) at sl_funcs.c:155
155 update_sock_struct_from_ip( to, msg );
(gdb) l
150 int ret;
151
152 if ( msg-REQ_METHOD==METHOD_ACK)
153 return 0;
154
155 update_sock_struct_from_ip( to, msg );
156
157 /* if that is a redirection message, dump current message
set to it */
158 if (code=300 code400) {
159 dset=print_dset(msg, dset_len);
(gdb) print to
$5 = (union sockaddr_union *) 0x7fffee2550a0
(gdb) print to
$6 = {s = {sa_family = 48480, sa_data = =\275m+\000\000P\275=\275m+\000},
sin = {sin_family = 48480, sin_port = 48445, sin_addr = {s_addr = 7},
sin_zero = P\275=\275m+\000}, sin6 = {sin6_family = 48480, sin6_port =
48445,
sin6_flowinfo = 7, sin6_addr = {in6_u = {u6_addr8 =
P\275=\275m+\000\000\000\034\275m+\000, u6_addr16 = {48464, 48445,
7, 0, 7168, 48446, 7, 0}, u6_addr32 = {3174939984, 7,
3174964224, 7}}},
sin6_scope_id = 3995423008}}
Seems like it's almost there. Thanks for the patches so far.
- David
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-26 02:51
Message:
David,
Please see the additional patch that should solve the triggering issue
too.
Regards,
Bogdan
--
Comment By: David Sanders (dmsanders)
Date: 2012-10-22 12:26
[OpenSIPS-Devel] SF.net SVN: opensips:[9396] branches/1.8/modules/b2b_logic
Revision: 9396 http://opensips.svn.sourceforge.net/opensips/?rev=9396view=rev Author: bogdan_iancu Date: 2012-10-30 10:13:31 + (Tue, 30 Oct 2012) Log Message: --- - added docs for the b2bl_th_init_timeout module param Credits go to Nick Altmann Closing bug #3574453 Modified Paths: -- branches/1.8/modules/b2b_logic/README branches/1.8/modules/b2b_logic/doc/b2b_logic_admin.xml This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3574453 ] b2b_logic: too small setup timeout when topology hiding
Bugs item #3574453, was opened at 2012-10-04 05:25 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3574453group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: b2b_logic: too small setup timeout when topology hiding Initial Comment: When b2b creates topology hiding scenario, it setups too small call setup time: /* if it will not be confirmed - delete */ tuple-lifetime = 60 + get_ticks(); When alice calls bob and bob don't answer for 60 seconds, b2b send CANCEL to both sides. I think we should give possibility to configure this parameter, either in AVP or b2b_init_request flags like b2b_init_request(top hiding/t300). I'd can to write the patch after discussion about what method to use. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-10-30 03:13 Message: Doc patch uploaded, thank you! Regards, Bogdan -- Comment By: Nick Altmann (nikbyte) Date: 2012-10-30 02:27 Message: Trunk - patch works as expected. 1.8 - docs patch uploaded (opensips_1.8_b2bl_th_init_timeout_docs.patch) -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-10-29 05:10 Message: Nick, Please do not forget to provide patch for docs for patch v1 (used on 1.8). Thanks and regards, Bogdan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-10-26 03:39 Message: Hi Nick, Thank you for your patches - for 1.8 I uploaded the fix with the minimal change (v1) - but please provide a small patch with the corresponding docs. For trunk I used the v3 patch, with some changes - please let me know if still works ok :). Regards, Bogdan -- Comment By: Nick Altmann (nikbyte) Date: 2012-10-22 04:34 Message: Look at new patch please (opensips_b2bl_tc_init_time_v3.patch). -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-10-21 08:01 Message: Hi Nick, I will go for v2, but I have some objection regarding your approach - I see you moved the scenario lookup from the fixup function to runtime part, which is totally inefficient - instead of doing the lookup once, you do it for each call. What I suggest here is to do both the scenario lookup and the flag detection in the fixup function. You can simply do that by replacing the param 1 (after fixup) with a structure (pkg) holding the scenario ID (as originally) plus the flag string. Or even better, the structure can already parse expend the flags, so that at runtime you have everything prepared. If you have doubts on how to do this, just let me know and I will do it as soon as I'll get available time. Regards, Bogdan -- Comment By: Nick Altmann (nikbyte) Date: 2012-10-15 05:10 Message: Here are two patches: 1. opensips_b2bl_tc_init_time_v1.patch Adds module param b2bl_th_init_timeout with default value 60 to setup initial b2b timeout for topology hiding scenario. 2. opensips_b2bl_tc_init_time_v1.patch Adds module parameter as previous patch, but also adds per b2b session flag t[number] for b2b_init_request. Usage examples: b2b_init_request(top hiding/t60), b2b_init_request(top hiding/t300). Number length is not fixed. You may choose. :-) If one or another patch will be applied, I'll add documentation patch for it. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-10-12 07:04 Message: Hi Nick, Normally the lifetime is controlled via the scenario XML, so it is per scenario. Of course, the TH does not have a scenario XML. I would go for a module param or by a flag-like approach - depending if we want to control this per scenario (like for other cases) or per instance of scenario. Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3574453group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9397] branches/1.7/tls/tls_init.c
Revision: 9397 http://opensips.svn.sourceforge.net/opensips/?rev=9397view=rev Author: vladut-paiu Date: 2012-10-30 10:22:09 + (Tue, 30 Oct 2012) Log Message: --- backport from trunk (rev #9268) Added openssl multithreading needed callbacks for locking and process identifier Should fix ugly bugs related to mem corruption when running TLS Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=9268view=rev Modified Paths: -- branches/1.7/tls/tls_init.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3552688 ] opensips crash with TLS
Bugs item #3552688, was opened at 2012-07-31 09:28 Message generated for change (Comment added) made by dragosoancea You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3552688group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: 1.7.x Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Dragos Oancea (dragosoancea) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: opensips crash with TLS Initial Comment: Hi all, opensips 1.7.2 crashes when using TLS with create_dialog(Pp) in the routing script - that would send OPTIONS (nat ping) both to caller and callee during a dialog . The TLS-related relevant lines in the routing script are: tls_verify_server = 1 tls_verify_client = 0 tls_require_client_certificate = 0 tls_method = TLSv1 tls_certificate = /etc/pki/CA/certs/x.crt tls_private_key = /etc/pki/CA/private/x.key tls_ca_list = /etc/pki/CA/certs/ca.crt listen = tls:X.X.X.X:5061 listen = tcp:X.X.X.X:5060 syslog: http://pastebin.com/Kkdns7Cr backtrace: http://pastebin.com/7P4ADL9y Apparently it crashes just after trying to send an OPTIONS or BYE to a device that is not there anymore (it's not on the socket opensips expects it to be - opensips usually generates a 477 SendFailed reply in situations like this) . and interesting enough, if I add an udp port to listen to with listen=udp:X.X.X.X:5060 does not crash anymore. Regards, Dragos -- Comment By: Dragos Oancea (dragosoancea) Date: 2012-10-30 04:24 Message: Hi Bogdan, I am running 1.8.1 with the tls_init.c patch and the dlg_unref.patch ( bug-id 3570495 ) . I had no crash anymore. However, I cannot be 100% sure that the bug is not there anymore because I had to make some changes in the routing script. When it was crashing (and not patched) I had : modparam(dialog, ping_interval, 20) modparam(tm, fr_timer, 15) Few days after I patched it had to change these values to (because opensips was dropping calls - the reply to OPTIONS from the clients was not coming due to network issues ): modparam(dialog, ping_interval, 40) modparam(tm, fr_timer, 30) So I ran about 3 days with the old config and the patched version and then I changed these params , and it is running like this since then (about a month I think) . #opensips -V version: opensips 1.8.1-tls (x86_64/linux) flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 8772 2012-03-08 11:16:13Z bogdan_iancu $ main.c compiled on 11:49:51 Oct 15 2012 with gcc 4.4.6 Regards, Dragos -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-10-30 01:54 Message: Hi Dragos, Is this still happening with the latest code from 1.8 SVN branch ? Regards, Bogdan -- Comment By: Dragos Oancea (dragosoancea) Date: 2012-08-29 06:25 Message: Hi It happened again. This time I had only two phones registered via TLS and I was just making a call between them. gdb: http://pastebin.com/1miGb7ct log (stderr): http://pastebin.com/bvDjLzPh can someone confirm it is related to 3522861 ? Cheers, Dragos -- Comment By: Dragos Oancea (dragosoancea) Date: 2012-08-16 04:00 Message: Hi I think there is only one problem. so because the OPTIONS is sent to the wrong interface , no reply will come back , and opensips will generate and send a BYE bothways. but in my case everything is running fine..with OPTIONS being sent to the right places at first , then something happends (memory corruption) , and maybe the function that does the pinging is first to access some unallocated memory. The crash could also happen when the callee or the caller sends BYE. Some extra informations: There are mobile devices under NAT running on TCP or TLS involved in this whole scenario. So when the mobile device is not there anymore (it ran out of battery durring a call for example) , the crash is most likely to happen. Also , I noticed that there is no problem if I only listen to tls (not listening on tcp, not listening on udp). But I need tcp , so I cannot disable it. another gdb backtrace : http://pastebin.com/aXgABJtE I hope to replicate this in a controlled environment with memlog/memdump soon and let you. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date:
[OpenSIPS-Devel] [ opensips-Bugs-3552688 ] opensips crash with TLS
Bugs item #3552688, was opened at 2012-07-31 09:28 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3552688group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: 1.7.x Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Dragos Oancea (dragosoancea) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: opensips crash with TLS Initial Comment: Hi all, opensips 1.7.2 crashes when using TLS with create_dialog(Pp) in the routing script - that would send OPTIONS (nat ping) both to caller and callee during a dialog . The TLS-related relevant lines in the routing script are: tls_verify_server = 1 tls_verify_client = 0 tls_require_client_certificate = 0 tls_method = TLSv1 tls_certificate = /etc/pki/CA/certs/x.crt tls_private_key = /etc/pki/CA/private/x.key tls_ca_list = /etc/pki/CA/certs/ca.crt listen = tls:X.X.X.X:5061 listen = tcp:X.X.X.X:5060 syslog: http://pastebin.com/Kkdns7Cr backtrace: http://pastebin.com/7P4ADL9y Apparently it crashes just after trying to send an OPTIONS or BYE to a device that is not there anymore (it's not on the socket opensips expects it to be - opensips usually generates a 477 SendFailed reply in situations like this) . and interesting enough, if I add an udp port to listen to with listen=udp:X.X.X.X:5060 does not crash anymore. Regards, Dragos -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-10-30 04:38 Message: OK, let's consider this fixed for the moment, if it does not crash anymore - if the problem pops up again, just open a new ticket. Regards, Bogdan -- Comment By: Dragos Oancea (dragosoancea) Date: 2012-10-30 04:24 Message: Hi Bogdan, I am running 1.8.1 with the tls_init.c patch and the dlg_unref.patch ( bug-id 3570495 ) . I had no crash anymore. However, I cannot be 100% sure that the bug is not there anymore because I had to make some changes in the routing script. When it was crashing (and not patched) I had : modparam(dialog, ping_interval, 20) modparam(tm, fr_timer, 15) Few days after I patched it had to change these values to (because opensips was dropping calls - the reply to OPTIONS from the clients was not coming due to network issues ): modparam(dialog, ping_interval, 40) modparam(tm, fr_timer, 30) So I ran about 3 days with the old config and the patched version and then I changed these params , and it is running like this since then (about a month I think) . #opensips -V version: opensips 1.8.1-tls (x86_64/linux) flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 8772 2012-03-08 11:16:13Z bogdan_iancu $ main.c compiled on 11:49:51 Oct 15 2012 with gcc 4.4.6 Regards, Dragos -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-10-30 01:54 Message: Hi Dragos, Is this still happening with the latest code from 1.8 SVN branch ? Regards, Bogdan -- Comment By: Dragos Oancea (dragosoancea) Date: 2012-08-29 06:25 Message: Hi It happened again. This time I had only two phones registered via TLS and I was just making a call between them. gdb: http://pastebin.com/1miGb7ct log (stderr): http://pastebin.com/bvDjLzPh can someone confirm it is related to 3522861 ? Cheers, Dragos -- Comment By: Dragos Oancea (dragosoancea) Date: 2012-08-16 04:00 Message: Hi I think there is only one problem. so because the OPTIONS is sent to the wrong interface , no reply will come back , and opensips will generate and send a BYE bothways. but in my case everything is running fine..with OPTIONS being sent to the right places at first , then something happends (memory corruption) , and maybe the function that does the pinging is first to access some unallocated memory. The crash could also happen when the callee or the caller sends BYE. Some extra informations: There are mobile devices under NAT running on TCP or TLS involved in this whole scenario. So when the mobile device is not there anymore (it ran out of battery durring a call for example) , the crash is most likely to happen. Also , I noticed that there is no problem if I only listen to tls (not listening on tcp, not listening on udp). But I need tcp , so I
[OpenSIPS-Devel] SF.net SVN: opensips:[9398] trunk/modules/path/path.c
Revision: 9398 http://opensips.svn.sourceforge.net/opensips/?rev=9398view=rev Author: bogdan_iancu Date: 2012-10-30 11:45:26 + (Tue, 30 Oct 2012) Log Message: --- - fixed buffer overflow and bogus freeing (related to previous fix on PATH module) Credits go to Nick Altmann Modified Paths: -- trunk/modules/path/path.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9399] trunk/modules/path/path.c
Revision: 9399 http://opensips.svn.sourceforge.net/opensips/?rev=9399view=rev Author: bogdan_iancu Date: 2012-10-30 11:46:46 + (Tue, 30 Oct 2012) Log Message: --- - fixing small syntax error :D Modified Paths: -- trunk/modules/path/path.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9400] branches/1.8/modules/path/path.c
Revision: 9400 http://opensips.svn.sourceforge.net/opensips/?rev=9400view=rev Author: bogdan_iancu Date: 2012-10-30 11:47:52 + (Tue, 30 Oct 2012) Log Message: --- backport from trunk (rev #9398 + #9399) - fixed buffer overflow and bogus freeing (related to previous fix on PATH module) Credits go to Nick Altmann Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=9398view=rev Modified Paths: -- branches/1.8/modules/path/path.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3576387 ] segfault on dlg_ping_routine
Bugs item #3576387, was opened at 2012-10-11 10:18
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3576387group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Flavio Goncalves (flaviogoncalves)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: segfault on dlg_ping_routine
Initial Comment:
I'm reopening the case, It happened again after the patch.
Program terminated with signal 11, Segmentation fault.
#0 dlg_ping_routine (ticks=value optimized out, attr=value optimized out)
at dlg_timer.c:525
525 dlg-pl = 0;
(gdb) bt full
#0 dlg_ping_routine (ticks=value optimized out, attr=value optimized out)
at dlg_timer.c:525
expired = value optimized out
it = value optimized out
curr = 0x7fba18391c18
dlg = 0x5d
__FUNCTION__ = dlg_ping_routine
#1 0x004b53dc in timer_ticker () at timer.c:360
t = 0x7fba5e562d58
#2 run_timer_process () at timer.c:430
multiple = 10
cnt = value optimized out
tv = {tv_sec = 0, tv_usec = 0}
#3 start_timer_processes () at timer.c:527
tpl = 0x7fba5e5614d0
pid = value optimized out
__FUNCTION__ = start_timer_processes
#4 0x004327d3 in main_loop (argc=value optimized out, argv=value
optimized out) at main.c:933
i = 8
pid = 24
si = 0x0
startup_done = 0x7fba16a1f598
chd_rank = 16
load_p = 0x7fba16a1f8e8
#5 main (argc=value optimized out, argv=value optimized out) at main.c:1520
cfg_log_stderr = 8
cfg_stream = value optimized out
c = value optimized out
r = value optimized out
tmp = 0x7fff5461eea0
tmp_len = value optimized out
port = value optimized out
proto = value optimized out
ret = value optimized out
seed = 2170505229
rfd = value optimized out
__FUNCTION__ = main
--
Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-10-30 07:11
Message:
Hello,
Could you please run, in GDB, the following, and post here the output ?
f 0
p dlg
p *dlg
Regards,
Vlad
--
Comment By: Dragos Oancea (dragosoancea)
Date: 2012-10-12 04:41
Message:
Hi
This did not happened to me after I applied the patches ( tls_init.c patch
and dialog module patch - see bug ID 3570495 ) .
I use :
modparam(dialog, ping_interval, 40)
modparam(tm, fr_timer, 15)
Cheers,
Dragos
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3576387group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release
Hello Ryan, Can you please open a SF bug about the db_virtual with insert buffering, describing the setup and what's happening ( if no rows were inserted at all, or there were rows missing, etc ) ? Also, thanks for the futex patch, we will definitely look into it. Regards, Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com On 10/29/2012 10:39 PM, Ryan Bullock wrote: Hey Bogdan, I came across the insert buffer problem with db_virtual when I was testing the patch for Bug ID# 3568579. I couldn't figure out why insert buffering wasn't working at all. Removing db_virtual and using straight db_mysql and buffering worked. I am actually taking advantage that buffering doesn’t work with db_virtual for use with the dialog module (seems to get a bit out of sync with the database if buffering is on). I thought insert buffering not working was intentional, however looking at the db_virtual source is *should* work. My guess would be that the capability flags are getting a bit messed up/overwritten somewhere. I can open a bug for this, if it should actually be working. 12 are things that make working in a HA/distributed environment easier. Having a cache go down should hopefully only cause a performance hit, not an outage :) We moved the futex patch into production recently and it seems to be holding up thus far. Regards, Ryan On Mon, Oct 29, 2012 at 3:20 AM, Bogdan-Andrei Iancu bog...@opensips.org mailto:bog...@opensips.org wrote: Hi Ryan, Indeed, several SIP stacks do not properly implement in-dialog OPTIONS - this is why we want to add re-INVITE as this is widely supported. 1) we can add that on the wish list, let's see what time will allow to do. 2) interesting idea...We need to check on connecting on the fly - add it to the list. 3) why is it not working ? could you detail the issues you have there ? Regarding the FUTEX patch - it definitely looks really interesting - we will do a review and upload it on SVN. Thanks and Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/26/2012 09:01 PM, Ryan Bullock wrote: The re-Invite pinging sounds great, so long as it is separate dlg flag from the OPTIONs ping. I know from experience that certain systems (Asterisk) will sometimes incorrectly respond with a 200 OK to in-Dialog OPTIONS when the call is actually gone. On the other hand, some equipment can't handle re-Invites either. A few things that I have noted, and that would be nice to see in a future release: 1. Better failure handling for cachedb_*. We use memcached and have lost a cache node before. Opensips will just continually timeout trying to read from the failed node. The only way to get it to stop was to edit the configuration to remove the dead node then restart opensips. Would be nice if this behaved similar to db_virtual or rtpproxy in detecting timeouts and retrying so often, as well as some mi commands to disable a cache temporarily. 2. Opensips should be able to start even if db_virtual was not able to connect to all databases. So long as it can connect to at least 1 it should still work. We have had to move away from using db_vritual because of this problem. 3. Insert buffering support for db_virtual. Currently these two things don't work together, which can make it a bit difficult to scale out database writes. On another note, I submitted a patch for direct futex support under linux for locking. It has shown good promise in my testing and I am wondering if there is any interest in trying to get it included for 1.9? Regards, Ryan On Fri, Oct 26, 2012 at 8:20 AM, Bogdan-Andrei Iancu bog...@opensips.org mailto:bog...@opensips.org wrote: Hi all, I would like to start a discussion about the next OpenSIPS major release - and in this discussion anyone is welcomed with options, ideas, critics and other. Your feedback is important to drive the project into a direction that reflects the user's needs!. So, I will here the starting points, for both release planing and release content. Content --- What was done: http://www.opensips.org/Main/Ver190#toc2 What is planned: http://www.opensips.org/Main/Ver190#toc9 Planned items have priorities (for being addressed); it is a must to have all items done for the next release, as we need to fit into a time frame. Whatever is not done, will be left for the next release (1.10) Planing --- Release candidate: second half of January 2012, depending on the progress with the items to be done. Testing phase: 1 month allocated (it may be extended if critical
[OpenSIPS-Devel] [ opensips-Bugs-3571806 ] Non-printable Characters in Via Host
Bugs item #3571806, was opened at 2012-09-25 23:25
Message generated for change (Comment added) made by dmsanders
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3571806group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.8.x
Status: Open
Resolution: Fixed
Priority: 7
Private: No
Submitted By: David Sanders (dmsanders)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Non-printable Characters in Via Host
Initial Comment:
RFC 3261 doesn't allow non-printable characters (minus CRLF ending the Via
header) in the host portion of the Via header.
However, OpenSIPs seems to tolerate them. PJSIP has a bug that sends gibberish
for a host in the Via on some unregisters. This is tolerated by OpenSIPs on
receive, but causes issues later on in the reply, which goes out with a blank
host. In particular nat_traversal can't parse the reply because the host is
blank.
It seems that the parsing of the Via header should be tightened to only allow
printable characters as a host.
--
Comment By: David Sanders (dmsanders)
Date: 2012-10-30 15:23
Message:
Bogdan,
That latest patch fixed the seg fault, but there is still a reply error.
osips[5913]: ScriptLogging: Error occurred
osips[5913]: ERROR:core:parse_via: SIP/2.0/UDP 0
osips[5913]: ERROR:core:parse_via: parsed so far:SIP/2.0/UDP 0
osips[5913]: ERROR:core:get_hdr_field: bad via
osips[5913]: INFO:core:parse_headers: bad header field
osips[5913]: ERROR:core:parse_via: SIP/2.0/UDP 0
osips[5913]: ERROR:core:parse_via: parsed so far:SIP/2.0/UDP 0
osips[5913]: ERROR:core:get_hdr_field: bad via
osips[5913]: INFO:core:parse_headers: bad header field
osips[5913]: ERROR:core:build_res_buf_from_sip_req: parse_headers failed
osips[5913]: ERROR:sl:sl_send_reply_helper: response building failed
osips[5913]: ERROR:signaling:sig_send_reply_mod: failed to send reply with
sl module
The first log message is from the error_route, the rest seem to come from
send_reply(...). It looks like it makes it further down in
sl_send_reply_helper but then trips up on parse_headers and/or
build_res_buf_from_sip_req.
- David
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-30 03:03
Message:
Hi David,
Please check the third additional patch. Let me know asap if ok, as I want
to include these fixes into the new 1.8.2 release (in 2 days from now)
Regards,
Bogdan
--
Comment By: David Sanders (dmsanders)
Date: 2012-10-26 13:48
Message:
Hi Bogdan,
The patch does correctly trigger the error_route for me, so that part works
nicely.
However, I am not able to use send_reply from the error_route without a
segmentation fault.
Here is the simple error_route I used for testing:
error_route
{
send_reply($err.rcode, $err.rreason);
}
And here is the info from GDB extracted from the core dump:
#0 0x2b6dbe01192f in sl_send_reply_helper (msg=0x2b6dbd3e1c00,
code=400, text=0x7fffee255180) at sl_funcs.c:155
155 update_sock_struct_from_ip( to, msg );
(gdb) bt
#0 0x2b6dbe01192f in sl_send_reply_helper (msg=0x2b6dbd3e1c00,
code=400, text=0x7fffee255180) at sl_funcs.c:155
#1 0x2b6dbdbf0311 in sig_send_reply_mod (msg=0x2b6dbd3e1c00, code=400,
reason=0x7fffee255180, to_tag=0x0) at signaling.c:192
#2 0x2b6dbdbf072b in sig_send_reply (msg=0x2b6dbd3e1c00, str1=value
optimized out, str2=0x2b6dbd3dbd50 xO:\275m+) at signaling.c:149
#3 0x00411955 in do_action (a=0x2b6dbd3a5010, msg=0x2b6dbd3e1c00)
at action.c:1486
#4 0x00416c85 in run_actions (msg=0x2b6dbd3e1c00, force_reset=1)
at action.c:157
#5 run_error_route (msg=0x2b6dbd3e1c00, force_reset=1) at action.c:144
#6 0x0045fb60 in receive_msg (buf=0x0, len=727, rcv_info=value
optimized out) at receive.c:115
#7 0x004b63ad in udp_rcv_loop () at udp_server.c:424
#8 0x0043050b in main_loop (argc=value optimized out,
argv=value optimized out) at main.c:881
#9 main (argc=value optimized out, argv=value optimized out) at
main.c:1528
(gdb) frame 0
#0 0x2b6dbe01192f in sl_send_reply_helper (msg=0x2b6dbd3e1c00,
code=400, text=0x7fffee255180) at sl_funcs.c:155
155 update_sock_struct_from_ip( to, msg );
(gdb) print *text
$1 = {s = 0x782440 bad Via header, len = 14}
(gdb) frame 0
#0 0x2b6dbe01192f in sl_send_reply_helper (msg=0x2b6dbd3e1c00,
code=400, text=0x7fffee255180) at sl_funcs.c:155
155 update_sock_struct_from_ip( to, msg );
(gdb) l
150 int ret;
151
152 if ( msg-REQ_METHOD==METHOD_ACK)
153 return 0;
154
155 update_sock_struct_from_ip( to, msg );
156
157 /* if that
[OpenSIPS-Devel] [ opensips-Bugs-3571806 ] Non-printable Characters in Via Host
Bugs item #3571806, was opened at 2012-09-25 23:25
Message generated for change (Comment added) made by dmsanders
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3571806group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.8.x
Status: Open
Resolution: Fixed
Priority: 7
Private: No
Submitted By: David Sanders (dmsanders)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Non-printable Characters in Via Host
Initial Comment:
RFC 3261 doesn't allow non-printable characters (minus CRLF ending the Via
header) in the host portion of the Via header.
However, OpenSIPs seems to tolerate them. PJSIP has a bug that sends gibberish
for a host in the Via on some unregisters. This is tolerated by OpenSIPs on
receive, but causes issues later on in the reply, which goes out with a blank
host. In particular nat_traversal can't parse the reply because the host is
blank.
It seems that the parsing of the Via header should be tightened to only allow
printable characters as a host.
--
Comment By: David Sanders (dmsanders)
Date: 2012-10-30 18:08
Message:
I've attached a SIPp scenario file which reproduces the latest errors I am
seeing.
Hopefully this helps you fix any remaining issues faster since we are in
different time zones.
- David
--
Comment By: David Sanders (dmsanders)
Date: 2012-10-30 15:23
Message:
Bogdan,
That latest patch fixed the seg fault, but there is still a reply error.
osips[5913]: ScriptLogging: Error occurred
osips[5913]: ERROR:core:parse_via: SIP/2.0/UDP 0
osips[5913]: ERROR:core:parse_via: parsed so far:SIP/2.0/UDP 0
osips[5913]: ERROR:core:get_hdr_field: bad via
osips[5913]: INFO:core:parse_headers: bad header field
osips[5913]: ERROR:core:parse_via: SIP/2.0/UDP 0
osips[5913]: ERROR:core:parse_via: parsed so far:SIP/2.0/UDP 0
osips[5913]: ERROR:core:get_hdr_field: bad via
osips[5913]: INFO:core:parse_headers: bad header field
osips[5913]: ERROR:core:build_res_buf_from_sip_req: parse_headers failed
osips[5913]: ERROR:sl:sl_send_reply_helper: response building failed
osips[5913]: ERROR:signaling:sig_send_reply_mod: failed to send reply with
sl module
The first log message is from the error_route, the rest seem to come from
send_reply(...). It looks like it makes it further down in
sl_send_reply_helper but then trips up on parse_headers and/or
build_res_buf_from_sip_req.
- David
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-30 03:03
Message:
Hi David,
Please check the third additional patch. Let me know asap if ok, as I want
to include these fixes into the new 1.8.2 release (in 2 days from now)
Regards,
Bogdan
--
Comment By: David Sanders (dmsanders)
Date: 2012-10-26 13:48
Message:
Hi Bogdan,
The patch does correctly trigger the error_route for me, so that part works
nicely.
However, I am not able to use send_reply from the error_route without a
segmentation fault.
Here is the simple error_route I used for testing:
error_route
{
send_reply($err.rcode, $err.rreason);
}
And here is the info from GDB extracted from the core dump:
#0 0x2b6dbe01192f in sl_send_reply_helper (msg=0x2b6dbd3e1c00,
code=400, text=0x7fffee255180) at sl_funcs.c:155
155 update_sock_struct_from_ip( to, msg );
(gdb) bt
#0 0x2b6dbe01192f in sl_send_reply_helper (msg=0x2b6dbd3e1c00,
code=400, text=0x7fffee255180) at sl_funcs.c:155
#1 0x2b6dbdbf0311 in sig_send_reply_mod (msg=0x2b6dbd3e1c00, code=400,
reason=0x7fffee255180, to_tag=0x0) at signaling.c:192
#2 0x2b6dbdbf072b in sig_send_reply (msg=0x2b6dbd3e1c00, str1=value
optimized out, str2=0x2b6dbd3dbd50 xO:\275m+) at signaling.c:149
#3 0x00411955 in do_action (a=0x2b6dbd3a5010, msg=0x2b6dbd3e1c00)
at action.c:1486
#4 0x00416c85 in run_actions (msg=0x2b6dbd3e1c00, force_reset=1)
at action.c:157
#5 run_error_route (msg=0x2b6dbd3e1c00, force_reset=1) at action.c:144
#6 0x0045fb60 in receive_msg (buf=0x0, len=727, rcv_info=value
optimized out) at receive.c:115
#7 0x004b63ad in udp_rcv_loop () at udp_server.c:424
#8 0x0043050b in main_loop (argc=value optimized out,
argv=value optimized out) at main.c:881
#9 main (argc=value optimized out, argv=value optimized out) at
main.c:1528
(gdb) frame 0
#0 0x2b6dbe01192f in sl_send_reply_helper (msg=0x2b6dbd3e1c00,
code=400, text=0x7fffee255180) at sl_funcs.c:155
155 update_sock_struct_from_ip( to, msg );
(gdb) print *text
$1 = {s = 0x782440 bad Via header, len = 14}
(gdb) frame 0
#0 0x2b6dbe01192f in sl_send_reply_helper
