Klaus Darilion a écrit : > Jerome Martin wrote: >> 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 ? > > or try > tcpdump -s 0 -w file.pcap port 5060 > I tried it with the same result : no bug. All the traffic is local in my case. sipp uac, openser and sipp uas are running on the same host.
I tried with tcpdump -s0 -ilo port 5060, with no better result. I'll try running sipp on other host, but latency caused by network interface will sure make the bug not show up. Cheers, Aurelien > As this does not cause any console output maybe it does generate less > load. > > klaus > >> >> 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 >>> >>> <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 <mailto:Users@lists.kamailio.org> >>> >>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>> >>>>>> >>> >>>>>> >>>>> >>> >>>>> >>> ------------------------------------------------------------------------ >>> >>>>> >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> Users mailing list >>> >>>>> Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> >>> >>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>> >>>> >>> >>> >>> >> >>> > >>> > >>> ------------------------------------------------------------------------ >>> >>> > >>> > _______________________________________________ >>> > Devel mailing list >>> > de...@lists.kamailio.org <mailto:de...@lists.kamailio.org> >>> > http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel >>> > >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.kamailio.org <mailto: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 : *jmart...@longphone.fr >> Web : www.longphone.com <http://www.longphone.com> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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
