Hi Konstantin,
I think the problem you have is misappropriating variables for example Wait-ack means duration to wait for acknowledgment before the resending a message. Each message has to get an ack (acknowledgement) from the SMSC. Check user guide wait-ack number (seconds) A message is resent if the acknowledge from SMSC takes more than this time. Defaults to 60 seconds. It goes hand in hand with wait-ack-expire wait-ack-expire number Defines what kind of action should be taken if the the ack of a message expires. The options for this value are: 0x00 - disconnect/reconnect, (default) 0x01 - as is now, re-queue, but this could potentially result in the msg arriving twice 0x02 – just carry on waiting (given that the wait-ack should never expire this is the mst accurate) I believe what you are referring to for checking whether SMSC has gone away is enquire-link. If you set it to say 30 secs then it will keep enquiring every 30secs and if the SMSC is not available kannel will initiate a reconnect. You can also use reconnect-delay to control how much time before kannel tries to reconnect after it ‘discovers’ it is unbound default is 10secs. Rapture From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Konstantin Vayner Sent: Tuesday, April 12, 2011 12:15 PM To: Kannel Users Subject: UCP keepalive ack problems Hello list, We have several UCP links to a certain operator's SMSC, here's one of the smscs configuration (excluding sensitive information of course) group = smsc smsc = emi smsc-id = smsc_x_mo2 log-file = "/var/log/kannel/x_mo2.log" log-level = 0 host = 1.2.3.4 port = 1234 smsc-username = "xxx" smsc-password = yyy keepalive = 30 idle-timeout = 120 source-addr-autodetect = yes allowed-smsc-id = smsc_x_mo2 flow-control = 0 window = 1 wait-ack = 60 wait-ack-expire = 0x00 (all the links are configured with keepalive=30 and idle-timeout=120 so that the links are never considered idle by kannel) some of the links are for outgoing traffic only, MT and DLR travel on these others are for incoming traffic only, MO travel there. naturally, most of our traffic is outgoing so the MT links are rarely idle, however even when they are, we see steady keepalive requests and ACKs for them going on on the MO links however, the situation is different. these are mostly idle, and keepalive requests do not "work" as expected. sometimes we get ACK on keepalive an *hour* after the original packet was sent (actually, this happens to every second keepalive packet according to the logs i'm looking at) To illustrate the problem, here's the log from such smsc link filtered by 60 and 31 packets dumped: (note that login *requests* are not listed as they are not dumped by kannel) Check out the bold lines - these are ack responses from the smsc that come back after an hour! 2011-04-07 07:18:57 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: < 00/00019/R/60/A//6D > 2011-04-07 07:18:57 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 sending packet: < 24/00025/O/31/201/0539/8E > 2011-04-07 07:18:57 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: < 24/00023/R/31/A/0000/2C > 2011-04-07 07:19:28 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 sending packet: < 25/00025/O/31/201/0539/8F > 2011-04-07 08:19:00 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: < 25/00023/R/31/A/0000/2D > 2011-04-07 08:19:01 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: < 00/00019/R/60/A//6D > 2011-04-07 08:19:01 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 sending packet: < 26/00025/O/31/201/0539/90 > 2011-04-07 08:19:01 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: < 26/00023/R/31/A/0000/2E > 2011-04-07 08:19:41 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 sending packet: < 27/00025/O/31/201/0539/91 > 2011-04-07 09:19:04 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: < 27/00023/R/31/A/0000/2F > 2011-04-07 09:19:04 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: < 00/00019/R/60/A//6D > So, the first question that arises is: why doesnt kannel re-connect automatically after 60 seconds like wait-ack* settings imply, and instead this happens only when the ack finally arrives after an hour? The second question is - in case the remote smsc fails to produce acks to keepalives properly, whats the way of ensuring the link is really alive? Lately, we're experiencing a lot of problems when the link went down on the other side and kannel does not notice that and keeps thinking the link is still alive. Moreover, when we're trying to reset such a "undead" link individually, everything fails, including killing the socket with tcpkill - kannel still does not bring the smsc down, and the only option left is shut down the kannel completely, including kill -9 bearerbox (because otherwise kannel never even finishes shutdown sequence) and performing a full restart.
