Well, then your only onption might be to get a hub and connect an other machine to it running tcpdump/ngrep instead of running it locally. Also, look at your switches, maybe they have port mirriring ?

On Thu, 2008-12-11 at 17:22 +0100, Aurelien Grimaud wrote:
Well, it seems hard to reproduce with ngrep running ..
It seems like the timing is not the same anymore and ngrep slow down the 
computer just enough for bug not to trigger.
I tried many times and the result is that when ngrep is not running, the 
bug shows up, while wth ngrep it stay hidden.
I hope last log from sipp were enough.

However, this retransmission should not disturb the remote user and 
while nasty race should be handled, this is minor for me.
My real problem, concerns transaction module too and is more troubling.
This is the one I related in 
http://lists.kamailio.org/pipermail/users/2008-December/020882.html

I use this timer triggering to fail over another end user and implement 
serial forking.
If the timer triggers while it should not, I will initiate a second call 
to another destination, which is wrong.

Any idea on this one ?

This is while trying to reproduce it that I found those weird 
retransmission.
I'll try and trigger this initial bug again.

Regards

Aurelien

Aurelien Grimaud a écrit :
> Sure, meanwhile here are messages provided by sipp
> UAS side and UAC side.
> UAC contains only the 10 calls done
> UAS contains much more as I was trying to reproduce it with 1 call at 
> a time.
>
> Aurelien
>
> Daniel-Constantin Mierla a écrit :
>> Can you please make the test again and send along with the debug 
>> messages the sip trace?
>>
>> ngrep -d any -qt -W byline port 5060
>>
>> I want to check the sip messages as well.
>>
>> Thank you,
>> Daniel
>>
>>
>> On 12/11/08 16:19, Aurelien Grimaud wrote:
>>> Answer waiting for approval : logs too big !
>>>
>>> Here is a lighter one.
>>>
>>> My answer was
>>>> Thanks for the patch.
>>>>
>>>> With 1 call at a time, the bug does not trigger anymore.
>>>> However, with 2 calls at a time it was triggered again on BYE.
>>>> Attached log is result of my testing.
>>>> 1 sipp as uac make 10 calls with 2 simultaneous calls allowed.
>>>>
>>>> The call callid=7-22285-127.0.0.1 request resending of BYE message 
>>>> at 14:21:07.563004, though we have a 200 ok on BYE at 
>>>> 14:21:07.156865 (pid=21493)
>>>> Bye request (pid=21495) was not finished to be treated at the time 
>>>> 200 ok was received.
>>>>
>>>> This was done with my module active.
>>>> I'll make new tests without it.
>>>>
>>>> Regards,
>>>> Aurelien 
>>>
>>>
>>> Daniel-Constantin Mierla a écrit :
>>>> ... disregard the previous patch, please use this one. It was not 
>>>> the latest. Thanks,
>>>>
>>>> Daniel
>>>>
>>>>
>>>> On 12/10/08 23:52, Daniel-Constantin Mierla wrote:
>>>>> Hello,
>>>>>
>>>>> On 12/09/08 20:41, Aurelien Grimaud wrote:
>>>>>> Daniel-Constantin Mierla a écrit :
>>>>>>  
>>>>>>> On 12/09/08 18:52, Aurelien Grimaud wrote:
>>>>>>>  
>>>>>>>> I am able to reproduce it with 1 call / second without my 
>>>>>>>> module on BYE requests.
>>>>>>>> here are traces.
>>>>>>>>       
>>>>>>> there is a race (at least), indeed. It happens when there is 
>>>>>>> fast reply. I am going to send you a patch soon for testing, you 
>>>>>>> use svn branch 1.4 or the tarball?
>>>>>>>     
>>>>>> Great, I use the kamailio-1.4.2-notls tarball.
>>>>>> But I can test any SVN branch / trunk if you wish.
>>>>>>   
>>>>> can you test the attached patch with SVN trunk? Let me know the 
>>>>> results. Pay attention to see if breaks something else, not just 
>>>>> if fixes the reported issue. I let there some debug messages, to 
>>>>> help troubleshooting, if the fix is ok, I'll remove them before 
>>>>> committing.
>>>>>
>>>>> Thanks,
>>>>> Daniel
>>>>>
>>>>>> Aurelien
>>>>>>
>>>>>>  
>>>>>>> Cheers,
>>>>>>> Daniel
>>>>>>>
>>>>>>>
>>>>>>>  
>>>>>>>> ps: I added the ms on Logs.
>>>>>>>>
>>>>>>>> Aurelien
>>>>>>>>
>>>>>>>> Daniel-Constantin Mierla a écrit :
>>>>>>>>  
>>>>>>>>> On 12/09/08 17:56, Klaus Darilion wrote:
>>>>>>>>>  
>>>>>>>>>    
>>>>>>>>>> Daniel-Constantin Mierla schrieb:
>>>>>>>>>>          
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> On 12/09/08 17:31, Klaus Darilion wrote:
>>>>>>>>>>>                
>>>>>>>>>>>> Aurelien Grimaud schrieb:
>>>>>>>>>>>>  
>>>>>>>>>>>>                      
>>>>>>>>>>>>> Fair enough.
>>>>>>>>>>>>> If no one already experienced this strange behavior, it 
>>>>>>>>>>>>> should be my module ...
>>>>>>>>>>>>> I'll try to make it again without my module.
>>>>>>>>>>>>>                                       
>>>>>>>>>>>> See my other email.
>>>>>>>>>>>>
>>>>>>>>>>>>  
>>>>>>>>>>>>                      
>>>>>>>>>>>>> However, in the log, after the 200 response, there is a 
>>>>>>>>>>>>> cleanup_uac_timers: RETR/FR timers reset.
>>>>>>>>>>>>> So those timers are cleared.
>>>>>>>>>>>>>                                       
>>>>>>>>>>>> But the problem is, that the process which handles the 
>>>>>>>>>>>> INVITE has not finished yet and those (re)SETS the timer.
>>>>>>>>>>>>
>>>>>>>>>>>> @Daniel - Have you investigated the problem?
>>>>>>>>>>>>                               
>>>>>>>>>>> so this is the half of the issue reported via:
>>>>>>>>>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2105813&group_id=139143&atid=743020 
>>>>>>>>>>>                       
>>>>>>>>>> yes.
>>>>>>>>>>
>>>>>>>>>> Can it be related to other modules which register callbacks 
>>>>>>>>>> (e.g. pua module or Aurelien's module?
>>>>>>>>>>                 
>>>>>>>>> what is the requests/second rate when the issue appears?
>>>>>>>>>
>>>>>>>>> At first look, between sending and setting retransmission 
>>>>>>>>> timer, there is no much processing for the request. The 
>>>>>>>>> callback executed there is in use by siptrace, are you using 
>>>>>>>>> this module?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Daniel
>>>>>>>>>         
>>>>>>>>>>> This one got lost, but as I started to fix the other half 
>>>>>>>>>>> (replying using proper mode to do retransmission), will 
>>>>>>>>>>> investigate this as well ...
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Daniel
>>>>>>>>>>>             
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users@lists.kamailio.org
>>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>>   
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users@lists.kamailio.org
>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>>>
>>>
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Devel mailing list
> Devel@lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
>   



_______________________________________________
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

Jérôme Martin | LongPhone
Responsable Architecture Réseau
122, rue la Boetie | 75008 Paris
Tel :  +33 (0)1 56 26 28 44
Fax : +33 (0)1 56 26 28 45
Mail : jmartin@longphone.fr
Web : www.longphone.com