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.
