[asterisk-users] Workaround for bug in Linksys Firmware 6.1.3(a) (or greater)

[Ryan Wagoner]

On Tue, Jun 22, 2010 at 8:30 PM, James Lamanna <jlamanna at gmail.com> wrote:
> On Tue, Jun 22, 2010 at 4:31 PM, Ryan Wagoner <rswagoner at gmail.com> wrote:
>> On Tue, Jun 22, 2010 at 6:26 PM, James Lamanna <jlamanna at gmail.com> wrote:
>>> On Tue, Jun 22, 2010 at 12:06 PM, Stefan Schmidt <sst at sil.at> wrote:
>>>> James Lamanna schrieb:
>>>>> If you've used Linksys phones against recent Asterisk 1.4.x you may
>>>>> have noticed
>>>>> that they may drop registration for a quick bit and then go back to being ok
>>>>> if your phone is behind NAT.
>>>>> If you turn Asterisk's sip debug information on, you'll probably find
>>>>> errors like these in your logs:
>>>>>
>>>>> NOTICE[30179] chan_sip.c: Correct auth, but based on stale nonce
>>>>> received from '"999911" <sip:999911 at 208.90.186.10>'
>>>>>
>>>>> I believe I have determined that this is caused by a bug in the
>>>>> Linksys firmware that is related to the NAT Keep-Alive packets.
>>>>> Because recent Asterisk 1.4.x's do not establish a SIP dialog for
>>>>> NOTIFY requests, the "489 Bad Event"
>>>>> replies were going back to the wrong address if your phone was behind NAT.
>>>>> This lack of reply would cause the next REGISTER message to use the
>>>>> same nonce as the previous REGISTER,
>>>>> resulting in the "stale nonce" errors and temporarily dropping
>>>>> registration. I've also seen the lack of response to
>>>>> the NAT keep-alive cause the phone to stop being able to register
>>>>> completely as well.
>>>>>
>>>>> Below I've posted a patch that responds with a 200 OK to these
>>>>> keep-alive requests, and I believe
>>>>> also solves the temporary loss of registration problem, though more
>>>>> testing in different environments
>>>>> for those who experience this problem would be greatly appreciated.
>>>>>
>>>>> The patch is against 1.4.32.
>>>>>
>>>>> -- James
>>>>>
>>>> Hello,
>>>>
>>>> you also just could set the NAT KEEP ALIVE MESSAGE on Ext 1 from $NOTIFY
>>>> to $OPTIONS and make this extension in your default context:
>>>> exten => s,1,hangup
>>>>
>>>> and you also would get a 200 ok for the keep alive package.
>>>>
>>>> IMHO a stale nonce would only occur when a user tries to register faster
>>>> than 3600s cause of the register timeout used in asterisk. Maybe you
>>>> should also try to set a higher register timeout on your phones. but i
>>>> dont have an 1.4 system running, only around 2k of linksys phones on a
>>>> 1.2.40 and 300 on 1.6.1.18 and i dont see this problem there.
>>>
>>> I'm not sure how this works.
>>> The OPTIONS message fails chan_sip.c:parse_request() so the OPTIONS
>>> message never gets processed.
>>> The options message I receive from a Linksys942 6.1.3(a) looks like this:
>>>
>>> <--- SIP read from xxx.xxx.xxx.xxx:8037 --->
>>> OPTIONS
>>> <------------->
>>>
>>> -- James
>>>
>>> --
>>
>> I had the same result when using $OPTIONS on a SPA941 phone with
>> firmware 5.1.8. I am running Asterisk 1.6.2.9 that has the keep-alive
>> support, however I still see Asterisk sending a 489 Bad Event. I just
>> reopened the issue and provided the necessary debug log at
>> https://issues.asterisk.org/bug_view_page.php?bug_id=17379
>
> Ryan,
> This is most likely because the packet never makes it to handle_request_notify.
> I haven't looked at the code for 1.6.2.9 yet, but in 1.4.32 without my
> patch, the
> NOTIFY request would never make it out of find_call() and return early with a
> 489 Bad Event response.
>
> Were you getting any response at 1.6.2.9 with the OPTIONS message?
>
> -- James
>
> --

The out of dialog support was the trick for 1.6.2.9 since it has
support for sending a keep-alive. I have attached a modified version
of your patch that worked for me. Do you mind if I attach the modified
version of the patch to my issue report?

Ryan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asterisk-1.6.2.9-keep-alive.patch
Type: application/octet-stream
Size: 1117 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20100622/857c9448/attachment.obj