On Wed, Nov 14, 2012 at 3:26 AM, Joegen Baclor <[email protected]> wrote:
> Domenico, > > Can I reproduce this then by using sipp over TCP transport and kill both > sipp-uac and sipp-uas by sending SIGKILL (This will put the sockets in an > unknown state)? > > I don't know .. maybe yes > Although I agree in the design philosophy you have proposed, to patch > sipXtackLib, we need to adhere to an acceptance test and this is the thing > I need to provide before the GIT gatekeeper allows this to be committed. > > that's right .. let me know about > Joegen > > > On 11/14/2012 12:47 AM, Domenico Chierico wrote: > > I'm speaking of self protect .. a server can't be undermined by a poorly > written client. > > the situation here is a server with 50 users that sends to me allarms > every 5 minutes 'cause proxy is at 300% of cpu usage. > > On Tue, Nov 13, 2012 at 5:40 PM, Tony Graziano < > [email protected]> wrote: > >> does it make sense for us to try to build the proxy up to fix UA's that >> might be considered a little more than misguided in the way they handle >> transactions? I don't disagree with the concept of trying to fix it, I just >> wonder if we head down a path of no-return by having to deal with poorly >> written ua's... >> >> >> On Tue, Nov 13, 2012 at 10:48 AM, Domenico Chierico < >> [email protected]> wrote: >> >>> Hi Joegen >>> >>> In more genereical way I've found that we have a problem with >>> uncorrectly closed socket from UA, this can be seen with an unfinished >>> sip stack that ends prematurely and with some softphone that crash or >>> (like linphone) allow to change the transport protocol on fly. >>> >>> Using many different softphone make our server behave as I described, >>> with this patch seems that things go better. >>> >>> I'm still testing so this aren't final results, what I really like to >>> know is your opinion about the validity of the approach, basically I >>> think that check if socket is broken before read or write on it seems >>> to be more safe way of manage. >>> Do you agree ? >>> >>> >>> On Tue, Nov 13, 2012 at 4:09 PM, Joegen Baclor <[email protected]> >>> wrote: >>> > Domenico, >>> > >>> > Thanks for the patch. Just clarifying, this patch is for the behavior >>> you >>> > specified in the August 3 post? If I'm correct, All I need to do to >>> > reproduce is send an INVITE using TCP, on receipt of 183, close the >>> socket. >>> > >>> > -j >>> > >>> > >>> > On 11/13/2012 10:53 PM, Domenico Chierico wrote: >>> > >>> > Just to simplify tests here is the patch >>> > >>> > On Tue, Nov 13, 2012 at 3:14 PM, Domenico Chierico >>> > <[email protected]> wrote: >>> > >>> > Hi >>> > We have 1 sipxecs 4.4 with 50 users installed on kvm based virtual >>> machine. >>> > We had the proxy that ran over 290% of cpu with an average cpu load >>> > close to 95%. Applying the review #22, the stuff start goes better and >>> > we are now close to 40% of cpu load. >>> > >>> > Some of this load come from the known SUBSCRIBE issue, but some others >>> > come from a strange behaviour of the tcp part of the sip stack that we >>> > found: >>> > >>> > - linphone client increases the load on sipXproxy, with his own >>> > strange keepalive method ("Jak" msg to the proxy) and switching the >>> > transport from tcp to udp. >>> > >>> > - Some other evidences come from my personal tests as I notify on 3 of >>> > August on dev-ml. >>> > >>> > Now I'm testing a solution that seems to work, but I wish to know your >>> > opinion. I've change the order of "if" statements into SipClient::run >>> > and I moved the branch about POLLERR and POLLHUP as first. >>> > >>> > On Fri, Aug 3, 2012 at 11:43 AM, Domenico Chierico >>> > <[email protected]> wrote: >>> > >>> > I'm just playing around with go(lang), and this days I was starting >>> > with sip stack implementation, just when messages starts float around >>> > I'd realize that I've written a DOS for proxy .. >>> > I just send INVITE to the proxy than reads for 100 and 180 and so I >>> > close the socket, at this point I got this into the logs forever: >>> > >>> > "2012-08-03T09:31:03.817653Z":43810:SIP:DEBUG:testpbx.labsip2ser.net: >>> SipClientTcp-30:22CEF700:SipXProxy:"SipClient[SipClientTcp-30]::run >>> > resPoll= 1 revents: fd[0]= 0 fd[1]= 1d" >>> > >>> "2012-08-03T09:31:03.817668Z":43811:KERNEL:DEBUG:testpbx.labsip2ser.net: >>> SipClientTcp-30:22CEF700:SipXProxy:"OsSocket::isReadyToWrite >>> > poll returned 1 in socket: 21 0x7f5eec002070" >>> > "2012-08-03T09:31:03.817683Z":43812:SIP:DEBUG:testpbx.labsip2ser.net: >>> SipClientTcp-30:22CEF700:SipXProxy:"SipClient[SipClientTcp-30]::run >>> > resPoll= 1 revents: fd[0]= 0 fd[1]= 1d" >>> > >>> "2012-08-03T09:31:03.817698Z":43813:KERNEL:DEBUG:testpbx.labsip2ser.net: >>> SipClientTcp-30:22CEF700:SipXProxy:"OsSocket::isReadyToWrite >>> > poll returned 1 in socket: 21 0x7f5eec002070" >>> > "2012-08-03T09:31:03.817714Z":43814:SIP:DEBUG:testpbx.labsip2ser.net: >>> SipClientTcp-30:22CEF700:SipXProxy:"SipClient[SipClientTcp-30]::run >>> > resPoll= 1 revents: fd[0]= 0 fd[1]= 1d" >>> > >>> "2012-08-03T09:31:03.817728Z":43815:KERNEL:DEBUG:testpbx.labsip2ser.net: >>> SipClientTcp-30:22CEF700:SipXProxy:"OsSocket::isReadyToWrite >>> > poll returned 1 in socket: 21 0x7f5eec002070" >>> > >>> > I hope this helps.. >>> > >>> > bye >>> > Domenico Chierico >>> > >>> > >>> > >>> > _______________________________________________ >>> > sipx-users mailing list >>> > [email protected] >>> > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> > >>> > >>> _______________________________________________ >>> sipx-users mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >> >> >> >> -- >> ~~~~~~~~~~~~~~~~~~ >> Tony Graziano, Manager >> Telephone: 434.984.8430 >> sip: [email protected] >> Fax: 434.465.6833 >> ~~~~~~~~~~~~~~~~~~ >> Linked-In Profile: >> http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >> Ask about our Internet Fax services! >> ~~~~~~~~~~~~~~~~~~ >> >> Using or developing for sipXecs from SIPFoundry? Ask me about >> sipX-CoLab 2013! >> <http://sipxcolab2013.eventbrite.com/?discount=tony2013> >> >> >> LAN/Telephony/Security and Control Systems Helpdesk: >> Telephone: 434.984.8426 >> sip: [email protected] >> >> Helpdesk Customers: http://myhelp.myitdepartment.net >> Blog: http://blog.myitdepartment.net >> >> _______________________________________________ >> sipx-users mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> > > > > _______________________________________________ > sipx-users mailing [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > >
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
