Re: Malformed addr for Incoming short code

"Arne K. Haaje" <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Organization Eurobate ASA
Message-ID <[email protected]> 
Stipe Tolj wrote:
> Amol Patwardhan wrote:
> 
>> 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.
>>
> 
> yep, the following commit added the "checking":
> 
> http://www.kannel.org/cgi-bin/viewcvs.cgi/gateway/gw/smsc/smsc_smpp.c.diff?r1=1.80&r2=1.81 
> 
> 
> Unfortunatly the checking itself is correct, speaking in semantics of 
> the SMPP protocoll. Which means the SMSC is mis-behaving.
> 
> @Alex: is it enough to set 'dest-addr-ton', 'dest-addr-npi' inside smsc 
> group to get rid of this. Or is the checking done before that and hence 
> we baild out?

Yes, if we could set it ourself that would help a lot. I am seeing this now on connections 
to two different operators with the latest snapshots. Running an old snapshot (before the 
data_sm patch I think) make the problem go away

> @Amol: you should contact your SMSC provider and let them now that their 
> desination-ton for the shortcode is not right, they should send the 
> appropriate TON value for network internal numbers (shortcode).

I contacted on of the operators above regarding this, but they insisted values were correct. 
  Thus, they were unwilling to change anything and I had to downgrade to an older version


-- 
Yours sincerely,
Eurobate ASA

Arne K. Haaje
Senior Network Engineer
--------------------------------------------------------------------
     Eurobate ASA - Postboks 4589 Nydalen - 0404 Oslo - Norway
Phone: +47 23 22 73 73 - Fax: +47 23 22 73 74 - Mob: +47 92 88 44 66
                     http://www.eurobate.no/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.