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 > > [EMAIL PROTECTED] > > 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 : [EMAIL PROTECTED] Web : www.longphone.com
_______________________________________________ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
