Re: [Couldnot parse DLR string sscanf way, fallback to old way. Please report!] -- problem with message id

Черепанов Алексей Влади славович <[email protected]> Tue, 23 Aug 2016 09:43:26 +0500
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <[email protected]>
Oops, it was my fault.
I've set "interface-version = 0" thinking somehow, that it was default 
value.
Changed it to 34 and now DLR parsing works fine in both stable and SVN 
version.
Thank you guys and sorry for disturbing!

22.08.2016 18:33, [email protected] пишет:
> Please check bind , whether you are using SMPP version > 3.3 ?
>
> Thanks,
> Alex
>
>> Am 22.08.2016 um 13:26 schrieb Черепанов Алексей Владиславович 
>> <[email protected] <mailto:[email protected]>>:
>>
>> Okay, tried SVN version. Seems like the same issue.
>>
>>
>> Kannel bearerbox version `svn-r5172'.
>> Build `Aug 22 2016 13:52:19', compiler `4.9.2'.
>> System Linux, release 3.16.0-4-amd64, version #1 SMP Debian 
>> 3.16.7-ckt25-2+deb8u3 (2016-07-02), machine x86_64.
>> Libxml version 2.9.1.
>> Using OpenSSL 1.0.1t 3 May 2016.
>> Using native malloc.
>> Status: running, uptime 0d 1h 0m 10s
>> WDP: received 0 (0 queued), sent 0 (0 queued)
>> SMS: received 0 (0 queued), sent 3 (0 queued), store size 0
>> SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.02,0.00,0.00) msg/sec
>> DLR: received 0, sent 0
>> DLR: inbound (0.00,0.00,0.00) msg/sec, outbound (0.00,0.00,0.00) msg/sec
>> DLR: 3 queued, using internal storage
>>
>> 2016-08-22 16:14:48 [18226] [6] DEBUG: SMPP[SMSC]: Got PDU:
>> 2016-08-22 16:14:48 [18226] [6] DEBUG: SMPP PDU 0x7fa2080029c0 dump:
>> 2016-08-22 16:14:48 [18226] [6] DEBUG:   type_name: submit_sm_resp
>> 2016-08-22 16:14:48 [18226] [6] DEBUG:   command_id: 2147483652 = 
>> 0x80000004
>> 2016-08-22 16:14:48 [18226] [6] DEBUG:   command_status: 0 = 0x00000000
>> 2016-08-22 16:14:48 [18226] [6] DEBUG: sequence_number: 16 = 0x00000010
>> *2016-08-22 16:14:48 [18226] [6] DEBUG: message_id: "13F19886"*
>> 2016-08-22 16:14:48 [18226] [6] DEBUG: SMPP PDU dump ends.
>> 2016-08-22 16:14:48 [18226] [6] DEBUG: DLR[internal]: Adding DLR 
>> smsc=SMSC, ts=334600326, src=3432690000, dst=79028710256, mask=7, 
>> boxc=smsbox-web
>>
>> 2016-08-22 16:14:53 [18226] [6] DEBUG: SMPP[SMSC]: Got PDU:
>> 2016-08-22 16:14:53 [18226] [6] DEBUG: SMPP PDU 0x7fa208002da0 dump:
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:   type_name: deliver_sm
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:   command_id: 5 = 0x00000005
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:   command_status: 0 = 0x00000000
>> 2016-08-22 16:14:53 [18226] [6] DEBUG: sequence_number: 731929910 = 
>> 0x2ba05d36
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:   service_type: NULL
>> 2016-08-22 16:14:53 [18226] [6] DEBUG: source_addr_ton: 1 = 0x00000001
>> 2016-08-22 16:14:53 [18226] [6] DEBUG: source_addr_npi: 1 = 0x00000001
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:   source_addr: "79028710256"
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:   dest_addr_ton: 1 = 0x00000001
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:   dest_addr_npi: 1 = 0x00000001
>> 2016-08-22 16:14:53 [18226] [6] DEBUG: destination_addr: "3432690000"
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:   esm_class: 4 = 0x00000004
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:   protocol_id: 127 = 0x0000007f
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:   priority_flag: 0 = 0x00000000
>> 2016-08-22 16:14:53 [18226] [6] DEBUG: schedule_delivery_time: NULL
>> 2016-08-22 16:14:53 [18226] [6] DEBUG: validity_period: NULL
>> 2016-08-22 16:14:53 [18226] [6] DEBUG: registered_delivery: 0 = 
>> 0x00000000
>> 2016-08-22 16:14:53 [18226] [6] DEBUG: replace_if_present_flag: 0 = 
>> 0x00000000
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:   data_coding: 0 = 0x00000000
>> 2016-08-22 16:14:53 [18226] [6] DEBUG: sm_default_msg_id: 0 = 0x00000000
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:   sm_length: 0 = 0x00000000
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:   short_message: ""
>> 2016-08-22 16:14:53 [18226] [6] DEBUG: source_subaddress:
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:    Octet string at 0x7fa208002a60:
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:      len:  12
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:      size: 13
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:      immutable: 0
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:      data: a0 37 39 30 32 38 
>> 37 31 30 30 39 39               .79028710099
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:    Octet string dump ends.
>> 2016-08-22 16:14:53 [18226] [6] DEBUG: network_error_code:
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:    Octet string at 0x7fa208003570:
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:      len:  3
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:      size: 4
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:      immutable: 0
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:      data: 03 00 
>> 00                                          ...
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:    Octet string dump ends.
>> 2016-08-22 16:14:53 [18226] [6] DEBUG:   message_state: 2 = 0x00000002
>> *2016-08-22 16:14:53 [18226] [6] DEBUG: receipted_message_id: "13F19886"*
>> 2016-08-22 16:14:53 [18226] [6] DEBUG: SMPP PDU dump ends.
>> 2016-08-22 16:14:53 [18226] [6] DEBUG: SMPP[SMSC] handle_pdu, got DLR
>> 2016-08-22 16:14:53 [18226] [6] DEBUG: SMPP[SMSC]: Could not parse 
>> DLR string sscanf way, fallback to old way. Please report!
>> *2016-08-22 16:14:53 [18226] [6] ERROR: SMPP[SMSC]: got DLR but could 
>> not find message or was not interested in it id<> dst<79028710256>, 
>> type<2>*
>>
>>
>>
>>
>> 22.08.2016 12:58, [email protected] пишет:
>>> Hi,
>>>
>>> please try SVN version. Looks like 1.4.4 has issue with TLVs…
>>>
>>> Alex
>>>
>>>
>>>> Am 15.08.2016 um 06:43 schrieb Черепанов Алексей Владиславович 
>>>> <[email protected] <mailto:[email protected]>>:
>>>>
>>>> Here's the dump of packets.
>>>>
>>>>
>>>> *Short Message Peer to Peer, Command: Submit_sm - resp, Status: 
>>>> "Ok", Seq: 684, Len: 25
>>>> *    Length: 25
>>>>     Operation: Submit_sm - resp (0x80000004)
>>>>     Result: Ok (0x00000000)
>>>>     Sequence #: 684
>>>>     Message id.: 2D8B40B4
>>>>
>>>> *Short Message Peer to Peer, Command: Deliver_sm, Seq: 674395051, 
>>>> Len: 95*
>>>>     Length: 95
>>>>     Operation: Deliver_sm (0x00000005)
>>>>     Sequence #: 674395051
>>>>     Service type: (Default)
>>>>     Type of number (originator): International (0x01)
>>>>     Numbering plan indicator (originator): ISDN (E163/E164) (0x01)
>>>>     Originator address: 79028710256
>>>>     Type of number (recipient): International (0x01)
>>>>     Numbering plan indicator (recipient): ISDN (E163/E164) (0x01)
>>>>     Recipient address: 3432690000
>>>>     .... ..00 = Messaging mode: Default SMSC mode (0x00)
>>>>     ..00 01.. = Message type: Short message contains SMSC Delivery 
>>>> Receipt (0x01)
>>>>     00.. .... = GSM features: No specific features selected (0x00)
>>>>     Protocol id.: 0x7f
>>>>     Priority level: GSM: None ANSI-136: Bulk         IS-95: Normal 
>>>> (0x00)
>>>>     Scheduled delivery time: Immediate delivery
>>>>     Validity period: SMSC default validity period
>>>>     .... ..00 = Delivery receipt: No SMSC delivery receipt 
>>>> requested (0x00)
>>>>     .... 00.. = Message type: No recipient SME acknowledgement 
>>>> requested (0x00)
>>>>     ...0 .... = Intermediate notif: No intermediate notification 
>>>> requested (0x00)
>>>>     .... ...0 = Replace: Don't replace (0x00)
>>>>     Data coding: 0x00
>>>>         SMPP Data Coding Scheme: SMSC default alphabet (0x00)
>>>>         GSM SMS Data Coding
>>>>         0000 .... = DCS Coding Group for SMS: SMS DCS: General Data 
>>>> Coding indication - Uncompressed text, no message class (0x00)
>>>>         ..0. .... = DCS Text compression: Uncompressed text
>>>>         ...0 .... = DCS Class present: No message class
>>>>         .... 00.. = DCS Character set: GSM 7-bit default alphabet 
>>>> (0x00)
>>>>         GSM CBS Data Coding
>>>>         0000 .... = DCS Coding Group for CBS: CBS DCS: Language 
>>>> using the GSM 7-bit default alphabet (0x00)
>>>>         ..00 0000 = DCS CBS Message language: German (0x00)
>>>>     Predefined message: 0
>>>>     Message length: 0
>>>>     Optional parameters
>>>>         Optional parameter: message_state (0x0427)
>>>>             Tag: 0x0427
>>>>             Length: 1
>>>>             Message state: DELIVERED (2)
>>>>         Optional parameter: network_error_code (0x0423)
>>>>             Tag: 0x0423
>>>>             Length: 3
>>>>             Error type: GSM (3)
>>>>             Error code: 0x0000
>>>>         Optional parameter: receipted_message_id (0x001e)
>>>>             Tag: 0x001e
>>>>             Length: 9
>>>>             SMSC identifier: 2D8B40B4
>>>>         Optional parameter: source_subaddress (0x0202)
>>>>             Tag: 0x0202
>>>>             Length: 12
>>>>             Source Subaddress: a03739303238373130303939
>>>>
>>>>
>>>> 14.08.2016 20:07, Rene Kluwen пишет:
>>>>> Even, the message appears in your log files.
>>>>> If you set the debug level high enough, you can just see it appear there.
>>>>>
>>>>> -----Oorspronkelijk bericht-----
>>>>> Van: devel [mailto:[email protected]] Namens Milan P. Stanic
>>>>> Verzonden: zondag 14 augustus 2016 12:44
>>>>> Aan:[email protected]
>>>>> Onderwerp: Re: [Couldnot parse DLR string sscanf way,fallback to old way. Please report!] -- problem with message id
>>>>>
>>>>> On Fri, 2016-08-12 at 15:27, Черепанов Алексей Владиславович wrote:
>>>>>> Hi, there. Having a problem with handling deliver_sm.
>>>>>> Kannel couldn't parse message id:
>>>>>>
>>>>>> 2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP[SMSC]: Couldnot parse DLR
>>>>>> string sscanf way,fallback to old way. Please report!
>>>>>> 2016-08-12 14:45:59 [2952] [6] ERROR: SMPP[SMSC]: got DLR but could
>>>>>> not find message or was not interested in it id<> dst<79028710256>,
>>>>>> type<2>
>>>>>> 2016-08-12 14:45:59 [2952] [6] DEBUG: message_id: NULL
>>>>> Look like your provider (upstream SMPP server) does not send 'standard'
>>>>> DLR message.
>>>>> Actually there is no standard format for DLR message but most providers format it following sample in SMPP specification document.
>>>>>
>>>>> Could you check with your provider in what format their server send message to your kannel. Or, you can extract it with some network capture tools (tcpdump, tshark/wireshark) and see in what format messages are.
>>>>>
>>>>>
>>>>>
>>>>
>>>> -- 
>>>> С уважением,
>>>> Черепанов Алексей
>>>
>>
>> -- 
>> С уважением,
>> Черепанов Алексей
>

-- 
С уважением,
Черепанов Алексей