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

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.
>>>
>>>
>>>
>>
>> -- 
>> С уважением,
>> Черепанов Алексей
>

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