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 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