Ok , so this is irrelevant, my mistake ;)
I assumed that this applied to any packet, and it only applies to op 51
(submit_sm in terms of ucp)?
This explains why this doens have any effect on the behavior.
To the other point however, this is UCP smsc, so configuration differs from
smpp
Instead of enquire-link theres "keepalive" and "idle-timeout" settings <-
which define how keepalive packets are sent
And i have them configured, too...
The question then remains, how do i control handling of broken keepalives on
the other side? :(
wait-ack* was my last bet...
On Tue, Apr 12, 2011 at 4:42 PM, Rapture wrote:
> 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//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//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//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//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: wh