Re: is there a parameter (escape code) in dlr-url to return smsc-admin-id?

[lbrezs...@gmx.co.uk]

Understood. Thanks.

On 10/12/2023 01:42, Alexander Malysh wrote:

Hi,

as far as I see, no.

Regards,
Alexander Malysh
Am 10. Okt. 2023, 18:33 +0200 schrieb lbrezs...@gmx.co.uk
:


In kannel.conf config when defining dlr-url is there a parameter
(escape code) to return smsc-admin-id?

Documented %i will return the smsc-id of the connection that received
the message. But if there are multiple binds per smsc defined by
smsc-admin-id for the same conncetion, is there a way to get more
granular info?

is there a parameter (escape code) in dlr-url to return smsc-admin-id?

[lbrezs...@gmx.co.uk]

In kannel.conf config when defining dlr-url is there a parameter (escape
code)  to return smsc-admin-id?

Documented %i will return the smsc-id of the connection that received
the message. But if there are multiple binds per smsc defined by
smsc-admin-id for the same conncetion, is there a way to get more
granular info?

Re: Error in LD when building kannel on Ubuntu 22.04

[lbrezs...@gmx.co.uk]

Last time I compiled on debian, bison 3.0 would give me errors when
compiling kannel package.


Remove
$ sudo apt-get remove bison

Install bison version 2.7:

$ sudo wget
http://launchpadlibrarian.net/140087283/libbison-dev_2.7.1.dfsg-1_amd64.deb
$ sudo wget
http://launchpadlibrarian.net/140087282/bison_2.7.1.dfsg-1_amd64.deb
$ sudo dpkg -i libbison-dev_2.7.1.dfsg-1_amd64.deb
$ sudo dpkg -i bison_2.7.1.dfsg-1_amd64.deb
$ sudo rm bison_2.7.1.dfsg-1_amd64.deb libbison-dev_2.7.1.dfsg-1_amd64.deb

To prevent update manager from overwriting this package

$ sudo apt-mark hold libbison-dev
$ sudo apt-mark hold bison


On 7/4/2023 10:43, Paulo Correia wrote:

Hello kannel users,

I'm trying to build kannel on Ubuntu Server 22.04 but keep getting the
following LD error:

/usr/bin/ld:
libwap.a(wtp_resp.o):/tmp/tmp.jkHPbxZ32N/gateway-1.4.5/wap/wtp_resp.c:100:
multiple definition of `dispatch_to_wsp';
libgw.a(wap_push_ota.o):/tmp/tmp.jkHPbxZ32N/gateway-1.4.5/gw/wap_push_ota.c:116:
first defined here
collect2: error: ld returned 1 exit status
make: *** [Makefile:361: gw/wapbox] Error 1

The configure command was:
./configure --with-defaults=speed --with-redis --enable-ssl
--with-ssl=/usr/lib/ssl --prefix=/opt/local/gateway-1.4.5
--enable-start-stop-daemon

and then called "make".

I had no issues with CentOS 7 and CentOS 8 ...

Any clues?

Kind regards,
*Paulo Correia*
Systems Architect

*telephone:*+351210337760*fax:* +351210337761
*email:* paulo.corr...@go4mobility.com skype: pcorreia.g4m

assinatura_email_go4mobility_comlogo

assinatura_email_go4mobility_followus

_

/CONFIDENTIALITY/

/This message, as well as existing attached files, may be confidential
and privileged. Use or disclosure by anyone other than an intended
recipient is not authorized./

/If you have received this message by error, you are kindly requested
to delete it and notify the sender. Thank you for your cooperation./

Re: kannel init.d script question

[lbrezs...@gmx.co.uk]

One more error: start-stop-daemon: unrecognized option '--retry'

kannel[1169]:  bearerbox
kannel[1173]: /usr/local/sbin/start-stop-daemon: unrecognized option
'--retry'
kannel[1173]: Try `/usr/local/sbin/start-stop-daemon --help' for more
information.
kannel[1169]: .
systemd[1]: kannel.service: Succeeded.

On 6/27/2022 20:59, lbrezs...@gmx.co.uk wrote:

Compiled kannel from svn (version 5324) on Debian.

Copied kannel init script to /etc/init.d/

~$ sudo cp /usr/src/gateway-svn-5324/debian/kannel.init
/etc/init.d/kannel

To start kannel

~$ systemctl start kannel

works as expected, but

~$ systemctl stop kannel

does not.

kannel[2707]: start-stop-daemon: unrecognized option '--retry'
kannel[2707]: Try `start-stop-daemon --help' for more information.
kannel[2705]: .
systemd[1]: kannel.service: Succeeded.
systemd[1]: kannel.service: Unit process 2199 (run_kannel_box) remains
running after unit stopped.
systemd[1]: kannel.service: Unit process 2201 (bearerbox) remains
running after unit stopped.
systemd[1]: kannel.service: Unit process 2211 (run_kannel_box) remains
running after unit stopped.
systemd[1]: kannel.service: Unit process 2212 (smsbox) remains running
after unit stopped.
systemd[1]: Stopped kannel.service.
systemd[1]: kannel.service: Consumed 1.102s CPU time.

As a result, kannel is still running

~$ pgrep -u kannel

2199
2201
2211
2212

shows all 4 pids active and have to kill them manually.

Am I missing something? Or it's a bug?

Thanks,

Lelik.

kannel init.d script question

[lbrezs...@gmx.co.uk]

Compiled kannel from svn (version 5324) on Debian.

Copied kannel init script to /etc/init.d/

~$ sudo cp /usr/src/gateway-svn-5324/debian/kannel.init /etc/init.d/kannel

To start kannel

~$ systemctl start kannel

works as expected, but

~$ systemctl stop kannel

does not.

kannel[2707]: start-stop-daemon: unrecognized option '--retry'
kannel[2707]: Try `start-stop-daemon --help' for more information.
kannel[2705]: .
systemd[1]: kannel.service: Succeeded.
systemd[1]: kannel.service: Unit process 2199 (run_kannel_box) remains
running after unit stopped.
systemd[1]: kannel.service: Unit process 2201 (bearerbox) remains
running after unit stopped.
systemd[1]: kannel.service: Unit process 2211 (run_kannel_box) remains
running after unit stopped.
systemd[1]: kannel.service: Unit process 2212 (smsbox) remains running
after unit stopped.
systemd[1]: Stopped kannel.service.
systemd[1]: kannel.service: Consumed 1.102s CPU time.

As a result, kannel is still running

~$ pgrep -u kannel

2199
2201
2211
2212

shows all 4 pids active and have to kill them manually.

Am I missing something? Or it's a bug?

Thanks,

Lelik.

Re: Multipart long message delivery receipt problem

[lbrezs...@gmx.co.uk]

Hi Ruben,

We are fully aware of TLV 0x0427. We implemented and use it .. with 1 of
our 3 providers.

The other two do not support it. :(

Regards,

Lelik.


On 6/24/2022 19:45, Ruben Melikyan wrote:

Hi Lelik,
To avoid such behavior you should tell kannel to submit long messages
as payload (instead of multipart, which is default option). In this
case you will have only one submit and one delivery report for long
messages.

You can reach this functionality by adding TLV parameter for your
smsc. Normally it goes  in the end of your smsc config.

Below you can see config example

#-SMSC smpp -

group = smsc
smsc = smpp
smsc-id = MYSMSC
host = ***.***.***.***
port = 
transceiver-mode = true
interface-version = 34
**
***



group = smpp-tlv
name = message_payload
tag = 0x0424
type = octetstring
length = 5000
smsc-id = MYSMSC;



On Wed, 22 Jun 2022 at 01:26 lbrezs...@gmx.co.uk
 wrote:

Alexander,

We observed totally different behaviour of Kannel:

1) Kannel requested all segments for delivery, not just 1, i.e. 3
segment message will result in 3 submit_sm (s) all marked with
registered_delivery: 1 = 0x0001

2) dlr_mask is altered with dlr8/16 flipped back to 0 as kannel
converts ACKs and NACKs to dlr8/16 instead

3) Kannel receives all corresponding submit_sm_resp(s). Only 1st
segment message_id is written to dlr storage. And only one
ACK/NACK is converted to dlr8/16.

4) Depending on the end user mobile provider, we get either all
segments deliver_sm(s) or just 1. In fact, majority of the
carriers return multiple. In fact, only one carrier returns 1
part and it's the last segment message_id :(

5) The order of the corresponding deliver_sm is arbitrary. If the
1st segment deliver_sm comes 1st, then you are in luck, as it
will be matched to the message_id in dlr_storage and delivered to
smsbox. Any other part would result in error "got DLR but could
not fi nd message or was not interested in it" and dlr would be lost.

In my honest opinion, there is an easy fix, but it involves
altering Kannel source code and re-compiling it.

Write both id(s) to the dlr storage. id of the 1 segment + id of
the current segment. We use redis for example. 3 segment message
would result in something like this:

Now:

123) "dlr:provider_smsc:11"

Altered:

100) "dlr:provider_smsc:11:11"

101) "dlr:provider_smsc:11:12"

102) "dlr:provider_smsc:11:13"

When 1st deliver_sm received, let say for message_id 13
(last), match dlr by message id 13, but delete by all dlr(s)
marked 11, and give the dlr to smsbox.

When next dlr let say for id 12 comes in, it will result in
"got DLR but could not find message or was not interested in it"
error (flip to warning) and no dlr would be given to smsbox.

This way you always get only one dlr, and you do not depend on
which order they are sent back by the provider.

Regards,

Lelik.


On 6/21/2022 04:27, Alexander Malysh wrote:

Hi,

Kännel per default split long message and request DLR for only
first part of long message. If carrier sends more DLRs as
requested, it’s a bug on carrier side. To get all DLRs requested
for long message, more work on patching channel is needed,
because a mid layer expect only one DLR from kannel to be
delivered, because mid layer made only one request to kannel.

Regards,
    Alexander Malysh
    Am 16. Juni 2022, 17:54 +0200 schrieb lbrezs...@gmx.co.uk
 <mailto:lbrezs...@gmx.co.uk>:

Hi all,

When sending long messages using native Kannel concatenation
functionality based on UDH, we are experiencing problems with
matching
delivery receipts of the submitted messages.

The problem arises from the fact that not all carries send back all
delivery receipts. Some send only one receipt and it's not not
necessarily #1.

Basically there are 3 scenarios:

1) Carrier/Provider #1 sends back 1 delivery receipt and message_id
correspondents to segment #1. Bearer_box matches by message_id, and
forwards 1 delivery receipt to sms_box. This is the most
desirable path.

2) Carrier/Provider #2 sends back 1 delivery receipt and message_id
correspondents to last segment. Bearer_box cannot match by
message_id,
and does NOT forward a delivery receipt to sms_box at all.

Delivery receipt is lost.

3) Carrier/Provider #3 sends back all delivery receipts for each
segment. The order is random, lat say 5-segment message migh
come back
as 3,5,1,4,2. Bearer_box cannot match 3,5, matches 1 , cannot
match 4,2
. It forwards only a delivery receipt for segment # 1 to
sms_box. The
other 2,3,4,5 would stay in dlr-storage and eventually expir

Re: Kannel as server?

[lbrezs...@gmx.co.uk]

https://www.smsfoxbox.it/documents/pdf/open_smpp_box_user_guide.pdf

On 6/20/2022 07:39, Antony Stone wrote:

On Monday 20 June 2022 at 13:18:46, Mesbahuddin Malik wrote:


what type of SMSC you are using smpp or http ?
Kannel do for both though opensmpp is not suitable until it is customized.

Sorry - I should have said - SMPP.

Interesting that you mention OpenSMPP - it's something I've found references
to whilst trying to discover the answer for myself, and it appears to be an
add-on for Kannel, but I find no documentation at all about how to install or
configure it.

https://www.kannel.org/download/1.4.5/userguide-1.4.5/userguide.html doesn't
seem to mention it at all, and I don't find it at https://kannel.org/ either.

If you could point me to any online guide to making this work, thanks!


On Mon, Jun 20, 2022 at 4:06 PM Antony Stone wrote:

Hi.

I've been using kannel for some time, connecting as a client to a mobile
operator's SMSC.

I've been asked whether we can set up a test environment which doesn't
have a connection to a "real" SMSC, but instead talks to something we run
which acts in the same way.

So, my question is: can kannel act as a server, allowing another (client)
kannel instance to connect to it as though it were an operator's SMSC?


Thanks in advance,


Antony.

Re: REDIS: redisCommand() failed: ERR unknown command

[lbrezs...@gmx.co.uk]

We considered DLR 27, but unfortunately some small number of ISPs don't
send DLR 1 or 2 at all.

They just acknowledged they received the request,  but not that end user
(mobile phone) received it.

Question: why code handling DLR1 and DLR4 is different? I compared the
structure of both DLRa and they are the same:

DLR4:
id:0273822961 sub:001 dlvrd:000 submit date:2204142257 done date
2204142257 stat ACCEPTD err:003 text:Test DLR 4
DLR1
id:0274640129 sub:001 dlvrd:001 submit date:2204151041 done date
2204151041 stat DELIVRD err:000 text:Test DLR 1

Why even make a trip to REDIS? As you need to wait for DLR 1/2 anyways,
why even bother?
They are still forwarded to smsbox, no? Shouldn't be just an "IF"
statement that DLR 1 or DLR 2 make a trip to REDIS, everything else is
forwarded to smsbox as is?

By the way, I double-check the WARNING exists on 1.4.4
(redis_version:3.2.6) vs  ERROR on 1.4.5 (redis_version:6.0.16)

old message, 1.4.4 (redis_version:3.2.6) :

2022-04-15 02:57:01 [24496] [6] DEBUG: DLR[redis]: DLR not destroyed,
still waiting for other delivery report
2022-04-15 02:57:01 [24496] [6] DEBUG: Updating DLR status in keystore
2022-04-15 02:57:01 [24496] [6] WARNING: DLR: REDIS: No dlr found to
update for dlr:?:?
2022-04-15 02:57:01 [24496] [6] DEBUG: new group created `smpp'
2022-04-15 02:57:01 [24496] [6] DEBUG: group=`smpp' key=`dlr_err' value='

new message, 1.4.5 (redis_version:6.0.16):

2022-04-07 16:05:40 [612] [6] ERROR: REDIS: redisCommand() failed: `ERR
unknown command `smsc_id`, with args beginning with: `1117930062`, `4`, '
2022-04-07 16:05:40 [612] [6] ERROR: DLR: REDIS: Error while updating
dlr entry for dlr:?:?

On 4/14/2022 20:55, lbrezs...@gmx.co.uk wrote:

I don't think it's the message.

bearer-box access-log looks ordinary

2022-04-14 18:49:56 send-SMS request added - sender:smsuser:XX999
192.168.27.35 target:1XXX9562019 request: 'Test DLR 4'

Hower, there is an important piece of information I forgot to mention.

Machine that handles DLR 4s correctly:

Kannel bearerbox version 1.4.4.
Compiler 6.2.1 20161124.
System Linux, release 4.9.0-13-amd64
debian 10 = SMP Debian 4.9.228-1 (2020-07-05), machine x86_64
hiredis API 0.13.3
redis_version:3.2.6

Machine that handles DLR 4s incorrectly:

Kannel bearerbox version 1.4.5.
Compiler 10.1.0.
System Linux, release 5.10.0-13-amd64,
debian 11 = SMP Debian 5.10.106-1 (2022-03-17), machine x86_64
Using hiredis API 0.14.1
redis_version:6.0.16

On 4/14/2022 18:38, Sayed Hadi Rastgou Haghi wrote:

REDIS: redisCommand()

Re: REDIS: redisCommand() failed: ERR unknown command

[lbrezs...@gmx.co.uk]

I don't think it's the message.

bearer-box access-log looks ordinary

2022-04-14 18:49:56 send-SMS request added - sender:smsuser:XX999
192.168.27.35 target:1XXX9562019 request: 'Test DLR 4'

Hower, there is an important piece of information I forgot to mention.

Machine that handles DLR 4s correctly:

Kannel bearerbox version 1.4.4.
Compiler 6.2.1 20161124.
System Linux, release 4.9.0-13-amd64
debian 10 = SMP Debian 4.9.228-1 (2020-07-05), machine x86_64
hiredis API 0.13.3
redis_version:3.2.6

Machine that handles DLR 4s incorrectly:

Kannel bearerbox version 1.4.5.
Compiler 10.1.0.
System Linux, release 5.10.0-13-amd64,
debian 11 = SMP Debian 5.10.106-1 (2022-03-17), machine x86_64
Using hiredis API 0.14.1
redis_version:6.0.16

On 4/14/2022 18:38, Sayed Hadi Rastgou Haghi wrote:

REDIS: redisCommand()

REDIS: redisCommand() failed: ERR unknown command

[lbrezs...@gmx.co.uk]

Using Redis for dlr-storage.

dlr-mask=31, which means everything.

Lately getting redis errors when receiving DLR 4

Anybody came across the same issue?

Logs:

2022-04-14 19:03:08 [2603] [6] DEBUG: DLR[redis]: DLR not destroyed,
still waiting for other delivery report
2022-04-14 19:03:08 [2603] [6] DEBUG: Updating DLR status in keystore
2022-04-14 19:03:08 [2603] [6] ERROR: REDIS: redisCommand() failed: `ERR
unknown command `*smsc_id*`, with args beginning with: `27807`, `4`, '
2022-04-14 19:03:08 [2603] [6] ERROR: DLR: REDIS: Error while updating
dlr entry for dlr:?:?
2022-04-14 19:03:08 [2603] [6] DEBUG: new group created `orig_msg'
2022-04-14 19:03:08 [2603] [6] DEBUG: group=`orig_msg' key=`dlr_mask'
value=`31'
2022-04-14 19:03:08 [2603] [6] DEBUG: new group created `orig_msg'
2022-04-14 19:03:08 [2603] [6] DEBUG: group=`orig_msg' key=`dlr_mask'
value=`31'
2022-04-14 19:03:08 [2603] [6] DEBUG: new group created `smpp'
2022-04-14 19:03:08 [2603] [6] DEBUG: group=`smpp' key=`dlr_err' value=`'
2022-04-14 19:03:08 [2603] [6] DEBUG: SMPP[smsc_id]: Sending PDU:
2022-04-14 19:03:08 [2603] [6] DEBUG: SMPP PDU 0x7faa36eee9f0 dump:
2022-04-14 19:03:08 [2603] [6] DEBUG:   type_name: deliver_sm_resp
2022-04-14 19:03:08 [2603] [6] DEBUG:   command_id: 2147483653 = 0x8005
2022-04-14 19:03:08 [2603] [6] DEBUG:   command_status: 0 = 0x
2022-04-14 19:03:08 [2603] [6] DEBUG:   sequence_number: 25058 = 0x61e2
2022-04-14 19:03:08 [2603] [6] DEBUG:   message_id: NULL
2022-04-14 19:03:08 [2603] [6] DEBUG: SMPP PDU dump ends.


On 3/31/2022 03:23, akamat sarat wrote:

Dear All,
Thank you for your replies.

We are using kannel 1.4.5 with the following setup: sqlbox ->
bearerbox -> smsc and  connected in  transceiver mode to SMSC.
we are inserting into mysql send_sms table for sending.
We are working with several SMSC and they where able to provide us
with logs clearly showing that they have submitted a DLR to our kannel
server and have received ACK from our kannel server.
In the example below the final Deliver_sm WE DO NOT see in any of the
logs (access or SMSC) once or ever and the DLR is stuck in dlr table
with where ts = 150903932114
There aren't any errors in sql box logs (we are using mysql).
We do not see any errors in SMSC logs except: "Could not parse DLR
string sscanf way, fallback to old way. Please report!"
I will reiterate that missing DLRs are happening intermittently about
25% of them are stuck in dlr table, and even with the error above 75%
of them still come in normally.
Also in the BB logs we have a lot of the following:
"
sms_router: handling message
Routing failed, re-queued
"
Not sure if it is all connected or not ...
Any help would be much appreciated!

here is an example: ( sensitive parts were redacted)
Our Submit_sm as logged on our server:
022-03-30 07:11:59 [9] [11] DEBUG:   type_name: submit_sm
2022-03-30 07:11:59 [9] [11] DEBUG:   command_id: 4 = 0x0004
2022-03-30 07:11:59 [9] [11] DEBUG: command_status: 0 = 0x
2022-03-30 07:11:59 [9] [11] DEBUG: sequence_number: 8513 = 0x2141
2022-03-30 07:11:59 [9] [11] DEBUG:   service_type: ""
2022-03-30 07:11:59 [9] [11] DEBUG: source_addr_ton: 5 = 0x0005
2022-03-30 07:11:59 [9] [11] DEBUG: source_addr_npi: 0 = 0x
2022-03-30 07:11:59 [9] [11] DEBUG:   source_addr: "srcaddr"
2022-03-30 07:11:59 [9] [11] DEBUG:   dest_addr_ton: 0 = 0x
2022-03-30 07:11:59 [9] [11] DEBUG:   dest_addr_npi: 0 = 0x
2022-03-30 07:11:59 [9] [11] DEBUG: destination_addr: "***"
2022-03-30 07:11:59 [9] [11] DEBUG:   esm_class: 3 = 0x0003
2022-03-30 07:11:59 [9] [11] DEBUG:   protocol_id: 0 = 0x
2022-03-30 07:11:59 [9] [11] DEBUG:   priority_flag: 0 = 0x
2022-03-30 07:11:59 [9] [11] DEBUG: schedule_delivery_time: NULL
2022-03-30 07:11:59 [9] [11] DEBUG: validity_period: NULL
2022-03-30 07:11:59 [9] [11] DEBUG: registered_delivery: 1 = 0x0001
2022-03-30 07:11:59 [9] [11] DEBUG: replace_if_present_flag: 0 =
0x
2022-03-30 07:11:59 [9] [11] DEBUG:   data_coding: 0 = 0x
2022-03-30 07:11:59 [9] [11] DEBUG: sm_default_msg_id: 0 = 0x
2022-03-30 07:11:59 [9] [11] DEBUG:   sm_length: 48 = 0x0030
2022-03-30 07:11:59 [9] [11] DEBUG:   short_message:
2022-03-30 07:11:59 [9] [11] DEBUG:    Octet string at 0x7ffb08002320:
2022-03-30 07:11:59 [9] [11] DEBUG:      len:  48
2022-03-30 07:11:59 [9] [11] DEBUG:      size: 50
2022-03-30 07:11:59 [9] [11] DEBUG:      immutable: 0
2022-03-30 07:11:59 [9] [11] DEBUG:      data: MY
2022-03-30 07:11:59 [9] [11] DEBUG:      data: SHORT
2022-03-30 07:11:59 [9] [11] DEBUG:      data: MESSAGE
2022-03-30 07:11:59 [9] [11] DEBUG:    Octet string dump ends.
2022-03-30 07:11:59 [9] [11] DEBUG: SMPP PDU dump ends.

TLV does not respect UC2 flag

[lbrezs...@gmx.co.uk]

**
=2=utf8=Unicode+Greek+Όλα Καλά

    2020-05-25 20:37:03 [24722] [6] DEBUG:   short_message:
    2020-05-25 20:37:03 [24722] [6] DEBUG:    Octet string at
0x7fe9e8006c80:
    2020-05-25 20:37:03 [24722] [6] DEBUG:  len:  44
    2020-05-25 20:37:03 [24722] [6] DEBUG:  size: 45
    2020-05-25 20:37:03 [24722] [6] DEBUG:  immutable: 0
    2020-05-25 20:37:03 [24722] [6] DEBUG:  data: 00 55 00 6e 00 69
00 63 00 6f 00 64 00 65 00 20   .U.n.i.c.o.d.e.
    2020-05-25 20:37:03 [24722] [6] DEBUG:  data: 00 47 00 72 00 65
00 65 00 6b 00 20 03 8c 03 bb   .G.r.e.e.k. 
    2020-05-25 20:37:03 [24722] [6] DEBUG:  data: 03 b1 00 20 03 9a
03 b1 03 bb 03 ac   ... 
    2020-05-25 20:37:03 [24722] [6] DEBUG:    Octet string dump ends.
    2020-05-25 20:37:03 [24722] [6] DEBUG: SMPP PDU dump ends.

When submitting unicode message in TLV 0x424 field and coding=2 and
char-set=utf-8, message is not converted to ucs2 and delivered as Chinese.


=2=utf8==%3Fsmpp%3Fmessage-payload%3D%=Unicode+Greek+Όλα
Καλά

[6] DEBUG:    Octet string at 0x7fe9e8006e10:
2020-05-25 21:05:11 [24722] [6] DEBUG:  len:  29
2020-05-25 21:05:11 [24722] [6] DEBUG:  size: 30
2020-05-25 21:05:11 [24722] [6] DEBUG:  immutable: 0
2020-05-25 21:05:11 [24722] [6] DEBUG:  data: 55 6e 69 63 6f 64 65
20 47 72 65 65 6b 20 ce 8c   Unicode Greek ..
2020-05-25 21:05:11 [24722] [6] DEBUG:  data: ce bb ce b1 20 ce 9a
ce b1 ce bb ce ac     
2020-05-25 21:05:11 [24722] [6] DEBUG:    Octet string dump ends.
2020-05-25 21:05:11 [24722] [6] DEBUG: SMPP PDU dump ends.

is it a bug or we have encode meta-data differently somehow?

Re: DLR but could not find message or was not interested Issue

[lbrezs...@gmx.co.uk]

Are the messages in questions are "oversized"? We are experiencing the
same issue, and had determined that the issue is connected to the
message length and how kannel is handling multipart messages.

When sending a concatenated MT, kannel keeps normally a reference for
the first part only and ignores the other parts. If provider sends you
dlrs for parts other then 1st, kannel cannot mach.

Regards,

Lelik.

On 2020-05-11 23:30, Wan Md Arif Noor Bin. Wan Nizam wrote:


Hi,

Thanks for the reply, tried it and same issue. Just to note that the
issue is pretty random but happening regularly.

Logs :

2020-05-12 11:16:34 [SMSC:6SeriesSHT] [from:62033] [to:601]
[msg:154:RM0 <#> Kod WhatsApp Anda: 664-190..Anda boleh ketik pautan
ini untuk mengesahkan nombor anda: v.whatsapp.com/..Jangan kongsikan
kod ini.4sgLq1p5sV6] [FID:1A7A1C61]

2020-05-12 11:22:57 [SMSC:6SeriesSHT] [from:+601] [to:62033]
[msg:122:id:0444210273 sub:000 dlvrd:000 submit date:2005121116 done
date:2005121122 stat:DELIVRD err:000 text:RM0 <#> Kod WhatsApp]
[FID:1A7A1C61]

2020-05-12 11:22:57 [85037] [7] ERROR: SMPP[6SeriesSHT]: got DLR but
could not find message or was not interested in it id<444210273>
dst<601>, type<1>

Best Regards.

Arif Noor

*From:* Gorki Alfaro 
*Sent:* Tuesday, May 12, 2020 11:19 AM
*To:* Wan Md Arif Noor Bin. Wan Nizam 
*Cc:* kannel users@kannel.org 
*Subject:* Re: DLR but could not find message or was not interested Issue

Hello

Try to changing your msg-id-type = 0x01

Regards

Gorki

On Mon, May 11, 2020 at 9:12 PM Wan Md Arif Noor Bin. Wan Nizam
mailto:md.a...@forest-interactive.com>> wrote:

Hello Guys,

I’ve been struggling to find what is the issue with the DLR which
regularly getting error “DLR but could not find message or was not
interested”. From the debug logs it looks just fine but from the
access logs it becomes like those normal MO instead of DN.

38029:2020-05-12 05:07:42 [1640] [9] DEBUG: SMPP[6SeriesSHT]: Got PDU:

38030:2020-05-12 05:07:42 [1640] [9] DEBUG: SMPP PDU
0x7f087c014d70 dump:

38031:2020-05-12 05:07:42 [1640] [9] DEBUG:   type_name: deliver_sm

38032:2020-05-12 05:07:42 [1640] [9] DEBUG:   command_id: 5 =
0x0005

38033:2020-05-12 05:07:42 [1640] [9] DEBUG:   command_status: 0 =
0x

38034:2020-05-12 05:07:42 [1640] [9] DEBUG:   sequence_number:
253886944 = 0x0f2201e0

38035:2020-05-12 05:07:42 [1640] [9] DEBUG:   service_type: NULL

38036:2020-05-12 05:07:42 [1640] [9] DEBUG:   source_addr_ton: 1 =
0x0001

38037:2020-05-12 05:07:42 [1640] [9] DEBUG:   source_addr_npi: 1 =
0x0001

38038:2020-05-12 05:07:42 [1640] [9] DEBUG:   source_addr:
"601"

38039:2020-05-12 05:07:42 [1640] [9] DEBUG:   dest_addr_ton: 0 =
0x

38040:2020-05-12 05:07:42 [1640] [9] DEBUG:   dest_addr_npi: 1 =
0x0001

38041:2020-05-12 05:07:42 [1640] [9] DEBUG:   destination_addr:
"63660"

38042:2020-05-12 05:07:42 [1640] [9] DEBUG:   esm_class: 4 =
0x0004

38043:2020-05-12 05:07:42 [1640] [9] DEBUG:   protocol_id: 0 =
0x

38044:2020-05-12 05:07:42 [1640] [9] DEBUG:   priority_flag: 0 =
0x

38045:2020-05-12 05:07:42 [1640] [9] DEBUG:
schedule_delivery_time: NULL

38046:2020-05-12 05:07:42 [1640] [9] DEBUG:   validity_period: NULL

38047:2020-05-12 05:07:42 [1640] [9] DEBUG: registered_delivery: 0
= 0x

38048:2020-05-12 05:07:42 [1640] [9] DEBUG:
replace_if_present_flag: 0 = 0x

38049:2020-05-12 05:07:42 [1640] [9] DEBUG:   data_coding: 0 =
0x

38050:2020-05-12 05:07:42 [1640] [9] DEBUG:   sm_default_msg_id: 0
= 0x

38051:2020-05-12 05:07:42 [1640] [9] DEBUG:   sm_length: 122 =
0x007a

38052:2020-05-12 05:07:42 [1640] [9] DEBUG:   short_message:

38053:2020-05-12 05:07:42 [1640] [9] DEBUG:    Octet string at
0x7f087c014330:

38054:2020-05-12 05:07:42 [1640] [9] DEBUG:  len:  122

38055:2020-05-12 05:07:42 [1640] [9] DEBUG:  size: 123

38056:2020-05-12 05:07:42 [1640] [9] DEBUG:  immutable: 0

38057:2020-05-12 05:07:42 [1640] [9] DEBUG:  data: 69 64 3a 30
34 31 36 32 39 33 38 30 38 20 73 75 id:0416293808 su

38058:2020-05-12 05:07:42 [1640] [9] DEBUG:  data: 62 3a 30 30
30 20 64 6c 76 72 64 3a 30 30 30 20   b:000 dlvrd:000

38059:2020-05-12 05:07:42 [1640] [9] DEBUG:  data: 73 75 62 6d
69 74 20 64 61 74 65 3a 32 30 30 35   submit date:2005

38060:2020-05-12 05:07:42 [1640] [9] DEBUG:  data: 31 32 30 35
30 37 20 64 6f 6e 65 20 64 61 74 65   120507 done date

38061:2020-05-12 05:07:42 [1640] [9] DEBUG:  data: 3a 32 30 30
35 31 32 30 35 30 37 20 73 74 61 74 :2005120507 stat

38062:2020-05-12 05:07:42 [1640] [9] DEBUG:  data: 3a 55 4e 44
45 4c 49 56 20 65 72 72 3a 32 34 35 :UNDELIV err:245

38063:2020-05-12 05:07:42 

got DLR but could not find message, bug?

[lbrezs...@gmx.co.uk]

Kannel 1.4.5 + redis is used to send sms via SMSC using smpp protocol.

When processing dlrs, once in a while we receive an ERROR similar to the
following:

ERROR: SMPP[X]: got DLR but could not find message or was not
interested in it id<143914440> dst

If sms body is long, it becomes a real problem as almost every 2nd
receipt can not be matched to the original submission.

So let me explain what I believe is a serious bug:

Kannel submits a request to send an sms to SMSC: smpp submit_sm

2020-03-31 22:53:43 [10846] [6] DEBUG:   type_name: submit_sm
2020-03-31 22:53:43 [10846] [6] DEBUG:   command_id: 4 = 0x0004
2020-03-31 22:53:43 [10846] [6] DEBUG:   sequence_number: 3305 = 0x0ce9
2020-03-31 22:53:43 [10846] [6] DEBUG:   destination_addr: "XXX0842"
2020-03-31 22:53:43 [10846] [6] DEBUG:   sm_length: 159 = 0x009f
2020-03-31 22:53:43 [10846] [6] DEBUG:   more_messages_to_send: 1 =
0x0001
...
2020-03-31 22:53:43 [10846] [6] DEBUG:   type_name: submit_sm
2020-03-31 22:53:43 [10846] [6] DEBUG:   command_id: 4 = 0x0004
2020-03-31 22:53:43 [10846] [6] DEBUG:   sequence_number: 3306 = 0x0cea
2020-03-31 22:53:43 [10846] [6] DEBUG:   destination_addr: "XXX0842"
2020-03-31 22:53:43 [10846] [6] DEBUG:   sm_length: 48 = 0x0030

It gets gets an ACK from the SMSC: smpp  submit_sm_resp

2020-03-31 22:53:43 [10846] [6] DEBUG:   type_name: submit_sm_resp
2020-03-31 22:53:43 [10846] [6] DEBUG:   command_id: 2147483652 = 0x8004
2020-03-31 22:53:43 [10846] [6] DEBUG:   sequence_number: 3305 = 0x0ce9

2020-03-31 22:53:43 [10846] [6] DEBUG:   message_id: "0893F5C7"

writes it to redis

2020-03-31 22:53:43 [10846] [6] DEBUG: DLR[redis]: Adding DLR
smsc=smsc_123, ts=143914439, src=XXX8356, dst=XXX0842, mask=31,
boxc=

It converts it to fake DLR8 and posts (actually http get) to our API. So
far so good, sms is going to the recipient and we have ACK (fake DLR8 as
a proof).

2020-03-31 22:53:43 [10846] [6] DEBUG:   type_name: submit_sm_resp
2020-03-31 22:53:43 [10846] [6] DEBUG:   command_id: 2147483652 = 0x8004
2020-03-31 22:53:43 [10846] [6] DEBUG:   sequence_number: 3306 = 0x0cea
2020-03-31 22:53:43 [10846] [6] DEBUG:   message_id: "0893F5C8"
2020-03-31 22:53:43 [10846] [6] DEBUG: SMSC[smsc_123]: creating DLR message

2020-03-31 22:53:43 [10846] [6] DEBUG: SMSC[smsc_123]: DLR = http://

Note message_id is +1 to what redis has ( we will need it later).

Now, sms is delivered and our provider sends us a delivery receipt.

2020-03-31 22:53:43 [10846] [6] DEBUG:   type_name: deliver_sm
2020-03-31 22:53:43 [10846] [6] DEBUG:   command_id: 5 = 0x0005
2020-03-31 22:53:43 [10846] [6] DEBUG:   sequence_number: 1650 = 0x0672
2020-03-31 22:53:43 [10846] [6] DEBUG:   source_addr: "XXX0842"
2020-03-31 22:53:43 [10846] [6] DEBUG:   sm_length: 102 = 0x0066

Kannel goes to redis but could not find the key needed:

2020-03-31 22:53:43 [10846] [6] DEBUG: DLR[redis]: Looking for DLR
smsc=smsc_123, ts=143914440, dst=XXX0842, type=2
2020-03-31 22:53:43 [10846] [6] WARNING: DLR[redis]: DLR from
SMSC for DST not found.
2020-03-31 22:53:43 [10846] [6] ERROR: SMPP[smsc_123]: got DLR but could
not find message or was not interested in it id<143914440>
dst, type<2>

Manually examining the redis confirms that there is no key:

Message_id converted from hex to int: 0893F5C8 => 143914440

redis-cli keys  "dlr:smsc_123:143914440"
(empty list or set)

Now to revisit on what was written to redis:

2020-03-31 22:53:43 [10846] [6] DEBUG: DLR[redis]: Adding DLR
smsc=smsc_123, ts=143914439, src=XXX8356, dst=XXX0842, mask=31,
boxc=

and compare to what is expected:

2020-03-31 22:53:43 [10846] [6] DEBUG: DLR[redis]: Looking for DLR
smsc=smsc_123, ts=143914440, dst=XXX0842, type=2

Now we getting somewhere:

0893F5C7 (part 1) => 143914439 is written to redis
0893F5C8 (part 2) => 143914440 is used to create DLR8
0893F5C8 (part 2) => 143914440 is used on receiving deliver_sm to
look-up in redis.
But in fact we should be looking for 0893F5C7 (part 1) => 143914439? no?

Correct:
redis-cli keys "dlr:smsc_123:143914439"

1) "dlr:smsc_123:143914439"

As you see kannel writes to redis ts = message_id from part 1, but on
receiving a dlr it is looking for ts = message_id from part 2, could not
find it, and as a result dlr is lost.

The puzzling part, as bug is not consistent. As I mentioned before, some
of the message(s) are Ok (???).

Not sure what trips kannel to look for a wrong message_id though.
Sometimes it matches message_id from part2 to part2, and everything is good.