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 _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
