[Users] nathelper natping OPTIONS packets formated to not get reply?

Bogdan-Andrei Iancu bogdan at voice-system.ro
Fri Feb 17 17:19:23 CET 2006


Hi Glenn,

no problem :) just keep me up to date if indeed the lack/presence of 
username in the TO hdr makes any difference. As we are close to make a 
new release on 1.0.x branch, it will be a nice fix to have .

regards,
bogdan

Glenn Dalgliesh wrote:

>Well I am feeling a little embarrassed at this point but it seems that my
>data may not have been exactly correct with regard to natpings not working
>without username in the TO field of OPTIONS packets. 
>
>First my original test scenario was to ngrep for OPTIONS packets generated
>from OpenSer and see if I was getting response without Username in the TO
>field. Then I would send an OPTIONS using sipsak thru openser and see if I
>got a reply. Based on this test it appeared that it was the lack of Username
>in the TO field. But then after recording results with my work round in
>place which rewrote the received field. I found that I was still not getting
>consistent results on replies to OPTIONS packets this lead me to start
>looking to see if the OPTIONS packets where ever reaching the dest...
>It turns out that the OPTIONS packets were not reaching the dest and it
>seems that the reason was that the Cisco router btw OPENSER and the Internet
>was dropping a very high percentage of out bound packets under bursty
>situations such as hundreds of OPTIONS packets being sent to it at once. I
>have resolved this issues and now I am getting consistant results from the
>natping OPTIONS packets. 
>
>I will follow up with one more test which is to remove my work around
>related to the received field and retest the results. However, I will have
>to wait until I can test this after hours inorder to make this change. 
>
>Thanks and sorry for the bad data but as you can see it wasn't do to lack of
>thought :)
>
>
>FYI: your patch did seem to added the natping FROM field to the TO field
>after I retest we can figure out if that is really necessary.
>
>  
>





More information about the sr-users mailing list