RE: Not ACKED message found, will retransmit.
Thanks Enrique this helped. Best regards Amit Sharma From: Enrique Echeverria [mailto:enriqueocta...@gmail.com] Sent: Wednesday, December 16, 2015 5:55 PM To: amal...@kannel.org Cc: Amit Sharma (VAS); users@kannel.org Subject: Re: Not ACKED message found, will retransmit. Hi Amit: At SMPP level, every time you send and MT you send a submit_sm PDU, that needs to receive back a submit_sm_resp PDU (this would be the ack) from the SMSC. Every time you receive the ACK (submit_sm_resp PDU), that message is "tagged" as sent (and so deleted from kannel queue), and as long as the ACK is not received the message is still tagged as "not sent" (and so still queued). Obviously, there is a timeout for that ACK (submit_sm_resp PDU) to come back, and once the timeout expires the message is queued for retry (and so the "Not ACKED message found, will retransmit." message is logged to the bind level log) Kannel has 2 parameters for controlling this behaviour : wait-ack ->A message is resent if the acknowledge from SMSC takes more than this time. Defaults to 60 seconds. wait-ack-expire -> Defines what kind of action should be taken if the ack of a message expires. The options for this value are: 0x00 - disconnect/reconnect, (default) 0x01 - as is now, re-queue, but this could potentially result in the msg arriving twice 0x02 - just carry on waiting (given that the wait-ack should never expire this is the must accurate) So, the fact that you are seeing the "Not ACKED message found, will retransmit" but the MTs are anyway reaching the handset means that the ACK is arriving from the SMSC when your timeout is already expired. You should capturer traffic, measure the submit_sm_resp arrrival delay, and set your wait-ack parameter accordingly. Using wait-ack-expire would be nastier. Hope this helps, kind regards: enrique On Mon, Dec 14, 2015 at 11:04 AM, <amal...@kannel.org<mailto:amal...@kannel.org>> wrote: Hi, check your logs whether you received ACK/NACK for those sequence numbers and if not ask by SMSC operator why you don’t receive ACK/NACK within > 60 sec. Alex Am 14.12.2015 um 11:33 schrieb Amit Sharma (VAS) <amit.shar...@mtsindia.in<mailto:amit.shar...@mtsindia.in>>: Hi, I am getting following error of “Not ACKED message found, will retransmit” again and again due to which at times a single number receives multiple sms. In below case “9142294005” number received 9 msgs. Please suggest the reason for the below error & rectification to be done accordingly. 2015-12-13 09:36:49 [15072] [18] DEBUG: destination_addr: "9142294005" 2015-12-13 09:37:55 [15072] [18] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<66>sec. ago, SEQ<187878>, DST<9142294005> 2015-12-13 09:40:16 [15072] [22] DEBUG: destination_addr: "9142294005" 2015-12-13 09:41:20 [15072] [22] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<64>sec. ago, SEQ<189768>, DST<9142294005> 2015-12-13 09:43:44 [15072] [8] DEBUG: destination_addr: "9142294005" 2015-12-13 09:46:04 [15072] [10] DEBUG: destination_addr: "9142294005" 2015-12-13 09:47:06 [15072] [10] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<62>sec. ago, SEQ<189281>, DST<9142294005> 2015-12-13 09:48:10 [15072] [16] DEBUG: destination_addr: "9142294005" 2015-12-13 09:49:17 [15072] [16] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<67>sec. ago, SEQ<189655>, DST<9142294005> 2015-12-13 09:51:18 [15072] [8] DEBUG: destination_addr: "9142294005" 2015-12-13 09:52:36 [15072] [8] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<78>sec. ago, SEQ<188844>, DST<9142294005> 2015-12-13 09:53:42 [15072] [20] DEBUG: destination_addr: "9142294005" 2015-12-13 09:56:09 [15072] [6] DEBUG: destination_addr: "9142294005" 2015-12-13 09:57:13 [15072] [6] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<64>sec. ago, SEQ<189816>, DST<9142294005> 2015-12-13 09:58:14 [15072] [8] DEBUG: destination_addr: "9142294005" 2015-12-13 09:59:15 [15072] [8] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<61>sec. ago, SEQ<189177>, DST<9142294005> 2015-12-13 10:01:47 [15072] [20] DEBUG: destination_addr: "9142294005" 2015-12-13 10:04:14 [15072] [20] DEBUG: destination_addr: "9142294005" 2015-12-13 10:05:23 [15072] [20] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<69>sec. ago, SEQ<189456>, DST<9142294005> 2015-12-13 10:08:14 [15072] [12] DEBUG: destination_addr: "9142294005" 2015-12-13 10:09:20 [15072] [12] WARNING: SMPP[MTS]: Not ACKED message found, wil
Re: Not ACKED message found, will retransmit.
Hi Amit: At SMPP level, every time you send and MT you send a submit_sm PDU, that needs to receive back a submit_sm_resp PDU (this would be the ack) from the SMSC. Every time you receive the ACK (submit_sm_resp PDU), that message is "tagged" as sent (and so deleted from kannel queue), and as long as the ACK is not received the message is still tagged as "not sent" (and so still queued). Obviously, there is a timeout for that ACK (submit_sm_resp PDU) to come back, and once the timeout expires the message is queued for retry (and so the "Not ACKED message found, will retransmit." message is logged to the bind level log) Kannel has 2 parameters for controlling this behaviour : *wait-ack* ->A message is resent if the acknowledge from SMSC takes more than this time. Defaults to 60 seconds. *wait-ack-expire* -> Defines what kind of action should be taken if the ack of a message expires. The options for this value are: 0x00 - disconnect/reconnect, (default) 0x01 - as is now, re-queue, but this could potentially result in the msg arriving twice 0x02 - just carry on waiting (given that the wait-ack should never expire this is the must accurate) So, the fact that you are seeing the "Not ACKED message found, will retransmit" but the MTs are anyway reaching the handset means that the ACK is arriving from the SMSC when your timeout is already expired. You should capturer traffic, measure the submit_sm_resp arrrival delay, and set your wait-ack parameter accordingly. Using wait-ack-expire would be nastier. Hope this helps, kind regards: enrique On Mon, Dec 14, 2015 at 11:04 AM, <amal...@kannel.org> wrote: > Hi, > > check your logs whether you received ACK/NACK for those sequence numbers > and if not > ask by SMSC operator why you don’t receive ACK/NACK within > 60 sec. > > Alex > > > Am 14.12.2015 um 11:33 schrieb Amit Sharma (VAS) <amit.shar...@mtsindia.in > >: > > Hi, > I am getting following error of “Not ACKED message found, will retransmit” > again and again due to which at times a single number receives multiple > sms. In below case “9142294005” number received 9 msgs. > > Please suggest the reason for the below error & rectification to be done > accordingly. > > > 2015-12-13 09:36:49 [15072] [18] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:37:55 [15072] [18] WARNING: SMPP[MTS]: Not ACKED message > found, will retransmit. SENT<66>sec. ago, SEQ<187878>, DST<9142294005> > 2015-12-13 09:40:16 [15072] [22] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:41:20 [15072] [22] WARNING: SMPP[MTS]: Not ACKED message > found, will retransmit. SENT<64>sec. ago, SEQ<189768>, DST<9142294005> > 2015-12-13 09:43:44 [15072] [8] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:46:04 [15072] [10] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:47:06 [15072] [10] WARNING: SMPP[MTS]: Not ACKED message > found, will retransmit. SENT<62>sec. ago, SEQ<189281>, DST<9142294005> > 2015-12-13 09:48:10 [15072] [16] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:49:17 [15072] [16] WARNING: SMPP[MTS]: Not ACKED message > found, will retransmit. SENT<67>sec. ago, SEQ<189655>, DST<9142294005> > 2015-12-13 09:51:18 [15072] [8] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:52:36 [15072] [8] WARNING: SMPP[MTS]: Not ACKED message > found, will retransmit. SENT<78>sec. ago, SEQ<188844>, DST<9142294005> > 2015-12-13 09:53:42 [15072] [20] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:56:09 [15072] [6] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:57:13 [15072] [6] WARNING: SMPP[MTS]: Not ACKED message > found, will retransmit. SENT<64>sec. ago, SEQ<189816>, DST<9142294005> > 2015-12-13 09:58:14 [15072] [8] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:59:15 [15072] [8] WARNING: SMPP[MTS]: Not ACKED message > found, will retransmit. SENT<61>sec. ago, SEQ<189177>, DST<9142294005> > 2015-12-13 10:01:47 [15072] [20] DEBUG: destination_addr: "9142294005" > 2015-12-13 10:04:14 [15072] [20] DEBUG: destination_addr: "9142294005" > 2015-12-13 10:05:23 [15072] [20] WARNING: SMPP[MTS]: Not ACKED message > found, will retransmit. SENT<69>sec. ago, SEQ<189456>, DST<9142294005> > 2015-12-13 10:08:14 [15072] [12] DEBUG: destination_addr: "9142294005" > 2015-12-13 10:09:20 [15072] [12] WARNING: SMPP[MTS]: Not ACKED message > found, will retransmit. SENT<66>sec. ago, SEQ<190251>, DST<9142294005> > > Configuration is as follows: > > group = core > admin-port = 130
Not ACKED message found, will retransmit.
Hi, I am getting following error of "Not ACKED message found, will retransmit" again and again due to which at times a single number receives multiple sms. In below case "9142294005" number received 9 msgs. Please suggest the reason for the below error & rectification to be done accordingly. 2015-12-13 09:36:49 [15072] [18] DEBUG: destination_addr: "9142294005" 2015-12-13 09:37:55 [15072] [18] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<66>sec. ago, SEQ<187878>, DST<9142294005> 2015-12-13 09:40:16 [15072] [22] DEBUG: destination_addr: "9142294005" 2015-12-13 09:41:20 [15072] [22] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<64>sec. ago, SEQ<189768>, DST<9142294005> 2015-12-13 09:43:44 [15072] [8] DEBUG: destination_addr: "9142294005" 2015-12-13 09:46:04 [15072] [10] DEBUG: destination_addr: "9142294005" 2015-12-13 09:47:06 [15072] [10] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<62>sec. ago, SEQ<189281>, DST<9142294005> 2015-12-13 09:48:10 [15072] [16] DEBUG: destination_addr: "9142294005" 2015-12-13 09:49:17 [15072] [16] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<67>sec. ago, SEQ<189655>, DST<9142294005> 2015-12-13 09:51:18 [15072] [8] DEBUG: destination_addr: "9142294005" 2015-12-13 09:52:36 [15072] [8] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<78>sec. ago, SEQ<188844>, DST<9142294005> 2015-12-13 09:53:42 [15072] [20] DEBUG: destination_addr: "9142294005" 2015-12-13 09:56:09 [15072] [6] DEBUG: destination_addr: "9142294005" 2015-12-13 09:57:13 [15072] [6] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<64>sec. ago, SEQ<189816>, DST<9142294005> 2015-12-13 09:58:14 [15072] [8] DEBUG: destination_addr: "9142294005" 2015-12-13 09:59:15 [15072] [8] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<61>sec. ago, SEQ<189177>, DST<9142294005> 2015-12-13 10:01:47 [15072] [20] DEBUG: destination_addr: "9142294005" 2015-12-13 10:04:14 [15072] [20] DEBUG: destination_addr: "9142294005" 2015-12-13 10:05:23 [15072] [20] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<69>sec. ago, SEQ<189456>, DST<9142294005> 2015-12-13 10:08:14 [15072] [12] DEBUG: destination_addr: "9142294005" 2015-12-13 10:09:20 [15072] [12] WARNING: SMPP[MTS]: Not ACKED message found, will retransmit. SENT<66>sec. ago, SEQ<190251>, DST<9142294005> Configuration is as follows: group = core admin-port = 13010 smsbox-port = 13012 log-file = "/u03/kannel/logs/bearerbox.log" box-allow-ip = "10.130.252.160,127.0.0.1" access-log = "/u03/kannel/logs/bearerbox_access.log" dlr-storage = internal ##TX-1## group = smsc smsc-id ="MT" smsc = smpp host =10.10.22.10 port = 5016 system-type = "INAPPS" interface-version = 34 receive-port =0 source-addr-ton = 1 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 keepalive = 30 log-level =0 throughput = 50 max-pending-submits=50 reconnect-delay = 60 reroute = true log-file = "/u03/kannel/logs/smsc_conn.log" ##RX-1 group = smsc smsc-id ="MTS" smsc = smpp host =10.10.22.10 port = 0 system-type = "INAPPS" receive-port =5016 interface-version = 34 source-addr-ton = 1 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 keepalive = 30 log-level =0 reconnect-delay = 60 reroute = true log-file = "/u03/kannel/logs/smsc_conn.log" group = smsbox bearerbox-host = 127.0.0.1 sendsms-port = 13013 global-sender = YD-MTS log-file = "/u03/kannel/logs/smsbox.log" log-level = 0 #SMSBOX ROUTING group = smsbox-route smsbox-id = smsbox smsc-id ="MT" group = sendsms-user username = smsg password = smsg@123 default-smsc="MT" concatenation= true max-messages = 6 group = sms-service keyword = default url = http://10.130.250.58/receivesms.php?sender=%p=%b<http://10.130.250.58/receivesms.php?sender=%25p=%25b> catch-all = true max-messages = 1 text = "This is a reply" Best regards Amit Sharma (VAS) Head, IN & VAS Operations Division IT Shared Service Center, CORPORATE CENTER Sistema Shyam Teleservices Limited MTS Tower2 Building No. 313, Udyog Vihar Phase IV,Gurgaon MTS+91 913 600 6473 Direct +91 124 481 2500 Email: amit.shar...@mtsindia.in [cid:image001.jpg@01D13688.031428C0]<http://www.mtsindia.in/> This E-Mail may contain Confidential and/or legally privileged Information and is meant for the intend
Re: Not ACKED message found, will retransmit.
Hi, check your logs whether you received ACK/NACK for those sequence numbers and if not ask by SMSC operator why you don’t receive ACK/NACK within > 60 sec. Alex > Am 14.12.2015 um 11:33 schrieb Amit Sharma (VAS) <amit.shar...@mtsindia.in>: > > Hi, > I am getting following error of “Not ACKED message found, will retransmit” > again and again due to which at times a single number receives multiple sms. > In below case “9142294005” number received 9 msgs. > > Please suggest the reason for the below error & rectification to be done > accordingly. > > > 2015-12-13 09:36:49 [15072] [18] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:37:55 [15072] [18] WARNING: SMPP[MTS]: Not ACKED message found, > will retransmit. SENT<66>sec. ago, SEQ<187878>, DST<9142294005> > 2015-12-13 09:40:16 [15072] [22] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:41:20 [15072] [22] WARNING: SMPP[MTS]: Not ACKED message found, > will retransmit. SENT<64>sec. ago, SEQ<189768>, DST<9142294005> > 2015-12-13 09:43:44 [15072] [8] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:46:04 [15072] [10] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:47:06 [15072] [10] WARNING: SMPP[MTS]: Not ACKED message found, > will retransmit. SENT<62>sec. ago, SEQ<189281>, DST<9142294005> > 2015-12-13 09:48:10 [15072] [16] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:49:17 [15072] [16] WARNING: SMPP[MTS]: Not ACKED message found, > will retransmit. SENT<67>sec. ago, SEQ<189655>, DST<9142294005> > 2015-12-13 09:51:18 [15072] [8] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:52:36 [15072] [8] WARNING: SMPP[MTS]: Not ACKED message found, > will retransmit. SENT<78>sec. ago, SEQ<188844>, DST<9142294005> > 2015-12-13 09:53:42 [15072] [20] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:56:09 [15072] [6] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:57:13 [15072] [6] WARNING: SMPP[MTS]: Not ACKED message found, > will retransmit. SENT<64>sec. ago, SEQ<189816>, DST<9142294005> > 2015-12-13 09:58:14 [15072] [8] DEBUG: destination_addr: "9142294005" > 2015-12-13 09:59:15 [15072] [8] WARNING: SMPP[MTS]: Not ACKED message found, > will retransmit. SENT<61>sec. ago, SEQ<189177>, DST<9142294005> > 2015-12-13 10:01:47 [15072] [20] DEBUG: destination_addr: "9142294005" > 2015-12-13 10:04:14 [15072] [20] DEBUG: destination_addr: "9142294005" > 2015-12-13 10:05:23 [15072] [20] WARNING: SMPP[MTS]: Not ACKED message found, > will retransmit. SENT<69>sec. ago, SEQ<189456>, DST<9142294005> > 2015-12-13 10:08:14 [15072] [12] DEBUG: destination_addr: "9142294005" > 2015-12-13 10:09:20 [15072] [12] WARNING: SMPP[MTS]: Not ACKED message found, > will retransmit. SENT<66>sec. ago, SEQ<190251>, DST<9142294005> > > Configuration is as follows: > > group = core > admin-port = 13010 > smsbox-port = 13012 > log-file = "/u03/kannel/logs/bearerbox.log" > box-allow-ip = "10.130.252.160,127.0.0.1" > access-log = "/u03/kannel/logs/bearerbox_access.log" > dlr-storage = internal > > ##TX-1## > group = smsc > smsc-id ="MT" > smsc = smpp > host =10.10.22.10 > port = 5016 > system-type = "INAPPS" > interface-version = 34 > receive-port =0 > source-addr-ton = 1 > source-addr-npi = 1 > dest-addr-ton = 1 > dest-addr-npi = 1 > keepalive = 30 > log-level =0 > throughput = 50 > max-pending-submits=50 > reconnect-delay = 60 > reroute = true > log-file = "/u03/kannel/logs/smsc_conn.log" > > > ##RX-1 > group = smsc > smsc-id ="MTS" > smsc = smpp > host =10.10.22.10 > port = 0 > system-type = "INAPPS" > receive-port =5016 > interface-version = 34 > source-addr-ton = 1 > source-addr-npi = 1 > dest-addr-ton = 1 > dest-addr-npi = 1 > keepalive = 30 > log-level =0 > reconnect-delay = 60 > reroute = true > log-file = "/u03/kannel/logs/smsc_conn.log" > > group = smsbox > bearerbox-host = 127.0.0.1 > sendsms-port = 13013 > global-sender = YD-MTS > log-file = "/u03/kannel/logs/smsbox.log" > log-level = 0 > > #SMSBOX ROUTING > group = smsbox-route > smsbox-id = smsbox > smsc-id ="MT" > > group = sendsms-user > username = smsg > password = smsg@123 > default-smsc=&q
Re: Messages not being delivered - Not ACKED message found, will retransmit.
bumping this to dev On Fri, Nov 7, 2014 at 7:15 PM, Eric Magutu emag...@gmail.com wrote: The telco says he is getting missed enquiry link On Fri, Nov 7, 2014 at 4:30 PM, Eric Magutu emag...@gmail.com wrote: Hi, here is an extract from the logs. 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: time to sleep 30.00 secs. 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x866f3c0 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x86691f0 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x866ee08 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x8666ef8 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x8621140 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x866ed38 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x8673f58 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x8669300 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x866f3c0 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: clear_old_concat_parts called 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP[dd-jm-test]: throughput (0.00,10.00) 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU dump ends. 2014-11-06 14:39:45 [22646] [13] DEBUG: sequence_number: 2 = 0x0002 2014-11-06 14:39:45 [22646] [13] DEBUG: command_status: 0 = 0x 2014-11-06 14:39:45 [22646] [13] DEBUG: command_id: 2147483669 = 0x8015 2014-11-06 14:39:45 [22646] [13] DEBUG: type_name: enquire_link_resp 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU 0xb3e0e7d0 dump: 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP[dd-jm-test]: Sending PDU: 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU dump ends. 2014-11-06 14:39:45 [22646] [13] DEBUG: sequence_number: 2 = 0x0002 2014-11-06 14:39:45 [22646] [13] DEBUG: command_status: 0 = 0x 2014-11-06 14:39:45 [22646] [13] DEBUG: command_id: 21 = 0x0015 2014-11-06 14:39:45 [22646] [13] DEBUG: type_name: enquire_link 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU 0xb3e0edd8 dump: 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP[dd-jm-test]: Got PDU: 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP[dd-jm-test]: throughput (0.00,10.00) 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ426, DST +4545318 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ425, DST +9569818 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ424, DST +4322763 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ423, DST +4762896 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ422, DST +4366488 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ421, DST +4264317 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ420, DST +4366488 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ419, DST +4765807 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU dump ends. 2014-11-06 14:39:45 [22646] [13] DEBUG: sequence_number: 428 = 0x01ac 2014-11-06 14:39:45 [22646] [13] DEBUG: command_status: 0 = 0x 2014-11-06 14:39:45 [22646] [13] DEBUG: command_id: 21 = 0x0015 2014-11-06 14:39:45 [22646] [13] DEBUG: type_name: enquire_link 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU 0xb3e0fa80 dump: 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP[dd-jm-test]: Sending enquire link: On Thu, Nov 6, 2014 at 5:29 PM, Eric Magutu emag...@gmail.com wrote: I should mention some messages go through others don't. Will increase debugging level and revert. On Nov 6, 2014 5:19 PM, Tapan Kumar Thapa
Re: Messages not being delivered - Not ACKED message found, will retransmit.
Hi, here is an extract from the logs. 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: time to sleep 30.00 secs. 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x866f3c0 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x86691f0 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x866ee08 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x8666ef8 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x8621140 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x866ed38 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x8673f58 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x8669300 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x866f3c0 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: clear_old_concat_parts called 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP[dd-jm-test]: throughput (0.00,10.00) 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU dump ends. 2014-11-06 14:39:45 [22646] [13] DEBUG: sequence_number: 2 = 0x0002 2014-11-06 14:39:45 [22646] [13] DEBUG: command_status: 0 = 0x 2014-11-06 14:39:45 [22646] [13] DEBUG: command_id: 2147483669 = 0x8015 2014-11-06 14:39:45 [22646] [13] DEBUG: type_name: enquire_link_resp 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU 0xb3e0e7d0 dump: 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP[dd-jm-test]: Sending PDU: 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU dump ends. 2014-11-06 14:39:45 [22646] [13] DEBUG: sequence_number: 2 = 0x0002 2014-11-06 14:39:45 [22646] [13] DEBUG: command_status: 0 = 0x 2014-11-06 14:39:45 [22646] [13] DEBUG: command_id: 21 = 0x0015 2014-11-06 14:39:45 [22646] [13] DEBUG: type_name: enquire_link 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU 0xb3e0edd8 dump: 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP[dd-jm-test]: Got PDU: 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP[dd-jm-test]: throughput (0.00,10.00) 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ426, DST +4545318 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ425, DST +9569818 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ424, DST +4322763 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ423, DST +4762896 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ422, DST +4366488 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ421, DST +4264317 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ420, DST +4366488 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ419, DST +4765807 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU dump ends. 2014-11-06 14:39:45 [22646] [13] DEBUG: sequence_number: 428 = 0x01ac 2014-11-06 14:39:45 [22646] [13] DEBUG: command_status: 0 = 0x 2014-11-06 14:39:45 [22646] [13] DEBUG: command_id: 21 = 0x0015 2014-11-06 14:39:45 [22646] [13] DEBUG: type_name: enquire_link 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU 0xb3e0fa80 dump: 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP[dd-jm-test]: Sending enquire link: On Thu, Nov 6, 2014 at 5:29 PM, Eric Magutu emag...@gmail.com wrote: I should mention some messages go through others don't. Will increase debugging level and revert. On Nov 6, 2014 5:19 PM, Tapan Kumar Thapa tapan.thapa2...@gmail.com wrote: As suggested by other user as well, try enabling debug logs and see what is the issue. if unable to understand debug output than paste here. On Thu, Nov 6, 2014 at 7:47 PM, Eric Magutu emag...@gmail.com wrote: Yes On Nov 6, 2014 5:16 PM, Tapan Kumar Thapa
Re: Messages not being delivered - Not ACKED message found, will retransmit.
The telco says he is getting missed enquiry link On Fri, Nov 7, 2014 at 4:30 PM, Eric Magutu emag...@gmail.com wrote: Hi, here is an extract from the logs. 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: time to sleep 30.00 secs. 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x866f3c0 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x86691f0 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x866ee08 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x8666ef8 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x8621140 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x866ed38 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x8673f58 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x8669300 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: re-queing SMS not-yet-to-be resent 2014-11-06 14:39:45 [22646] [14] DEBUG: sms_router: handling message (0x866f3c0 vs 0x866f3c0) 2014-11-06 14:39:45 [22646] [14] DEBUG: clear_old_concat_parts called 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP[dd-jm-test]: throughput (0.00,10.00) 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU dump ends. 2014-11-06 14:39:45 [22646] [13] DEBUG: sequence_number: 2 = 0x0002 2014-11-06 14:39:45 [22646] [13] DEBUG: command_status: 0 = 0x 2014-11-06 14:39:45 [22646] [13] DEBUG: command_id: 2147483669 = 0x8015 2014-11-06 14:39:45 [22646] [13] DEBUG: type_name: enquire_link_resp 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU 0xb3e0e7d0 dump: 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP[dd-jm-test]: Sending PDU: 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU dump ends. 2014-11-06 14:39:45 [22646] [13] DEBUG: sequence_number: 2 = 0x0002 2014-11-06 14:39:45 [22646] [13] DEBUG: command_status: 0 = 0x 2014-11-06 14:39:45 [22646] [13] DEBUG: command_id: 21 = 0x0015 2014-11-06 14:39:45 [22646] [13] DEBUG: type_name: enquire_link 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU 0xb3e0edd8 dump: 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP[dd-jm-test]: Got PDU: 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP[dd-jm-test]: throughput (0.00,10.00) 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ426, DST +4545318 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ425, DST +9569818 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ424, DST +4322763 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ423, DST +4762896 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ422, DST +4366488 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ421, DST +4264317 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ420, DST +4366488 2014-11-06 14:39:45 [22646] [13] WARNING: SMPP[dd-jm-test]: Not ACKED message found, will retransmit. SENT120sec. ago, SEQ419, DST +4765807 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU dump ends. 2014-11-06 14:39:45 [22646] [13] DEBUG: sequence_number: 428 = 0x01ac 2014-11-06 14:39:45 [22646] [13] DEBUG: command_status: 0 = 0x 2014-11-06 14:39:45 [22646] [13] DEBUG: command_id: 21 = 0x0015 2014-11-06 14:39:45 [22646] [13] DEBUG: type_name: enquire_link 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP PDU 0xb3e0fa80 dump: 2014-11-06 14:39:45 [22646] [13] DEBUG: SMPP[dd-jm-test]: Sending enquire link: On Thu, Nov 6, 2014 at 5:29 PM, Eric Magutu emag...@gmail.com wrote: I should mention some messages go through others don't. Will increase debugging level and revert. On Nov 6, 2014 5:19 PM, Tapan Kumar Thapa tapan.thapa2...@gmail.com wrote: As suggested by other user as well, try enabling debug
Messages not being delivered - Not ACKED message found, will retransmit.
Hi, I am running Kannel bearerbox version `1.4.4'. Build `Oct 12 2014 04:19:47', compiler `4.6.3'. System Linux, release 3.2.0-70-virtual, version #105-Ubuntu My messages are not being delivered and I am getting the following error Not ACKED message found, will retransmit. When I do a tcpdump (attached) I can see the a lot of TCP Retransmission messages from my service provider followed by SMPP Enquire_link, Unbind Can someone assist me to figure out what is going on? Does my Enquire_link interval have to match the service provider? https://www.dropbox.com/s/z1royw0rwyjfsdh/jm.pcap -- Regards, Eric Magutu jm.pcap Description: application/vnd.tcpdump.pcap
Re: Messages not being delivered - Not ACKED message found, will retransmit.
No sure..But Is your SMPP connection working fine? Please also post your kannel config. On Thu, Nov 6, 2014 at 7:00 PM, Eric Magutu emag...@gmail.com wrote: Hi, I am running Kannel bearerbox version `1.4.4'. Build `Oct 12 2014 04:19:47', compiler `4.6.3'. System Linux, release 3.2.0-70-virtual, version #105-Ubuntu My messages are not being delivered and I am getting the following error Not ACKED message found, will retransmit. When I do a tcpdump (attached) I can see the a lot of TCP Retransmission messages from my service provider followed by SMPP Enquire_link, Unbind Can someone assist me to figure out what is going on? Does my Enquire_link interval have to match the service provider? https://www.dropbox.com/s/z1royw0rwyjfsdh/jm.pcap -- Regards, Eric Magutu
Re: Messages not being delivered - Not ACKED message found, will retransmit.
Hi, Here is my config # # dd-JM TEST SMSC # group = smsc smsc = smpp smsc-id = dd-jm-test allowed-smsc-id = dd-jm-test host = 172.16.2.7 #host = 172.16.2.59 port = 4000 transceiver-mode = 1 source-addr-ton = 3 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 smsc-username = smsc-password = system-type = SMPP alt-charset = UTF-8 enquire-link-interval = 60 throughput = 10 # # dd JM smsbox DIY # group = smsbox smsbox-id = dd-jm-diy #bearerbox-host = 127.0.0.1 bearerbox-host = localhost log-file = /var/log/kannel/dd-jm-smsbox-diy.log sendsms-port = 6089 sendsms-chars = 0123456789 +- # # dd JM smsbox staging # group = smsbox smsbox-id = dd-jm-staging #bearerbox-host = 127.0.0.1 bearerbox-host = localhost log-file = /var/log/kannel/dd-jm-smsbox-staging.log sendsms-port = 6090 sendsms-chars = 0123456789 +- # # dd JM smsbox staging # group = smsbox smsbox-id = dd-jm-staging2 #bearerbox-host = 127.0.0.1 bearerbox-host = localhost log-file = /var/log/kannel/dd-jm-smsbox-staging2.log sendsms-port = 6091 sendsms-chars = 0123456789 +- # # dd JM smsbox-route staging 2 # group = smsbox-route smsbox-id = dd-jm-staging2 smsc-id = dd-jm-test shortcode = 164;+164 # # dd smsbox staging # group = smsbox smsbox-id = dd-staging #bearerbox-host = 127.0.0.1 bearerbox-host = localhost log-file = /var/log/kannel/dd-smsbox-staging.log sendsms-port = 6092 sendsms-chars = 0123456789 +- On Thu, Nov 6, 2014 at 4:39 PM, Tapan Kumar Thapa tapan.thapa2...@gmail.com wrote: No sure..But Is your SMPP connection working fine? Please also post your kannel config. On Thu, Nov 6, 2014 at 7:00 PM, Eric Magutu emag...@gmail.com wrote: Hi, I am running Kannel bearerbox version `1.4.4'. Build `Oct 12 2014 04:19:47', compiler `4.6.3'. System Linux, release 3.2.0-70-virtual, version #105-Ubuntu My messages are not being delivered and I am getting the following error Not ACKED message found, will retransmit. When I do a tcpdump (attached) I can see the a lot of TCP Retransmission messages from my service provider followed by SMPP Enquire_link, Unbind Can someone assist me to figure out what is going on? Does my Enquire_link interval have to match the service provider? https://www.dropbox.com/s/z1royw0rwyjfsdh/jm.pcap -- Regards, Eric Magutu -- Regards, Eric Magutu
Re: Messages not being delivered - Not ACKED message found, will retransmit.
In the admin interface of kannel, is smpp connection up? On Thu, Nov 6, 2014 at 7:26 PM, Eric Magutu emag...@gmail.com wrote: Hi, Here is my config # # dd-JM TEST SMSC # group = smsc smsc = smpp smsc-id = dd-jm-test allowed-smsc-id = dd-jm-test host = 172.16.2.7 #host = 172.16.2.59 port = 4000 transceiver-mode = 1 source-addr-ton = 3 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 smsc-username = smsc-password = system-type = SMPP alt-charset = UTF-8 enquire-link-interval = 60 throughput = 10 # # dd JM smsbox DIY # group = smsbox smsbox-id = dd-jm-diy #bearerbox-host = 127.0.0.1 bearerbox-host = localhost log-file = /var/log/kannel/dd-jm-smsbox-diy.log sendsms-port = 6089 sendsms-chars = 0123456789 +- # # dd JM smsbox staging # group = smsbox smsbox-id = dd-jm-staging #bearerbox-host = 127.0.0.1 bearerbox-host = localhost log-file = /var/log/kannel/dd-jm-smsbox-staging.log sendsms-port = 6090 sendsms-chars = 0123456789 +- # # dd JM smsbox staging # group = smsbox smsbox-id = dd-jm-staging2 #bearerbox-host = 127.0.0.1 bearerbox-host = localhost log-file = /var/log/kannel/dd-jm-smsbox-staging2.log sendsms-port = 6091 sendsms-chars = 0123456789 +- # # dd JM smsbox-route staging 2 # group = smsbox-route smsbox-id = dd-jm-staging2 smsc-id = dd-jm-test shortcode = 164;+164 # # dd smsbox staging # group = smsbox smsbox-id = dd-staging #bearerbox-host = 127.0.0.1 bearerbox-host = localhost log-file = /var/log/kannel/dd-smsbox-staging.log sendsms-port = 6092 sendsms-chars = 0123456789 +- On Thu, Nov 6, 2014 at 4:39 PM, Tapan Kumar Thapa tapan.thapa2...@gmail.com wrote: No sure..But Is your SMPP connection working fine? Please also post your kannel config. On Thu, Nov 6, 2014 at 7:00 PM, Eric Magutu emag...@gmail.com wrote: Hi, I am running Kannel bearerbox version `1.4.4'. Build `Oct 12 2014 04:19:47', compiler `4.6.3'. System Linux, release 3.2.0-70-virtual, version #105-Ubuntu My messages are not being delivered and I am getting the following error Not ACKED message found, will retransmit. When I do a tcpdump (attached) I can see the a lot of TCP Retransmission messages from my service provider followed by SMPP Enquire_link, Unbind Can someone assist me to figure out what is going on? Does my Enquire_link interval have to match the service provider? https://www.dropbox.com/s/z1royw0rwyjfsdh/jm.pcap -- Regards, Eric Magutu -- Regards, Eric Magutu
RE: Messages not being delivered - Not ACKED message found, will retransmit.
Turn the smsc log on with level 0 is easier for trouble shouting. Anway, try source-addr-ton = 0, perhaps your up stream doesn't not allow other values. ::Lamnt. From: emag...@gmail.com Date: Thu, 6 Nov 2014 16:56:34 +0300 Subject: Re: Messages not being delivered - Not ACKED message found, will retransmit. To: tapan.thapa2...@gmail.com CC: users@kannel.org Hi,Here is my config ## dd-JM TEST SMSC# group = smscsmsc = smppsmsc-id = dd-jm-testallowed-smsc-id = dd-jm-testhost = 172.16.2.7 #host = 172.16.2.59 port = 4000transceiver-mode = 1source-addr-ton = 3source-addr-npi = 1dest-addr-ton = 1dest-addr-npi = 1smsc-username = smsc-password = system-type = SMPPalt-charset = UTF-8enquire-link-interval = 60throughput = 10## dd JM smsbox DIY# group = smsboxsmsbox-id = dd-jm-diy#bearerbox-host = 127.0.0.1bearerbox-host = localhostlog-file = /var/log/kannel/dd-jm-smsbox-diy.logsendsms-port = 6089sendsms-chars = 0123456789 +- ## dd JM smsbox staging# group = smsboxsmsbox-id = dd-jm-staging#bearerbox-host = 127.0.0.1bearerbox-host = localhostlog-file = /var/log/kannel/dd-jm-smsbox-staging.logsendsms-port = 6090sendsms-chars = 0123456789 +- ## dd JM smsbox staging# group = smsboxsmsbox-id = dd-jm-staging2#bearerbox-host = 127.0.0.1bearerbox-host = localhostlog-file = /var/log/kannel/dd-jm-smsbox-staging2.logsendsms-port = 6091sendsms-chars = 0123456789 +- ## dd JM smsbox-route staging 2# group = smsbox-routesmsbox-id = dd-jm-staging2smsc-id = dd-jm-testshortcode = 164;+164 ## dd smsbox staging# group = smsboxsmsbox-id = dd-staging#bearerbox-host = 127.0.0.1bearerbox-host = localhostlog-file = /var/log/kannel/dd-smsbox-staging.logsendsms-port = 6092sendsms-chars = 0123456789 +- On Thu, Nov 6, 2014 at 4:39 PM, Tapan Kumar Thapa tapan.thapa2...@gmail.com wrote: No sure..But Is your SMPP connection working fine? Please also post your kannel config. On Thu, Nov 6, 2014 at 7:00 PM, Eric Magutu emag...@gmail.com wrote: Hi,I am running Kannel bearerbox version `1.4.4'. Build `Oct 12 2014 04:19:47', compiler `4.6.3'. System Linux, release 3.2.0-70-virtual, version #105-Ubuntu My messages are not being delivered and I am getting the following error Not ACKED message found, will retransmit. When I do a tcpdump (attached) I can see the a lot of TCP Retransmission messages from my service provider followed by SMPP Enquire_link, Unbind Can someone assist me to figure out what is going on? Does my Enquire_link interval have to match the service provider? https://www.dropbox.com/s/z1royw0rwyjfsdh/jm.pcap -- Regards, Eric Magutu -- Regards, Eric Magutu
Re: Messages not being delivered - Not ACKED message found, will retransmit.
As suggested by other user as well, try enabling debug logs and see what is the issue. if unable to understand debug output than paste here. On Thu, Nov 6, 2014 at 7:47 PM, Eric Magutu emag...@gmail.com wrote: Yes On Nov 6, 2014 5:16 PM, Tapan Kumar Thapa tapan.thapa2...@gmail.com wrote: In the admin interface of kannel, is smpp connection up? On Thu, Nov 6, 2014 at 7:26 PM, Eric Magutu emag...@gmail.com wrote: Hi, Here is my config # # dd-JM TEST SMSC # group = smsc smsc = smpp smsc-id = dd-jm-test allowed-smsc-id = dd-jm-test host = 172.16.2.7 #host = 172.16.2.59 port = 4000 transceiver-mode = 1 source-addr-ton = 3 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 smsc-username = smsc-password = system-type = SMPP alt-charset = UTF-8 enquire-link-interval = 60 throughput = 10 # # dd JM smsbox DIY # group = smsbox smsbox-id = dd-jm-diy #bearerbox-host = 127.0.0.1 bearerbox-host = localhost log-file = /var/log/kannel/dd-jm-smsbox-diy.log sendsms-port = 6089 sendsms-chars = 0123456789 +- # # dd JM smsbox staging # group = smsbox smsbox-id = dd-jm-staging #bearerbox-host = 127.0.0.1 bearerbox-host = localhost log-file = /var/log/kannel/dd-jm-smsbox-staging.log sendsms-port = 6090 sendsms-chars = 0123456789 +- # # dd JM smsbox staging # group = smsbox smsbox-id = dd-jm-staging2 #bearerbox-host = 127.0.0.1 bearerbox-host = localhost log-file = /var/log/kannel/dd-jm-smsbox-staging2.log sendsms-port = 6091 sendsms-chars = 0123456789 +- # # dd JM smsbox-route staging 2 # group = smsbox-route smsbox-id = dd-jm-staging2 smsc-id = dd-jm-test shortcode = 164;+164 # # dd smsbox staging # group = smsbox smsbox-id = dd-staging #bearerbox-host = 127.0.0.1 bearerbox-host = localhost log-file = /var/log/kannel/dd-smsbox-staging.log sendsms-port = 6092 sendsms-chars = 0123456789 +- On Thu, Nov 6, 2014 at 4:39 PM, Tapan Kumar Thapa tapan.thapa2...@gmail.com wrote: No sure..But Is your SMPP connection working fine? Please also post your kannel config. On Thu, Nov 6, 2014 at 7:00 PM, Eric Magutu emag...@gmail.com wrote: Hi, I am running Kannel bearerbox version `1.4.4'. Build `Oct 12 2014 04:19:47', compiler `4.6.3'. System Linux, release 3.2.0-70-virtual, version #105-Ubuntu My messages are not being delivered and I am getting the following error Not ACKED message found, will retransmit. When I do a tcpdump (attached) I can see the a lot of TCP Retransmission messages from my service provider followed by SMPP Enquire_link, Unbind Can someone assist me to figure out what is going on? Does my Enquire_link interval have to match the service provider? https://www.dropbox.com/s/z1royw0rwyjfsdh/jm.pcap -- Regards, Eric Magutu -- Regards, Eric Magutu
Re: Messages not being delivered - Not ACKED message found, will retransmit.
I should mention some messages go through others don't. Will increase debugging level and revert. On Nov 6, 2014 5:19 PM, Tapan Kumar Thapa tapan.thapa2...@gmail.com wrote: As suggested by other user as well, try enabling debug logs and see what is the issue. if unable to understand debug output than paste here. On Thu, Nov 6, 2014 at 7:47 PM, Eric Magutu emag...@gmail.com wrote: Yes On Nov 6, 2014 5:16 PM, Tapan Kumar Thapa tapan.thapa2...@gmail.com wrote: In the admin interface of kannel, is smpp connection up? On Thu, Nov 6, 2014 at 7:26 PM, Eric Magutu emag...@gmail.com wrote: Hi, Here is my config # # dd-JM TEST SMSC # group = smsc smsc = smpp smsc-id = dd-jm-test allowed-smsc-id = dd-jm-test host = 172.16.2.7 #host = 172.16.2.59 port = 4000 transceiver-mode = 1 source-addr-ton = 3 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 smsc-username = smsc-password = system-type = SMPP alt-charset = UTF-8 enquire-link-interval = 60 throughput = 10 # # dd JM smsbox DIY # group = smsbox smsbox-id = dd-jm-diy #bearerbox-host = 127.0.0.1 bearerbox-host = localhost log-file = /var/log/kannel/dd-jm-smsbox-diy.log sendsms-port = 6089 sendsms-chars = 0123456789 +- # # dd JM smsbox staging # group = smsbox smsbox-id = dd-jm-staging #bearerbox-host = 127.0.0.1 bearerbox-host = localhost log-file = /var/log/kannel/dd-jm-smsbox-staging.log sendsms-port = 6090 sendsms-chars = 0123456789 +- # # dd JM smsbox staging # group = smsbox smsbox-id = dd-jm-staging2 #bearerbox-host = 127.0.0.1 bearerbox-host = localhost log-file = /var/log/kannel/dd-jm-smsbox-staging2.log sendsms-port = 6091 sendsms-chars = 0123456789 +- # # dd JM smsbox-route staging 2 # group = smsbox-route smsbox-id = dd-jm-staging2 smsc-id = dd-jm-test shortcode = 164;+164 # # dd smsbox staging # group = smsbox smsbox-id = dd-staging #bearerbox-host = 127.0.0.1 bearerbox-host = localhost log-file = /var/log/kannel/dd-smsbox-staging.log sendsms-port = 6092 sendsms-chars = 0123456789 +- On Thu, Nov 6, 2014 at 4:39 PM, Tapan Kumar Thapa tapan.thapa2...@gmail.com wrote: No sure..But Is your SMPP connection working fine? Please also post your kannel config. On Thu, Nov 6, 2014 at 7:00 PM, Eric Magutu emag...@gmail.com wrote: Hi, I am running Kannel bearerbox version `1.4.4'. Build `Oct 12 2014 04:19:47', compiler `4.6.3'. System Linux, release 3.2.0-70-virtual, version #105-Ubuntu My messages are not being delivered and I am getting the following error Not ACKED message found, will retransmit. When I do a tcpdump (attached) I can see the a lot of TCP Retransmission messages from my service provider followed by SMPP Enquire_link, Unbind Can someone assist me to figure out what is going on? Does my Enquire_link interval have to match the service provider? https://www.dropbox.com/s/z1royw0rwyjfsdh/jm.pcap -- Regards, Eric Magutu -- Regards, Eric Magutu
Re: Not ACKED message found, will retransmit
Dears Falko, Nikos, Thanks for your kind help, my configuration was like that: group = smsc smsc = smpp smsc-id = MOCONN host = xxx.xxx.xxx.xxx port = 0 receive-port = 8000 smsc-username = X smsc-password = XXX system-type = allowed-smsc-id = MOCONN interface-version = 34 address-range = reconnect-delay = 10 source-addr-ton = 1 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 bind-addr-ton = 1 bind-addr-npi = 1 msg-id-type = 0x01 log-file = /var/log/mo.log group = smsc smsc = smpp smsc-id = MTCONN host = xxx.xxx.xxx.xxx port = 8000 receive-port = 0 smsc-username = X smsc-password = XXX system-type = allowed-smsc-id = MTCONN interface-version = 34 address-range = reconnect-delay = 10 source-addr-ton = 1 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 bind-addr-ton = 1 bind-addr-npi = 1 msg-id-type = 0x01 log-file = /var/log/mt.log after that I make the transmitter and receiver in one SMSC group like that smsc = smpp smsc-id = MYCONN host = xxx.xxx.xxx.xxx port = 8000 receive-port = 8000 smsc-username = X smsc-password = XXX keepalive = 10 enquire-link-interval = 10 system-type = allowed-smsc-id = MYCONN interface-version = 34 address-range = reconnect-delay = 10 source-addr-ton = 5 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 bind-addr-ton = 1 bind-addr-npi = 1 msg-id-type = 0x01 log-file = /var/log/conn.log but I still get the error in the logs until I changed the source-addr-npi = 1 to be source-addr-npi = 5. by the way is there different if I configure the transmitter and receiver in one SMSC group or 2 SMSC group? Thanks for help. Regards, Hafez On Tue, Mar 10, 2009 at 1:32 AM, Falko Ziemann fal...@gmail.com wrote: By the way, I just realised: transmitter and receiver? Are you using SMPP 3.3 instead of 3.4? Have you configured the receiver and transmitter in the same SMSC group?Normal SMPP 3.4 shouldn't have transmitter and receiver but only one transceiver. If you use 3.3 with divided transmitter and receiver connection, you need to configure both inside the same smsc-group, otherwise kannel cannot associate the ACK. (Well, no smsc I have seen so far could do this...) Falko Am 10.03.2009 um 00:26 schrieb Falko Ziemann: I just saw this behavior once before. There a service provider routed the ACK to another large account. So I send the message on MYMTCONN1 and received the ACK on MYMTCONN2. That's not the case, or? I can't see it from the log, the first line where kannel states the connection name is missing. But I really don't have a idea what this problem should have to do with keep alives. Are you loosing the connection between the submit and the ACK? Falko Am 09.03.2009 um 21:13 schrieb Nikos Balkanas: Well, there is an enquire-link-interval which you could tweak. It defaults to 30. BR, Nikos - Original Message - *From:* hafez ahmad hafezad...@gmail.com *To:* Falko Ziemann fal...@gmail.com *Cc:* users@kannel.org *Sent:* Monday, March 09, 2009 3:43 PM *Subject:* Re: Not ACKED message found, will retransmit Dears, I still have the same problem, Any Ideas? , by they my operator advice me that * * *use “ESME_QRYLINK” on both transmitter and receiver to keep the connection live* may be that related to this error . Please advice. Regards, Hafez On Thu, Mar 5, 2009 at 4:17 PM, Falko Ziemann fal...@gmail.com wrote: Hmm, sorry, no idea. Seems like kannel forgets about the ack... A hotfix would be to set wait-ack-expire = 0x02 in the smsc group. That would make kannel waiting forever for the ACK and never retry. Very dirty hack, but should do the job until someone comes around with a better solution... Regards Falko Am 05.03.2009 um 13:37 schrieb hafez ahmad: Sorry, thats the correct 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU 0xa732ad00 dump: 2009-03-03 21:00:16 [2825] [14] DEBUG: type_name: submit_sm 2009-03-03 21:00:16 [2825] [14] DEBUG: command_id: 4 = 0x0004 2009-03-03 21:00:16 [2825] [14] DEBUG: command_status: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sequence_number: 3684 = 0x0e64 2009-03-03 21:00:16 [2825] [14] DEBUG: service_type: V 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr_ton: 5 = 0x0005 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr_npi: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr: T2ME 2009-03-03 21:00:16 [2825] [14] DEBUG: dest_addr_ton: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: dest_addr_npi: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: destination_addr: 2009-03-03 21:00:16 [2825] [14] DEBUG: esm_class: 67 = 0x0043 2009-03-03 21:00:16 [2825] [14] DEBUG: protocol_id: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: priority_flag: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: schedule_delivery_time: NULL 2009-03-03 21:00:16 [2825] [14] DEBUG: validity_period: NULL 2009-03-03
Re: Not ACKED message found, will retransmit
Hi, try to delete the receive-port from the config and set: transceiver-mode = on I'm not sure how kannel handles the notification problem. The MT gets send on the MTCONN while the DLR arrives on the MOCONN. I don't know if kannel can assign the DLR to message when they arrive in two diffrent SMSCs, but I don't think that this works. Maybe the same problem with ACKs ?! Regards Falko Am 10.03.2009 um 10:00 schrieb hafez ahmad: Dears Falko, Nikos, Thanks for your kind help, my configuration was like that: group = smsc smsc = smpp smsc-id = MOCONN host = xxx.xxx.xxx.xxx port = 0 receive-port = 8000 smsc-username = X smsc-password = XXX system-type = allowed-smsc-id = MOCONN interface-version = 34 address-range = reconnect-delay = 10 source-addr-ton = 1 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 bind-addr-ton = 1 bind-addr-npi = 1 msg-id-type = 0x01 log-file = /var/log/mo.log group = smsc smsc = smpp smsc-id = MTCONN host = xxx.xxx.xxx.xxx port = 8000 receive-port = 0 smsc-username = X smsc-password = XXX system-type = allowed-smsc-id = MTCONN interface-version = 34 address-range = reconnect-delay = 10 source-addr-ton = 1 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 bind-addr-ton = 1 bind-addr-npi = 1 msg-id-type = 0x01 log-file = /var/log/mt.log after that I make the transmitter and receiver in one SMSC group like that smsc = smpp smsc-id = MYCONN host = xxx.xxx.xxx.xxx port = 8000 receive-port = 8000 smsc-username = X smsc-password = XXX keepalive = 10 enquire-link-interval = 10 system-type = allowed-smsc-id = MYCONN interface-version = 34 address-range = reconnect-delay = 10 source-addr-ton = 5 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 bind-addr-ton = 1 bind-addr-npi = 1 msg-id-type = 0x01 log-file = /var/log/conn.log but I still get the error in the logs until I changed the source- addr-npi = 1 to be source-addr-npi = 5. by the way is there different if I configure the transmitter and receiver in one SMSC group or 2 SMSC group? Thanks for help. Regards, Hafez On Tue, Mar 10, 2009 at 1:32 AM, Falko Ziemann fal...@gmail.com wrote: By the way, I just realised: transmitter and receiver? Are you using SMPP 3.3 instead of 3.4? Have you configured the receiver and transmitter in the same SMSC group? Normal SMPP 3.4 shouldn't have transmitter and receiver but only one transceiver. If you use 3.3 with divided transmitter and receiver connection, you need to configure both inside the same smsc-group, otherwise kannel cannot associate the ACK. (Well, no smsc I have seen so far could do this...) Falko Am 10.03.2009 um 00:26 schrieb Falko Ziemann: I just saw this behavior once before. There a service provider routed the ACK to another large account. So I send the message on MYMTCONN1 and received the ACK on MYMTCONN2. That's not the case, or? I can't see it from the log, the first line where kannel states the connection name is missing. But I really don't have a idea what this problem should have to do with keep alives. Are you loosing the connection between the submit and the ACK? Falko Am 09.03.2009 um 21:13 schrieb Nikos Balkanas: Well, there is an enquire-link-interval which you could tweak. It defaults to 30. BR, Nikos - Original Message - From: hafez ahmad To: Falko Ziemann Cc: users@kannel.org Sent: Monday, March 09, 2009 3:43 PM Subject: Re: Not ACKED message found, will retransmit Dears, I still have the same problem, Any Ideas? , by they my operator advice me that use “ESME_QRYLINK” on both transmitter and receiver to keep the connection live may be that related to this error . Please advice. Regards, Hafez On Thu, Mar 5, 2009 at 4:17 PM, Falko Ziemann fal...@gmail.com wrote: Hmm, sorry, no idea. Seems like kannel forgets about the ack... A hotfix would be to set wait-ack-expire = 0x02 in the smsc group. That would make kannel waiting forever for the ACK and never retry. Very dirty hack, but should do the job until someone comes around with a better solution... Regards Falko Am 05.03.2009 um 13:37 schrieb hafez ahmad: Sorry, thats the correct 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU 0xa732ad00 dump: 2009-03-03 21:00:16 [2825] [14] DEBUG: type_name: submit_sm 2009-03-03 21:00:16 [2825] [14] DEBUG: command_id: 4 = 0x0004 2009-03-03 21:00:16 [2825] [14] DEBUG: command_status: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sequence_number: 3684 = 0x0e64 2009-03-03 21:00:16 [2825] [14] DEBUG: service_type: V 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr_ton: 5 = 0x0005 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr_npi: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr: T2ME 2009-03-03 21:00:16 [2825] [14] DEBUG: dest_addr_ton: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: dest_addr_npi: 1 = 0x0001 2009-03-03 21:00:16 [2825
Re: Not ACKED message found, will retransmit
Hi, try to delete the receive-port from the config and set: transceiver-mode = on I tried before but my operator disable the transceiver mode from his side. I'm not sure how kannel handles the notification problem. The MT gets send on the MTCONN while the DLR arrives on the MOCONN. I don't know if kannel can assign the DLR to message when they arrive in two diffrent SMSCs, but I don't think that this works. Maybe the same problem with ACKs ?! for the DLR that send using MT and received with another MO, I have it before and I solved it using the DLR group id batch, now every thing works fine, but I will monitor and update the list. Regards and many thanks for help. Hafez Am 10.03.2009 um 10:00 schrieb hafez ahmad: Dears Falko, Nikos, Thanks for your kind help, my configuration was like that: group = smsc smsc = smpp smsc-id = MOCONN host = xxx.xxx.xxx.xxx port = 0 receive-port = 8000 smsc-username = X smsc-password = XXX system-type = allowed-smsc-id = MOCONN interface-version = 34 address-range = reconnect-delay = 10 source-addr-ton = 1 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 bind-addr-ton = 1 bind-addr-npi = 1 msg-id-type = 0x01 log-file = /var/log/mo.log group = smsc smsc = smpp smsc-id = MTCONN host = xxx.xxx.xxx.xxx port = 8000 receive-port = 0 smsc-username = X smsc-password = XXX system-type = allowed-smsc-id = MTCONN interface-version = 34 address-range = reconnect-delay = 10 source-addr-ton = 1 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 bind-addr-ton = 1 bind-addr-npi = 1 msg-id-type = 0x01 log-file = /var/log/mt.log after that I make the transmitter and receiver in one SMSC group like that smsc = smpp smsc-id = MYCONN host = xxx.xxx.xxx.xxx port = 8000 receive-port = 8000 smsc-username = X smsc-password = XXX keepalive = 10 enquire-link-interval = 10 system-type = allowed-smsc-id = MYCONN interface-version = 34 address-range = reconnect-delay = 10 source-addr-ton = 5 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 bind-addr-ton = 1 bind-addr-npi = 1 msg-id-type = 0x01 log-file = /var/log/conn.log but I still get the error in the logs until I changed the source-addr-npi = 1 to be source-addr-npi = 5. by the way is there different if I configure the transmitter and receiver in one SMSC group or 2 SMSC group? Thanks for help. Regards, Hafez On Tue, Mar 10, 2009 at 1:32 AM, Falko Ziemann fal...@gmail.com wrote: By the way, I just realised: transmitter and receiver? Are you using SMPP 3.3 instead of 3.4? Have you configured the receiver and transmitter in the same SMSC group? Normal SMPP 3.4 shouldn't have transmitter and receiver but only one transceiver. If you use 3.3 with divided transmitter and receiver connection, you need to configure both inside the same smsc-group, otherwise kannel cannot associate the ACK. (Well, no smsc I have seen so far could do this...) Falko Am 10.03.2009 um 00:26 schrieb Falko Ziemann: I just saw this behavior once before. There a service provider routed the ACK to another large account. So I send the message on MYMTCONN1 and received the ACK on MYMTCONN2. That's not the case, or? I can't see it from the log, the first line where kannel states the connection name is missing. But I really don't have a idea what this problem should have to do with keep alives. Are you loosing the connection between the submit and the ACK? Falko Am 09.03.2009 um 21:13 schrieb Nikos Balkanas: Well, there is an enquire-link-interval which you could tweak. It defaults to 30. BR, Nikos - Original Message - *From:* hafez ahmad hafezad...@gmail.com *To:* Falko Ziemann fal...@gmail.com *Cc:* users@kannel.org *Sent:* Monday, March 09, 2009 3:43 PM *Subject:* Re: Not ACKED message found, will retransmit Dears, I still have the same problem, Any Ideas? , by they my operator advice me that * * *use “ESME_QRYLINK” on both transmitter and receiver to keep the connection live* may be that related to this error . Please advice. Regards, Hafez On Thu, Mar 5, 2009 at 4:17 PM, Falko Ziemann fal...@gmail.com wrote: Hmm, sorry, no idea. Seems like kannel forgets about the ack... A hotfix would be to set wait-ack-expire = 0x02 in the smsc group. That would make kannel waiting forever for the ACK and never retry. Very dirty hack, but should do the job until someone comes around with a better solution... Regards Falko Am 05.03.2009 um 13:37 schrieb hafez ahmad: Sorry, thats the correct 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU 0xa732ad00 dump: 2009-03-03 21:00:16 [2825] [14] DEBUG: type_name: submit_sm 2009-03-03 21:00:16 [2825] [14] DEBUG: command_id: 4 = 0x0004 2009-03-03 21:00:16 [2825] [14] DEBUG: command_status: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sequence_number: 3684 = 0x0e64 2009-03-03 21:00
Re: Not ACKED message found, will retransmit
Hello ppl, I just detected similar issue: 2009-03-10 12:37:02 [23769] [10] WARNING: SMPP[sir]: Not ACKED message found, will retransmit. SENT96sec. ago, SEQ20582, DST+359888deleteddigitshere I can confirm the issue is at the SMSC side, because the issue apeared after migration to a new SMPP proxy/loadbalancer the telco has implemented. Hope to save some time of yours with this info. cheers hafez ahmad wrote: Hi, try to delete the receive-port from the config and set: transceiver-mode = on I tried before but my operator disable the transceiver mode from his side. I'm not sure how kannel handles the notification problem. The MT gets send on the MTCONN while the DLR arrives on the MOCONN. I don't know if kannel can assign the DLR to message when they arrive in two diffrent SMSCs, but I don't think that this works. Maybe the same problem with ACKs ?! for the DLR that send using MT and received with another MO, I have it before and I solved it using the DLR group id batch, now every thing works fine, but I will monitor and update the list. Regards and many thanks for help. Hafez Am 10.03.2009 um 10:00 schrieb hafez ahmad: Dears Falko, Nikos, Thanks for your kind help, my configuration was like that: group = smsc smsc = smpp smsc-id = MOCONN host = xxx.xxx.xxx.xxx port = 0 receive-port = 8000 smsc-username = X smsc-password = XXX system-type = allowed-smsc-id = MOCONN interface-version = 34 address-range = reconnect-delay = 10 source-addr-ton = 1 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 bind-addr-ton = 1 bind-addr-npi = 1 msg-id-type = 0x01 log-file = /var/log/mo.log group = smsc smsc = smpp smsc-id = MTCONN host = xxx.xxx.xxx.xxx port = 8000 receive-port = 0 smsc-username = X smsc-password = XXX system-type = allowed-smsc-id = MTCONN interface-version = 34 address-range = reconnect-delay = 10 source-addr-ton = 1 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 bind-addr-ton = 1 bind-addr-npi = 1 msg-id-type = 0x01 log-file = /var/log/mt.log after that I make the transmitter and receiver in one SMSC group like that smsc = smpp smsc-id = MYCONN host = xxx.xxx.xxx.xxx port = 8000 receive-port = 8000 smsc-username = X smsc-password = XXX keepalive = 10 enquire-link-interval = 10 system-type = allowed-smsc-id = MYCONN interface-version = 34 address-range = reconnect-delay = 10 source-addr-ton = 5 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 bind-addr-ton = 1 bind-addr-npi = 1 msg-id-type = 0x01 log-file = /var/log/conn.log but I still get the error in the logs until I changed the source-addr-npi = 1 to be source-addr-npi = 5. by the way is there different if I configure the transmitter and receiver in one SMSC group or 2 SMSC group? Thanks for help. Regards, Hafez On Tue, Mar 10, 2009 at 1:32 AM, Falko Ziemann fal...@gmail.com wrote: By the way, I just realised: transmitter and receiver? Are you using SMPP 3.3 instead of 3.4? Have you configured the receiver and transmitter in the same SMSC group? Normal SMPP 3.4 shouldn't have transmitter and receiver but only one transceiver. If you use 3.3 with divided transmitter and receiver connection, you need to configure both inside the same smsc-group, otherwise kannel cannot associate the ACK. (Well, no smsc I have seen so far could do this...) Falko Am 10.03.2009 um 00:26 schrieb Falko Ziemann: I just saw this behavior once before. There a service provider routed the ACK to another large account. So I send the message on MYMTCONN1 and received the ACK on MYMTCONN2. That's not the case, or? I can't see it from the log, the first line where kannel states the connection name is missing. But I really don't have a idea what this problem should have to do with keep alives. Are you loosing the connection between the submit and the ACK? Falko Am 09.03.2009 um 21:13 schrieb Nikos Balkanas: Well, there is an enquire-link-interval which you could tweak. It defaults to 30. BR, Nikos - Original Message - *From:* hafez ahmad hafezad...@gmail.com *To:* Falko Ziemann fal...@gmail.com *Cc:* users@kannel.org *Sent:* Monday, March 09, 2009 3:43 PM *Subject:* Re: Not ACKED message found, will retransmit Dears, I still have the same problem, Any Ideas? , by they my operator advice me that * * *use “ESME_QRYLINK” on both transmitter and receiver to keep the connection live* may be that related to this error . Please advice. Regards, Hafez On Thu, Mar 5, 2009 at 4:17 PM, Falko Ziemann fal...@gmail.com wrote: Hmm, sorry, no idea. Seems like kannel forgets about the ack... A hotfix would be to set wait-ack-expire = 0x02 in the smsc group. That would make kannel waiting forever for the ACK and never retry. Very dirty hack, but should do the job until someone comes around with a better solution... Regards Falko Am 05.03.2009 um 13:37 schrieb hafez ahmad: Sorry, thats the correct 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU 0xa732ad00 dump
Re: Not ACKED message found, will retransmit
: type_name: submit_sm 2009-03-03 21:00:16 [2825] [14] DEBUG: command_id: 4 = 0x0004 2009-03-03 21:00:16 [2825] [14] DEBUG: command_status: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sequence_number: 3684 = 0x0e64 2009-03-03 21:00:16 [2825] [14] DEBUG: service_type: V 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr_ton: 5 = 0x0005 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr_npi: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr: T2ME 2009-03-03 21:00:16 [2825] [14] DEBUG: dest_addr_ton: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: dest_addr_npi: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: destination_addr: 2009-03-03 21:00:16 [2825] [14] DEBUG: esm_class: 67 = 0x0043 2009-03-03 21:00:16 [2825] [14] DEBUG: protocol_id: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: priority_flag: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: schedule_delivery_time: NULL 2009-03-03 21:00:16 [2825] [14] DEBUG: validity_period: NULL 2009-03-03 21:00:16 [2825] [14] DEBUG: registered_delivery: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: replace_if_present_flag: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: data_coding: 8 = 0x0008 2009-03-03 21:00:16 [2825] [14] DEBUG: sm_default_msg_id: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sm_length: 140 = 0x008c 2009-03-03 21:00:16 [2825] [14] DEBUG: short_message: 2009-03-03 21:00:16 [2825] [14] DEBUG:Octet string at 0xa732af00: 2009-03-03 21:00:16 [2825] [14] DEBUG: len: 140 2009-03-03 21:00:16 [2825] [14] DEBUG: size: 1024 2009-03-03 21:00:16 [2825] [14] DEBUG: immutable: 0 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 05 00 03 83 04 01 06 23 06 47 06 45 00 20 06 48 ...#.G.E. .H 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 35 06 41 06 27 06 2a 00 20 06 4a 06 48 06 33 .5.A.'.*. .J.H.3 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 41 00 20 06 27 06 44 06 34 06 31 06 41 06 27 .A. .'.D.4.1.A.' 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 21 00 20 06 44 06 39 06 44 06 27 06 2c 00 20 .!. .D.9.D.'.,. 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 27 06 44 06 43 06 48 06 44 06 4a 06 33 06 2a .'.D.C.H.D.J.3.* 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 31 06 48 06 44 00 3a 00 20 06 2a 06 24 06 2e .1.H.D.:. .*.$.. 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 30 00 20 06 46 06 33 06 28 00 20 06 45 06 2a .0. .F.3.(. .E.* 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 33 06 27 06 48 06 4a 06 29 00 20 06 45 06 46 .3.'.H.J.). .E.F 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 00 20 06 27 06 44 06 44 06 48 06 32 . .'.D.D.H.2 2009-03-03 21:00:16 [2825] [14] DEBUG:Octet string dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: more_messages_to_send: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Got PDU: 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU 0xa732ad00 dump: 2009-03-03 21:00:16 [2825] [14] DEBUG: type_name: submit_sm_resp 2009-03-03 21:00:16 [2825] [14] DEBUG: command_id: 2147483652 = 0x8004 2009-03-03 21:00:16 [2825] [14] DEBUG: command_status: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sequence_number: 3680 = 0x0e60 2009-03-03 21:00:16 [2825] [14] DEBUG: message_id: 4129215894 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Manually forced source addr ton = 5, source add npi = 1 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Manually forced dest addr ton = 1, dest add npi = 1 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Sending PDU: BR, Hafez On Thu, Mar 5, 2009 at 11:49 AM, Falko Ziemann fal...@gmail.com wrote: It looks like your SMPP service provider hasn't send a correct ACK for the message but delivered it. Please take a look in the smpp-logfile, what you provider answered to the submit_sm. Strongly looks like an error on your providers side. Regards Falko Am 05.03.2009 um 10:40 schrieb hafez ahmad: Hi All, Hope your all doing well, I have the following warning in my logs, 2009-03-04 16:45:56 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT62sec. ago, SEQ11674, DST+ 2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT88sec. ago, SEQ11684, DST+9888 2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT88sec. ago, SEQ11685, DST+ 2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT88sec. ago, SEQ11686, DST+ 2009-03-04 16:47:24 [2825] [14] WARNING: SMPP
Re: Not ACKED message found, will retransmit
Well, there is an enquire-link-interval which you could tweak. It defaults to 30. BR, Nikos - Original Message - From: hafez ahmad To: Falko Ziemann Cc: users@kannel.org Sent: Monday, March 09, 2009 3:43 PM Subject: Re: Not ACKED message found, will retransmit Dears, I still have the same problem, Any Ideas? , by they my operator advice me that use “ESME_QRYLINK” on both transmitter and receiver to keep the connection live may be that related to this error . Please advice. Regards, Hafez On Thu, Mar 5, 2009 at 4:17 PM, Falko Ziemann fal...@gmail.com wrote: Hmm, sorry, no idea. Seems like kannel forgets about the ack... A hotfix would be to set wait-ack-expire = 0x02 in the smsc group. That would make kannel waiting forever for the ACK and never retry. Very dirty hack, but should do the job until someone comes around with a better solution... Regards Falko Am 05.03.2009 um 13:37 schrieb hafez ahmad: Sorry, thats the correct 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU 0xa732ad00 dump: 2009-03-03 21:00:16 [2825] [14] DEBUG: type_name: submit_sm 2009-03-03 21:00:16 [2825] [14] DEBUG: command_id: 4 = 0x0004 2009-03-03 21:00:16 [2825] [14] DEBUG: command_status: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sequence_number: 3684 = 0x0e64 2009-03-03 21:00:16 [2825] [14] DEBUG: service_type: V 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr_ton: 5 = 0x0005 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr_npi: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr: T2ME 2009-03-03 21:00:16 [2825] [14] DEBUG: dest_addr_ton: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: dest_addr_npi: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: destination_addr: 2009-03-03 21:00:16 [2825] [14] DEBUG: esm_class: 67 = 0x0043 2009-03-03 21:00:16 [2825] [14] DEBUG: protocol_id: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: priority_flag: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: schedule_delivery_time: NULL 2009-03-03 21:00:16 [2825] [14] DEBUG: validity_period: NULL 2009-03-03 21:00:16 [2825] [14] DEBUG: registered_delivery: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: replace_if_present_flag: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: data_coding: 8 = 0x0008 2009-03-03 21:00:16 [2825] [14] DEBUG: sm_default_msg_id: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sm_length: 140 = 0x008c 2009-03-03 21:00:16 [2825] [14] DEBUG: short_message: 2009-03-03 21:00:16 [2825] [14] DEBUG:Octet string at 0xa732af00: 2009-03-03 21:00:16 [2825] [14] DEBUG: len: 140 2009-03-03 21:00:16 [2825] [14] DEBUG: size: 1024 2009-03-03 21:00:16 [2825] [14] DEBUG: immutable: 0 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 05 00 03 83 04 01 06 23 06 47 06 45 00 20 06 48 ...#.G.E. .H 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 35 06 41 06 27 06 2a 00 20 06 4a 06 48 06 33 .5.A.'.*. .J.H.3 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 41 00 20 06 27 06 44 06 34 06 31 06 41 06 27 .A. .'.D.4.1.A.' 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 21 00 20 06 44 06 39 06 44 06 27 06 2c 00 20 .!. .D.9.D.'.,. 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 27 06 44 06 43 06 48 06 44 06 4a 06 33 06 2a .'.D.C.H.D.J.3.* 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 31 06 48 06 44 00 3a 00 20 06 2a 06 24 06 2e .1.H.D.:. .*.$.. 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 30 00 20 06 46 06 33 06 28 00 20 06 45 06 2a .0. .F.3.(. .E.* 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 33 06 27 06 48 06 4a 06 29 00 20 06 45 06 46 .3.'.H.J.). .E.F 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 00 20 06 27 06 44 06 44 06 48 06 32 . .'.D.D.H.2 2009-03-03 21:00:16 [2825] [14] DEBUG:Octet string dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: more_messages_to_send: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Got PDU: 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU 0xa732ad00 dump: 2009-03-03 21:00:16 [2825] [14] DEBUG: type_name: submit_sm_resp 2009-03-03 21:00:16 [2825] [14] DEBUG: command_id: 2147483652 = 0x8004 2009-03-03 21:00:16 [2825] [14] DEBUG: command_status: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sequence_number: 3684 = 0x0e64 2009-03-03 21:00:16 [2825] [14] DEBUG: message_id: 4129216897 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU dump ends. Regards, Hafez On Thu
Re: Not ACKED message found, will retransmit
I just saw this behavior once before. There a service provider routed the ACK to another large account. So I send the message on MYMTCONN1 and received the ACK on MYMTCONN2. That's not the case, or? I can't see it from the log, the first line where kannel states the connection name is missing. But I really don't have a idea what this problem should have to do with keep alives. Are you loosing the connection between the submit and the ACK? Falko Am 09.03.2009 um 21:13 schrieb Nikos Balkanas: Well, there is an enquire-link-interval which you could tweak. It defaults to 30. BR, Nikos - Original Message - From: hafez ahmad To: Falko Ziemann Cc: users@kannel.org Sent: Monday, March 09, 2009 3:43 PM Subject: Re: Not ACKED message found, will retransmit Dears, I still have the same problem, Any Ideas? , by they my operator advice me that use “ESME_QRYLINK” on both transmitter and receiver to keep the connection live may be that related to this error . Please advice. Regards, Hafez On Thu, Mar 5, 2009 at 4:17 PM, Falko Ziemann fal...@gmail.com wrote: Hmm, sorry, no idea. Seems like kannel forgets about the ack... A hotfix would be to set wait-ack-expire = 0x02 in the smsc group. That would make kannel waiting forever for the ACK and never retry. Very dirty hack, but should do the job until someone comes around with a better solution... Regards Falko Am 05.03.2009 um 13:37 schrieb hafez ahmad: Sorry, thats the correct 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU 0xa732ad00 dump: 2009-03-03 21:00:16 [2825] [14] DEBUG: type_name: submit_sm 2009-03-03 21:00:16 [2825] [14] DEBUG: command_id: 4 = 0x0004 2009-03-03 21:00:16 [2825] [14] DEBUG: command_status: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sequence_number: 3684 = 0x0e64 2009-03-03 21:00:16 [2825] [14] DEBUG: service_type: V 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr_ton: 5 = 0x0005 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr_npi: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr: T2ME 2009-03-03 21:00:16 [2825] [14] DEBUG: dest_addr_ton: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: dest_addr_npi: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: destination_addr: 2009-03-03 21:00:16 [2825] [14] DEBUG: esm_class: 67 = 0x0043 2009-03-03 21:00:16 [2825] [14] DEBUG: protocol_id: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: priority_flag: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: schedule_delivery_time: NULL 2009-03-03 21:00:16 [2825] [14] DEBUG: validity_period: NULL 2009-03-03 21:00:16 [2825] [14] DEBUG: registered_delivery: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: replace_if_present_flag: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: data_coding: 8 = 0x0008 2009-03-03 21:00:16 [2825] [14] DEBUG: sm_default_msg_id: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sm_length: 140 = 0x008c 2009-03-03 21:00:16 [2825] [14] DEBUG: short_message: 2009-03-03 21:00:16 [2825] [14] DEBUG:Octet string at 0xa732af00: 2009-03-03 21:00:16 [2825] [14] DEBUG: len: 140 2009-03-03 21:00:16 [2825] [14] DEBUG: size: 1024 2009-03-03 21:00:16 [2825] [14] DEBUG: immutable: 0 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 05 00 03 83 04 01 06 23 06 47 06 45 00 20 06 48 ...#.G.E. .H 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 35 06 41 06 27 06 2a 00 20 06 4a 06 48 06 33 .5.A.'.*. .J.H.3 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 41 00 20 06 27 06 44 06 34 06 31 06 41 06 27 .A. .'.D.4.1.A.' 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 21 00 20 06 44 06 39 06 44 06 27 06 2c 00 20 .!. .D.9.D.'.,. 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 27 06 44 06 43 06 48 06 44 06 4a 06 33 06 2a .'.D.C.H.D.J.3.* 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 31 06 48 06 44 00 3a 00 20 06 2a 06 24 06 2e .1.H.D.:. .*.$.. 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 30 00 20 06 46 06 33 06 28 00 20 06 45 06 2a .0. .F.3.(. .E.* 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 33 06 27 06 48 06 4a 06 29 00 20 06 45 06 46 .3.'.H.J.). .E.F 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 00 20 06 27 06 44 06 44 06 48 06 32 . .'.D.D.H.2 2009-03-03 21:00:16 [2825] [14] DEBUG:Octet string dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: more_messages_to_send: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Got PDU: 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU 0xa732ad00 dump: 2009-03-03 21:00:16 [2825] [14] DEBUG: type_name: submit_sm_resp 2009-03-03 21:00:16 [2825] [14] DEBUG: command_id: 2147483652 = 0x8004 2009-03-03 21:00:16 [2825] [14] DEBUG: command_status: 0 = 0x 2009-03-03 21:00:16 [2825
Not ACKED message found, will retransmit
Hi All,
Hope your all doing well, I have the following warning in my logs,
2009-03-04 16:45:56 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED
message found, will retransmit. SENT62sec. ago, SEQ11674,
DST+
2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED
message found, will retransmit. SENT88sec. ago, SEQ11684,
DST+9888
2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED
message found, will retransmit. SENT88sec. ago, SEQ11685,
DST+
2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED
message found, will retransmit. SENT88sec. ago, SEQ11686,
DST+
2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED
message found, will retransmit. SENT88sec. ago, SEQ11682,
DST+
2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED
message found, will retransmit. SENT88sec. ago, SEQ11683,
DST+9888
2009-03-04 16:48:54 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED
message found, will retransmit. SENT90sec. ago, SEQ11693,
DST+
2009-03-04 16:48:54 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED
message found, will retransmit. SENT89sec. ago, SEQ11694,
DST+
2009-03-04 16:48:54 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED
message found, will retransmit. SENT89sec. ago, SEQ11695,
DST+9888
2009-03-04 16:48:54 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED
message found, will retransmit. SENT90sec. ago, SEQ11691,
DST+9888
2009-03-04 16:48:54 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED
message found, will retransmit. SENT90sec. ago, SEQ11692,
DST+
2009-03-04 16:50:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED
message found, will retransmit. SENT90sec. ago, SEQ11701,
DST+9888
2009-03-04 16:50:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED
message found, will retransmit. SENT90sec. ago, SEQ11702,
DST+9888
2009-03-04 16:50:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED
message found, will retransmit. SENT89sec. ago, SEQ11703,
DST+
2009-03-04 16:50:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED
message found, will retransmit. SENT90sec. ago, SEQ11699,
DST+
some users like the user +, received the SMS 2 times and every
time he is billed, I search about the problem and I found the following
code:
case SMPP_WAITACK_REQUEUE: /* requeue */
smpp_msg = dict_remove(smpp-sent_msgs, key);
if (smpp_msg != NULL) {
warning(0, SMPP[%s]: Not ACKED message found, will retransmit.
SENT%ldsec. ago, SEQ%s, DST%s,
octstr_get_cstr(smpp-conn-id),
(long)difftime(now, smpp_msg-sent_time) ,
octstr_get_cstr(key),
octstr_get_cstr(smpp_msg-msg-sms.receiver));
bb_smscconn_send_failed(smpp-conn, smpp_msg-msg,
SMSCCONN_FAILED_TEMPORARILY,NULL);
smpp_msg_destroy(smpp_msg, 0);
(*pending_submits)--;
}
As I understand from the code that the connection was down so kannel
requeue the SMS, is that right? and how can I be sure that the user will
get the SMS only one time? please advice.
BR,
Hafez
Re: Not ACKED message found, will retransmit
It looks like your SMPP service provider hasn't send a correct ACK for
the message but delivered it.
Please take a look in the smpp-logfile, what you provider answered to
the submit_sm. Strongly looks like an error on your providers side.
Regards
Falko
Am 05.03.2009 um 10:40 schrieb hafez ahmad:
Hi All,
Hope your all doing well, I have the following warning in my logs,
2009-03-04 16:45:56 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not
ACKED message found, will retransmit. SENT62sec. ago, SEQ11674,
DST+
2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not
ACKED message found, will retransmit. SENT88sec. ago, SEQ11684,
DST+9888
2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not
ACKED message found, will retransmit. SENT88sec. ago, SEQ11685,
DST+
2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not
ACKED message found, will retransmit. SENT88sec. ago, SEQ11686,
DST+
2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not
ACKED message found, will retransmit. SENT88sec. ago, SEQ11682,
DST+
2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not
ACKED message found, will retransmit. SENT88sec. ago, SEQ11683,
DST+9888
2009-03-04 16:48:54 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not
ACKED message found, will retransmit. SENT90sec. ago, SEQ11693,
DST+
2009-03-04 16:48:54 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not
ACKED message found, will retransmit. SENT89sec. ago, SEQ11694,
DST+
2009-03-04 16:48:54 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not
ACKED message found, will retransmit. SENT89sec. ago, SEQ11695,
DST+9888
2009-03-04 16:48:54 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not
ACKED message found, will retransmit. SENT90sec. ago, SEQ11691,
DST+9888
2009-03-04 16:48:54 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not
ACKED message found, will retransmit. SENT90sec. ago, SEQ11692,
DST+
2009-03-04 16:50:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not
ACKED message found, will retransmit. SENT90sec. ago, SEQ11701,
DST+9888
2009-03-04 16:50:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not
ACKED message found, will retransmit. SENT90sec. ago, SEQ11702,
DST+9888
2009-03-04 16:50:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not
ACKED message found, will retransmit. SENT89sec. ago, SEQ11703,
DST+
2009-03-04 16:50:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not
ACKED message found, will retransmit. SENT90sec. ago, SEQ11699,
DST+
some users like the user +, received the SMS 2 times and
every time he is billed, I search about the problem and I found the
following code:
case SMPP_WAITACK_REQUEUE: /* requeue */
smpp_msg = dict_remove(smpp-sent_msgs, key);
if (smpp_msg != NULL) {
warning(0, SMPP[%s]: Not ACKED message found, will
retransmit.
SENT%ldsec. ago, SEQ%s, DST%s,
octstr_get_cstr(smpp-conn-id),
(long)difftime(now, smpp_msg-sent_time) ,
octstr_get_cstr(key),
octstr_get_cstr(smpp_msg-msg-sms.receiver));
bb_smscconn_send_failed(smpp-conn, smpp_msg-msg,
SMSCCONN_FAILED_TEMPORARILY,NULL);
smpp_msg_destroy(smpp_msg, 0);
(*pending_submits)--;
}
As I understand from the code that the connection was down so kannel
requeue the SMS, is that right? and how can I be sure that the user
will get the SMS only one time? please advice.
BR,
Hafez
Re: Not ACKED message found, will retransmit
Dear falko, Thanks for reply I check the submit_sm_respon and I think everything works fine, Please advice, this is my log 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU 0xa732ad00 dump: 2009-03-03 21:00:16 [2825] [14] DEBUG: type_name: submit_sm 2009-03-03 21:00:16 [2825] [14] DEBUG: command_id: 4 = 0x0004 2009-03-03 21:00:16 [2825] [14] DEBUG: command_status: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sequence_number: 3684 = 0x0e64 2009-03-03 21:00:16 [2825] [14] DEBUG: service_type: V 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr_ton: 5 = 0x0005 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr_npi: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr: T2ME 2009-03-03 21:00:16 [2825] [14] DEBUG: dest_addr_ton: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: dest_addr_npi: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: destination_addr: 2009-03-03 21:00:16 [2825] [14] DEBUG: esm_class: 67 = 0x0043 2009-03-03 21:00:16 [2825] [14] DEBUG: protocol_id: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: priority_flag: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: schedule_delivery_time: NULL 2009-03-03 21:00:16 [2825] [14] DEBUG: validity_period: NULL 2009-03-03 21:00:16 [2825] [14] DEBUG: registered_delivery: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: replace_if_present_flag: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: data_coding: 8 = 0x0008 2009-03-03 21:00:16 [2825] [14] DEBUG: sm_default_msg_id: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sm_length: 140 = 0x008c 2009-03-03 21:00:16 [2825] [14] DEBUG: short_message: 2009-03-03 21:00:16 [2825] [14] DEBUG:Octet string at 0xa732af00: 2009-03-03 21:00:16 [2825] [14] DEBUG: len: 140 2009-03-03 21:00:16 [2825] [14] DEBUG: size: 1024 2009-03-03 21:00:16 [2825] [14] DEBUG: immutable: 0 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 05 00 03 83 04 01 06 23 06 47 06 45 00 20 06 48 ...#.G.E. .H 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 35 06 41 06 27 06 2a 00 20 06 4a 06 48 06 33 .5.A.'.*. .J.H.3 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 41 00 20 06 27 06 44 06 34 06 31 06 41 06 27 .A. .'.D.4.1.A.' 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 21 00 20 06 44 06 39 06 44 06 27 06 2c 00 20 .!. .D.9.D.'.,. 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 27 06 44 06 43 06 48 06 44 06 4a 06 33 06 2a .'.D.C.H.D.J.3.* 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 31 06 48 06 44 00 3a 00 20 06 2a 06 24 06 2e .1.H.D.:. .*.$.. 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 30 00 20 06 46 06 33 06 28 00 20 06 45 06 2a .0. .F.3.(. .E.* 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 33 06 27 06 48 06 4a 06 29 00 20 06 45 06 46 .3.'.H.J.). .E.F 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 00 20 06 27 06 44 06 44 06 48 06 32 . .'.D.D.H.2 2009-03-03 21:00:16 [2825] [14] DEBUG:Octet string dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: more_messages_to_send: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Got PDU: 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU 0xa732ad00 dump: 2009-03-03 21:00:16 [2825] [14] DEBUG: type_name: submit_sm_resp 2009-03-03 21:00:16 [2825] [14] DEBUG: command_id: 2147483652 = 0x8004 2009-03-03 21:00:16 [2825] [14] DEBUG: command_status: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sequence_number: 3680 = 0x0e60 2009-03-03 21:00:16 [2825] [14] DEBUG: message_id: 4129215894 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Manually forced source addr ton = 5, source add npi = 1 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Manually forced dest addr ton = 1, dest add npi = 1 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Sending PDU: BR, Hafez On Thu, Mar 5, 2009 at 11:49 AM, Falko Ziemann fal...@gmail.com wrote: It looks like your SMPP service provider hasn't send a correct ACK for the message but delivered it. Please take a look in the smpp-logfile, what you provider answered to the submit_sm. Strongly looks like an error on your providers side. Regards Falko Am 05.03.2009 um 10:40 schrieb hafez ahmad: Hi All, Hope your all doing well, I have the following warning in my logs, 2009-03-04 16:45:56 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT62sec. ago, SEQ11674, DST+ 2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT88sec. ago, SEQ11684, DST+9888 2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT88sec. ago, SEQ11685, DST+ 2009-03-04 16:47:24 [2825] [14] WARNING
Re: Not ACKED message found, will retransmit
Nope take a closer look: submit_sm: sequence_number: 3684 = 0x0e64 submit_sm_resp: sequence_number: 3680 = 0x0e60 That's not the ACK for the message you have posted but for 4 messages earlier. Regards Falko Am 05.03.2009 um 12:10 schrieb hafez ahmad: Dear falko, Thanks for reply I check the submit_sm_respon and I think everything works fine, Please advice, this is my log 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU 0xa732ad00 dump: 2009-03-03 21:00:16 [2825] [14] DEBUG: type_name: submit_sm 2009-03-03 21:00:16 [2825] [14] DEBUG: command_id: 4 = 0x0004 2009-03-03 21:00:16 [2825] [14] DEBUG: command_status: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sequence_number: 3684 = 0x0e64 2009-03-03 21:00:16 [2825] [14] DEBUG: service_type: V 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr_ton: 5 = 0x0005 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr_npi: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr: T2ME 2009-03-03 21:00:16 [2825] [14] DEBUG: dest_addr_ton: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: dest_addr_npi: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: destination_addr: 2009-03-03 21:00:16 [2825] [14] DEBUG: esm_class: 67 = 0x0043 2009-03-03 21:00:16 [2825] [14] DEBUG: protocol_id: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: priority_flag: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: schedule_delivery_time: NULL 2009-03-03 21:00:16 [2825] [14] DEBUG: validity_period: NULL 2009-03-03 21:00:16 [2825] [14] DEBUG: registered_delivery: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: replace_if_present_flag: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: data_coding: 8 = 0x0008 2009-03-03 21:00:16 [2825] [14] DEBUG: sm_default_msg_id: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sm_length: 140 = 0x008c 2009-03-03 21:00:16 [2825] [14] DEBUG: short_message: 2009-03-03 21:00:16 [2825] [14] DEBUG:Octet string at 0xa732af00: 2009-03-03 21:00:16 [2825] [14] DEBUG: len: 140 2009-03-03 21:00:16 [2825] [14] DEBUG: size: 1024 2009-03-03 21:00:16 [2825] [14] DEBUG: immutable: 0 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 05 00 03 83 04 01 06 23 06 47 06 45 00 20 06 48 ...#.G.E. .H 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 35 06 41 06 27 06 2a 00 20 06 4a 06 48 06 33 .5.A.'.*. .J.H.3 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 41 00 20 06 27 06 44 06 34 06 31 06 41 06 27 .A. .'.D.4.1.A.' 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 21 00 20 06 44 06 39 06 44 06 27 06 2c 00 20 .!. .D.9.D.'.,. 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 27 06 44 06 43 06 48 06 44 06 4a 06 33 06 2a .'.D.C.H.D.J.3.* 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 31 06 48 06 44 00 3a 00 20 06 2a 06 24 06 2e .1.H.D.:. .*.$.. 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 30 00 20 06 46 06 33 06 28 00 20 06 45 06 2a .0. .F.3.(. .E.* 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 33 06 27 06 48 06 4a 06 29 00 20 06 45 06 46 .3.'.H.J.). .E.F 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 00 20 06 27 06 44 06 44 06 48 06 32 . .'.D.D.H.2 2009-03-03 21:00:16 [2825] [14] DEBUG:Octet string dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: more_messages_to_send: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Got PDU: 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU 0xa732ad00 dump: 2009-03-03 21:00:16 [2825] [14] DEBUG: type_name: submit_sm_resp 2009-03-03 21:00:16 [2825] [14] DEBUG: command_id: 2147483652 = 0x8004 2009-03-03 21:00:16 [2825] [14] DEBUG: command_status: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sequence_number: 3680 = 0x0e60 2009-03-03 21:00:16 [2825] [14] DEBUG: message_id: 4129215894 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Manually forced source addr ton = 5, source add npi = 1 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Manually forced dest addr ton = 1, dest add npi = 1 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Sending PDU: BR, Hafez On Thu, Mar 5, 2009 at 11:49 AM, Falko Ziemann fal...@gmail.com wrote: It looks like your SMPP service provider hasn't send a correct ACK for the message but delivered it. Please take a look in the smpp-logfile, what you provider answered to the submit_sm. Strongly looks like an error on your providers side. Regards Falko Am 05.03.2009 um 10:40 schrieb hafez ahmad: Hi All, Hope your all doing well, I have the following warning in my logs, 2009-03-04 16:45:56 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT62sec. ago, SEQ11674, DST+ 2009
Re: Not ACKED message found, will retransmit
-03 21:00:16 [2825] [14] DEBUG: esm_class: 67 = 0x0043 2009-03-03 21:00:16 [2825] [14] DEBUG: protocol_id: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: priority_flag: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: schedule_delivery_time: NULL 2009-03-03 21:00:16 [2825] [14] DEBUG: validity_period: NULL 2009-03-03 21:00:16 [2825] [14] DEBUG: registered_delivery: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: replace_if_present_flag: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: data_coding: 8 = 0x0008 2009-03-03 21:00:16 [2825] [14] DEBUG: sm_default_msg_id: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sm_length: 140 = 0x008c 2009-03-03 21:00:16 [2825] [14] DEBUG: short_message: 2009-03-03 21:00:16 [2825] [14] DEBUG:Octet string at 0xa732af00: 2009-03-03 21:00:16 [2825] [14] DEBUG: len: 140 2009-03-03 21:00:16 [2825] [14] DEBUG: size: 1024 2009-03-03 21:00:16 [2825] [14] DEBUG: immutable: 0 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 05 00 03 83 04 01 06 23 06 47 06 45 00 20 06 48 ...#.G.E. .H 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 35 06 41 06 27 06 2a 00 20 06 4a 06 48 06 33 .5.A.'.*. .J.H.3 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 41 00 20 06 27 06 44 06 34 06 31 06 41 06 27 .A. .'.D.4.1.A.' 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 21 00 20 06 44 06 39 06 44 06 27 06 2c 00 20 .!. .D.9.D.'.,. 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 27 06 44 06 43 06 48 06 44 06 4a 06 33 06 2a .'.D.C.H.D.J.3.* 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 31 06 48 06 44 00 3a 00 20 06 2a 06 24 06 2e .1.H.D.:. .*.$.. 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 30 00 20 06 46 06 33 06 28 00 20 06 45 06 2a .0. .F.3.(. .E.* 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 33 06 27 06 48 06 4a 06 29 00 20 06 45 06 46 .3.'.H.J.). .E.F 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 00 20 06 27 06 44 06 44 06 48 06 32 . .'.D.D.H.2 2009-03-03 21:00:16 [2825] [14] DEBUG:Octet string dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: more_messages_to_send: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Got PDU: 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU 0xa732ad00 dump: 2009-03-03 21:00:16 [2825] [14] DEBUG: type_name: submit_sm_resp 2009-03-03 21:00:16 [2825] [14] DEBUG: command_id: 2147483652 = 0x8004 2009-03-03 21:00:16 [2825] [14] DEBUG: command_status: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sequence_number: 3680 = 0x0e60 2009-03-03 21:00:16 [2825] [14] DEBUG: message_id: 4129215894 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Manually forced source addr ton = 5, source add npi = 1 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Manually forced dest addr ton = 1, dest add npi = 1 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Sending PDU: BR, Hafez On Thu, Mar 5, 2009 at 11:49 AM, Falko Ziemann fal...@gmail.com wrote: It looks like your SMPP service provider hasn't send a correct ACK for the message but delivered it. Please take a look in the smpp-logfile, what you provider answered to the submit_sm. Strongly looks like an error on your providers side. Regards Falko Am 05.03.2009 um 10:40 schrieb hafez ahmad: Hi All, Hope your all doing well, I have the following warning in my logs, 2009-03-04 16:45:56 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT62sec. ago, SEQ11674, DST+ 2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT88sec. ago, SEQ11684, DST+9888 2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT88sec. ago, SEQ11685, DST+ 2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT88sec. ago, SEQ11686, DST+ 2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT88sec. ago, SEQ11682, DST+ 2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT88sec. ago, SEQ11683, DST+9888 2009-03-04 16:48:54 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT90sec. ago, SEQ11693, DST+ 2009-03-04 16:48:54 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT89sec. ago, SEQ11694, DST+ 2009-03-04 16:48:54 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT89sec. ago, SEQ11695, DST+9888 2009-03-04 16:48:54 [2825] [14] WARNING
Re: Not ACKED message found, will retransmit
] [14] DEBUG: source_addr_ton: 5 = 0x0005 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr_npi: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: source_addr: T2ME 2009-03-03 21:00:16 [2825] [14] DEBUG: dest_addr_ton: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: dest_addr_npi: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: destination_addr: 2009-03-03 21:00:16 [2825] [14] DEBUG: esm_class: 67 = 0x0043 2009-03-03 21:00:16 [2825] [14] DEBUG: protocol_id: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: priority_flag: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: schedule_delivery_time: NULL 2009-03-03 21:00:16 [2825] [14] DEBUG: validity_period: NULL 2009-03-03 21:00:16 [2825] [14] DEBUG: registered_delivery: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: replace_if_present_flag: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: data_coding: 8 = 0x0008 2009-03-03 21:00:16 [2825] [14] DEBUG: sm_default_msg_id: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sm_length: 140 = 0x008c 2009-03-03 21:00:16 [2825] [14] DEBUG: short_message: 2009-03-03 21:00:16 [2825] [14] DEBUG:Octet string at 0xa732af00: 2009-03-03 21:00:16 [2825] [14] DEBUG: len: 140 2009-03-03 21:00:16 [2825] [14] DEBUG: size: 1024 2009-03-03 21:00:16 [2825] [14] DEBUG: immutable: 0 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 05 00 03 83 04 01 06 23 06 47 06 45 00 20 06 48 ...#.G.E. .H 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 35 06 41 06 27 06 2a 00 20 06 4a 06 48 06 33 .5.A.'.*. .J.H.3 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 41 00 20 06 27 06 44 06 34 06 31 06 41 06 27 .A. .'.D.4.1.A.' 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 21 00 20 06 44 06 39 06 44 06 27 06 2c 00 20 .!. .D.9.D.'.,. 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 27 06 44 06 43 06 48 06 44 06 4a 06 33 06 2a .'.D.C.H.D.J.3.* 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 31 06 48 06 44 00 3a 00 20 06 2a 06 24 06 2e .1.H.D.:. .*.$.. 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 30 00 20 06 46 06 33 06 28 00 20 06 45 06 2a .0. .F.3.(. .E.* 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 06 33 06 27 06 48 06 4a 06 29 00 20 06 45 06 46 .3.'.H.J.). .E.F 2009-03-03 21:00:16 [2825] [14] DEBUG: data: 00 20 06 27 06 44 06 44 06 48 06 32 . .'.D.D.H.2 2009-03-03 21:00:16 [2825] [14] DEBUG:Octet string dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: more_messages_to_send: 1 = 0x0001 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Got PDU: 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU 0xa732ad00 dump: 2009-03-03 21:00:16 [2825] [14] DEBUG: type_name: submit_sm_resp 2009-03-03 21:00:16 [2825] [14] DEBUG: command_id: 2147483652 = 0x8004 2009-03-03 21:00:16 [2825] [14] DEBUG: command_status: 0 = 0x 2009-03-03 21:00:16 [2825] [14] DEBUG: sequence_number: 3680 = 0x0e60 2009-03-03 21:00:16 [2825] [14] DEBUG: message_id: 4129215894 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP PDU dump ends. 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Manually forced source addr ton = 5, source add npi = 1 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Manually forced dest addr ton = 1, dest add npi = 1 2009-03-03 21:00:16 [2825] [14] DEBUG: SMPP[MYMTCONN]: Sending PDU: BR, Hafez On Thu, Mar 5, 2009 at 11:49 AM, Falko Ziemann fal...@gmail.com wrote: It looks like your SMPP service provider hasn't send a correct ACK for the message but delivered it. Please take a look in the smpp-logfile, what you provider answered to the submit_sm. Strongly looks like an error on your providers side. Regards Falko Am 05.03.2009 um 10:40 schrieb hafez ahmad: Hi All, Hope your all doing well, I have the following warning in my logs, 2009-03-04 16:45:56 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT62sec. ago, SEQ11674, DST+ 2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT88sec. ago, SEQ11684, DST+9888 2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT88sec. ago, SEQ11685, DST+ 2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT88sec. ago, SEQ11686, DST+ 2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT88sec. ago, SEQ11682, DST+ 2009-03-04 16:47:24 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found, will retransmit. SENT88sec. ago, SEQ11683, DST+9888 2009-03-04 16:48:54 [2825] [14] WARNING: SMPP[MT_CONNICTION]: Not ACKED message found
Not ACKED message found, will retransmit. SENT...
hi, i have warning for smpp sending, WARNING: SMPP[*]: Not ACKED message found, will retransmit. SENT90sec. ago, SEQ71, DST6*9 then the sending is about 1minute / msg :(( and store file is big. please help... thanks gerandong
