Re: DLRs - decoding PDU problem
I've solved the problem myself. In at2_pdu_decode function those DLRs have type 1 (AT_SUBMIT_SM) instead of 2 (AT_STATUS_REPORT_SM). Probably operator make some modifications in DLR PDUs he sends. After adding support for AT_SUBMIT_SM type there all DLRs are processed correctly again. Tomasz W Twoim liście datowanym 30 sierpnia 2012 (12:36:59) można przeczytać: Hello, I'm using Kannel since few years as a core for gateway based on GSM modems (AT). Since few days I've got a problem with DLRs. I'm receiving only DLRs for some messages (before DLRs for all SMS were delivered correctly). No configuration changes were made from that time on my side. I've looked into logs and have seen that when receiving DLRs sometimes all is ok and sometimes there is could not decode PDU to a message message. 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: -- +CDSI: SM,0 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: +CMTI incoming SMS indication: +CDSI: SM,0 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: -- ^MODE:3,3 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- AT+CMGR=0^M 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- +CMGR: 0,,25 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- 07918405210077F79EC00B918405566182F6218082900332802180829003828000 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: received message from SMSC: +48501200777 2012-08-28 09:22:02 [3626] [42] ERROR: AT2[modem_032]: could not decode PDU to a message. 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- OK ...but some DLRs are processed correctly: 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: -- +CDSI: SM,0 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: +CMTI incoming SMS indication: +CDSI: SM,0 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: -- ^MODE:3,3 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: -- AT+CMGR=0^M 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: -- +CMGR: 0,,25 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: -- 07918405210077F706B90B918405693009F2218082807541802180828075918000 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: received message from SMSC: +48501200777 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: got STATUS-REPORT for message 185: 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: Numeric receiver (international) +48509603XXX I've decoded both PDUs using a tool from http://www.diafaan.com/sms-tutorials/gsm-modem-tutorial/online-sms-pdu-decoder/ and both could be decoded properly (as SMS-STATUS-REPORT). The one difference between those PDUs is that 07918405210077F706B90B918405693009F2218082807541802180828075918000 has PDU header: 06 and 07918405210077F79EC00B918405566182F6218082900332802180829003828000 has PDU header: 9E. I've made more tests and have seen that all DLRs with PDU header: 06 are decoded by kannel and processed correctly, but when PDU header: 9E than DLR isn't decoded properly and in logs there is could not decode PDU to a message message. Probably my GSM operator made some modifications and it delivers DLRs with 9E and 06 headers. I've looked into kannel source code but I can't find a place where to make modifications to have kannel decode PDU with 9E header correctly. Could you help me? Tomasz -- Pozdrowienia, Tomasz
Re: DLRs - decoding PDU problem
Hi, I'll offer 50 EUR for the first person who will help me modify kannel sources to solve the described problem with DLRs. Tomasz W Twoim liście datowanym 30 sierpnia 2012 (12:36:59) można przeczytać: Hello, I'm using Kannel since few years as a core for gateway based on GSM modems (AT). Since few days I've got a problem with DLRs. I'm receiving only DLRs for some messages (before DLRs for all SMS were delivered correctly). No configuration changes were made from that time on my side. I've looked into logs and have seen that when receiving DLRs sometimes all is ok and sometimes there is could not decode PDU to a message message. 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: -- +CDSI: SM,0 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: +CMTI incoming SMS indication: +CDSI: SM,0 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: -- ^MODE:3,3 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- AT+CMGR=0^M 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- +CMGR: 0,,25 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- 07918405210077F79EC00B918405566182F6218082900332802180829003828000 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: received message from SMSC: +48501200777 2012-08-28 09:22:02 [3626] [42] ERROR: AT2[modem_032]: could not decode PDU to a message. 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- OK ...but some DLRs are processed correctly: 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: -- +CDSI: SM,0 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: +CMTI incoming SMS indication: +CDSI: SM,0 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: -- ^MODE:3,3 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: -- AT+CMGR=0^M 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: -- +CMGR: 0,,25 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: -- 07918405210077F706B90B918405693009F2218082807541802180828075918000 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: received message from SMSC: +48501200777 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: got STATUS-REPORT for message 185: 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: Numeric receiver (international) +48509603XXX I've decoded both PDUs using a tool from http://www.diafaan.com/sms-tutorials/gsm-modem-tutorial/online-sms-pdu-decoder/ and both could be decoded properly (as SMS-STATUS-REPORT). The one difference between those PDUs is that 07918405210077F706B90B918405693009F2218082807541802180828075918000 has PDU header: 06 and 07918405210077F79EC00B918405566182F6218082900332802180829003828000 has PDU header: 9E. I've made more tests and have seen that all DLRs with PDU header: 06 are decoded by kannel and processed correctly, but when PDU header: 9E than DLR isn't decoded properly and in logs there is could not decode PDU to a message message. Probably my GSM operator made some modifications and it delivers DLRs with 9E and 06 headers. I've looked into kannel source code but I can't find a place where to make modifications to have kannel decode PDU with 9E header correctly. Could you help me? Tomasz -- Pozdrowienia, Tomasz Konopka
DLRs - decoding PDU problem
Hello, I'm using Kannel since few years as a core for gateway based on GSM modems (AT). Since few days I've got a problem with DLRs. I'm receiving only DLRs for some messages (before DLRs for all SMS were delivered correctly). No configuration changes were made from that time on my side. I've looked into logs and have seen that when receiving DLRs sometimes all is ok and sometimes there is could not decode PDU to a message message. 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: -- +CDSI: SM,0 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: +CMTI incoming SMS indication: +CDSI: SM,0 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: -- ^MODE:3,3 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- AT+CMGR=0^M 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- +CMGR: 0,,25 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- 07918405210077F79EC00B918405566182F6218082900332802180829003828000 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: received message from SMSC: +48501200777 2012-08-28 09:22:02 [3626] [42] ERROR: AT2[modem_032]: could not decode PDU to a message. 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- OK ...but some DLRs are processed correctly: 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: -- +CDSI: SM,0 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: +CMTI incoming SMS indication: +CDSI: SM,0 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: -- ^MODE:3,3 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: -- AT+CMGR=0^M 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: -- +CMGR: 0,,25 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: -- 07918405210077F706B90B918405693009F2218082807541802180828075918000 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: received message from SMSC: +48501200777 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: got STATUS-REPORT for message 185: 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: Numeric receiver (international) +48509603XXX I've decoded both PDUs using a tool from http://www.diafaan.com/sms-tutorials/gsm-modem-tutorial/online-sms-pdu-decoder/ and both could be decoded properly (as SMS-STATUS-REPORT). The one difference between those PDUs is that 07918405210077F706B90B918405693009F2218082807541802180828075918000 has PDU header: 06 and 07918405210077F79EC00B918405566182F6218082900332802180829003828000 has PDU header: 9E. I've made more tests and have seen that all DLRs with PDU header: 06 are decoded by kannel and processed correctly, but when PDU header: 9E than DLR isn't decoded properly and in logs there is could not decode PDU to a message message. Probably my GSM operator made some modifications and it delivers DLRs with 9E and 06 headers. I've looked into kannel source code but I can't find a place where to make modifications to have kannel decode PDU with 9E header correctly. Could you help me? Tomasz
Re: HTTP Generic relay and prevent splitting long messages
That is I was looking for :) I don't know how couldn't I see this option. Thx Nii Tomasz Take a look at the max-sms-octets setting under config group smsc. Nii On May 30, 2011, at 9:03 PM, Tomasz wrote: I've tried it but the only difference is that kannel doesn't add UDH parameter. Message is still splitted into parts. Tomasz Try concatenation = false in group = sendsms-user. == Rene -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Tomasz Sent: Monday, 30 May, 2011 22:38 To: users@kannel.org Subject: HTTP Generic relay and prevent splitting long messages Hello group, The company I'm working in need access to specific SMSC which doesn't provide SMPP access. I'm forced to use their HTTP API and connect to it using Kannel HTTP-based relay (generic system-type). Everything works fine if message is up to 160 chars. Above Kannel splits messages as normally, adds UDH for each part and sends it independently to SMSC. But the SMSC doesn't support UDH, and it want to get one long message (in one string) - splitting and concatenating is done at their side. If kannel splits message, the recipient receives several messages which are not concatenated on his mobile but they are independent ones. Is it possible to configure Kannel to not splitting messages when using http based relay (generic) but to send them at one part to SMSC? BR, Tomasz
HTTP Generic relay and prevent splitting long messages
Hello group, The company I'm working in need access to specific SMSC which doesn't provide SMPP access. I'm forced to use their HTTP API and connect to it using Kannel HTTP-based relay (generic system-type). Everything works fine if message is up to 160 chars. Above Kannel splits messages as normally, adds UDH for each part and sends it independently to SMSC. But the SMSC doesn't support UDH, and it want to get one long message (in one string) - splitting and concatenating is done at their side. If kannel splits message, the recipient receives several messages which are not concatenated on his mobile but they are independent ones. Is it possible to configure Kannel to not splitting messages when using http based relay (generic) but to send them at one part to SMSC? BR, Tomasz
Re: HTTP Generic relay and prevent splitting long messages
I've tried it but the only difference is that kannel doesn't add UDH parameter. Message is still splitted into parts. Tomasz Try concatenation = false in group = sendsms-user. == Rene -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Tomasz Sent: Monday, 30 May, 2011 22:38 To: users@kannel.org Subject: HTTP Generic relay and prevent splitting long messages Hello group, The company I'm working in need access to specific SMSC which doesn't provide SMPP access. I'm forced to use their HTTP API and connect to it using Kannel HTTP-based relay (generic system-type). Everything works fine if message is up to 160 chars. Above Kannel splits messages as normally, adds UDH for each part and sends it independently to SMSC. But the SMSC doesn't support UDH, and it want to get one long message (in one string) - splitting and concatenating is done at their side. If kannel splits message, the recipient receives several messages which are not concatenated on his mobile but they are independent ones. Is it possible to configure Kannel to not splitting messages when using http based relay (generic) but to send them at one part to SMSC? BR, Tomasz
Re: how i read messages from SIM card, and how i store the message
Hi, Try to add: message-start = 0 to your group = modems section BR, Tomasz W Twoim liście datowanym 20 września 2010 (14:56:44) można przeczytać: i have restart the machine, but nothing, the seam error...what is wrong? offtopic: and the sqlbox, when i starting sqlbox /etc/kannel/sqlbox.config segmentation fault whay:( Constantin Zaharia try restarting your machine 2010/9/20 Zaharia Constantin soulra...@muscel.ro How i setup the sqlbox? i have installed using apt-get, but now i don't know what i have to do... is necessary to start some application? and now i get another error, regarding the read of sms from sim 2010-09-14 23:51:37 [10621] [6] DEBUG: AT2[huawei_E160e]: -- OK 2010-09-14 23:51:37 [10621] [6] DEBUG: AT2[huawei_E160e]: not deleted. 2010-09-14 23:51:37 [10621] [6] DEBUG: AT2[huawei_E160e]: -- AT+CMGR=43^M 2010-09-14 23:51:37 [10621] [6] DEBUG: AT2[huawei_E160e]: -- AT+CMGR=43 2010-09-14 23:51:37 [10621] [6] DEBUG: AT2[huawei_E160e]: -- OK 2010-09-14 23:51:37 [10621] [6] DEBUG: AT2[huawei_E160e]: not deleted. 2010-09-14 23:51:37 [10621] [6] DEBUG: AT2[huawei_E160e]: -- AT+CMGR=44^M 2010-09-14 23:51:37 [10621] [6] DEBUG: AT2[huawei_E160e]: -- AT+CMGR=44 2010-09-14 23:51:37 [10621] [6] DEBUG: AT2[huawei_E160e]: -- OK 2010-09-14 23:51:37 [10621] [6] DEBUG: AT2[huawei_E160e]: not deleted. 2010-09-14 23:51:37 [10621] [6] DEBUG: AT2[huawei_E160e]: -- AT+CMGR=45^M 2010-09-14 23:51:37 [10621] [6] DEBUG: AT2[huawei_E160e]: -- AT+CMGR=45 2010-09-14 23:51:37 [10621] [6] DEBUG: AT2[huawei_E160e]: -- OK 2010-09-14 23:51:37 [10621] [6] DEBUG: AT2[huawei_E160e]: not deleted. 2010-09-14 23:51:37 [10621] [6] DEBUG: AT2[huawei_E160e]: -- AT+CMGR=46^M 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: -- AT+CMGR=46 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: -- OK 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: not deleted. 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: -- AT+CMGR=47^M 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: -- AT+CMGR=47 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: -- OK 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: not deleted. 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: -- AT+CMGR=48^M 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: -- AT+CMGR=48 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: -- OK 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: not deleted. 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: -- AT+CMGR=49^M 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: -- AT+CMGR=49 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: -- OK 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: not deleted. 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: -- AT+CMGR=50^M 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: -- AT+CMGR=50 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: -- +CMS ERROR: 321 2010-09-14 23:51:38 [10621] [6] ERROR: AT2[huawei_E160e]: CMS ERROR: +CMS ERROR: 321 2010-09-14 23:51:38 [10621] [6] ERROR: AT2[huawei_E160e]: CMS ERROR: Invalid memory index - don't worry, just memory fragmentation. (321) 2010-09-14 23:51:38 [10621] [6] DEBUG: AT2[huawei_E160e]: failed to get message 50. what is wrong ? Here is my answer to the exact same question from a few months ago: http://www.mail-archive.com/users@kannel.org/msg20081.html 2010/9/17 Zaharia Constantin soulra...@muscel.ro hy, how i read the message from SIM card and how i store the messages. I want to see when a new message has arrived and store in a database. please help me... best regards, Constantin Zaharia -- Best regards, Alex -- Best regards, Alex
Re: smppbox bulk sms: slow reception from a client
Hi, I've also had similar problem some time ago when I was sending some bulk of 5.000 msgs. There was sometimes Broken pipe error and several problems with some DLRs (PDU unpacking failed). I tried to reproduce this problem but I was not able to get those errors anymore, it was happening one time when there was a huge traffic. Tomasz. W Twoim liście datowanym 17 sierpnia 2010 (17:09:57) można przeczytać: Hi, I kept playing around with the configuration files but still no luck. Today I tried to send 20 sms to smppbox but my smppbox or kannel kept stalling again. My system receives some 6 sms from my client and than it stalls for 1 minute or so before it continues receiving the rest. Moreover, my client does not receive all the deliveries back. It gets some 12 out of 20. I checked my log files and I noticed several error and warning messages. In my smppbox.log I get the following error and warning messages periodically. DEBUG: SMPP[ESME]: Sending PDU: DEBUG: SMPP PDU 0x910c7b0 dump: DEBUG: type_name: bind_receiver_resp DEBUG: command_id: 2147483649 = 0x8001 DEBUG: command_status: 0 = 0x DEBUG: sequence_number: 1 = 0x0001 DEBUG: system_id: VMA DEBUG: SMPP PDU dump ends. WARNING: SMPP: PDU NULL terminated string (service_type) has no NULL. DEBUG: Octet string at 0x910ae28: DEBUG: len: 12 DEBUG: size: 13 DEBUG: immutable: 0 DEBUG: data: 00 00 00 05 00 00 00 00 00 00 00 02 DEBUG: Octet string dump ends. ERROR: smppbox[ESME]: PDU unpacking failed. DEBUG: smppbox[ESME]: Failed PDU omitted. ERROR: Invalid SMPP PDU received. DEBUG: Thread 2 (smppbox.c:smpp_to_bearerbox) terminates. DEBUG: Started thread 3 (smppbox.c:function) ERROR: SMPP: Unknown TLV `dlr_err', don't send. INFO: We received an SMS message. DEBUG: DLR[internal]: Looking for DLR smsc=ESME, ts=a4517482, dst=+37494086408, type=1 WARNING: DLR[internal]: DLR from SMSCESME for DST+37494086408 not found. and in my kannel.log I get this message periodically DEBUG: boxc_sender: sent message to 127.0.0.1 DEBUG: send_msg: sending msg to boxc: ESME DEBUG: boxc_sender: sent message to 127.0.0.1 ERROR: Connection to box 127.0.0.1 broke. EBUG: send_msg: sending msg to boxc: ESME ERROR: Error writing 16 octets to fd 29: ERROR: System error 32: Broken pipe ERROR: Couldn't write Msg to box 127.0.0.1, disconnecting DEBUG: Thread 19 (gw/bb_boxc.c:boxc_sender) terminates. ERROR: Error writing 16 octets to fd 29: ERROR: System error 32: Broken pipe DEBUG: Thread 18 (gw/bb_boxc.c:function) terminates. DEBUG: send_msg: sending msg to boxc: ESME DEBUG: boxc_sender: sent message to 127.0.0.1 DEBUG: send_msg: sending msg to boxc: ESME DEBUG: boxc_sender: sent message to 127.0.0.1 INFO: Connection closed by the box 127.0.0.1 DEBUG: send_msg: sending msg to boxc: ESME DEBUG: Thread 17 (gw/bb_boxc.c:boxc_sender) terminates. WARNING: smsbox_list empty! Most of all the error about the Broken pipe alerts me, I don't know what that means but it seems to be serious. I don't know if that can be the reason. My current configuration is as follows: smskannel.conf ** group = core admin-port = 13000 smsbox-port = 13001 admin-password = bar log-file = /tmp/kannel.log log-level = 0 box-deny-ip = *.*.*.* box-allow-ip = 127.0.0.1 include = /home/davit/workspace/kannel/gateway-revision-4837/gw/smsbox.conf include = /home/davit/workspace/kannel/gateway-revision-4837/gw/smsc.conf ** smsc.conf * group=smsc smsc=smpp smsc-id=17 interface-version=34 host=*** port=* system-id=* smsc-password=** system-type=default transceiver-mode=1 ** * smsbox.conf *** group = smsbox bearerbox-host = 127.0.0.1 sendsms-port = 13013 log-level = 0 group = smsbox-route smsbox-id = VMA smsc-id = 17 *** smppbox.conf group = core group = smppbox # our boxc type smppbox-id = box1 # the port to listen on for smpp connections smppbox-port = 16000 # we connect to the following host as a box bearerbox-host = 127.0.0.1 bearerbox-port = 13001 log-level = 0 log-file = smppbox.log our-system-id = VMA route-to-smsc = 17 # see sample smpplogins.txt smpp-logins = /home/davit/workspace/kannel/smppbox-revision-41/gw/smpplogins.txt *** and my smpplogins.txt foo bar VMA 245.127.0.0.1 client-02 password-02 vma 127.0.0.1 I would really appreciate any help and ideas. I don't know how to tackle this problem ;) Cheers, Davit Date: Sat, 14 Aug 2010 21:14:04 +0200 Subject: Re: smppbox bulk sms: slow reception from a client From: rene.klu...@chimit.nl To: davit.mirzo...@hotmail.com CC: users@kannel.org Onlly 10 sms is nothing of course
Re: SMPPbox: client binding problem
I had the similar problem a week ago after updating smppbox to recent revision. I added: use-systemid-as-smsboxid = true to my group = smppbox and then I could bind succesfully. Tomasz W Twoim liście datowanym 12 sierpnia 2010 (15:59:37) można przeczytać: Here are my configuration files. smskannel.conf ** group = core admin-port = 13000 smsbox-port = 13001 admin-password = bar log-file = /tmp/kannel.log log-level = 0 box-deny-ip = *.*.*.* box-allow-ip = 127.0.0.1 include = /home/davit/workspace/kannel/gateway-revision-4837/gw/smsbox.conf include = /home/davit/workspace/kannel/gateway-revision-4837/gw/smsc.conf group = sendsms-user username = tester password = foobar ** smsc.conf * group=smsc smsc=smpp smsc-id=17 interface-version=34 host=*** port=* system-id=* smsc-password=** system-type=default transceiver-mode=1 ** * smsbox.conf *** group = smsbox bearerbox-host = 127.0.0.1 sendsms-port = 13013 log-level = 0 group = smsbox-route smsbox-id = VMA smsc-id = 17 *** smppbox.conf group = core group = smppbox # our boxc type smppbox-id = abcd # the port to listen on for smpp connections smppbox-port = 16000 # we connect to the following host as a box bearerbox-host = 127.0.0.1 bearerbox-port = 13001 log-level = 0 log-file = smppbox.log our-system-id = VMA route-to-smsc = 17 # see sample smpplogins.txt smpp-logins = /home/davit/workspace/kannel/smppbox-revision-41/gw/smpplogins.txt *** and my smpplogins.txt foo bar VMA client-02 password-02 vma 127.0.0.1 my bearerbox connects to the server fine. Davit From: rene.klu...@chimit.nl To: davit.mirzo...@hotmail.com CC: users@kannel.org Subject: RE: SMPPbox: client binding problem Date: Thu, 12 Aug 2010 15:20:54 +0200 Best send your question to the Kannel users list. You might get more response. Is the file readable by the user that you start Kannel with? What is your smppbox.conf? The syntax seems to be right. A document containing command id’s and statuses are the SMPP v3.4 specifications: http://www.smsforum.net/SMPP_v3_4_Issue1_2.zip == Rene From: Davit Mirzoyan [mailto:davit.mirzo...@hotmail.com] Sent: Thursday, 12 August, 2010 14:09 To: rene.klu...@chimit.nl Subject: RE: SMPPbox: client binding problem Hi Rene, Thanks for the feedback. I will check the path to the file again. Here is my file's content. foo bar vma client-02 password-02 vma 127.0.0.1 Is the syntax ok? My client uses the first line for binding to my smppbox. Is there a document or a link that explains these command IDs and statuses? Thanks once more Cheers, Davit From: rene.klu...@chimit.nl To: davit.mirzo...@hotmail.com; users@kannel.org Subject: RE: SMPPbox: client binding problem Date: Thu, 12 Aug 2010 13:21:05 +0200 Command status 0x0d means: Invalid login. Either the login file could not be found or it doesn’t have the correct syntax. == Rene From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Davit Mirzoyan Sent: Thursday, 12 August, 2010 13:03 To: users@kannel.org Subject: SMPPbox: client binding problem Dear all, Lately I was testing the smppbox with the gateway. I got the SMPPbox sources (revision 41), together with the latest gateway sources (revision 4837), from the svn repository. I managed to compile and install kannel and smppbox. Anyhow, I was running the smppbox with the bearerbox and strangely I couldn't manage to bind my client over SMPP to SMPPbox. Every time my client tries to bind to smppbox, it says that an invalid SMPP PDU is recieved (even though correct username and password are sent to my smppbox, as set up in smpp-logins.txt). I was wondering if there is anybody who managed to bind the whole thing and get it work or if anybody got a binding error like this. I would greatly appreciate your help, I am kind of stalled here. I can post my configuration files if needed. Here is my output 2010-08-12 12:47:48 [4738] [0] INFO: Waiting for SMPP connections on port 2346. 2010-08-12 12:54:17 [4738] [0] DEBUG: Started thread 1 (smppbox.c:function) 2010-08-12 12:54:17 [4738] [1] DEBUG: Thread 1 (smppbox.c:function) maps to pid 4738. 2010-08-12 12:54:17 [4738] [1] INFO: Client connected from 192.123.1.103 2010-08-12 12:54:17 [4738] [1] DEBUG: Connecting to 127.0.0.1 2010-08-12 12:54:17 [4738] [1] INFO: Connected to bearerbox at 127.0.0.1 port 13001. 2010-08-12 12:54:17 [4738] [1] DEBUG: Started thread 2 (smppbox.c:smpp_to_bearerbox) 2010-08-12 12:54:17 [4738] [2] DEBUG: Thread 2
Re: Problem with spool store - missing sms_type
Hi Rene,
Thanks for solving the problem. However I've found in the code few
lines earlier in *pdu_to_msg:
if (pdu-u.submit_sm.esm_class (0x04|0x08)) {
msg-sms.sms_type = report_mo;
}
and then there is:
msg-sms.sms_type = mt_push;
which will finally always rewrite a value of msg-sms.sms_type to mt_push.
Shouldn't this line be set before?
Tomasz
W Twoim liście datowanym 11 sierpnia 2010 (14:10:20) można przeczytać:
I submitted the MT_PUSH fix to svn trunk already.
You just need to svn update and you are all set.
== Rene
-Original Message-
From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of
Tomasz
Sent: Tuesday, 10 August, 2010 22:26
To: users@kannel.org
Subject: Re: Problem with spool store - missing sms_type
Hi Rene,
I added following line after 1485 line to smppbox.c (is case
submit_sm section):
msg-sms.sms_type = mt_push;
to check if this time msg_type will be filled and it seems to be.
Bearerbox now see MT_PUSH as Type in admin page.
But I don't know if submit_sm is used only to send MT messages so this
is not final clear solution I think.
Tomasz
W Twoim liście datowanym 10 sierpnia 2010 (21:49:05) można przeczytać:
Looking into the msg.c source code (function msg_pack()) it is not
even possible for smppbox to send a message with an invalid msg-type to
bearerbox.
I wonder what might be wrong.
== Rene
-Original Message-
From: Tomasz [mailto:ad...@impexrur.pl]
Sent: Tuesday, 10 August, 2010 20:22
To: Rene Kluwen
Subject: Re: Problem with spool store - missing sms_type
When I call http://domain.pl:13000/store-status I can see the table of
all queued messages (if any). And all those messages which were
submitted via openSMPPBOX have Type field empty there. However all
messages submitted by SMSBOX have this value filled correctly.
Tomasz
W Twoim liście datowanym 10 sierpnia 2010 (19:06:21) można przeczytać:
Where exactly in the http admin page do you see that msg_type is empty?
-Original Message-
From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf
Of Tomasz
Sent: Tuesday, 10 August, 2010 18:21
To: users@kannel.org
Subject: Re: Problem with spool store - missing sms_type
Hi,
I don't know for sure if this is openSMPPBOX issue or not but if
messages are submitted via openSMPPBOX the msg_type is empty and this
makes that Bearerbox crashes during restart when we have some messages
queued in the spool. When submitting messages by SMSBOX (CGI push),
the problem didn't exists - msg_type is set correctly.
I can check if msg_type exists or not using http admin store-status
command (when there are some queued messages). Messages submitted via
openSMPPBOX have empty fields in Type column.
Rene, I can provide more details with the issue, but I can't see
in logs any revelant information - only PANICs during start of
Bearerbox. Only at http admin page I can see that msg_type is empty.
But if you need please let me know what information would be helpful.
Tomasz
W Twoim liście datowanym 10 sierpnia 2010 (17:01:52) można przeczytać:
In the smppbox code, I don’t see anywhere where a msg is created without
msg_type.
We use the msg_create() function and dlr_find functions to create messages.
If this is an smppbox issue, I would like to get more information about it.
== Rene
From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com]
Sent: Monday, 09 August, 2010 23:27
To: Rene Kluwen
Cc: Nikos Balkanas; users@kannel.org
Subject: Re: Problem with spool store - missing sms_type
Exactly.
The point is: during normal operation, kannel of course it doesn't
panic and will accept messages without a valid sms type. However,
they're kept on the store with an invalid format, so if you shutdown
the service with messages pending on the store, and just one of them
happens to have an invalid sms type, the service panics at startup.
This is less than desirable of course, specially when you have a ton
of completely valid messages and just a bunch of invalid.
IMHO, kannel should reject messages with invalid sms type during
regular operation (with a WARN logged). It _shouldn't_ try to fix
them. That would take care of the problem in a proper way.
Apart from that, a way to discard invalid messages at bootup
without panicking would also be desirable
Regards,
Alex
On Mon, Aug 9, 2010 at 11:11 PM, Rene Kluwen rene.klu...@chimit.nl wrote:
Yes, open smppbox should correctly fill in the correct type. If it doesn't
it is an error.
But at the same time: If one particular message has an incorrent
sms_type. Why panic? It can just discard the message and go on with normal
operation.
== Rene
-Original Message-
From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf
Of Nikos Balkanas
Sent: Monday, 09 August, 2010 22:34
To: Alejandro Guerrieri
Cc: users
Re: Problem with spool store - missing sms_type
Hi Rene, I added following line after 1485 line to smppbox.c (is case submit_sm section): msg-sms.sms_type = mt_push; to check if this time msg_type will be filled and it seems to be. Bearerbox now see MT_PUSH as Type in admin page. But I don't know if submit_sm is used only to send MT messages so this is not final clear solution I think. Tomasz W Twoim liście datowanym 10 sierpnia 2010 (21:49:05) można przeczytać: Looking into the msg.c source code (function msg_pack()) it is not even possible for smppbox to send a message with an invalid msg-type to bearerbox. I wonder what might be wrong. == Rene -Original Message- From: Tomasz [mailto:ad...@impexrur.pl] Sent: Tuesday, 10 August, 2010 20:22 To: Rene Kluwen Subject: Re: Problem with spool store - missing sms_type When I call http://domain.pl:13000/store-status I can see the table of all queued messages (if any). And all those messages which were submitted via openSMPPBOX have Type field empty there. However all messages submitted by SMSBOX have this value filled correctly. Tomasz W Twoim liście datowanym 10 sierpnia 2010 (19:06:21) można przeczytać: Where exactly in the http admin page do you see that msg_type is empty? -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Tomasz Sent: Tuesday, 10 August, 2010 18:21 To: users@kannel.org Subject: Re: Problem with spool store - missing sms_type Hi, I don't know for sure if this is openSMPPBOX issue or not but if messages are submitted via openSMPPBOX the msg_type is empty and this makes that Bearerbox crashes during restart when we have some messages queued in the spool. When submitting messages by SMSBOX (CGI push), the problem didn't exists - msg_type is set correctly. I can check if msg_type exists or not using http admin store-status command (when there are some queued messages). Messages submitted via openSMPPBOX have empty fields in Type column. Rene, I can provide more details with the issue, but I can't see in logs any revelant information - only PANICs during start of Bearerbox. Only at http admin page I can see that msg_type is empty. But if you need please let me know what information would be helpful. Tomasz W Twoim liście datowanym 10 sierpnia 2010 (17:01:52) można przeczytać: In the smppbox code, I don’t see anywhere where a msg is created without msg_type. We use the msg_create() function and dlr_find functions to create messages. If this is an smppbox issue, I would like to get more information about it. == Rene From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] Sent: Monday, 09 August, 2010 23:27 To: Rene Kluwen Cc: Nikos Balkanas; users@kannel.org Subject: Re: Problem with spool store - missing sms_type Exactly. The point is: during normal operation, kannel of course it doesn't panic and will accept messages without a valid sms type. However, they're kept on the store with an invalid format, so if you shutdown the service with messages pending on the store, and just one of them happens to have an invalid sms type, the service panics at startup. This is less than desirable of course, specially when you have a ton of completely valid messages and just a bunch of invalid. IMHO, kannel should reject messages with invalid sms type during regular operation (with a WARN logged). It _shouldn't_ try to fix them. That would take care of the problem in a proper way. Apart from that, a way to discard invalid messages at bootup without panicking would also be desirable Regards, Alex On Mon, Aug 9, 2010 at 11:11 PM, Rene Kluwen rene.klu...@chimit.nl wrote: Yes, open smppbox should correctly fill in the correct type. If it doesn't it is an error. But at the same time: If one particular message has an incorrent sms_type. Why panic? It can just discard the message and go on with normal operation. == Rene -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Nikos Balkanas Sent: Monday, 09 August, 2010 22:34 To: Alejandro Guerrieri Cc: users@kannel.org Subject: Re: Problem with spool store - missing sms_type Hi, The behaviour in store is the only correct one. sms_type could be an MO (0), MT (2) or DLR (3). Different logic and routing is applied in each case. During startup it doesn't know which one is and correctly panics. During operation, maybe bb can tell more, but I am not sure it is always safe to do so. It has to discriminate between an MT, a reroute_dlr (report_mt) and an mt_reply (from an MO). Or between an MO and a report_mo. Anyway, it should at least be consistent, and it should check for sms_type and if missing and absolutely sure it knows what it is, fill it in, else discard with an error. This is an opensmppbox issue. It should set the correct sms_type according to gw/msg.h. BR, Nikos
Problem with spool store - missing sms_type
Hi, Today I've found some critical error with kannel spool store-type. When I have messages in a queue (spool) and restart Bearerbox I get Panic: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(gw_panic+0x14b) [0x487f5b] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419721] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419144] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419166] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419689] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(main+0x80f) [0x40f22f] 2010-08-09 17:49:55 [29887] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f5cdfd3b1a6] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x40db09] When I checked store-status (via http admin) I could see that Type field of all messages was empty. All messages were submitted to Bearerbox via open SMPPBOX. My Kannel version is from latest SVN (Rev. 4837). Tomasz
Re: Problem with spool store - missing sms_type
Hi, Yes, I know that they are corrupted, but all msgs in spool are always corrupted :) I removed them, but all new messages queued at spool are corrupted. They are probably incorrectly saved by Bearerbox/openSMPPBOX. The problem starts when I want to restart Bearerbox - it displays PANICs and won't start until I remove spool manually. It causes that I can't restart Bearerbox if there is some queue in spool... Tomasz W Twoim liście datowanym 9 sierpnia 2010 (18:34:44) można przeczytać: Hi, You have a corrupted SMS in your spool. Remove it and you will be fine. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, August 09, 2010 7:30 PM Subject: Problem with spool store - missing sms_type Hi, Today I've found some critical error with kannel spool store-type. When I have messages in a queue (spool) and restart Bearerbox I get Panic: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(gw_panic+0x14b) [0x487f5b] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419721] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419144] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419166] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419689] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(main+0x80f) [0x40f22f] 2010-08-09 17:49:55 [29887] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f5cdfd3b1a6] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x40db09] When I checked store-status (via http admin) I could see that Type field of all messages was empty. All messages were submitted to Bearerbox via open SMPPBOX. My Kannel version is from latest SVN (Rev. 4837). Tomasz
Re: Problem with spool store - missing sms_type
Hi, Open SMPPBOX haven't its own queue - I submit messages to Bearerbox via open SMPPBOX from other system. But sometimes these messages are being queued by Bearerbox in spool. But when Bearerbox is restarted while at spool there are some messages, it PANICs and won't run. The problem is because messages at spool haven't Type field. They have SMS ID, Time, Sender, Receiver, SMSC ID, BOX ID, UDH, Message fields but Type field is empty. Bearerbox during start informs about it: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! I didn't tried submitting messages to BEARERBOX from a standard SMSBOX yet, only by open SMPPBOX so I don't know at the moment if this problem happens only when using open SMPPBOX. @Nikos Sorry for adressing you private, it was my mistake. Tomasz Please address list. I didn't know that opensmppbox has now a queue. Clearly you shouldn't have overlapping spools between bb and openssmppbox. Configure different spool areas for each one. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: Nikos Balkanas nbalka...@gmail.com Sent: Monday, August 09, 2010 7:55 PM Subject: Re: Problem with spool store - missing sms_type Hi, Yes, I know that they are corrupted, but all msgs in spool are always corrupted :) I removed them, but all new messages queued at spool are corrupted. They are probably incorrectly saved by Bearerbox/openSMPPBOX. The problem starts when I want to restart Bearerbox - it displays PANICs and won't start until I remove spool manually. It causes that I can't restart Bearerbox if there is some queue in spool... Tomasz W Twoim licie datowanym 9 sierpnia 2010 (18:34:44) moΏna przeczytaζ: Hi, You have a corrupted SMS in your spool. Remove it and you will be fine. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, August 09, 2010 7:30 PM Subject: Problem with spool store - missing sms_type Hi, Today I've found some critical error with kannel spool store-type. When I have messages in a queue (spool) and restart Bearerbox I get Panic: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(gw_panic+0x14b) [0x487f5b] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419721] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419144] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419166] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419689] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(main+0x80f) [0x40f22f] 2010-08-09 17:49:55 [29887] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f5cdfd3b1a6] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x40db09] When I checked store-status (via http admin) I could see that Type field of all messages was empty. All messages were submitted to Bearerbox via open SMPPBOX. My Kannel version is from latest SVN (Rev. 4837). Tomasz
Re: Problem with spool store - missing sms_type
Hi, I've tried to send message via standard SMSBOX (CGI push) and when it is being queued sms_type field is present (value 2). But if message is pushed via open SMPPBOX, sms_type field is missing and Bearerbox crashes during restart. So it must be issue with open SMPPBOX. As Alex wrote, probably sms_type field is empty so it makes problems with store. Tomasz A similar problem happens with sqlbox if you don't set the sms_type to 2 when submitting mt's: everything works fine until you restart the service, and then when bearerbox tries to restore the queue from the store it fails with those errors. I don't know if opensmppbox is leaving the sms type empty, if is this a bug or misconfiguration (I've no experience with opensmppbox so far myself) but perhaps the sqlbox issue points you on the right direction? Regards, Alex On Mon, Aug 9, 2010 at 7:14 PM, Tomasz ad...@impexrur.pl wrote: Hi, Open SMPPBOX haven't its own queue - I submit messages to Bearerbox via open SMPPBOX from other system. But sometimes these messages are being queued by Bearerbox in spool. But when Bearerbox is restarted while at spool there are some messages, it PANICs and won't run. The problem is because messages at spool haven't Type field. They have SMS ID, Time, Sender, Receiver, SMSC ID, BOX ID, UDH, Message fields but Type field is empty. Bearerbox during start informs about it: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! I didn't tried submitting messages to BEARERBOX from a standard SMSBOX yet, only by open SMPPBOX so I don't know at the moment if this problem happens only when using open SMPPBOX. @Nikos Sorry for adressing you private, it was my mistake. Tomasz Please address list. I didn't know that opensmppbox has now a queue. Clearly you shouldn't have overlapping spools between bb and openssmppbox. Configure different spool areas for each one. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: Nikos Balkanas nbalka...@gmail.com Sent: Monday, August 09, 2010 7:55 PM Subject: Re: Problem with spool store - missing sms_type Hi, Yes, I know that they are corrupted, but all msgs in spool are always corrupted I removed them, but all new messages queued at spool are corrupted. They are probably incorrectly saved by Bearerbox/openSMPPBOX. The problem starts when I want to restart Bearerbox - it displays PANICs and won't start until I remove spool manually. It causes that I can't restart Bearerbox if there is some queue in spool... Tomasz W Twoim liœcie datowanym 9 sierpnia 2010 (18:34:44) moΏna przeczytaζ: Hi, You have a corrupted SMS in your spool. Remove it and you will be fine. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, August 09, 2010 7:30 PM Subject: Problem with spool store - missing sms_type Hi, Today I've found some critical error with kannel spool store-type. When I have messages in a queue (spool) and restart Bearerbox I get Panic: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(gw_panic+0x14b) [0x487f5b] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419721] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419144] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419166] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419689] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(main+0x80f) [0x40f22f] 2010-08-09 17:49:55 [29887] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f5cdfd3b1a6] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x40db09] When I checked store-status (via http admin) I could see that Type field of all messages was empty. All messages were submitted to Bearerbox via open SMPPBOX. My Kannel version is from latest SVN (Rev. 4837). Tomasz
Re: Huawei E220 / +CMS ERROR: The memory/message storage index assigned to the AT command is invalid (321)
Hi, Try to add: message-start = 0 in your group = modems section. It should help Tomasz W Twoim liście datowanym 8 lipca 2010 (05:09:16) można przeczytać: Thanks Rene, I have modified for 'ME', deleted the remaining SMS and restarted Kannel, will check if it happens again. If Alvajo or someone else have an idea why this error occurs using Huawei E220... BR, Emmanuel 2010/7/8 Rene Kluwen rene.klu...@chimit.nl Don’t know why this is occurs or how to solve it. But a workaround might be using “me” memory instead of “sm”? It may speed up things a little bit as well and probably you will have more memory indices. == Rene *From:* users-boun...@kannel.org [mailto:users-boun...@kannel.org] *On Behalf Of *Emmanuel CHANSON *Sent:* donderdag 8 juli 2010 0:07 *To:* users *Subject:* Huawei E220 / +CMS ERROR: The memory/message storage index assigned to the AT command is invalid (321) A little question about Huawei E220 and this issue: +CMS ERROR: The memory/message storage index assigned to the AT command is invalid (321) The only solution I have is to connect using minicom to the modem and delete the message. Do you know why does this happen on this modem ? 2010-07-08 09:01:01 [7101] [18] DEBUG: AT2[huawei_e220]: -- ^BOOT:92407792,0,0,0,6 2010-07-08 09:01:31 [7101] [18] DEBUG: AT2[huawei_e220]: -- ^BOOT:92407792,0,0,0,6 2010-07-08 09:01:47 [7101] [18] DEBUG: AT2[huawei_e220]: -- AT+CPMS?^M 2010-07-08 09:01:47 [7101] [18] DEBUG: AT2[huawei_e220]: -- +CPMS: SM,1,60,SM,1,60,SM,1,60 2010-07-08 09:01:47 [7101] [18] DEBUG: AT2[huawei_e220]: -- OK 2010-07-08 09:01:47 [7101] [18] DEBUG: AT2[huawei_e220]: 1 messages waiting in memory 2010-07-08 09:01:47 [7101] [18] DEBUG: AT2[huawei_e220]: -- AT+CMGR=1^M 2010-07-08 09:01:47 [7101] [18] DEBUG: AT2[huawei_e220]: -- OK 2010-07-08 09:01:47 [7101] [18] DEBUG: AT2[huawei_e220]: not deleted. 2010-07-08 09:01:47 [7101] [18] DEBUG: AT2[huawei_e220]: -- AT+CMGR=2^M ... ... 2010-07-08 09:01:53 [7101] [18] DEBUG: AT2[huawei_e220]: not deleted. 2010-07-08 09:01:53 [7101] [18] DEBUG: AT2[huawei_e220]: -- AT+CMGR=59^M 2010-07-08 09:01:53 [7101] [18] DEBUG: AT2[huawei_e220]: -- OK 2010-07-08 09:01:53 [7101] [18] DEBUG: AT2[huawei_e220]: not deleted. 2010-07-08 09:01:53 [7101] [18] DEBUG: AT2[huawei_e220]: -- AT+CMGR=60^M 2010-07-08 09:01:53 [7101] [18] DEBUG: AT2[huawei_e220]: -- +CMS ERROR: 321 2010-07-08 09:01:53 [7101] [18] ERROR: AT2[huawei_e220]: +CMS ERROR: +CMS ERROR: 321 2010-07-08 09:01:53 [7101] [18] ERROR: AT2[huawei_e220]: +CMS ERROR: The memory/message storage index assigned to the AT command is invalid (321) 2010-07-08 09:01:53 [7101] [18] DEBUG: AT2[huawei_e220]: failed to get message 60. My modems config: group = modems id = huawei_e220 name = Huawei E220 detect-string = huawei init-string = AT+CNMI=2,1,2,2,0 message-storage = sm speed = 460800 kannel.conf: ... # SMSC GSM group = smsc smsc = at #SMSC: HUAWEI E220 device = /dev/ttyUSB1 smsc-id = huawei_e220 modemtype = huawei_e220 allowed-smsc-id = huawei_e220 sms-center = +687xx #mynumber = 687xx pin = validityperiod = 167 sim-buffering = true log-file = /var/log/kannel/smsc.log log-level = 0 include = /etc/kannel/modems.conf ... Regards, -- Emmanuel
Re: SMPPBOX - problem with long Incoming SMS (MO)
Hi, Yes, its the same issue. BR, Tomasz W Twoim liście datowanym 29 czerwca 2010 (04:18:36) można przeczytać: Correct me if I am wrong, is this the same issue with last week's ticket about long MOs? Then it is only for MOs. Patch is ready, we are in the process of testing it. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, June 28, 2010 11:01 PM Subject: Re: SMPPBOX - problem with long Incoming SMS (MO) Hi, I've read in SMPP specification that short_message field in The deliver_sm PDU can contain 0-254 chars only. I've found that SMPPBOX sends more characters here so it breaks SMPP protocol and that is why Kannel 1 can't receive that message correctly. So it is 100% SMPPBOX bug. In SMPP specification (by SMPP Developers Forum), near short_message field description I can read : Up to 254 octets of short message user data. When sending messages longer than 254 octets the message_payload parameter should be used and the sm_length parameter should be set to zero. Note: The message data should be inserted in either the short_message or the message_payload parameters. Both parameters must not be used simultaneously. Could someone provide a patch to resolve this issue? Thanks, Tomasz W Twoim licie datowanym 25 czerwca 2010 (07:41:05) moΏna przeczytaζ: Hi, I'm sending logs of Bearerbox 1 2 and SMPPBOX on debug level: SMPPBOX log (Kannel 2): 2010-06-25 07:12:01 [21850] [1] INFO: We received an SMS message. 2010-06-25 07:12:01 [21850] [1] DEBUG: SMPP[main]: Manually forced source addr ton = 0, source add npi = 0 2010-06-25 07:12:01 [21850] [1] DEBUG: SMPP[main]: Manually forced dest addr ton = 0, dest add npi = 0 2010-06-25 07:12:01 [21850] [1] DEBUG: SMPP[main]: Sending PDU: 2010-06-25 07:12:01 [21850] [1] DEBUG: SMPP PDU 0x70b3c0 dump: 2010-06-25 07:12:01 [21850] [1] DEBUG: type_name: deliver_sm 2010-06-25 07:12:01 [21850] [1] DEBUG: command_id: 5 = 0x0005 2010-06-25 07:12:01 [21850] [1] DEBUG: command_status: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: sequence_number: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: service_type: NULL 2010-06-25 07:12:01 [21850] [1] DEBUG: source_addr_ton: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: source_addr_npi: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: source_addr: +48601232323 2010-06-25 07:12:01 [21850] [1] DEBUG: dest_addr_ton: 1 = 0x0001 2010-06-25 07:12:01 [21850] [1] DEBUG: dest_addr_npi: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: destination_addr: 48513123434 2010-06-25 07:12:01 [21850] [1] DEBUG: esm_class: 3 = 0x0003 2010-06-25 07:12:01 [21850] [1] DEBUG: protocol_id: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: priority_flag: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: schedule_delivery_time: NULL 2010-06-25 07:12:01 [21850] [1] DEBUG: validity_period: 100625051201000+ 2010-06-25 07:12:01 [21850] [1] DEBUG: registered_delivery: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: replace_if_present_flag: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: data_coding: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: sm_default_msg_id: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: sm_length: 256 = 0x0100 2010-06-25 07:12:01 [21850] [1] DEBUG: short_message: 2010-06-25 07:12:01 [21850] [1] DEBUG:Octet string at 0x70b5d0: 2010-06-25 07:12:01 [21850] [1] DEBUG: len: 256 2010-06-25 07:12:01 [21850] [1] DEBUG: size: 257 2010-06-25 07:12:01 [21850] [1] DEBUG: immutable: 0 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 54 65 73 74 20 74 65 73 74 20 74 75 74 75 75 75 Test test tutuuu 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 20 6a 6a 6a 6a 6a 20 6a 6a 6a 6a 6a 20 6b 6c 61j j kla 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 63 63 61 63 61 63 61 20 62 61 62 61 20 6a 6a 6a ccacaca baba jjj 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 6a 6a 20 6a 6a 6a 6a 6a 20 6a 6a 6a 6a 6a 20 6b jj j j k 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 6c 69 6b 20 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d 29 lik :-):-):-):-) 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 2e 31 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d .1:-):-):-):-):- 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 29 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d 29 ):-):-):-):-):-) 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 3a 29 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d :):-):-):-):-):- 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 29 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d 29 ):-):-):-):-):-) 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 3a 29 62 61 20 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d :)ba :-):-):-):- 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 29 2e 2d 62 61 62 61 31 61 61 61 61 61 61 61 61 ).-baba1 2010-06
Re: SMPPBOX - problem with long Incoming SMS (MO)
Hi, I've read in SMPP specification that short_message field in The deliver_sm PDU can contain 0-254 chars only. I've found that SMPPBOX sends more characters here so it breaks SMPP protocol and that is why Kannel 1 can't receive that message correctly. So it is 100% SMPPBOX bug. In SMPP specification (by SMPP Developers Forum), near short_message field description I can read : Up to 254 octets of short message user data. When sending messages longer than 254 octets the message_payload parameter should be used and the sm_length parameter should be set to zero. Note: The message data should be inserted in either the short_message or the message_payload parameters. Both parameters must not be used simultaneously. Could someone provide a patch to resolve this issue? Thanks, Tomasz W Twoim liście datowanym 25 czerwca 2010 (07:41:05) można przeczytać: Hi, I'm sending logs of Bearerbox 1 2 and SMPPBOX on debug level: SMPPBOX log (Kannel 2): 2010-06-25 07:12:01 [21850] [1] INFO: We received an SMS message. 2010-06-25 07:12:01 [21850] [1] DEBUG: SMPP[main]: Manually forced source addr ton = 0, source add npi = 0 2010-06-25 07:12:01 [21850] [1] DEBUG: SMPP[main]: Manually forced dest addr ton = 0, dest add npi = 0 2010-06-25 07:12:01 [21850] [1] DEBUG: SMPP[main]: Sending PDU: 2010-06-25 07:12:01 [21850] [1] DEBUG: SMPP PDU 0x70b3c0 dump: 2010-06-25 07:12:01 [21850] [1] DEBUG: type_name: deliver_sm 2010-06-25 07:12:01 [21850] [1] DEBUG: command_id: 5 = 0x0005 2010-06-25 07:12:01 [21850] [1] DEBUG: command_status: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: sequence_number: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: service_type: NULL 2010-06-25 07:12:01 [21850] [1] DEBUG: source_addr_ton: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: source_addr_npi: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: source_addr: +48601232323 2010-06-25 07:12:01 [21850] [1] DEBUG: dest_addr_ton: 1 = 0x0001 2010-06-25 07:12:01 [21850] [1] DEBUG: dest_addr_npi: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: destination_addr: 48513123434 2010-06-25 07:12:01 [21850] [1] DEBUG: esm_class: 3 = 0x0003 2010-06-25 07:12:01 [21850] [1] DEBUG: protocol_id: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: priority_flag: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: schedule_delivery_time: NULL 2010-06-25 07:12:01 [21850] [1] DEBUG: validity_period: 100625051201000+ 2010-06-25 07:12:01 [21850] [1] DEBUG: registered_delivery: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: replace_if_present_flag: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: data_coding: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: sm_default_msg_id: 0 = 0x 2010-06-25 07:12:01 [21850] [1] DEBUG: sm_length: 256 = 0x0100 2010-06-25 07:12:01 [21850] [1] DEBUG: short_message: 2010-06-25 07:12:01 [21850] [1] DEBUG:Octet string at 0x70b5d0: 2010-06-25 07:12:01 [21850] [1] DEBUG: len: 256 2010-06-25 07:12:01 [21850] [1] DEBUG: size: 257 2010-06-25 07:12:01 [21850] [1] DEBUG: immutable: 0 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 54 65 73 74 20 74 65 73 74 20 74 75 74 75 75 75 Test test tutuuu 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 20 6a 6a 6a 6a 6a 20 6a 6a 6a 6a 6a 20 6b 6c 61j j kla 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 63 63 61 63 61 63 61 20 62 61 62 61 20 6a 6a 6a ccacaca baba jjj 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 6a 6a 20 6a 6a 6a 6a 6a 20 6a 6a 6a 6a 6a 20 6b jj j j k 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 6c 69 6b 20 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d 29 lik :-):-):-):-) 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 2e 31 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d .1:-):-):-):-):- 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 29 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d 29 ):-):-):-):-):-) 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 3a 29 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d :):-):-):-):-):- 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 29 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d 29 ):-):-):-):-):-) 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 3a 29 62 61 20 3a 2d 29 3a 2d 29 3a 2d 29 3a 2d :)ba :-):-):-):- 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 29 2e 2d 62 61 62 61 31 61 61 61 61 61 61 61 61 ).-baba1 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 61 61 61 61 61 61 61 61 6f 6f 6f 6f 6f 6f 6f 6f 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 6f 6f 6f 6f 6f 6f 6f 6f 6f 6f 6f 6f 6f 6f 6f 6f 2010-06-25 07:12:01 [21850] [1] DEBUG: data: 6f 6f 6f 6f 6f 6f 6f 6f 6f 6f 6f 6f 6f 6f 6f 6f 2010-06-25 07:12:01 [21850] [1
Re: CMS ERROR: Unknown error. - maybe Sim storage is full? I'll have alook at it. (500)
Hi I've got this error with few operators when I'm sending a message to invalid destination number (which doesn't exists). BR, Tomasz W Twoim liście datowanym 25 czerwca 2010 (08:34:30) można przeczytać: Hi It is just what it says: Unknown error. 500 errors are vendor modem specific. Read User's guide about modem initialization on how to use CMEE. You might get a bit more info for it. BR, Nikos - Original Message - From: Tarun Goswami tarun.gosw...@tcs.com To: users@kannel.org; users-boun...@kannel.org Sent: Friday, June 25, 2010 6:04 AM Subject: CMS ERROR: Unknown error. - maybe Sim storage is full? I'll have alook at it. (500) Dear All, I am often getting the following error with couple of SIMS i used in GSP phone being used as a Modem. The SIM Memory is otherwise empty..no contacts..no messages... Please help? Thanks Best Regards, Tarun Kumar Goswami Tata Consultancy Services TCS Towers, 249 DE Udyog Vihar, Phase IV, Gurgaon Gurgaon,Haryana India Ph:- +91 124 4165229 Buzz:- 4145229 Mailto: tarun.gosw...@tcs.com Website: http://www.tcs.com Experience certainty. IT Services Business Solutions Outsourcing Can you tell me what is the purpose of max-messages variable under the sendsms-user group . I tried the user guide but there is not explanation about this variable , the description field for it is blank there . 2010/6/25 Nikos Balkanas nbalka...@gmail.com Seems very unlikely. BR, Nikos - Original Message - From: Harbhag Singh Sohal To: users@kannel.org Sent: Thursday, June 24, 2010 9:08 PM Subject: Re: CMS ERROR: Unknown error. - maybe Sim storage is full? under group = sendsms-usr i changed the value of max-message to a higher number (before it was 10) . and now I am not having that error . Can this be the actual solution ? . My modem is getting initialized properly . 2010/6/24 Nikos Balkanas nbalka...@gmail.com Hi, Please read User's Guide about modem initialization and repost detailed relevant bb logs. BR, Nikos - Original Message - From: Harbhag Singh Sohal To: users@kannel.org Sent: Thursday, June 24, 2010 5:42 PM Subject: CMS ERROR: Unknown error. - maybe Sim storage is full? I am getting this error . 2010-06-24 20:03:58 [1755] [0] INFO: Debug_lvl = 1, log_file = none, log_lvl = 0 2010-06-24 20:03:58 [1755] [0] WARNING: DLR: using default 'internal' for storage type. 2010-06-24 20:03:58 [1755] [0] INFO: DLR using storage type: internal 2010-06-24 20:03:58 [1755] [0] INFO: Added logfile `/var/log/kannel/bearerbox.log' with level `1'. 2010-06-24 20:03:58 [1755] [0] INFO: HTTP: Opening server at port 13000. 2010-06-24 20:03:58 [1755] [0] INFO: BOXC: 'smsbox-max-pending' not set, using default (100). 2010-06-24 20:03:58 [1755] [0] INFO: Set SMS resend frequency to 60 seconds. 2010-06-24 20:03:58 [1755] [0] INFO: SMS resend retry set to unlimited. 2010-06-24 20:03:58 [1755] [0] INFO: DLR rerouting for smsc id (null) disabled. 2010-06-24 20:03:58 [1755] [0] INFO: AT2[/dev/ttyACM0]: configuration doesn't show modemtype. will autodetect 2010-06-24 20:03:58 [1755] [0] INFO: 2010-06-24 20:03:58 [1755] [0] INFO: Kannel bearerbox II version 1.4.3 starting 2010-06-24 20:03:58 [1755] [0] INFO: MAIN: Start-up done, entering mainloop 2010-06-24 20:03:58 [1755] [6] INFO: AT2[/dev/ttyACM0]: opening device 2010-06-24 20:03:59 [1755] [6] INFO: AT2[/dev/ttyACM0]: speed set to 115200 2010-06-24 20:04:01 [1755] [6] INFO: AT2[/dev/ttyACM0]: Closing device 2010-06-24 20:04:01 [1755] [6] INFO: AT2[/dev/ttyACM0]: detect speed is 115200 2010-06-24 20:04:01 [1755] [6] INFO: AT2[/dev/ttyACM0]: opening device 2010-06-24 20:04:02 [1755] [6] INFO: AT2[/dev/ttyACM0]: speed set to 115200 2010-06-24 20:04:04 [1755] [6] INFO: AT2[/dev/ttyACM0]: Closing device 2010-06-24 20:04:04 [1755] [6] INFO: AT2[/dev/ttyACM0]: opening device 2010-06-24 20:04:04 [1755] [6] INFO: AT2[/dev/ttyACM0]: Logging in 2010-06-24 20:04:05 [1755] [6] INFO: AT2[/dev/ttyACM0]: init device 2010-06-24 20:04:05 [1755] [6] INFO: AT2[/dev/ttyACM0]: speed set to 115200 2010-06-24 20:04:06 [1755] [6] INFO: AT2[/dev/ttyACM0]: AT SMSC successfully opened. 2010-06-24 20:04:35 [1755] [5] INFO: Client connected from 127.0.0.1 2010-06-24 20:08:30 [1755] [6] ERROR: AT2[/dev/ttyACM0]: CMS ERROR: +CMS ERROR: 500 2010-06-24 20:08:30 [1755] [6] ERROR: AT2[/dev/ttyACM0]: CMS ERROR: Unknown error. - maybe Sim storage is full? I'll have a look at it. (500) 2010-06-24 20:09:51 [1755] [6] ERROR: AT2[/dev/ttyACM0]: CMS ERROR: +CMS ERROR: 500 2010-06-24 20:09:51 [1755] [6] ERROR: AT2[/dev/ttyACM0]: CMS ERROR
SMPPBOX - problem with long Incoming SMS (MO)
Hello, I've found another problem with incoming messages and SMPPBOX. My configuration is: KANNEL 1 KANNEL 2 CGI PUSH -- SMSBOX 1 -- BEARERBOX 1 -- SMPP LINK -- Open SMPPBOX --- BEARERBOX 2 - SMSC Here is scenario: Bearerbox 2 receives MO message from SMSC, next it is packed into PDU (deliver_sm) by SMPPBOX and send to Bearerbox 1. Everything works great if message length is up to 255 characters. But if received message is longer (more than 255 chars), Bearerbox 1 displays warning: 2010-06-24 11:22:10 [28065] [11] WARNING: SMPP: Unknown TLV(...) for PDU type (deliver_sm) received! and Bearerbox 1 sends to SMSBOX 1 blank message or only several chars of message. I've attached logs from SMPPBOX (kannel 2) and Bearerbox 1 during sending message with 256 characters. Is it bug with SMPPBOX or Bearerbox? Best Regards, Tomasz bearerbox-kannel1.log Description: Binary data smppbox-kannel2.log Description: Binary data
Re: SMPPBOX - problem with long Incoming SMS (MO)
Hi, I haven't got BB2 log on debug level of that attempt. But I can make a new attempt and send all logs on debug level. SMSC I use with Kannel 2 is AT2 (modem connection) so I don't know if BB2 logs will contain any interesting information for this issue. But if there is a need, I can deliver all logs. Tomasz W Twoim liście datowanym 24 czerwca 2010 (15:51:11) można przeczytać: Hi, Can you also post detailed bb2 logs from the same attempt? BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Tomasz ad...@impexrur.pl; rene.klu...@chimit.nl Cc: users@kannel.org Sent: Thursday, June 24, 2010 4:40 PM Subject: Re: SMPPBOX - problem with long Incoming SMS (MO) Hi, Hi, Looks like an SMPPBox issue. @Rene: Do you want to look at it, or should I?(If you are already working with SMPPBox, you better take it, otherwise I may mess it up) BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Thursday, June 24, 2010 1:34 PM Subject: SMPPBOX - problem with long Incoming SMS (MO) Hello, I've found another problem with incoming messages and SMPPBOX. My configuration is: KANNEL 1 KANNEL 2 CGI PUSH -- SMSBOX 1 -- BEARERBOX 1 -- SMPP LINK -- Open SMPPBOX --- BEARERBOX 2 - SMSC Here is scenario: Bearerbox 2 receives MO message from SMSC, next it is packed into PDU (deliver_sm) by SMPPBOX and send to Bearerbox 1. Everything works great if message length is up to 255 characters. But if received message is longer (more than 255 chars), Bearerbox 1 displays warning: 2010-06-24 11:22:10 [28065] [11] WARNING: SMPP: Unknown TLV(...) for PDU type (deliver_sm) received! and Bearerbox 1 sends to SMSBOX 1 blank message or only several chars of message. I've attached logs from SMPPBOX (kannel 2) and Bearerbox 1 during sending message with 256 characters. Is it bug with SMPPBOX or Bearerbox? Best Regards, Tomasz
Re: SMPPBOX - problem with long Incoming SMS (MO)
d293a2d293a2d293a2d293a2d293a2d293a2d293a296261203a2d293a2d293a2d293a2d292e2d626162613161616161616161616161616161616161616161616161616161616161616161616f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f6f61646464646561) for PDU type (deliver_sm) received! 2010-06-25 07:14:23 [28065] [11] DEBUG: SMPP[Ekonomiczne_sms]: Got PDU: 2010-06-25 07:14:23 [28065] [11] DEBUG: SMPP PDU 0x7f656c000cd0 dump: 2010-06-25 07:14:23 [28065] [11] DEBUG: type_name: deliver_sm 2010-06-25 07:14:23 [28065] [11] DEBUG: command_id: 5 = 0x0005 2010-06-25 07:14:23 [28065] [11] DEBUG: command_status: 0 = 0x 2010-06-25 07:14:23 [28065] [11] DEBUG: sequence_number: 0 = 0x 2010-06-25 07:14:23 [28065] [11] DEBUG: service_type: NULL 2010-06-25 07:14:23 [28065] [11] DEBUG: source_addr_ton: 0 = 0x 2010-06-25 07:14:23 [28065] [11] DEBUG: source_addr_npi: 0 = 0x 2010-06-25 07:14:23 [28065] [11] DEBUG: source_addr: +48601232323 2010-06-25 07:14:23 [28065] [11] DEBUG: dest_addr_ton: 1 = 0x0001 2010-06-25 07:14:23 [28065] [11] DEBUG: dest_addr_npi: 0 = 0x 2010-06-25 07:14:23 [28065] [11] DEBUG: destination_addr: 48513123434 2010-06-25 07:14:23 [28065] [11] DEBUG: esm_class: 3 = 0x0003 2010-06-25 07:14:23 [28065] [11] DEBUG: protocol_id: 0 = 0x 2010-06-25 07:14:23 [28065] [11] DEBUG: priority_flag: 0 = 0x 2010-06-25 07:14:23 [28065] [11] DEBUG: schedule_delivery_time: NULL 2010-06-25 07:14:23 [28065] [11] DEBUG: validity_period: 100625051201000+ 2010-06-25 07:14:23 [28065] [11] DEBUG: registered_delivery: 0 = 0x 2010-06-25 07:14:23 [28065] [11] DEBUG: replace_if_present_flag: 0 = 0x 2010-06-25 07:14:23 [28065] [11] DEBUG: data_coding: 0 = 0x 2010-06-25 07:14:23 [28065] [11] DEBUG: sm_default_msg_id: 0 = 0x 2010-06-25 07:14:23 [28065] [11] DEBUG: sm_length: 0 = 0x 2010-06-25 07:14:23 [28065] [11] DEBUG: short_message: 2010-06-25 07:14:23 [28065] [11] DEBUG: SMPP PDU dump ends. 2010-06-25 07:14:23 [28065] [11] DEBUG: SMPP[Ekonomiczne_sms]: Sending PDU: 2010-06-25 07:14:23 [28065] [11] DEBUG: SMPP PDU 0x7f656c0010a0 dump: 2010-06-25 07:14:23 [28065] [11] DEBUG: type_name: deliver_sm_resp 2010-06-25 07:14:23 [28065] [11] DEBUG: command_id: 2147483653 = 0x8005 2010-06-25 07:14:23 [28065] [11] DEBUG: command_status: 0 = 0x 2010-06-25 07:14:23 [28065] [11] DEBUG: sequence_number: 0 = 0x 2010-06-25 07:14:23 [28065] [11] DEBUG: message_id: NULL 2010-06-25 07:14:23 [28065] [11] DEBUG: SMPP PDU dump ends. 2010-06-25 07:14:23 [28065] [11] DEBUG: SMPP[Ekonomiczne_sms]: throughput (0.00,0.00) Bearerbox 1 access log: 2010-06-25 07:14:23 Receive SMS [SMSC:Ekonomiczne_sms] [SVC:] [ACT:gsmservice] [BINF:] [FID:] [META:?smpp?] [from:+48601232323] [to:+48513123434] [flags:-1:0:-1:0:-1] [msg:0:] [udh:0:] Tomasz W Twoim liście datowanym 24 czerwca 2010 (17:17:12) można przeczytać: Hi, Please retry and post fresh logs from all. Also do not attach logs, just post inlined, else they get lost in reply. Thanks,
Issue with concatenated messages and load balancing over SMPP
I'm currently using Kannel from last SVN in such configuration: CGI PUSH -- SMSBOX 1 -- BEARERBOX 1 -- SMPP LINK -- Open SMPPBOX --- BEARERBOX 2 To BEARERBOX 2 I have connected 3 SMSC via AT2. Each SMSC have the same smsc-id to make load balancing available. When I push a MT Message to CGI interface of SMSBOX 1 which is longer than 160 chars, it is concatenated and BEARERBOX 1 sends two submit_sm PDUs to BEARERBOX 2 via SMPPBOX. But BEARERBOX 2 sends each part of concatenated message via different SMSC (make load balancing for each part of concatenated msg) which makes the message unavailable to read on mobile. I think that BEARERBOX 2 doesn't know that these two messages are parts of one message and should be sent via the same SMSC. I can attach some logs if they are needed. If you could please help me to fix this issue. Thank you. Regarards, Tomasz
Re: Issue with concatenated messages and load balancing over SMPP
Hi Nikos, Sorry, I didn't make it so clear in my first post. I use other smsc-id for each SMSC but I use also some virtual smsc-id at allowed-smsc-id which is identical for several SMSC. It allows me to make several SMSC groups with load balancing - each group has several modems. Then I specify this virtual smsc-id in SMPPBOX config (route-to-smsc) and kannel makes load-balancing :) Everything works great with non-concatenated messages. I've also found that issue is caused by SMPPBOX as it pass to bearerbox two messages (received from BB 1) instead of 1. It makes that each part of concatenated is being sent via different smsc, due to load balancing. Regards, Tomasz Hi, You are not using correct configuration for load-balancing. Use different smsc-id for each smsc and simply do not specify smsc in your sendsms url. Kannel will load-balance SMS using rand() and load on each smsc. This will allow finer control (load) over your smscs, since when you want to use a specific SMSc (termination issues?) you can still direct to a specific SMSc from your sendsms URL. For that you will want to specify preferred-smsc-id as itself in each smsc definition. However, I suspect that this will not fix your problem. For a fix, SMPPbox needs to reassemble SMS to 1 before sending it to bearerbox 2. Any takers on that? BR, Nikos
Re: [PATCH] RE: Messages with php stripslashes
Hi,
Try to use -R option with path or press y when Assume -R? [n]
displays.
Regards,
Tomasz
W Twoim liście datowanym 14 czerwca 2010 (11:46:40) można przeczytać:
Hello Rene,
Trying to patch gw/sqlbox.c I got this error, is it an issue?
[r...@kannel gw]# patch -p0 sqlbox.c sql-escape.patch
patching file sqlbox.c
patching file sqlbox.c
Hunk #1 FAILED at 82.
1 out of 1 hunk FAILED -- saving rejects to file sqlbox.c.rej
patching file sqlbox.c
Reversed (or previously applied) patch detected! Assume -R? [n] n
Apply anyway? [n] y
Hunk #1 FAILED at 252.
Hunk #2 FAILED at 269.
Hunk #3 FAILED at 375.
Hunk #4 FAILED at 398.
4 out of 4 hunks FAILED -- saving rejects to file sqlbox.c.rej
[r...@kannel gw]#
[r...@kannel gw]# cat sqlbox.c.rej
Index: sb-config.h.in
--- sb-config.h.in (revision 28)
+++ sb-config.h.in (working copy)
@@ -82,10 +82,6 @@
/* Define to 1 if you have the unistd.h header file. */
#undef HAVE_UNISTD_H
-/* Define to the sub-directory in which libtool stores uninstalled
libraries.
- */
-#undef LT_OBJDIR
-
/* Name of package */
#undef PACKAGE
Index: gw/sqlbox.c
--- gw/sqlbox.c (revision 28)
+++ gw/sqlbox.c (working copy)
@@ -252,7 +252,7 @@
static void smsbox_to_bearerbox(void *arg)
{
Boxc *conn = arg;
-Msg *msg;
+Msg *msg, *msg_escaped;
/* remove messages from socket until it is closed */
while (sqlbox_status != SQL_DEAD conn-alive) {
@@ -269,7 +269,9 @@
if (msg_type(msg) == sms) {
debug(sqlbox, 0, smsbox_to_bearerbox: sms received);
-gw_sql_save_msg(msg, octstr_imm(MT));
+ msg_escaped = msg_duplicate(msg);
+gw_sql_save_msg(msg_escaped, octstr_imm(MT));
+ msg_destroy(msg_escaped);
}
send_msg(conn-bearerbox_connection, conn, msg);
@@ -375,7 +377,7 @@
static void bearerbox_to_smsbox(void *arg)
{
-Msg *msg;
+Msg *msg, *msg_escaped;
Boxc *conn = arg;
while (sqlbox_status != SQL_DEAD conn-alive) {
@@ -398,10 +400,12 @@
break;
}
if ((msg_type(msg) == sms)
(strcmp(octstr_get_cstr(msg-sms.msgdata),ACK/) != 0)) {
+ msg_escaped = msg_duplicate(msg);
if (msg-sms.sms_type != report_mo)
-gw_sql_save_msg(msg, octstr_imm(MO));
+gw_sql_save_msg(msg_escaped, octstr_imm(MO));
else
-gw_sql_save_msg(msg, octstr_imm(DLR));
+gw_sql_save_msg(msg_escaped, octstr_imm(DLR));
+ msg_destroy(msg_escaped);
}
send_msg(conn-smsbox_connection, conn, msg);
msg_destroy(msg);
[r...@kannel gw]#
Regards,
Emmanuel
2010/6/13 Rene Kluwen rene.klu...@chimit.nl
msg_duplicate is the normal function from msg.h. No special meaning.
What happens is that gw_sql_save has a side effect. It escapes all text
strings with a backslash before the ' sign because it displays them in
the
INSERT INTO... statement in the database.
When I designed the function I was under the impression that it escaped the
strings in a copy... But apparently it doesn't.
What happens in the old version is that gw_sql_save_msg escapes the
strings inline and later it does a send_msg(conn-smsbox_connection, conn,
msg) with the same message... which has a backslash in front of the '.
By duplicating the message before calling the gw_sql_save_msg, this
behavior
is eliminated.
Someone on the mailinglist (Tomasz) has already confirmed that the problem
has been solved with this patch.
== Rene
-Original Message-
From: Alejandro Guerrieri [mailto:aguerri...@kannel.org]
Sent: vrijdag 11 juni 2010 23:52
To: Rene Kluwen
Cc: 'Tomasz'; 'Kannel list'; de...@kannel.org
Subject: Re: [PATCH] RE: Messages with php stripslashes
+ msg_escaped = msg_duplicate(msg);
if (msg-sms.sms_type != report_mo)
-gw_sql_save_msg(msg, octstr_imm(MO));
+gw_sql_save_msg(msg_escaped, octstr_imm(MO));
else
-gw_sql_save_msg(msg, octstr_imm(DLR));
+gw_sql_save_msg(msg_escaped, octstr_imm(DLR));
+ msg_destroy(msg_escaped);
and
-gw_sql_save_msg(msg, octstr_imm(MT));
+ msg_escaped = msg_duplicate(msg);
+gw_sql_save_msg(msg_escaped, octstr_imm(MT));
+ msg_destroy(msg_escaped);
(and other similar lines)
You're duplicating the msg to msg_escaped and then running the same
gw_sql_save_msg function? What difference does it make?
Or maybe msg_duplicate does some escaping magic I'm not aware of? If
msg_duplicate does what the name says, I don't see what's changed.
Regards,
Alex
--
Alejandro Guerrieri
aguerri...@kannel.org
On 11/06/2010, at 23:25, Rene Kluwen wrote:
Sorry for crossposting. But I think the users are allowed to know what is
going on, even if this is a developers matter.
I think I found the solution to the problem below, which affects all
smsbox-sqlbox-bearerbox users
Re: Messages with php stripslashes
Hi, I've got the same issue - when we send MT message by CGI which contains ' sign, the recipient gets \' (escaped '). When we inject MT directly to MySQL Database, recipient get only ' sing (valid!). Our configuration is: PHP MT PUSH - SMSBOX - SQLBOX - BEARERBOX - SMSC The problem is caused probably by SQLBOX - somewhere there must be some kind of addslashes function. Escaped sign is being delivered to BEARERBOX. I've tried to find this is source code but I was unable. Have someone fixed this problem yet? Thanks Tomasz W Twoim liście datowanym 24 maja 2010 (02:05:22) można przeczytać: I have posted some weeks ago a similar issue with sqlbox but it is not resolved for the moment, Alejandro to check on his side to reproduce the issue. Check my post in the mailling list archive to see if it the same problem: Object: *Quote and backslash issue* As you when using CGI interface to send a SMS I got the quote escaped on the mobile, BUT when using directly SQL injection on sqlbox it works correctly. Regards, Emmanuel
Re: [PATCH] RE: Messages with php stripslashes
Thanks Rene for a patch! It works :) Now ' sign is coming correctly. Regards, Tomasz W Twoim liście datowanym 11 czerwca 2010 (23:25:30) można przeczytać: Sorry for crossposting. But I think the users are allowed to know what is going on, even if this is a developers matter. I think I found the solution to the problem below, which affects all smsbox-sqlbox-bearerbox users. I must admit: Haven't tested it yet. But it should work. See attached patch. Votes? -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Tomasz Sent: vrijdag 11 juni 2010 15:10 To: Kannel list Subject: Re: Messages with php stripslashes Hi, I've got the same issue - when we send MT message by CGI which contains ' sign, the recipient gets \' (escaped '). When we inject MT directly to MySQL Database, recipient get only ' sing (valid!). Our configuration is: PHP MT PUSH - SMSBOX - SQLBOX - BEARERBOX - SMSC The problem is caused probably by SQLBOX - somewhere there must be some kind of addslashes function. Escaped sign is being delivered to BEARERBOX. I've tried to find this is source code but I was unable. Have someone fixed this problem yet? Thanks Tomasz W Twoim liście datowanym 24 maja 2010 (02:05:22) można przeczytać: I have posted some weeks ago a similar issue with sqlbox but it is not resolved for the moment, Alejandro to check on his side to reproduce the issue. Check my post in the mailling list archive to see if it the same problem: Object: *Quote and backslash issue* As you when using CGI interface to send a SMS I got the quote escaped on the mobile, BUT when using directly SQL injection on sqlbox it works correctly. Regards, Emmanuel
Invalid recipient number CMS ERROR: 500 requeuing such messages
Hello, We have some problems with sending messages via GSM Modem (smsc=at) when recipient number is invalid (nonexisting). Normally we should get DLR REJECTED or UNDELIVERED but instead of it in logs we have CMS ERROR: +CMS ERROR: 500 and message is being queued and kannel try to resend it within one minute with CMS ERROR: 500 again and again (in loop). After each try modem is being disconnected and connects again. Messages sent to valid (existing) numbers are being delivered without any problems. I've found that this could be SIM operator specified problem because some other operator accepts messages to nonexisting numbers returning DLR REJECTED. But most of operators (SIM cards) we use doesn't accepts at all messages to nonexisting returning an CMS error 500. Is it possible to set some option to discard messages with CMS ERROR: 500 (with invalid recipient number) instead of queuing them and resending again with the same results? Or maybe there is some other solution to disallow queuing messages sent to invalid number? Here is a part of bearerbox logs: 2010-05-10 09:40:02 [2344] [9] DEBUG: AT2[modem]: TP-Validity-Period: 24.0 hours 2010-05-10 09:40:02 [2344] [9] DEBUG: AT2[modem]: -- AT+CMGS=18^M 2010-05-10 09:40:02 [2344] [9] DEBUG: AT2[modem]: -- 2010-05-10 09:40:02 [2344] [9] DEBUG: AT2[modem]: send command status: 1 2010-05-10 09:40:02 [2344] [9] DEBUG: AT2[modem]: -- 0031000B918405896745F3A704F4F29C0E 2010-05-10 09:40:02 [2344] [9] DEBUG: AT2[modem]: -- ^Z 2010-05-10 09:40:02 [2344] [9] DEBUG: AT2[modem]: -- 2010-05-10 09:40:23 [2344] [9] DEBUG: AT2[modem]: send command status: -1 2010-05-10 09:40:32 [2344] [9] DEBUG: AT2[modem]: -- +CMS ERROR: 500 2010-05-10 09:40:32 [2344] [9] ERROR: AT2[modem]: CMS ERROR: +CMS ERROR: 500 2010-05-10 09:40:32 [2344] [9] ERROR: AT2[modem]: CMS ERROR: Unknown error. - maybe Sim storage is full? I'll have a look at it. (500) Thank you for helping us. -- Best regards Tomasz
Re: Invalid recipient number CMS ERROR: 500 requeuing such messages
We have yet in modem init string: init-string = AT+CNMI=2,1,2,2,0;+CMEE=1 I've tried also with +CMEE=2 but no more info we get from modem - only CMS ERROR: 500. Modems we use are Huawei E1550. Tomasz Add CMEE=1 or 2 to your modem init string to see if you get more info from the modem. Repost logs if something changes |-| Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.perusms.NET www.smsglobal.com.mx y www.pravcom.com 2010/5/10 Tomasz ad...@impexrur.pl: Hello, We have some problems with sending messages via GSM Modem (smsc=at) when recipient number is invalid (nonexisting). Normally we should get DLR REJECTED or UNDELIVERED but instead of it in logs we have CMS ERROR: +CMS ERROR: 500 and message is being queued and kannel try to resend it within one minute with CMS ERROR: 500 again and again (in loop). After each try modem is being disconnected and connects again. Messages sent to valid (existing) numbers are being delivered without any problems. I've found that this could be SIM operator specified problem because some other operator accepts messages to nonexisting numbers returning DLR REJECTED. But most of operators (SIM cards) we use doesn't accepts at all messages to nonexisting returning an CMS error 500. Is it possible to set some option to discard messages with CMS ERROR: 500 (with invalid recipient number) instead of queuing them and resending again with the same results? Or maybe there is some other solution to disallow queuing messages sent to invalid number? Here is a part of bearerbox logs: 2010-05-10 09:40:02 [2344] [9] DEBUG: AT2[modem]: TP-Validity-Period: 24.0 hours 2010-05-10 09:40:02 [2344] [9] DEBUG: AT2[modem]: -- AT+CMGS=18^M 2010-05-10 09:40:02 [2344] [9] DEBUG: AT2[modem]: -- 2010-05-10 09:40:02 [2344] [9] DEBUG: AT2[modem]: send command status: 1 2010-05-10 09:40:02 [2344] [9] DEBUG: AT2[modem]: -- 0031000B918405896745F3A704F4F29C0E 2010-05-10 09:40:02 [2344] [9] DEBUG: AT2[modem]: -- ^Z 2010-05-10 09:40:02 [2344] [9] DEBUG: AT2[modem]: -- 2010-05-10 09:40:23 [2344] [9] DEBUG: AT2[modem]: send command status: -1 2010-05-10 09:40:32 [2344] [9] DEBUG: AT2[modem]: -- +CMS ERROR: 500 2010-05-10 09:40:32 [2344] [9] ERROR: AT2[modem]: CMS ERROR: +CMS ERROR: 500 2010-05-10 09:40:32 [2344] [9] ERROR: AT2[modem]: CMS ERROR: Unknown error. - maybe Sim storage is full? I'll have a look at it. (500) Thank you for helping us. -- Best regards Tomasz
Re: Repost: Using a Broker HTTP API with Kannel
for sure it's not!!:) On Fri, Oct 17, 2008 at 10:57 AM, brice dandjinou [EMAIL PROTECTED] wrote: What's up Mailing list is dead ?
Re: How to Acknowledge message send to kannel in delivery_sm
Thank You Stipe that cleared my view on that:)
regards
tomasz
On Wed, Oct 15, 2008 at 6:11 PM, Stipe Tolj [EMAIL PROTECTED] wrote:
Tomasz Zieleniewski schrieb:
Hi,
I have the following scenario.
Kannel is connected to SMSC through SMPP as ESME.
My simulator generates MO message and sends to kannel
the delivery_sm PDU.
Should Kannel send any acknowledgment to SMPP simulator to inform about
message
delivery if registered_delivery parameter is set to 1(0x0001)??
(if yes in what form?)
I know that in case of submit_sm with this parameter set to 1 should cause
to send SMSC Delivery or SME Acknowledgment in delivery_sm or data_sm PDU.
Hi Tomasz,
there is no explicite DLR from the ESME towards the SMSC, as we have in the
other case, where the ESME sends a submit_sm PDU and sets the
registered_delivery = 0x01 flag to indicate to the upstream SMSC that a
corresponding DLR is requested.
Here a reference from the spec:
SME Delivery Acknowledgement
Despite its name, an SME Delivery Acknowledgement is not an indication that
the
short message has arrived at the SME, but rather an indication from the
recipient SME that the user has read the short message.
For an MS-based SME, an SME Delivery Acknowledgement is sent when the MS user
or
MS application has read the message from the SMS storage unit (e.g. SIM card).
For a fixed SME (i.e. ESME) the circumstances in which an SME Delivery
Acknowledgement may be sent are beyond the scope of this specification.
Note: The SME Delivery Acknowledgement function may not be supported on all
network types.
So, the ESME _does_ acknowledge by the corresponding deliver_sm_resp PDU that
the ESME has received the MO and will transport it accordingly to the final
receiver.
Stipe
--
---
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
How to Acknowledge message send to kannel in delivery_sm
Hi, I have the following scenario. Kannel is connected to SMSC through SMPP as ESME. My simulator generates MO message and sends to kannel the delivery_sm PDU. Should Kannel send any acknowledgment to SMPP simulator to inform about message delivery if registered_delivery parameter is set to 1(0x0001)?? (if yes in what form?) I know that in case of submit_sm with this parameter set to 1 should cause to send SMSC Delivery or SME Acknowledgment in delivery_sm or data_sm PDU. I Kindly ask for Your support Regards Tomasz DETAILS: I am sending the following PDU (MO) to kannel from my SMPP simulator: 2008-10-15 14:56:08 [19592] [8] DEBUG: SMPP PDU 0x67a3c0 dump: 2008-10-15 14:56:08 [19592] [8] DEBUG: type_name: deliver_sm 2008-10-15 14:56:08 [19592] [8] DEBUG: command_id: 5 = 0x0005 2008-10-15 14:56:08 [19592] [8] DEBUG: command_status: 0 = 0x 2008-10-15 14:56:08 [19592] [8] DEBUG: sequence_number: 7 = 0x0007 2008-10-15 14:56:08 [19592] [8] DEBUG: service_type: NULL 2008-10-15 14:56:08 [19592] [8] DEBUG: source_addr_ton: 1 = 0x0001 2008-10-15 14:56:08 [19592] [8] DEBUG: source_addr_npi: 1 = 0x0001 2008-10-15 14:56:08 [19592] [8] DEBUG: source_addr: 8877665544 2008-10-15 14:56:08 [19592] [8] DEBUG: dest_addr_ton: 1 = 0x0001 2008-10-15 14:56:08 [19592] [8] DEBUG: dest_addr_npi: 1 = 0x0001 2008-10-15 14:56:08 [19592] [8] DEBUG: destination_addr: 997788665522 2008-10-15 14:56:08 [19592] [8] DEBUG: esm_class: 0 = 0x 2008-10-15 14:56:08 [19592] [8] DEBUG: protocol_id: 0 = 0x 2008-10-15 14:56:08 [19592] [8] DEBUG: priority_flag: 0 = 0x 2008-10-15 14:56:08 [19592] [8] DEBUG: schedule_delivery_time: NULL 2008-10-15 14:56:08 [19592] [8] DEBUG: validity_period: NULL 2008-10-15 14:56:08 [19592] [8] DEBUG: registered_delivery: 1 = 0x0001 2008-10-15 14:56:08 [19592] [8] DEBUG: replace_if_present_flag: 0 = 0x 2008-10-15 14:56:08 [19592] [8] DEBUG: data_coding: 0 = 0x 2008-10-15 14:56:08 [19592] [8] DEBUG: sm_default_msg_id: 0 = 0x 2008-10-15 14:56:08 [19592] [8] DEBUG: sm_length: 18 = 0x0012 2008-10-15 14:56:08 [19592] [8] DEBUG: short_message: Hello response from Kannel: 2008-10-15 14:39:56 [19592] [8] DEBUG: SMPP PDU 0x67a810 dump: 2008-10-15 14:39:56 [19592] [8] DEBUG: type_name: deliver_sm_resp 2008-10-15 14:39:56 [19592] [8] DEBUG: command_id: 2147483653 = 0x8005 2008-10-15 14:39:56 [19592] [8] DEBUG: command_status: 0 = 0x 2008-10-15 14:39:56 [19592] [8] DEBUG: sequence_number: 5 = 0x0005 2008-10-15 14:39:56 [19592] [8] DEBUG: message_id: NULL 2008-10-15 14:39:56 [19592] [8] DEBUG: SMPP PDU dump ends.
