[OpenSIPS-Users] Nathelper ping does not consistently ping all contacts

[James Lamanna]

Bogdan,
I'm really not sure where that garbage is coming from.
It almost seems like some weird artifact from printing to syslog..
I had it print out the length, and I see lines like this:

pinging contact: sip:208.xx.xxx.130:7538??z len: 23

"sip:208.xx.xxx.130:7538" is 23 characters long, so the '??z'
shouldn't be printed...

-- James

On Fri, Jul 8, 2011 at 6:12 PM, James Lamanna <jlamanna at gmail.com> wrote:
> Hi Bogdan,
> I've been monitoring it (I wrote myself a script that checks the AORs
> in memory against syslog).
> I haven't seen any issues lately.
> The trailing garbage is weird as well. In the DB, the contacts look ok.
> I haven't tracked down where that is coming from yet.
>
> -- James
>
> On Fri, Jul 8, 2011 at 8:42 AM, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
>> Hi James,
>>
>> thanks a lot for the feedback.
>>
>> The log you added does not show anything wrong - the path fields may be
>> missing and the so called contact part (returned by usrloc) is either the
>> received URI (if present), either the contact URI (if not received URI).
>>
>> What looks scary are the trailing chars for the URI....but the question is
>> if the bogus contact happens because it get bogus when returned by usrloc
>> (by get_all_mem_contacts) function or because the received URI was bogusly
>> saved in ursloc from the beginning via the fix_nated_registered() function
>>
>> Regards,
>> Bogdan
>>
>>
>> On 07/01/2011 05:58 PM, James Lamanna wrote:
>>
>> Hi Bogdan,
>> Unfortunately I've found that it doesn't fix the entire problem.
>> I have a contact now that is online, that still isn't getting pinged for
>> some reason.
>> I think there's something subtle in get_all_mem_contacts in dlist.c.
>> I haven't tried to see if this problem still manifests itself if the usrloc
>> mode is DBONLY (its a production server).
>> But as an example, I have this contact online (from opensipsctl ul show):
>> AOR:: 22505
>> Contact:: sip:22505 at 192.168.1.117:7945 Q=
>> Expires:: 1401
>> Callid:: c3bfd2f5-50aff633 at 192.168.1.117
>> Cseq:: 63708
>> User-agent:: Linksys/SPA962-6.1.3(a)-000e08d21b47
>> Received:: sip:x.x.x.x.:1024
>> State:: CS_SYNC
>> Flags:: 0
>> Cflag:: 192
>> Socket:: udp:opensips.ip:5060
>> Methods:: 5183
>> I've added a print in nathelper.c:
>> @@ -3648,8 +3650,11 @@
>>   continue;
>>   }
>>   }
>> - if (curi.proto != PROTO_UDP && curi.proto != PROTO_NONE)
>> + LM_INFO("pinging contact: %*s %*s\n", path.len, path.s, c.len, c.s);
>> + if (curi.proto != PROTO_UDP && curi.proto != PROTO_NONE) {
>> + LM_ERR("dumping contact: %*s %*s\n", path.len, path.s, c.len, c.s);
>>   continue;
>> + }
>>   if (curi.port_no == 0)
>>   curi.port_no = SIP_PORT;
>>   proto = curi.proto;
>> I see these prints for a while for this contact:
>> Jun 30 12:30:53 frontend1 /usr/local/sbin/opensips[7087]:
>> INFO:nathelper:nh_timer: pinging contact: (null) sip:208.90.185.166:7945??z
>>
>> And then it just stops.
>> Restarting Opensips doesn't bring it back either.
>> unfortunately I haven't had time to digest the code in dlist.c to figure out
>> what is actually going on in there with the 2 indices.
>> Thanks.
>> -- James
>>
>> On Fri, Jul 1, 2011 at 7:29 AM, Bogdan-Andrei Iancu <bogdan at opensips.org>
>> wrote:
>>>
>>> Hi Andrew,
>>>
>>> Thanks God for mentioning this - the initial report from James missed me,
>>> and I was not aware of the bug and the fix - I just fixed it right now on
>>> the SVN trunk and 1.6
>>>
>>> Thanks and regards,
>>> Bogdan
>>>
>>> On 07/01/2011 06:45 AM, Andrew Pogrebennyk wrote:
>>>>
>>>> James,
>>>>
>>>> On 01.07.2011 06:42, James Lamanna wrote:
>>>>>
>>>>> Hi,
>>>>> I've noticed after a period of time, Nathelper will stop sending pings
>>>>> to some contacts.
>>>>> I've verified that the contact is still registered (it is even in the
>>>>> location table) but the ping process appears to skip some contacts for
>>>>> unknown reasons.
>>>>
>>>> maybe see if this fixes the problem for you:
>>>> http://www.mail-archive.com/users@lists.opensips.org/msg16200.html
>>>> ?
>>>>
>>>>> Could someone please look into this? I have phones behind NAT that stop
>>>>> being able to receive calls because firewalls close down the UDP mapping
>>>>> since this feature is not working properly.
>>>
>>> --
>>> Bogdan-Andrei Iancu
>>> OpenSIPS solutions and "know-how"
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> --
>> Bogdan-Andrei Iancu
>> OpenSIPS eBootcamp - 2nd of May 2011
>> OpenSIPS solutions and "know-how"
>