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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Черепанов Алексей Владиславович
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


Full log
2016-08-12 14:45:53 [2952] [6] DEBUG: SMPP[SMSC]: Sending PDU:
2016-08-12 14:45:53 [2952] [6] DEBUG: SMPP PDU 0x7f42b00029c0 dump:
2016-08-12 14:45:53 [2952] [6] DEBUG: type_name: submit_sm
2016-08-12 14:45:53 [2952] [6] DEBUG: command_id: 4 = 0x00000004
2016-08-12 14:45:53 [2952] [6] DEBUG: command_status: 0 = 0x00000000
2016-08-12 14:45:53 [2952] [6] DEBUG: sequence_number: 4 = 0x00000004
2016-08-12 14:45:53 [2952] [6] DEBUG: service_type: NULL
2016-08-12 14:45:53 [2952] [6] DEBUG: source_addr_ton: 1 = 0x00000001
2016-08-12 14:45:53 [2952] [6] DEBUG: source_addr_npi: 1 = 0x00000001
2016-08-12 14:45:53 [2952] [6] DEBUG: source_addr: "3432690000"
2016-08-12 14:45:53 [2952] [6] DEBUG: dest_addr_ton: 1 = 0x00000001
2016-08-12 14:45:53 [2952] [6] DEBUG: dest_addr_npi: 1 = 0x00000001
2016-08-12 14:45:53 [2952] [6] DEBUG: destination_addr: "79028710256"
2016-08-12 14:45:53 [2952] [6] DEBUG: esm_class: 67 = 0x00000043
2016-08-12 14:45:53 [2952] [6] DEBUG: protocol_id: 127 = 0x0000007f
2016-08-12 14:45:53 [2952] [6] DEBUG: priority_flag: 0 = 0x00000000
2016-08-12 14:45:53 [2952] [6] DEBUG: schedule_delivery_time: NULL
2016-08-12 14:45:53 [2952] [6] DEBUG: validity_period: NULL
2016-08-12 14:45:53 [2952] [6] DEBUG: registered_delivery: 1 = 0x00000001
2016-08-12 14:45:53 [2952] [6] DEBUG: replace_if_present_flag: 0 = 0x00000000
2016-08-12 14:45:53 [2952] [6] DEBUG: data_coding: 246 = 0x000000f6
2016-08-12 14:45:53 [2952] [6] DEBUG: sm_default_msg_id: 0 = 0x00000000
2016-08-12 14:45:53 [2952] [6] DEBUG: sm_length: 53 = 0x00000035
2016-08-12 14:45:53 [2952] [6] DEBUG: short_message:
2016-08-12 14:45:53 [2952] [6] DEBUG: Octet string at 0x7f42b0000be0:
2016-08-12 14:45:53 [2952] [6] DEBUG: len: 53
2016-08-12 14:45:53 [2952] [6] DEBUG: size: 1024
2016-08-12 14:45:53 [2952] [6] DEBUG: immutable: 0
2016-08-12 14:45:53 [2952] [6] DEBUG: data: 02 70 00 00 30 15 06 3a 19 19 b0 00 00 1f 7e 72 .p..0..:......~r
2016-08-12 14:45:53 [2952] [6] DEBUG: data: da 2c d1 5e 41 a3 4a 95 0e 20 e4 92 8e 4d fe d8 .,.^A.J.. ...M..
2016-08-12 14:45:53 [2952] [6] DEBUG: data: cc 7a 3f 62 f5 ce 8d 25 70 65 47 db ad cf 3e 77 .z?b...%peG...>w
2016-08-12 14:45:53 [2952] [6] DEBUG: data: 4b 2a 57 09 1f K*W..
2016-08-12 14:45:53 [2952] [6] DEBUG: Octet string dump ends.
2016-08-12 14:45:53 [2952] [6] DEBUG: SMPP PDU dump ends.

2016-08-12 14:45:53 [2952] [6] DEBUG: SMPP[SMSC]: Got PDU:
2016-08-12 14:45:53 [2952] [6] DEBUG: SMPP PDU 0x7f42b00029c0 dump:
2016-08-12 14:45:53 [2952] [6] DEBUG: type_name: submit_sm_resp
2016-08-12 14:45:53 [2952] [6] DEBUG: command_id: 2147483652 = 0x80000004
2016-08-12 14:45:53 [2952] [6] DEBUG: command_status: 0 = 0x00000000
2016-08-12 14:45:53 [2952] [6] DEBUG: sequence_number: 4 = 0x00000004
2016-08-12 14:45:53 [2952] [6] DEBUG: message_id: "6D7872F"
2016-08-12 14:45:53 [2952] [6] DEBUG: SMPP PDU dump ends.
2016-08-12 14:45:53 [2952] [6] DEBUG: DLR[internal]: Adding DLR smsc=SMSC, ts=114788143, src=3432690000, dst=79028710256, mask=7, boxc=smsbox-web

2016-08-12 14:45:59 [2952] [6] DEBUG: Optional parameter tag (0x0427)
2016-08-12 14:45:59 [2952] [6] DEBUG: Optional parameter length read as 1
2016-08-12 14:45:59 [2952] [6] DEBUG: Optional parameter tag (0x0423)
2016-08-12 14:45:59 [2952] [6] DEBUG: Optional parameter length read as 3
2016-08-12 14:45:59 [2952] [6] DEBUG: Optional parameter tag (0x001e)
2016-08-12 14:45:59 [2952] [6] DEBUG: Optional parameter length read as 8
2016-08-12 14:45:59 [2952] [6] DEBUG: Optional parameter tag (0x0202)
2016-08-12 14:45:59 [2952] [6] DEBUG: Optional parameter length read as 12

2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP[SMSC]: Got PDU:
2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP PDU 0x7f42b0002d70 dump:
2016-08-12 14:45:59 [2952] [6] DEBUG: type_name: deliver_sm
2016-08-12 14:45:59 [2952] [6] DEBUG: command_id: 5 = 0x00000005
2016-08-12 14:45:59 [2952] [6] DEBUG: command_status: 0 = 0x00000000
2016-08-12 14:45:59 [2952] [6] DEBUG: sequence_number: 653984193 = 0x26fb01c1
2016-08-12 14:45:59 [2952] [6] DEBUG: service_type: NULL
2016-08-12 14:45:59 [2952] [6] DEBUG: source_addr_ton: 1 = 0x00000001
2016-08-12 14:45:59 [2952] [6] DEBUG: source_addr_npi: 1 = 0x00000001
2016-08-12 14:45:59 [2952] [6] DEBUG: source_addr: "79028710256"
2016-08-12 14:45:59 [2952] [6] DEBUG: dest_addr_ton: 1 = 0x00000001
2016-08-12 14:45:59 [2952] [6] DEBUG: dest_addr_npi: 1 = 0x00000001
2016-08-12 14:45:59 [2952] [6] DEBUG: destination_addr: "3432690000"
2016-08-12 14:45:59 [2952] [6] DEBUG: esm_class: 4 = 0x00000004
2016-08-12 14:45:59 [2952] [6] DEBUG: protocol_id: 127 = 0x0000007f
2016-08-12 14:45:59 [2952] [6] DEBUG: priority_flag: 0 = 0x00000000
2016-08-12 14:45:59 [2952] [6] DEBUG: schedule_delivery_time: NULL
2016-08-12 14:45:59 [2952] [6] DEBUG: validity_period: NULL
2016-08-12 14:45:59 [2952] [6] DEBUG: registered_delivery: 0 = 0x00000000
2016-08-12 14:45:59 [2952] [6] DEBUG: replace_if_present_flag: 0 = 0x00000000
2016-08-12 14:45:59 [2952] [6] DEBUG: data_coding: 0 = 0x00000000
2016-08-12 14:45:59 [2952] [6] DEBUG: sm_default_msg_id: 0 = 0x00000000
2016-08-12 14:45:59 [2952] [6] DEBUG: sm_length: 0 = 0x00000000
2016-08-12 14:45:59 [2952] [6] DEBUG: short_message: ""
2016-08-12 14:45:59 [2952] [6] DEBUG: source_subaddress:
2016-08-12 14:45:59 [2952] [6] DEBUG: Octet string at 0x7f42b0002ae0:
2016-08-12 14:45:59 [2952] [6] DEBUG: len: 12
2016-08-12 14:45:59 [2952] [6] DEBUG: size: 13
2016-08-12 14:45:59 [2952] [6] DEBUG: immutable: 0
2016-08-12 14:45:59 [2952] [6] DEBUG: data: a0 37 39 30 32 38 37 31 30 30 39 39 .79028710099
2016-08-12 14:45:59 [2952] [6] DEBUG: Octet string dump ends.
2016-08-12 14:45:59 [2952] [6] DEBUG: network_error_code:
2016-08-12 14:45:59 [2952] [6] DEBUG: Octet string at 0x7f42b0002a60:
2016-08-12 14:45:59 [2952] [6] DEBUG: len: 3
2016-08-12 14:45:59 [2952] [6] DEBUG: size: 4
2016-08-12 14:45:59 [2952] [6] DEBUG: immutable: 0
2016-08-12 14:45:59 [2952] [6] DEBUG: data: 03 00 00 ...
2016-08-12 14:45:59 [2952] [6] DEBUG: Octet string dump ends.
2016-08-12 14:45:59 [2952] [6] DEBUG: message_state: 2 = 0x00000002
2016-08-12 14:45:59 [2952] [6] DEBUG: receipted_message_id: "6D7872F"
2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP PDU dump ends.
2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP[SMSC] handle_pdu, got DLR
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: SMPP[SMSC]: Sending PDU:
2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP PDU 0x7f42b0003020 dump:
2016-08-12 14:45:59 [2952] [6] DEBUG: type_name: deliver_sm_resp
2016-08-12 14:45:59 [2952] [6] DEBUG: command_id: 2147483653 = 0x80000005
2016-08-12 14:45:59 [2952] [6] DEBUG: command_status: 0 = 0x00000000
2016-08-12 14:45:59 [2952] [6] DEBUG: sequence_number: 653984193 = 0x26fb01c1
2016-08-12 14:45:59 [2952] [6] DEBUG: message_id: NULL
2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP PDU dump ends.


Kannel version
Kannel bearerbox version `1.4.4'.
Build `Jan 1 1970 00:00:00', compiler `5.3.1 20160528'.
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.3.
Using OpenSSL 1.0.2h 3 May 2016.
Compiled with MySQL 5.6.30, using MySQL 5.5.50.
Compiled with PostgreSQL 9.5.3.
Using SQLite 3.13.0.
Using hiredis API 0.13.3
Using native malloc.
Status: running, uptime 0d 0h 0m 26s
WDP: received 0 (0 queued), sent 0 (0 queued)
SMS: received 0 (0 queued), sent 1 (0 queued), store size 0
SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.04,0.04,0.04) 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: 1 queued, using internal storage

-- 
Alexey Cherepanov
Reply | Threaded
Open this post in threaded view
|

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

Milan P. Stanic-3
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.

Reply | Threaded
Open this post in threaded view
|

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

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:[hidden email]] Namens Milan P. Stanic
Verzonden: zondag 14 augustus 2016 12:44
Aan: [hidden email]
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.



Reply | Threaded
Open this post in threaded view
|

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

Черепанов Алексей Владиславович
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 [[hidden email]] Namens Milan P. Stanic
Verzonden: zondag 14 augustus 2016 12:44
Aan: [hidden email]
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.




-- 
С уважением,
Черепанов Алексей
Reply | Threaded
Open this post in threaded view
|

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

amalysh
Hi,

please try SVN version. Looks like 1.4.4 has issue with TLVs…

Alex


Am 15.08.2016 um 06:43 schrieb Черепанов Алексей Владиславович <[hidden email]>:

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 [[hidden email]] Namens Milan P. Stanic
Verzonden: zondag 14 augustus 2016 12:44
Aan: [hidden email]
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.




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

Reply | Threaded
Open this post in threaded view
|

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, [hidden email] пишет:
Hi,

please try SVN version. Looks like 1.4.4 has issue with TLVs…

Alex


Am 15.08.2016 um 06:43 schrieb Черепанов Алексей Владиславович <[hidden email]>:

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 [[hidden email]] Namens Milan P. Stanic
Verzonden: zondag 14 augustus 2016 12:44
Aan: [hidden email]
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.




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


-- 
С уважением,
Черепанов Алексей
Reply | Threaded
Open this post in threaded view
|

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

amalysh
Please check bind , whether you are using SMPP version > 3.3 ?

Thanks,
Alex

Am 22.08.2016 um 13:26 schrieb Черепанов Алексей Владиславович <[hidden email]>:

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, [hidden email] пишет:
Hi,

please try SVN version. Looks like 1.4.4 has issue with TLVs…

Alex


Am 15.08.2016 um 06:43 schrieb Черепанов Алексей Владиславович <[hidden email]>:

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 [[hidden email]] Namens Milan P. Stanic
Verzonden: zondag 14 augustus 2016 12:44
Aan: [hidden email]
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.




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


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

Reply | Threaded
Open this post in threaded view
|

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

Milan P. Stanic-3
On Mon, 2016-08-22 at 15:33, [hidden email] wrote:
> Please check bind , whether you are using SMPP version > 3.3 ?

Maybe I'm wrong but to me it looks like the DLR message (string) from
upstream SMPP provider is not formatted according to kannel expectation,
or maybe upstream does not send anything in DLR message (I mean text in
the DLR and not DLR packet). Just my assumptions.

> Thanks,
> Alex
>
> > Am 22.08.2016 um 13:26 schrieb Черепанов Алексей Владиславович <[hidden email]>:
> >
> > 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, [hidden email] <mailto:[hidden email]> пишет:
> >> Hi,
> >>
> >> please try SVN version. Looks like 1.4.4 has issue with TLVs…
> >>
> >> Alex
> >>
> >>
> >>> Am 15.08.2016 um 06:43 schrieb Черепанов Алексей Владиславович <[hidden email] <mailto:[hidden email]>>:
> >>>
> >>> 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:[hidden email] <mailto:[hidden email]>] Namens Milan P. Stanic
> >>>> Verzonden: zondag 14 augustus 2016 12:44
> >>>> Aan: [hidden email] <mailto:[hidden email]>
> >>>> 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.
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> С уважением,
> >>> Черепанов Алексей
> >>
> >
> > --
> > С уважением,
> > Черепанов Алексей
>

Reply | Threaded
Open this post in threaded view
|

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

Черепанов Алексей Владиславович
In reply to this post by amalysh
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, [hidden email] пишет:
Please check bind , whether you are using SMPP version > 3.3 ?

Thanks,
Alex

Am 22.08.2016 um 13:26 schrieb Черепанов Алексей Владиславович <[hidden email]>:

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, [hidden email] пишет:
Hi,

please try SVN version. Looks like 1.4.4 has issue with TLVs…

Alex


Am 15.08.2016 um 06:43 schrieb Черепанов Алексей Владиславович <[hidden email]>:

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 [[hidden email]] Namens Milan P. Stanic
Verzonden: zondag 14 augustus 2016 12:44
Aan: [hidden email]
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.




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


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


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