RE: Malformed addr for Incoming short code

Hi Stipe/Alex,

Please take a look at the SMPP PDU dump: Kannel bearerbox II version cvs-20060110

2006-01-29 15:51:41 [12663] [6] DEBUG: SMPP[XXX]: Got PDU:
2006-01-29 15:51:41 [12663] [6] DEBUG: SMPP PDU 0x8a0c5e8 dump:
2006-01-29 15:51:41 [12663] [6] DEBUG:   type_name: deliver_sm
2006-01-29 15:51:41 [12663] [6] DEBUG:   command_id: 5 = 0x00000005
2006-01-29 15:51:41 [12663] [6] DEBUG:   command_status: 0 = 0x00000000
2006-01-29 15:51:41 [12663] [6] DEBUG:   sequence_number: 2 = 0x00000002
2006-01-29 15:51:41 [12663] [6] DEBUG:   service_type: NULL
2006-01-29 15:51:41 [12663] [6] DEBUG:   source_addr_ton: 1 = 0x00000001
2006-01-29 15:51:41 [12663] [6] DEBUG:   source_addr_npi: 1 = 0x00000001
2006-01-29 15:51:41 [12663] [6] DEBUG:   source_addr: "97339405477"
2006-01-29 15:51:41 [12663] [6] DEBUG:   dest_addr_ton: 1 = 0x00000001
2006-01-29 15:51:41 [12663] [6] DEBUG:   dest_addr_npi: 1 = 0x00000001
2006-01-29 15:51:41 [12663] [6] DEBUG:   destination_addr: "4900"
2006-01-29 15:51:41 [12663] [6] DEBUG:   esm_class: 0 = 0x00000000
2006-01-29 15:51:41 [12663] [6] DEBUG:   protocol_id: 0 = 0x00000000
2006-01-29 15:51:41 [12663] [6] DEBUG:   priority_flag: 0 = 0x00000000
2006-01-29 15:51:41 [12663] [6] DEBUG:   schedule_delivery_time: NULL
2006-01-29 15:51:41 [12663] [6] DEBUG:   validity_period: NULL
2006-01-29 15:51:41 [12663] [6] DEBUG:   registered_delivery: 0 = 0x00000000
2006-01-29 15:51:41 [12663] [6] DEBUG:   replace_if_present_flag: 0 = 0x00000000
2006-01-29 15:51:41 [12663] [6] DEBUG:   data_coding: 0 = 0x00000000
2006-01-29 15:51:41 [12663] [6] DEBUG:   sm_default_msg_id: 0 = 0x00000000
2006-01-29 15:51:41 [12663] [6] DEBUG:   sm_length: 23 = 0x00000017
2006-01-29 15:51:41 [12663] [6] DEBUG:   short_message:
2006-01-29 15:51:41 [12663] [6] DEBUG:    Octet string at 0x8a0ca50:
2006-01-29 15:51:41 [12663] [6] DEBUG:      len:  23
2006-01-29 15:51:41 [12663] [6] DEBUG:      size: 24
2006-01-29 15:51:41 [12663] [6] DEBUG:      immutable: 0
2006-01-29 15:51:41 [12663] [6] DEBUG:      data: 0F 0F 0F 0F 0F 0F 0F 02 05 00 02 02 0b 01 0c 0a   XXXXXXXBE XXXXXX
2006-01-29 15:51:41 [12663] [6] DEBUG:      data: 0c 02 02 0b 09 30 03                              ,XXXXXX
2006-01-29 15:51:41 [12663] [6] DEBUG:    Octet string dump ends.
2006-01-29 15:51:41 [12663] [6] DEBUG: SMPP PDU dump ends.
2006-01-29 15:51:41 [12663] [6] ERROR: SMPP[MAR]: Mallformed addr `4900', expected at least 7 digits.

*******************************************************************************

When I reverted the kannel version back to: Kannel bearerbox II version cvs-20050908 
After this it works fine i.e., the TON is accepted and not treated as 'Mallformed'. 

SMPP PDU for this version,
2006-02-05 10:01:50 [12740] [6] DEBUG: SMPP[MAR]: Got PDU:
2006-02-05 10:01:50 [12740] [6] DEBUG: SMPP PDU 0x927d140 dump:
2006-02-05 10:01:50 [12740] [6] DEBUG:   type_name: deliver_sm
2006-02-05 10:01:50 [12740] [6] DEBUG:   command_id: 5 = 0x00000005
2006-02-05 10:01:50 [12740] [6] DEBUG:   command_status: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [6] DEBUG:   sequence_number: 1 = 0x00000001
2006-02-05 10:01:50 [12740] [6] DEBUG:   service_type: NULL
2006-02-05 10:01:50 [12740] [6] DEBUG:   source_addr_ton: 1 = 0x00000001
2006-02-05 10:01:50 [12740] [6] DEBUG:   source_addr_npi: 1 = 0x00000001
2006-02-05 10:01:50 [12740] [6] DEBUG:   source_addr: "97339405477"
2006-02-05 10:01:50 [12740] [6] DEBUG:   dest_addr_ton: 1 = 0x00000001
2006-02-05 10:01:50 [12740] [6] DEBUG:   dest_addr_npi: 1 = 0x00000001
2006-02-05 10:01:50 [12740] [6] DEBUG:   destination_addr: "4900"
2006-02-05 10:01:50 [12740] [6] DEBUG:   esm_class: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [6] DEBUG:   protocol_id: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [6] DEBUG:   priority_flag: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [6] DEBUG:   schedule_delivery_time: NULL
2006-02-05 10:01:50 [12740] [6] DEBUG:   validity_period: NULL
2006-02-05 10:01:50 [12740] [6] DEBUG:   registered_delivery: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [6] DEBUG:   replace_if_present_flag: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [6] DEBUG:   data_coding: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [6] DEBUG:   sm_default_msg_id: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [6] DEBUG:   sm_length: 4 = 0x00000004
2006-02-05 10:01:50 [12740] [6] DEBUG:   short_message: "Test"
2006-02-05 10:01:50 [12740] [6] DEBUG: SMPP PDU dump ends.
2006-02-05 10:01:50 [12740] [6] DEBUG: SMPP[MAR]: Sending PDU:
2006-02-05 10:01:50 [12740] [6] DEBUG: SMPP PDU 0x927d218 dump:
2006-02-05 10:01:50 [12740] [6] DEBUG:   type_name: deliver_sm_resp
2006-02-05 10:01:50 [12740] [9] DEBUG: send_msg: sending msg to boxc: <XXX>
2006-02-05 10:01:50 [12740] [6] DEBUG:   command_id: 2147483653 = 0x80000005
2006-02-05 10:01:50 [12740] [6] DEBUG:   command_status: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [9] DEBUG: boxc_sender: sent message to <127.0.0.1>
2006-02-05 10:01:50 [12740] [6] DEBUG:   sequence_number: 1 = 0x00000001
2006-02-05 10:01:50 [12740] [6] DEBUG:   message_id: NULL
2006-02-05 10:01:50 [12740] [6] DEBUG: SMPP PDU dump ends.


Let me know if you need more details. My apologies for the cross posting to both groups.


Best Regards,
Amol Patwardhan.
Application Developer.
Office: +973-17515222 (Ext:1033)
Mobile: +973-39405477
Arabian Network Information Services W.L.L

-----Original Message-----
From: Stipe Tolj [mailto:[email protected]]
Sent: Monday, February 06, 2006 3:45 AM
To: Amol Patwardhan
Cc: [email protected]
Subject: Re: Malformed addr for Incoming short code

Amol Patwardhan wrote:

> Hi,
>
> I am using Kannel bearer box II version cvs-20060110 on Red Hat.
>
> I've configured the kannel for the short code '4900'. The outgoing messages
> are going fine. However,
> The incoming message fails to reach the post-url and kannel.log is showing
> the following log
>
> Mallformed addr '4900', expected at least 7 digits.  !!

as Alex suggests, we'd need a debug log-level from bearerbox dump to see the
details of the "deliver_sm" PDU.

It seems that your SMSC provider sends a ton=1 but the shortcode is obviously
only 4 digit long. So interpreting the protocol stricly the SMSC would have to
define an appropriate ton instead.

BTW, please do _NOT_ cross-post to both mailing lists.

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
-------------------------------------------------------------------