[OpenSIPS-Users] DNS SRV Crashes
Sergio Gutierrez
saguti at gmail.com
Wed Nov 12 04:21:54 CET 2008
Hi Brett.
This issue has been fixed in OpenSIPS 1.4.3.
I suggest, as much as possible update your installation.
You can download it from
http://www.opensips.org/index.php?n=Resources.Downloads#svn
Please, let us know if you have further troubles.
Best regards.
Sergio Gutiérrez.
On Tue, Nov 11, 2008 at 5:19 PM, Brett Nemeroff <brett at nemeroff.com> wrote:
> Mostly what I expected:Core was generated by `opensips -Eddddd'.
> Program terminated with signal 11, Segmentation fault.
> [New process 7787]
> #0 do_srv_lookup (name=0x734e20 "_sip._
> udp.wholesaleorigination.acc.globalipcom.com", port=0x77b292, dn=0x77b2b8)
> at resolve.c:810
> 810 else {crt2->next = crt->next;}
> (gdb) bt
> #0 do_srv_lookup (name=0x734e20 "_sip._
> udp.wholesaleorigination.acc.globalipcom.com", port=0x77b292, dn=0x77b2b8)
> at resolve.c:810
> #1 0x0000000000455e55 in sip_resolvehost (name=0x7fff3de98e60,
> port=0x77b292, proto=0x77b294, is_sips=173, dn=0x77b2b8) at resolve.c:1247
> #2 0x000000000043da45 in mk_proxy (name=0x7fff3de98e60, port=36288,
> proto=7787, is_sips=0) at proxy.c:252
> #3 0x00007f59350bac67 in add_uac (t=0x7f5931c99e08, request=0x77eb20,
> uri=0x7fff3de99100, next_hop=0x7fff3de99110, path=<value optimized out>,
> proxy=0x0) at ut.h:111
> #4 0x00007f59350bbed4 in t_forward_nonack (t=0x7f5931c99e08, p_msg=0x0,
> proxy=0x0) at t_fwd.c:615
> #5 0x00007f59350b82b1 in t_relay_to (p_msg=0x77eb20, proxy=0x0, flags=0)
> at t_funcs.c:252
> #6 0x00007f59350c9bfa in w_t_relay (p_msg=0x77eb20, proxy=0x0, flags=0x0)
> at tm.c:962
> #7 0x000000000040f6b7 in do_action (a=0x777568, msg=0x77eb20) at
> action.c:845
> #8 0x000000000040e52a in run_action_list (a=<value optimized out>,
> msg=0x77eb20) at action.c:138
> #9 0x000000000045fa12 in eval_expr (e=0x777638, msg=0x77eb20,
> val=0x7799a8) at route.c:1104
> #10 0x000000000045f6fc in eval_expr (e=0x777680, msg=0x77eb20, val=0x0) at
> route.c:1417
> #11 0x000000000045f717 in eval_expr (e=0x7776c8, msg=0x77eb20, val=0x0) at
> route.c:1422
> #12 0x000000000040f7ee in do_action (a=0x777870, msg=0x77eb20) at
> action.c:700
> #13 0x000000000040e52a in run_action_list (a=<value optimized out>,
> msg=0x77eb20) at action.c:138
> #14 0x0000000000410881 in do_action (a=0x776fe8, msg=0x77eb20) at
> action.c:118
> #15 0x000000000040e52a in run_action_list (a=<value optimized out>,
> msg=0x77eb20) at action.c:138
> #16 0x0000000000411fc0 in run_top_route (a=0x773a70, msg=0x77eb20) at
> action.c:118
> #17 0x00000000004506e4 in receive_msg (buf=0x1e6b <Address 0x1e6b out of
> bounds>, len=1038722304, rcv_info=0x7fff3de9a500) at receive.c:165
> #18 0x00000000004924d7 in udp_rcv_loop () at udp_server.c:449
> #19 0x000000000042928f in main (argc=1038722592, argv=0x20) at main.c:780
>
> Any thoughts?
> Thanks,
> -Brett
>
>
> On Tue, Nov 11, 2008 at 4:16 PM, Brett Nemeroff <brett at nemeroff.com>wrote:
>
>> I found it.. thanks.. maybe I'll run gdb on it and see if I can make
>> anything out of the backtrace..
>> Running on Ubuntu 8.04
>>
>> Thanks for your help
>> -Brett
>>
>>
>> On Tue, Nov 11, 2008 at 4:15 PM, Sergio Gutierrez <saguti at gmail.com>wrote:
>>
>>> Hi Brett.
>>>
>>> Is not OpenSER creating a core file when fails? Maybe try to find it at /
>>>
>>> By the way, what Operating System are you running on?
>>>
>>> Check also in OpenSER configuration file to make sure that
>>> disable_core_dump is set to no.
>>>
>>> Regards.
>>>
>>> --
>>> Sergio Gutiérrez
>>>
>>>
>>>
>>>
>>> On Tue, Nov 11, 2008 at 5:10 PM, Brett Nemeroff <brett at nemeroff.com>wrote:
>>>
>>>> Well I definitely see it doing a SRV lookup. When it gets the reply it
>>>> dies. I'm not really sure how to make it dump core or how to make that
>>>> available to the developers.
>>>> The domain I'm using is hosted by Verizon and they control the DNS.
>>>> Using DIG yields valid SRV records.
>>>>
>>>>
>>>> On Tue, Nov 11, 2008 at 4:06 PM, Sergio Gutierrez <saguti at gmail.com>wrote:
>>>>
>>>>>
>>>>> Hello Brett.
>>>>>
>>>>> If you are trying to use SRV location, I suggest to do it this way:
>>>>>
>>>>> rewritehost("wholesaleorigination.acc.globalipcom.com");
>>>>> rewriteport("");
>>>>>
>>>>> The last line is equivalente to define port as 0, which implies a SRV
>>>>> lookup.
>>>>>
>>>>> Anyway, make sure your DNS defines
>>>>> wholesaleorigination.acc.globalipcom.com as a SRV RR for SIP.
>>>>>
>>>>> Anyway, the issue you reported would be investigated. I suggest to
>>>>> paste to a backtrace from the corefile, so that developers can trace it.
>>>>>
>>>>> Regards.
>>>>>
>>>>> --
>>>>> Sergio Gutiérrez
>>>>>
>>>>>
>>>>> On Tue, Nov 11, 2008 at 5:02 PM, Brett Nemeroff <brett at nemeroff.com>wrote:
>>>>>
>>>>>> It's excessively boring:
>>>>>> main route block........{
>>>>>> ...
>>>>>> if ($rU==NULL) {
>>>>>> # request with no Username in RURI
>>>>>> sl_send_reply("484","Address Incomplete");
>>>>>> exit;
>>>>>> }
>>>>>>
>>>>>>
>>>>>> rewritehost("wholesaleorigination.acc.globalipcom.com");
>>>>>>
>>>>>> route(1);
>>>>>> exit;
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>> route[1] {
>>>>>> # for INVITEs enable some additional helper routes
>>>>>> if (is_method("INVITE")) {
>>>>>> # t_on_branch("2");
>>>>>> #t_on_reply("2");
>>>>>> #t_on_failure("1");
>>>>>> }
>>>>>>
>>>>>> if (!t_relay()) {
>>>>>> sl_reply_error();
>>>>>> };
>>>>>> exit;
>>>>>> }
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 11, 2008 at 3:56 PM, Sergio Gutierrez <saguti at gmail.com>wrote:
>>>>>>
>>>>>>> Hello Brett.
>>>>>>>
>>>>>>> could you paste the section of your config file where you are calling
>>>>>>> rewritehost?
>>>>>>>
>>>>>>> Best regards.
>>>>>>>
>>>>>>> Sergio Gutiérrez.
>>>>>>>
>>>>>>> On Tue, Nov 11, 2008 at 4:55 PM, Brett Nemeroff <brett at nemeroff.com>wrote:
>>>>>>>
>>>>>>>> Hi All,I'm using 1.4.2. I'm using rewritehost followed by a t_relay
>>>>>>>> and I'm getting a crash. Happens every time.
>>>>>>>>
>>>>>>>> Debug log shows:
>>>>>>>> Nov 11 08:58:51 [7787] DBG:core:_shm_resize: resize(0) called
>>>>>>>> Nov 11 08:58:51 [7787] DBG:tm:_reply_light: reply sent out.
>>>>>>>> buf=0x77b278: SIP/2.0 1..., shmem=0x7f5931c9cda8: SIP/2.0 1
>>>>>>>> Nov 11 08:58:51 [7787] DBG:tm:_reply_light: finished
>>>>>>>> Nov 11 08:58:51 [7787] DBG:core:mk_proxy: doing DNS lookup...
>>>>>>>> Nov 11 08:58:51 [7787] DBG:core:sip_resolvehost: no port, no proto
>>>>>>>> -> do NAPTR lookup!
>>>>>>>> Nov 11 08:58:51 [7787] DBG:core:get_record: lookup(
>>>>>>>> wholesaleorigination.acc.globalipcom.com, 35) failed
>>>>>>>> Nov 11 08:58:51 [7787] DBG:core:sip_resolvehost: no valid NAPTR
>>>>>>>> record found for wholesaleorigination.acc.globalipcom.com, trying
>>>>>>>> direct SRV lookup...
>>>>>>>> Nov 11 08:58:51 [7794] CRITICAL:core:receive_fd: EOF on 15
>>>>>>>> Nov 11 08:58:51 [7794] DBG:core:handle_ser_child: dead child 8, pid
>>>>>>>> 7787 (shutting down?)
>>>>>>>> Nov 11 08:58:51 [7794] DBG:core:io_watch_del: io_watch_del
>>>>>>>> (0x737640, 15, -1, 0x0) fd_no=20 called
>>>>>>>> Nov 11 08:58:51 [7779] INFO:core:handle_sigs: child process 7787
>>>>>>>> exited by a signal 11
>>>>>>>> Nov 11 08:58:51 [7779] INFO:core:handle_sigs: core was generated
>>>>>>>> Nov 11 08:58:51 [7779] INFO:core:handle_sigs: terminating due to
>>>>>>>> SIGCHLD
>>>>>>>> Nov 11 08:58:51 [7780] INFO:core:sig_usr: signal 15 received
>>>>>>>>
>>>>>>>> I know someone else asked this same question, but I never saw a
>>>>>>>> resolution posted. I do a trace on port 53 at the same time and I most
>>>>>>>> definately see a SRV record returned:
>>>>>>>>
>>>>>>>> 0.000000 192.168.122.250 -> 192.168.122.132 SIP/SDP Request:
>>>>>>>> INVITE sip:17135454263 at 192.168.122.132<sip%3A17135454263 at 192.168.122.132>,
>>>>>>>> with session description
>>>>>>>>
>>>>>>>> 0.016831 192.168.122.132 -> 192.168.122.250 SIP Status: 100
>>>>>>>> Giving a try
>>>>>>>>
>>>>>>>> 0.026370 192.168.122.132 -> 10.128.222.222 DNS Standard query
>>>>>>>> NAPTR wholesaleorigination.acc.globalipcom.com
>>>>>>>>
>>>>>>>> 0.059006 10.128.222.222 -> 192.168.122.132 DNS Standard query
>>>>>>>> response
>>>>>>>>
>>>>>>>> 0.059087 192.168.122.132 -> 10.128.222.222 DNS Standard query
>>>>>>>> NAPTR wholesaleorigination.acc.globalipcom.com.sipinterchange.com
>>>>>>>>
>>>>>>>> 0.091265 10.128.222.222 -> 192.168.122.132 DNS Standard query
>>>>>>>> response, No such name
>>>>>>>>
>>>>>>>> 0.091332 192.168.122.132 -> 10.128.222.222 DNS Standard query SRV
>>>>>>>> _sip._udp.wholesaleorigination.acc.globalipcom.com
>>>>>>>>
>>>>>>>> 0.126236 10.128.222.222 -> 192.168.122.132 DNS Standard query
>>>>>>>> response SRV 100 50 5060 wholesaleoriginationc.acc.globalipcom.comSRV 100 50 5060
>>>>>>>> wholesaleoriginationd.acc.globalipcom.com SRV 100 50 5060
>>>>>>>> wholesaleoriginationa.acc.globalipcom.com SRV 100 50 5060
>>>>>>>> wholesaleoriginationb.acc.globalipcom.com
>>>>>>>>
>>>>>>>> 8 packets captured
>>>>>>>> (the packet capture doesn't return anything else past this because
>>>>>>>> opensips is dead)
>>>>>>>>
>>>>>>>> Any ideas?
>>>>>>>> Thanks,
>>>>>>>> Brett
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list
>>>>>>>> Users at lists.opensips.org
>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
--
Sergio Gutiérrez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20081111/b8236dbe/attachment-0001.htm
More information about the Users
mailing list