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].**net<[email protected]> > > Helpdesk Customers: > http://myhelp.myitdepartment.**net<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 list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
