Hi,

I'm unable to reproduce it with the latest SVN version.

In your SMPP dump, it seems Kannel sends in UTF-8 without any converting. 
Please check your
SMPP config whether you have alt-charset set to utf-8?

smsbox URL called:
http://localhost:13003/cgi-bin/sendsms?username=tester&password=foobar&from=123&to=456&text=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa%C2%A35.00%2F%C2%A34.00aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa&charset=utf8

SMPP PDU:

2013-02-25 23:07:37 [21166] [8] DEBUG: SMPP PDU 0x7ff560d0c8c0 dump:
2013-02-25 23:07:37 [21166] [8] DEBUG:   type_name: submit_sm
2013-02-25 23:07:37 [21166] [8] DEBUG:   command_id: 4 = 0x00000004
2013-02-25 23:07:37 [21166] [8] DEBUG:   command_status: 0 = 0x00000000
2013-02-25 23:07:37 [21166] [8] DEBUG:   sequence_number: 2 = 0x00000002
2013-02-25 23:07:37 [21166] [8] DEBUG:   service_type: NULL
2013-02-25 23:07:37 [21166] [8] DEBUG:   source_addr_ton: 2 = 0x00000002
2013-02-25 23:07:37 [21166] [8] DEBUG:   source_addr_npi: 1 = 0x00000001
2013-02-25 23:07:37 [21166] [8] DEBUG:   source_addr: "123"
2013-02-25 23:07:37 [21166] [8] DEBUG:   dest_addr_ton: 2 = 0x00000002
2013-02-25 23:07:37 [21166] [8] DEBUG:   dest_addr_npi: 1 = 0x00000001
2013-02-25 23:07:37 [21166] [8] DEBUG:   destination_addr: "456"
2013-02-25 23:07:37 [21166] [8] DEBUG:   esm_class: 3 = 0x00000003
2013-02-25 23:07:37 [21166] [8] DEBUG:   protocol_id: 0 = 0x00000000
2013-02-25 23:07:37 [21166] [8] DEBUG:   priority_flag: 0 = 0x00000000
2013-02-25 23:07:37 [21166] [8] DEBUG:   schedule_delivery_time: NULL
2013-02-25 23:07:37 [21166] [8] DEBUG:   validity_period: NULL
2013-02-25 23:07:37 [21166] [8] DEBUG:   registered_delivery: 0 = 0x00000000
2013-02-25 23:07:37 [21166] [8] DEBUG:   replace_if_present_flag: 0 = 0x00000000
2013-02-25 23:07:37 [21166] [8] DEBUG:   data_coding: 0 = 0x00000000
2013-02-25 23:07:37 [21166] [8] DEBUG:   sm_default_msg_id: 0 = 0x00000000
2013-02-25 23:07:37 [21166] [8] DEBUG:   sm_length: 159 = 0x0000009f
2013-02-25 23:07:37 [21166] [8] DEBUG:   short_message:
2013-02-25 23:07:37 [21166] [8] DEBUG:    Octet string at 0x7ff560d0cca0:
2013-02-25 23:07:37 [21166] [8] DEBUG:      len:  159
2013-02-25 23:07:37 [21166] [8] DEBUG:      size: 162
2013-02-25 23:07:37 [21166] [8] DEBUG:      immutable: 0
2013-02-25 23:07:37 [21166] [8] DEBUG:      data: 61 61 61 61 61 61 61 61 61 61 
61 61 61 61 61 61   aaaaaaaaaaaaaaaa
2013-02-25 23:07:37 [21166] [8] DEBUG:      data: 61 61 61 61 61 61 61 61 61 61 
61 61 61 61 61 61   aaaaaaaaaaaaaaaa
2013-02-25 23:07:37 [21166] [8] DEBUG:      data: 61 61 61 61 61 61 61 61 61 61 
61 61 61 61 61 61   aaaaaaaaaaaaaaaa
2013-02-25 23:07:37 [21166] [8] DEBUG:      data: 61 61 61 61 61 61 61 61 61 61 
61 61 61 61 61 61   aaaaaaaaaaaaaaaa
2013-02-25 23:07:37 [21166] [8] DEBUG:      data: 61 61 61 61 61 61 61 61 61 61 
61 01 35 2e 30 30   aaaaaaaaaaa.5.00
2013-02-25 23:07:37 [21166] [8] DEBUG:      data: 2f 01 34 2e 30 30 61 61 61 61 
61 61 61 61 61 61   /.4.00aaaaaaaaaa
2013-02-25 23:07:37 [21166] [8] DEBUG:      data: 61 61 61 61 61 61 61 61 61 61 
61 61 61 61 61 61   aaaaaaaaaaaaaaaa
2013-02-25 23:07:37 [21166] [8] DEBUG:      data: 61 61 61 61 61 61 61 61 61 61 
61 61 61 61 61 61   aaaaaaaaaaaaaaaa
2013-02-25 23:07:37 [21166] [8] DEBUG:      data: 61 61 61 61 61 61 61 61 61 61 
61 61 61 61 61 61   aaaaaaaaaaaaaaaa
2013-02-25 23:07:37 [21166] [8] DEBUG:      data: 61 61 61 61 61 61 61 61 61 61 
61 61 61 61 61      aaaaaaaaaaaaaaa
2013-02-25 23:07:37 [21166] [8] DEBUG:    Octet string dump ends.
2013-02-25 23:07:37 [21166] [8] DEBUG: SMPP PDU dump ends.


Am 25.02.2013 um 21:24 schrieb Nathan Kelly <nat...@callparents.com>:

> PDU dump:
>  
> 2013-02-25 20:13:02 [32385] [37] DEBUG: SMPP[default]: Sending PDU:
> 2013-02-25 20:13:02 [32385] [37] DEBUG: SMPP PDU 0xb44b9c50 dump:
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   type_name: submit_sm
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   command_id: 4 = 0x00000004
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   command_status: 0 = 0x00000000
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   sequence_number: 1230 = 0x000004ce
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   service_type: NULL
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   source_addr_ton: 5 = 0x00000005
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   source_addr_npi: 0 = 0x00000000
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   source_addr: " default "
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   dest_addr_ton: 1 = 0x00000001
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   dest_addr_npi: 1 = 0x00000001
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   destination_addr: "447123456789"
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   esm_class: 0 = 0x00000000
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   protocol_id: 0 = 0x00000000
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   priority_flag: 0 = 0x00000000
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   schedule_delivery_time: NULL
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   validity_period: "130226070302000+"
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   registered_delivery: 1 = 0x00000001
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   replace_if_present_flag: 0 = 
> 0x00000000
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   data_coding: 0 = 0x00000000
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   sm_default_msg_id: 0 = 0x00000000
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   sm_length: 161 = 0x000000a1
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   short_message:
> 2013-02-25 20:13:02 [32385] [37] DEBUG:    Octet string at 0xb44c2850:
> 2013-02-25 20:13:02 [32385] [37] DEBUG:      len:  161
> 2013-02-25 20:13:02 [32385] [37] DEBUG:      size: 162
> 2013-02-25 20:13:02 [32385] [37] DEBUG:      immutable: 0
> 2013-02-25 20:13:02 [32385] [37] DEBUG:      data: 61 61 61 61 61 61 61 61 61 
> 61 61 61 61 61 61 61   aaaaaaaaaaaaaaaa
> 2013-02-25 20:13:02 [32385] [37] DEBUG:      data: 61 61 61 61 61 61 61 61 61 
> 61 61 61 61 61 61 61   aaaaaaaaaaaaaaaa
> 2013-02-25 20:13:02 [32385] [37] DEBUG:      data: 61 61 61 61 61 61 61 61 61 
> 61 61 61 61 61 61 61   aaaaaaaaaaaaaaaa
> 2013-02-25 20:13:02 [32385] [37] DEBUG:      data: 61 61 61 61 61 61 61 61 61 
> 61 61 61 61 61 61 61   aaaaaaaaaaaaaaaa
> 2013-02-25 20:13:02 [32385] [37] DEBUG:      data: 61 61 61 61 61 61 61 61 61 
> 61 61 c2 a3 35 2e 30   aaaaaaaaaaa..5.0
> 2013-02-25 20:13:02 [32385] [37] DEBUG:      data: 30 2f c2 a3 34 2e 30 30 61 
> 61 61 61 61 61 61 61   0/..4.00aaaaaaaa
> 2013-02-25 20:13:02 [32385] [37] DEBUG:      data: 61 61 61 61 61 61 61 61 61 
> 61 61 61 61 61 61 61   aaaaaaaaaaaaaaaa
> 2013-02-25 20:13:02 [32385] [37] DEBUG:      data: 61 61 61 61 61 61 61 61 61 
> 61 61 61 61 61 61 61   aaaaaaaaaaaaaaaa
> 2013-02-25 20:13:02 [32385] [37] DEBUG:      data: 61 61 61 61 61 61 61 61 61 
> 61 61 61 61 61 61 61   aaaaaaaaaaaaaaaa
> 2013-02-25 20:13:02 [32385] [37] DEBUG:      data: 61 61 61 61 61 61 61 61 61 
> 61 61 61 61 61 61 61   aaaaaaaaaaaaaaaa
> 2013-02-25 20:13:02 [32385] [37] DEBUG:      data: 61                         
>                        a
> 2013-02-25 20:13:02 [32385] [37] DEBUG:    Octet string dump ends.
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   ChannelId: " default "
> 2013-02-25 20:13:02 [32385] [37] DEBUG: SMPP PDU dump ends.
> 2013-02-25 20:13:02 [32385] [37] ERROR: SMPP: Unknown TLV `ChannelId', don't 
> send.
> 2013-02-25 20:13:02 [32385] [37] DEBUG: SMPP[default]: throughput (1.00,0.00)
> 2013-02-25 20:13:02 [32385] [37] DEBUG: SMPP[default]: throughput (1.00,0.00)
> 2013-02-25 20:13:02 [32385] [37] DEBUG: SMPP[default]: Got PDU:
> 2013-02-25 20:13:02 [32385] [37] DEBUG: SMPP PDU 0xb44b9c50 dump:
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   type_name: submit_sm_resp
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   command_id: 2147483652 = 0x80000004
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   command_status: 1 = 0x00000001
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   sequence_number: 1230 = 0x000004ce
> 2013-02-25 20:13:02 [32385] [37] DEBUG:   message_id: NULL
> 2013-02-25 20:13:02 [32385] [37] DEBUG: SMPP PDU dump ends.
> 2013-02-25 20:13:02 [32385] [37] ERROR: SMPP[default]: SMSC returned error 
> code 0x00000001 (Message Length is invalid) in response to submit_sm.
>  
>  
>  
>  
>  
> From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] 
> Sent: 25 February 2013 20:08
> To: Nathan Kelly
> Cc: devel@kannel.org
> Subject: Re: 159 chars with symbols results in a 
> msg:41:NACK/0x00000001/Message Length is invalid
>  
> Interesting, what about putting log-level 0 and see the full message dump?
>  
> 
> On Mon, Feb 25, 2013 at 3:04 PM, Nathan Kelly <nat...@callparents.com> wrote:
> Do you mean max-sms-octets ? no it’s not configured, so will be using the 
> default – I have the concatenation set to true in the users config, and it’s 
> sending other messages >160 chars with no problems:
>  
> group = sendsms-user
> username = blah
> password = blah
> name = Kannel
> max-messages = 100
> concatenation = true
> default-sender= default
> default-smsc= anySMSC
>  
> From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] 
> Sent: 25 February 2013 19:56
> 
> To: Nathan Kelly
> Cc: devel@kannel.org
> Subject: Re: 159 chars with symbols results in a 
> msg:41:NACK/0x00000001/Message Length is invalid
>  
> Do you have configured kannel to split messages?
>  
> 
> On Mon, Feb 25, 2013 at 2:19 PM, Nathan Kelly <nat...@callparents.com> wrote:
> Thanks, but if kannel sees the length as 161 it should send it as 2 messages 
> then, rather than fail?
>  
> As I said below, if I add another two chars to the message and send again it 
> goes through with no problems as a auto concatenated message with 2 parts. I 
> assume because this makes it appear to be 2 messages on the initial character 
> count, and so when converted to GSM it is sendable.
>  
> When it is 159 chars with symbols, kannel seems to count the chars, make it 
> one message only, then is unable to stuff the required bits into the 
> available space?
>  
> Nathan
>  
>  
> From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] 
> Sent: 25 February 2013 19:07
> To: Nathan Kelly
> Cc: devel@kannel.org
> Subject: Re: 159 chars with symbols results in a 
> msg:41:NACK/0x00000001/Message Length is invalid
>  
> Yup, you went over 160, check:
>  
> ...[msg:161:...
>  
> Regards,
>  
> Alejandro
>  
> 
> On Mon, Feb 25, 2013 at 2:02 PM, Nathan Kelly <nat...@callparents.com> wrote:
> Currently seeing a strange bug in build from SVN (Build `Dec 20 2012 
> 12:06:01'). When a message is sent that is 159 chars and has symbols in - 
> such as:
> 
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa£5.00/£4.00aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> 
> I get a fail
> 
> 2013-02-25 16:41:08 FAILED Send SMS [SMSC:default] [SVC:Kannel] [ACT:] 
> [BINF:] [FID:] [META:?smpp?ChannelId=REMOVED] [from:me] [to:+44123456789] 
> [flags:-1:0:-1:-1:3] 
> [msg:161:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa..5.00/..4.00aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa]
>  [udh:0:]
> 
> Add 2 more chars to it and try again - goes through no problems...
> 
> My guess is it's calculating the pound signs as 2 chars (or maybe the 
> backslash?) then trying to concatenate and then failing on the length when 
> converting to GSM to send to the SMSC? Or am I way off with that? can anyone 
> else recreate this fail on their setup, using latest from SVN?
> 
> Config for the smsc is:
> 
> group = smsc
> smsc = smpp
> smsc-id = defaultSMSC
> smsc-admin-id = defaultSMSC
> host = address.removed
> port = 1775
> receive-port = 1775
> smsc-username = blah
> smsc-password = blah
> system-type = ""
> address-range = ""
> # allow messages to UK mobile numbers only allowed-prefix = 07;+447;
> 
> # Optional Parameters
> 
> group = smpp-tlv
> name = CampaignId
> tag = 0x1400
> type = octetstring
> length = 32
> smsc-id = defaultSMSC
> 
> group = smpp-tlv
> name = Reference
> tag = 0x1401
> type = octetstring
> length = 32
> smsc-id = defaultSMSC
> 
> group = smpp-tlv
> name = ChannelId
> tag = 0x1402
> type = octetstring
> length = 32
> smsc-id = Oxygen8
> 
> # End of Optional Parameters
> 
> 
> 
>  
>  

Reply via email to