Project

General

Profile

Bug #769

Invalid sm_length if message is larger than 254 octets

Added by Mikko Mensonen about 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
SMSC SMPP
Target version:
Start date:
07/19/2017
Due date:
% Done:

0%

Estimated time:
Affected version:

Description

Hello,

we are attempting to configure kannel to not split messages into multiple parts (letting the SMSC handle this). We set the max-sms-octets configuration parameter to an arbitrary high number (e.g 2800). This results in kannel not splitting the message, as expected, but as a result the sm_length is set incorrectly.

If you look at the PDU dump:

2017-07-19 14:37:37 [5797] [7] DEBUG: SMPP[LABSMSC01MT]: Sending PDU:
2017-07-19 14:37:37 [5797] [7] DEBUG: SMPP PDU 0x7f9d08000a10 dump:
2017-07-19 14:37:37 [5797] [7] DEBUG:   type_name: submit_sm
2017-07-19 14:37:37 [5797] [7] DEBUG:   command_id: 4 = 0x00000004
2017-07-19 14:37:37 [5797] [7] DEBUG:   command_status: 0 = 0x00000000
2017-07-19 14:37:37 [5797] [7] DEBUG:   sequence_number: 29 = 0x0000001d
2017-07-19 14:37:37 [5797] [7] DEBUG:   service_type: NULL
2017-07-19 14:37:37 [5797] [7] DEBUG:   source_addr_ton: 1 = 0x00000001
2017-07-19 14:37:37 [5797] [7] DEBUG:   source_addr_npi: 1 = 0x00000001
2017-07-19 14:37:37 [5797] [7] DEBUG:   source_addr: "447xxxxxxxxx" 
2017-07-19 14:37:37 [5797] [7] DEBUG:   dest_addr_ton: 1 = 0x00000001
2017-07-19 14:37:37 [5797] [7] DEBUG:   dest_addr_npi: 1 = 0x00000001
2017-07-19 14:37:37 [5797] [7] DEBUG:   destination_addr: "447xxxxxxxxx" 
2017-07-19 14:37:37 [5797] [7] DEBUG:   esm_class: 3 = 0x00000003
2017-07-19 14:37:37 [5797] [7] DEBUG:   protocol_id: 0 = 0x00000000
2017-07-19 14:37:37 [5797] [7] DEBUG:   priority_flag: 0 = 0x00000000
2017-07-19 14:37:37 [5797] [7] DEBUG:   schedule_delivery_time: NULL
2017-07-19 14:37:37 [5797] [7] DEBUG:   validity_period: "170719124731000+" 
2017-07-19 14:37:37 [5797] [7] DEBUG:   registered_delivery: 17 = 0x00000011
2017-07-19 14:37:37 [5797] [7] DEBUG:   replace_if_present_flag: 0 = 0x00000000
2017-07-19 14:37:37 [5797] [7] DEBUG:   data_coding: 241 = 0x000000f1
2017-07-19 14:37:37 [5797] [7] DEBUG:   sm_default_msg_id: 0 = 0x00000000
2017-07-19 14:37:37 [5797] [7] DEBUG:   sm_length: 300 = 0x0000012c
2017-07-19 14:37:37 [5797] [7] DEBUG:   short_message:
2017-07-19 14:37:37 [5797] [7] DEBUG:    Octet string at 0x7f9d080056c0:
2017-07-19 14:37:37 [5797] [7] DEBUG:      len:  300
2017-07-19 14:37:37 [5797] [7] DEBUG:      size: 301
2017-07-19 14:37:37 [5797] [7] DEBUG:      immutable: 0
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 4f 6e 65 20 6d 6f 72 6e 69 6e 67 2c 20 77 68 65   One morning, whe
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 6e 20 47 72 65 67 6f 72 20 53 61 6d 73 61 20 77   n Gregor Samsa w
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 6f 6b 65 20 66 72 6f 6d 20 74 72 6f 75 62 6c 65   oke from trouble
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 64 20 64 72 65 61 6d 73 2c 20 68 65 20 66 6f 75   d dreams, he fou
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 6e 64 20 68 69 6d 73 65 6c 66 20 74 72 61 6e 73   nd himself trans
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 66 6f 72 6d 65 64 20 69 6e 20 68 69 73 20 62 65   formed in his be
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 64 20 69 6e 74 6f 20 61 20 68 6f 72 72 69 62 6c   d into a horribl
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 65 20 76 65 72 6d 69 6e 2e 20 48 65 20 6c 61 79   e vermin. He lay
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 20 6f 6e 20 68 69 73 20 61 72 6d 6f 75 72 2d 6c    on his armour-l
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 69 6b 65 20 62 61 63 6b 2c 20 61 6e 64 20 69 66   ike back, and if
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 20 68 65 20 6c 69 66 74 65 64 20 68 69 73 20 68    he lifted his h
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 65 61 64 20 61 20 6c 69 74 74 6c 65 20 68 65 20   ead a little he 
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 63 6f 75 6c 64 20 73 65 65 20 68 69 73 20 62 72   could see his br
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 6f 77 6e 20 62 65 6c 6c 79 2c 20 73 6c 69 67 68   own belly, sligh
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 74 6c 79 20 64 6f 6d 65 64 20 61 6e 64 20 64 69   tly domed and di
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 76 69 64 65 64 20 62 79 20 61 72 63 68 65 73 20   vided by arches 
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 69 6e 74 6f 20 73 74 69 66 66 20 73 65 63 74 69   into stiff secti
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 6f 6e 73 2e 20 54 68 65 20 62 65 64 64 69 6e 67   ons. The bedding
2017-07-19 14:37:37 [5797] [7] DEBUG:      data: 20 77 61 73 20 68 61 72 64 6c 79 2e                was hardly.
2017-07-19 14:37:37 [5797] [7] DEBUG:    Octet string dump ends.
2017-07-19 14:37:37 [5797] [7] DEBUG: SMPP PDU dump ends.

You'll see sm_length set to 0x012c. However the standard states that:

The sm_length parameter specifies the length of the short_message parameter in octets. The sm_length should be set to 0 in the submit_sm, submit_multi, and deliver_sm PDUs if the message_payload parameter is being used to send user data larger than 254 octets.
0 no user data in short message field
1-254 allowed
255 not allowed

By setting the sm_length to 0x012c, only the last byte fits into the SMPP packet structure, effectively setting the message length to 0x2c (44). This results in a malformed packet, as the message is longer than 0x2c, and is discarded by the SMSC.

The expected outcome of this configuration setting would be sm_length to be set to 0.

Was tested with bearerbox version `svn-r5187'.

Associated revisions

Revision 5188 (diff)
Added by Alexander Malysh about 3 years ago

  • gw/smsc/smsc_smpp.c: Fixed sending of long messages.
    This fixes #769.

History

#1 Updated by Alexander Malysh about 3 years ago

  • Status changed from New to Resolved

Hi,

please check SVN. It should be fixed now.

Thanks,
Alex

#2 Updated by Mikko Mensonen about 3 years ago

Thanks, that was fast. Confirmed working.

#3 Updated by Alexander Malysh about 3 years ago

I had this patch already in my tree. Just forgot to merge it :-)

#4 Updated by Alexander Malysh almost 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF