Please check bind , whether you are using SMPP version > 3.3 ? Thanks, Alex
> Am 22.08.2016 um 13:26 schrieb Черепанов Алексей Владиславович > <sw_cherepa...@motivtelecom.ru>: > > 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, amal...@kannel.org <mailto:amal...@kannel.org> пишет: >> Hi, >> >> please try SVN version. Looks like 1.4.4 has issue with TLVs… >> >> Alex >> >> >>> Am 15.08.2016 um 06:43 schrieb Черепанов Алексей Владиславович >>> <sw_cherepa...@motivtelecom.ru <mailto:sw_cherepa...@motivtelecom.ru>>: >>> >>> 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:devel-boun...@kannel.org >>>> <mailto:devel-boun...@kannel.org>] Namens Milan P. Stanic >>>> Verzonden: zondag 14 augustus 2016 12:44 >>>> Aan: devel@kannel.org <mailto:devel@kannel.org> >>>> 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. >>>> >>>> >>>> >>> >>> -- >>> С уважением, >>> Черепанов Алексей >> > > -- > С уважением, > Черепанов Алексей
