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
