Dears, I had similar problem, I find workaround (not efficient but work for me), that I increase the reconnect-delay so the TCP connections (from client side) closed.
Hope that work for you. BR, Hafez On Tue, Feb 17, 2009 at 9:53 PM, Nikos Balkanas <[email protected]> wrote: > Hi, > > Just to add that this is not a kannel issue, but network. Kannel, like any > application, doesn't control the 3-way TCP handshake or the 3-way closing. > It just opens and closes a connection. The underlying OS is taking care of > the rest, which it is safe to assume it is not at fault. > > I see 2 problems: > > 1) Network: Something is hanging up connections to dry. Since the SMSc says > that no other client has this issue, it could be a device on your side. If > you don't get any hang connections with other servers, it could be something > in the middle. > > 2) Server: The SMSc server needs to configure tcp_close_timeouts on the tcp > driver. I am surprised if it is the only time they noticed. > > BR, > Nikos > ----- Original Message ----- From: "Nikos Balkanas" <[email protected]> > To: "Falko Ziemann" <[email protected]>; "Manuel Fernando Aller" < > [email protected]> > Cc: <[email protected]> > Sent: Tuesday, February 17, 2009 8:56 PM > > Subject: Re: Kannel left open connections on provider's side > > > Well, actually it shows that the local SMPP server (192.x) is waiting on a >> FIN from 10.10.x. There is an issue why 10.10 is not sending a fin (brute >> disconnection?), but the provider should fine-tune his >> tcp-close-wait-interval, nevertheless. >> >> In Solaris: >> >> ndd /dev/tcp tcp_time_wait_interval 60000 (for 1' CLOSE_WAIT interval) >> >> BR, >> Nikos >> ----- Original Message ----- From: "Falko Ziemann" <[email protected]> >> To: "Manuel Fernando Aller" <[email protected]> >> Cc: <[email protected]> >> Sent: Tuesday, February 17, 2009 8:14 PM >> Subject: Re: Kannel left open connections on provider's side >> >> >> Ok, the operator sent the output of netstat -n to me: >>>> >>>> tcp 0 0 192.168.1.55:3000 10.10.2.10:55740 >>>> CLOSE_WAIT >>>> tcp 0 0 192.168.1.55:3000 10.10.2.10:41852 >>>> CLOSE_WAIT >>>> tcp 0 0 192.168.1.55:3000 10.10.2.10:40574 >>>> CLOSE_WAIT >>>> tcp 0 0 192.168.1.55:3000 10.10.2.10:45049 >>>> CLOSE_WAIT >>>> tcp 0 0 192.168.1.55:3000 10.10.2.10:43960 >>>> CLOSE_WAIT >>>> tcp 0 0 192.168.1.55:3000 10.10.2.10:45496 >>>> CLOSE_WAIT >>>> tcp 0 0 192.168.1.55:3000 10.10.2.10:56315 >>>> CLOSE_WAIT >>>> tcp 0 0 192.168.1.55:3000 10.10.2.10:57205 >>>> CLOSE_WAIT >>>> ..... >>>> ..... >>>> >>>> where 192.168.1.55 is the local ip for his smsc server, and 10.10.2.10 >>>> is my ip (yes, I've chage that!). >>>> >>> >>> That's NAT, that's normal. But, I admit, I have forgot a lot about the >>> TCP stack since my apprentienceship, but doesn't CLOSE_WAIT mean, the >>> foreign side (you) closed the connection and the stack is waiting for the >>> LOCAL software to acknowledge the FIN? >>> >>> http://en.wikipedia.org/wiki/File:Tcp_state_diagram_fixed.svg >>> >>> Regards >>> Falko >>> >>> >> > > -- Hafez A.Ahmad Amman-Jordan mobile:962-785259011 962-795708728 http://blog.hafezadnan.com
