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)?
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.
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] <mailto:[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]
<mailto:[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] <mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[email protected]>
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
_______________________________________________
sipx-users mailing list
[email protected]
<mailto:[email protected]>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: [email protected]
<mailto:[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]
<mailto:[email protected]>
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
[email protected] <mailto:[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/
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
