[OpenSIPS-Users] What is protocol/port mismatch?

[opensipslist at encambio.com]

Hello Bogdan,

An mer., févr 03, 2010, Bogdan-Andrei Iancu schrieb:
>Regarding the crash you mentioned - do you have any backtraces ?
>
There's quite a lot of situations in which OpenSIPS crashes, so
I'm not sure this one is related to TLS traffic arriving on a non
TLS port. In any case, here's the last backtrace:

$ gdb /pfx/sbin/opensips opensips.17272.name.host.tld.core 
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.11"...
(no debugging symbols found)
Cannot access memory at address 0x70795464
(gdb) bt
#0  0x0810eefc in fm_realloc ()
#1  0xd0d8cc8c in ?? ()
#2  0x080465a8 in ?? ()
#3  0xd0d859d4 in ?? ()
#4  0x08353c2c in mem_pool ()
#5  0x00000191 in ?? ()
#6  0x08046640 in ?? ()
#7  0xffffffff in ?? ()
#8  0xffffffff in ?? ()
#9  0x080467d8 in ?? ()
#10 0x08046638 in ?? ()
#11 0x0812437e in parse_min_se ()
#12 0x083132e0 in mem_pool ()
#13 0xffffffff in ?? ()
#14 0x81af694b in ?? ()
#15 0xd0d8c6fc in ?? ()
#16 0x00000001 in ?? ()
#17 0x08353c2c in mem_pool ()
#18 0xce43365d in ?? ()
#19 0x080467c4 in ?? ()
#20 0x0804678c in ?? ()
#21 0x08353f9c in mem_pool ()
#22 0x08046640 in ?? ()
#23 0x08353f9c in mem_pool ()
#24 0x00000073 in ?? ()
#25 0x082ff8e8 in ?? ()
#26 0xd13dbbe9 in ?? ()
#27 0x00000002 in ?? ()
#28 0x082ff8f0 in ?? ()
#29 0x00003332 in ?? ()
#30 0x00000000 in ?? ()
(gdb)

$ pstack opensips.17272.name.host.tld.core core 'opensips.17272.name.host.tld.core' of 17272:        /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
 0810eefc fm_realloc (0, 80467cc, 0, 80467d8, d10f0000, 8354104) + 4bc
 d1011537 dlg_validate_dialog (8353c2c, ce4334b0, 8046a38, d101459b, ce4334b0, 8323390) + 290
 d10035ba w_validate_dialog (8353c2c, 0, 0, 0, 0, 0) + 2a
 08076240 do_action (8323390, 8353c2c, 7275652e, 8046c00, 8046bf0, 0) + 15a5
 08079877 run_action_list (8323390, 8353c2c, 844f7c8, 844f735, 83132ba, 13) + 281
 080d03a7 eval_expr (83233fc, 8353c2c, 0, 0, 313c5, 1) + 46a
 080d014a eval_expr (8323428, 8353c2c, 0, 0, 0, 0) + 20d
 080d0019 eval_expr (8323454, 8353c2c, 0, d0ff18b3, 0, 8354890) + dc
 080d0172 eval_expr (8323480, 8353c2c, 0, 8354700, 8354a2c, 27) + 235
 0807643d do_action (83238cc, 8353c2c, 40, 82b1c50, 80472d4, 80472d4) + 17a2
 08079877 run_action_list (83238cc, 8353c2c, 0, 81aaf92, 82b1c50, ce4350a8) + 281
 08078381 do_action (832536c, 8353c2c, ce415b0d, d0dadd84, ce433690, ce415b08) + 36e6
 08079877 run_action_list (832536c, 8353c2c, 0, 0, 0, 0) + 281
 08078381 do_action (8325654, 8353c2c, ce415790, 0, 8353c30, 1) + 36e6
 08079877 run_action_list (832108c, 8353c2c, d106ea15, 8344074, 8353c2c, 0) + 281
 08079c50 get_bl_head_by_name (832108c, 8353c2c, 8353c2c, 80478f0, 308, 8353c2c) + f3
 080be5aa receive_msg (ce415808, 308, ce4157a0, 80478d4, ce375d9c, 2) + 5ac
 080f4cf4 tcp_read_req (ce415790, 8047978, d11d10c5, d11bfa64, 17, ce375d4c) + 18c
 080f687d ???????? (b, d001, 8047ac4, d06e7e60, d06e9ae0, 831a84c)
 080f77a4 tcp_receive_loop (c, 2, 0, 8047b10, 9, 0) + 94b
 080ed6f8 tcp_send (82cb1f4, 138a, 83178e8, 805f130, d1169cc8, 8047c5c) + 4b
 08091d47 main     (80749c0, 3, 8047bdc) + 3bab
 080749c0 do_assign (3, 8047cc4, 8047cd8, 8047cdb, 0, 8047cfb) + d0

$ pflags opensips.17272.name.host.tld.core
core 'opensips.17272.name.host.tld.core' of 17272:        /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
        data model = _ILP32  flags = ORPHAN|MSACCT|MSFORK
 /1:    flags = 0
        sigmask = 0xffffbefc,0x0000ffff  cursig = SIGSEGV

>1) t_relay() is not forcing any proto by itself: it preserves the 
>inbound proto if the RURI (or socket) is not saying otherwise.
>
Okay, then I assume the t_relay() tried sending TLS traffic to
the voicemail server, could not negotiate a TLS connection, and
so resent the message over UDP instead. Is that right? Does
t_relay() choose UDP instead of TCP when its first choice (the
preserved inbound proto) cannot be used?

>2) turning off the double RR may brake some things as opensips will
>not be able to properly route between the original inbound and
>outbound interfaces... only if you do it manually from the script.
>
I've configured OpenSIPS to listen on only one interface, so I guess
that I'm not affected by this breakage. Next I'll try to solve the
problem another way without disabling double Record-Route headers.

>To me, the solution looks like a dirty hack, but if makes Asterisk
>happy... what can I say :)
>
Now that I know more I'll try to solve it another way.

Regards,
Brian