Hi, just some ideas 1) Are all the resources of the machine where kannel is runing ok?
2) How is the network connection quality to your provider? If I read it right, I see many enquire_link without response and the one enquire_link_resp took 4 secs (if they really belong to the same transaction): 2013-03-06 20:32:07 [26488] [15] DEBUG: SMPP[saf_receiver_b]: Sending enquire link: 2013-03-06 20:32:07 [26488] [15] DEBUG: SMPP PDU 0x7f36c0000e90 dump: 2013-03-06 20:32:07 [26488] [15] DEBUG: type_name: enquire_link 2013-03-06 20:32:07 [26488] [15] DEBUG: command_id: 21 = 0x00000015 2013-03-06 20:32:07 [26488] [15] DEBUG: command_status: 0 = 0x00000000 2013-03-06 20:32:07 [26488] [15] DEBUG: sequence_number: 13 = 0x0000000d 2013-03-06 20:32:07 [26488] [15] DEBUG: SMPP PDU dump ends. ........................................................................................................................... 2013-03-06 20:32:11 [26488] [15] DEBUG: SMPP[saf_receiver_b]: Got PDU: 2013-03-06 20:32:11 [26488] [15] DEBUG: SMPP PDU 0x7f36c0000e40 dump: 2013-03-06 20:32:11 [26488] [15] DEBUG: type_name: enquire_link_resp 2013-03-06 20:32:11 [26488] [15] DEBUG: command_id: 2147483669 = 0x80000015 2013-03-06 20:32:11 [26488] [15] DEBUG: command_status: 0 = 0x00000000 2013-03-06 20:32:11 [26488] [15] DEBUG: sequence_number: 13 = 0x0000000d 2013-03-06 20:32:11 [26488] [15] DEBUG: SMPP PDU dump ends. 3) If you are logging all the instances of saf_receiver_b to the same file (as it looks to me right now), please provide a clean log for one instance only (you can separate log-file = "/var/log/kannel/bearerbox.log" for each or just keep 1 instance running) 4) You say you have 10 instances of saf_receiver_b,that based on your config (enquire-link-interval = 5), are issuing in total 120 enquire_link/minute to the same provider, this without taking in consideration instances of saf_7711. Is that really necessary? Can you try to increase the value of enquire-link-interval. (Even if you use 1 connection try to set it to smth approx 60 seconds). 5) Have you tried to use active throttling with throughput = X (based on provider instruction) 6) Have you tried to increase the value of store-dump-freq = 1 On Thu, Mar 7, 2013 at 10:25 AM, Jam Hitz <[email protected]> wrote: > Did you discover anything out of the ordinary? > > On Wed, Mar 6, 2013 at 9:22 PM, Rene Kluwen <[email protected]> wrote: > > So you do send a deliver_sm_resp. Just with an empty message id. > > Let me look at this closer. > > > > -----Original Message----- > > From: Jam Hitz [mailto:[email protected]] > > Sent: woensdag 6 maart 2013 18:40 > > To: Rene Kluwen > > Cc: Alexander Malysh; [email protected] > > Subject: Re: No submit_sm_resp > > > > Here is the Bearerbox Log (Please NOTE: Upon the recommendations of the > > telco, I have created 10 instances of saf_receiver_b SMSC as defined in > the > > config). I shared my settings with the telco and they are also insisting > > that I raise window setting to 500 even though the documentation says > > maximum is 10). Inspite of all that, I still get like only 5 SMS/min > (when > > I'm lucky) > > > > Another observation: in my bearerbox log, I am getting some interesting > > errors especially when restarting the daemon: > > > > 2013-03-06 20:20:41 [26334] [3] ERROR: System error 98: Address already > in > > use [26385] [0] INFO: DLR rerouting for smsc id <saf_receiver_b> > disabled. > > > > .... and lots of these: > > 2013-03-06 20:24:43 [26488] [17] DEBUG: sms_router: handling message > > (0x20bbc10 vs 0x12a4460) > > 2013-03-06 20:24:43 [26488] [17] DEBUG: Routing failed, re-queued. > > > > ...and lots of these (saf_7711 is the transmitter SMSC bind) > > WARNING: SMPP[saf_7711]: Not ACKED message found, will retransmit. > > SENT<66>sec. ago, SEQ<84>, DST<12345398700> > > > > > > Here is my bearerbox log: > > > > 2013-03-06 20:32:05 [26488] [9] DEBUG: SMPP[saf_receiver_b]: Sending > enquire > > link: > > 2013-03-06 20:32:05 [26488] [9] DEBUG: SMPP PDU 0x7f36dc000a30 dump: > > 2013-03-06 20:32:05 [26488] [9] DEBUG: type_name: enquire_link > > 2013-03-06 20:32:05 [26488] [9] DEBUG: command_id: 21 = 0x00000015 > > 2013-03-06 20:32:05 [26488] [9] DEBUG: command_status: 0 = 0x00000000 > > 2013-03-06 20:32:05 [26488] [9] DEBUG: sequence_number: 14 = 0x0000000e > > 2013-03-06 20:32:05 [26488] [9] DEBUG: SMPP PDU dump ends. > > 2013-03-06 20:32:06 [26488] [8] DEBUG: SMPP[saf_receiver_b]: Sending > enquire > > link: > > 2013-03-06 20:32:06 [26488] [8] DEBUG: SMPP PDU 0x7f36e4000e40 dump: > > 2013-03-06 20:32:06 [26488] [8] DEBUG: type_name: enquire_link > > 2013-03-06 20:32:06 [26488] [8] DEBUG: command_id: 21 = 0x00000015 > > 2013-03-06 20:32:06 [26488] [8] DEBUG: command_status: 0 = 0x00000000 > > 2013-03-06 20:32:06 [26488] [8] DEBUG: sequence_number: 88 = 0x00000058 > > 2013-03-06 20:32:06 [26488] [8] DEBUG: SMPP PDU dump ends. > > 2013-03-06 20:32:07 [26488] [15] DEBUG: SMPP[saf_receiver_b]: Sending > > enquire link: > > 2013-03-06 20:32:07 [26488] [15] DEBUG: SMPP PDU 0x7f36c0000e90 dump: > > 2013-03-06 20:32:07 [26488] [15] DEBUG: type_name: enquire_link > > 2013-03-06 20:32:07 [26488] [15] DEBUG: command_id: 21 = 0x00000015 > > 2013-03-06 20:32:07 [26488] [15] DEBUG: command_status: 0 = 0x00000000 > > 2013-03-06 20:32:07 [26488] [15] DEBUG: sequence_number: 13 = > 0x0000000d > > 2013-03-06 20:32:07 [26488] [15] DEBUG: SMPP PDU dump ends. > > 2013-03-06 20:32:08 [26488] [11] DEBUG: SMPP[saf_receiver_b]: Sending > > enquire link: > > 2013-03-06 20:32:08 [26488] [11] DEBUG: SMPP PDU 0x7f36d0000e40 dump: > > 2013-03-06 20:32:08 [26488] [11] DEBUG: type_name: enquire_link > > 2013-03-06 20:32:08 [26488] [11] DEBUG: command_id: 21 = 0x00000015 > > 2013-03-06 20:32:08 [26488] [11] DEBUG: command_status: 0 = 0x00000000 > > 2013-03-06 20:32:08 [26488] [11] DEBUG: sequence_number: 14 = > 0x0000000e > > 2013-03-06 20:32:08 [26488] [11] DEBUG: SMPP PDU dump ends. > > 2013-03-06 20:32:09 [26488] [11] DEBUG: Optional parameter tag (0x0606) > > 2013-03-06 20:32:09 [26488] [11] DEBUG: Optional parameter length read > as 1 > > 2013-03-06 20:32:09 [26488] [11] WARNING: SMPP: Unknown > > TLV(0x0606,0x0001,00) for PDU type (deliver_sm) received! > > 2013-03-06 20:32:09 [26488] [11] DEBUG: Optional parameter tag (0x1501) > > 2013-03-06 20:32:09 [26488] [11] DEBUG: Optional parameter length read > as 13 > > 2013-03-06 20:32:09 [26488] [11] WARNING: SMPP: Unknown > > TLV(0x1501,0x000d,32353437323235303036313200) for PDU type > > (deliver_sm) received! > > 2013-03-06 20:32:09 [26488] [11] DEBUG: SMPP[saf_receiver_b]: Got PDU: > > 2013-03-06 20:32:09 [26488] [11] DEBUG: SMPP PDU 0x7f36d0001500 dump: > > 2013-03-06 20:32:09 [26488] [11] DEBUG: type_name: deliver_sm > > 2013-03-06 20:32:09 [26488] [11] DEBUG: command_id: 5 = 0x00000005 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: command_status: 0 = 0x00000000 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: sequence_number: 2 = 0x00000002 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: service_type: "INSRV" > > 2013-03-06 20:32:09 [26488] [11] DEBUG: source_addr_ton: 1 = 0x00000001 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: source_addr_npi: 1 = 0x00000001 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: source_addr: "254703842263" > > 2013-03-06 20:32:09 [26488] [11] DEBUG: dest_addr_ton: 0 = 0x00000000 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: dest_addr_npi: 1 = 0x00000001 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: destination_addr: "7711" > > 2013-03-06 20:32:09 [26488] [11] DEBUG: esm_class: 0 = 0x00000000 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: protocol_id: 0 = 0x00000000 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: priority_flag: 0 = 0x00000000 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: schedule_delivery_time: NULL > > 2013-03-06 20:32:09 [26488] [11] DEBUG: validity_period: NULL > > 2013-03-06 20:32:09 [26488] [11] DEBUG: registered_delivery: 0 = > > 0x00000000 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: replace_if_present_flag: 0 = > > 0x00000000 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: data_coding: 0 = 0x00000000 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: sm_default_msg_id: 0 = > 0x00000000 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: sm_length: 48 = 0x00000030 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: short_message: > > 2013-03-06 20:32:09 [26488] [11] DEBUG: Octet string at > 0x7f36d0000f40: > > 2013-03-06 20:32:09 [26488] [11] DEBUG: len: 48 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: size: 49 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: immutable: 0 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: data: 53 61 6d 73 6f 6e > > 20 6b 61 72 69 75 6b 69 20 6e Some SMS content > > 2013-03-06 20:32:09 [26488] [11] DEBUG: data: 6a 65 6e 67 61 20 > > 32 38 38 39 36 39 38 20 2c 20 appears here <has > > 2013-03-06 20:32:09 [26488] [11] DEBUG: data: 20 6b 69 61 6e 6a > > 6f 67 75 20 20 2e 67 65 74 61 been trimmed> > > 2013-03-06 20:32:09 [26488] [11] DEBUG: Octet string dump ends. > > 2013-03-06 20:32:09 [26488] [11] DEBUG: SMPP PDU dump ends. > > 2013-03-06 20:32:09 [26488] [11] DEBUG: SMPP[saf_receiver_b]: Sending > PDU: > > 2013-03-06 20:32:09 [26488] [20] DEBUG: send_msg: sending msg to box: > > <127.0.0.1> > > 2013-03-06 20:32:09 [26488] [11] DEBUG: SMPP PDU 0x7f36d00016b0 dump: > > 2013-03-06 20:32:09 [26488] [11] DEBUG: type_name: deliver_sm_resp > > 2013-03-06 20:32:09 [26488] [11] DEBUG: command_id: 2147483653 = > > 0x80000005 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: command_status: 0 = 0x00000000 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: sequence_number: 2 = 0x00000002 > > 2013-03-06 20:32:09 [26488] [11] DEBUG: message_id: NULL > > 2013-03-06 20:32:09 [26488] [11] DEBUG: SMPP PDU dump ends. > > 2013-03-06 20:32:09 [26488] [20] DEBUG: boxc_sender: sent message to > > <127.0.0.1> > > 2013-03-06 20:32:09 [26488] [19] DEBUG: boxc_receiver: got ack > > 2013-03-06 20:32:09 [26488] [16] DEBUG: SMPP[saf_7711]: Sending enquire > > link: > > 2013-03-06 20:32:09 [26488] [16] DEBUG: SMPP PDU 0x7f36c502c720 dump: > > 2013-03-06 20:32:09 [26488] [16] DEBUG: type_name: enquire_link > > 2013-03-06 20:32:09 [26488] [16] DEBUG: command_id: 21 = 0x00000015 > > 2013-03-06 20:32:09 [26488] [16] DEBUG: command_status: 0 = 0x00000000 > > 2013-03-06 20:32:09 [26488] [16] DEBUG: sequence_number: 63 = > 0x0000003f > > 2013-03-06 20:32:09 [26488] [16] DEBUG: SMPP PDU dump ends. > > 2013-03-06 20:32:11 [26488] [8] DEBUG: SMPP[saf_receiver_b]: Sending > enquire > > link: > > 2013-03-06 20:32:11 [26488] [8] DEBUG: SMPP PDU 0x7f36e4000e40 dump: > > 2013-03-06 20:32:11 [26488] [8] DEBUG: type_name: enquire_link > > 2013-03-06 20:32:11 [26488] [8] DEBUG: command_id: 21 = 0x00000015 > > 2013-03-06 20:32:11 [26488] [8] DEBUG: command_status: 0 = 0x00000000 > > 2013-03-06 20:32:11 [26488] [8] DEBUG: sequence_number: 89 = 0x00000059 > > 2013-03-06 20:32:11 [26488] [8] DEBUG: SMPP PDU dump ends. > > 2013-03-06 20:32:11 [26488] [15] DEBUG: SMPP[saf_receiver_b]: Got PDU: > > 2013-03-06 20:32:11 [26488] [15] DEBUG: SMPP PDU 0x7f36c0000e40 dump: > > 2013-03-06 20:32:11 [26488] [15] DEBUG: type_name: enquire_link_resp > > 2013-03-06 20:32:11 [26488] [15] DEBUG: command_id: 2147483669 = > > 0x80000015 > > 2013-03-06 20:32:11 [26488] [15] DEBUG: command_status: 0 = 0x00000000 > > 2013-03-06 20:32:11 [26488] [15] DEBUG: sequence_number: 13 = > 0x0000000d > > 2013-03-06 20:32:11 [26488] [15] DEBUG: SMPP PDU dump ends. > > 2013-03-06 20:32:11 [26488] [18] DEBUG: Dumping 17016 messages to store > > > > I can attach a more detailed log if you want. > > > > Thanks > > > > On Wed, Mar 6, 2013 at 6:40 PM, Rene Kluwen <[email protected]> > wrote: > >> Could you maybe share some log files details of the appropriate message? > >> > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On > >> Behalf Of Jam Hitz > >> Sent: woensdag 6 maart 2013 16:34 > >> To: Alexander Malysh > >> Cc: [email protected] > >> Subject: Re: No submit_sm_resp > >> > >> Hello, > >> > >> Sorry, I think I had read it wrong. The SMSC says that I am not > >> responding to deliver_sm (not sending deliver_sm_resp) {NOT > >> submit_sm_resp} as earlier indicated. What could be causing this? > >> > >> Please assist > >> > >> On Tue, Mar 5, 2013 at 6:24 PM, Alexander Malysh <[email protected]> > > wrote: > >>> And Kannel send generick NACK for unknown/wrong commands. > >>> > >>> Alex > >>> > >>> Am 05.03.2013 um 16:01 schrieb Jason Mule <[email protected]>: > >>> > >>>> Jam, > >>>> > >>>> The SMSC should send messages to you using either deliver_sm or > >>>> data_sm > >> PDUs. > >>>> > >>>> On 5 March 2013 09:24, Jam Hitz <[email protected]> wrote: > >>>>> Hello. > >>>>> > >>>>> I have a very long queue of messages at the SMSC that Kannel is > >>>>> picking up very, very slowly. We did a tcpdump and they concluded > >>>>> that Kannel was not sending a submit_sm_resp after getting a > >>>>> submit_sm causing the SMSC to re-transmit the submit_sm over and > >>>>> over, hence the delay. > >>>>> > >>>>> Please help. My settings are as follows: > >>>>> > >>>>> # ======================== CORE ========================= group = > >>>>> core admin-port = 13000 smsbox-port = 13001 admin-password = > >>>>> password log-level = 0 store-type = file store-location = > >>>>> /var/log/kannel/store_file store-dump-freq = 1 log-file = > >>>>> "/var/log/kannel/bearerbox.log" > >>>>> access-log = "/var/log/kannel/bearerbox_access.log" > >>>>> box-deny-ip = "*.*.*.*" > >>>>> box-allow-ip = "127.0.0.1" > >>>>> dlr-storage = mysql > >>>>> sms-resend-retry = 50 > >>>>> > >>>>> # ==================== SMS DAEMON ======================== group = > >>>>> smsbox bearerbox-host = 127.0.0.1 sendsms-port = 13013 log-file = > >>>>> "/var/log/kannel/smsbox.log" > >>>>> log-level = 0 > >>>>> access-log = "/var/log/kannel/smsbox_access.log" > >>>>> http-request-retry = 10 > >>>>> #sendsms-url=/send > >>>>> mo-recode=true > >>>>> > >>>>> #---------- MYSQL DLR -------- > >>>>> group = mysql-connection > >>>>> id = mysql_dlr > >>>>> host = localhost > >>>>> username = dlr > >>>>> password = dlr > >>>>> database = dlr > >>>>> max-connections = 1 > >>>>> > >>>>> group = dlr-db > >>>>> id = mysql_dlr > >>>>> table = dlr > >>>>> field-smsc = smsc > >>>>> field-timestamp = ts > >>>>> field-destination = destination > >>>>> field-source = source > >>>>> field-service = service > >>>>> field-url = url > >>>>> field-mask = mask > >>>>> field-status = status > >>>>> field-boxc-id = boxc > >>>>> > >>>>> #=============== SERVICES =============== include = > >>>>> "/etc/kannel/default_service.conf" > >>>>> > >>>>> > >>>>> #=========== SMSC CONNECTIONS =========== > >>>>> > >>>>> group=smsc > >>>>> smsc=smpp > >>>>> smsc-id=saf_receiver_b > >>>>> interface-version=34 > >>>>> host=192.168.9.93 > >>>>> receive-port=6695 > >>>>> system-type= > >>>>> smsc-username=<username> > >>>>> smsc-password=<password> > >>>>> log-level=0 > >>>>> source-addr-ton = 2 > >>>>> source-addr-npi = 1 > >>>>> dest-addr-ton = 2 > >>>>> dest-addr-npi = 1 > >>>>> msg-id-type = 0x01 > >>>>> alt-charset = "ASCII" > >>>>> alt-addr-charset = "GSM" > >>>>> enquire-link-interval = 5 > >>>>> max-pending-submits = 20 > >>>>> flow-control = 0 > >>>>> window = 50 > >>>>> wait-ack=120 > >>>>> wait-ack-expire=0x02 > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Kind regards > >>>> Jason Mule > >>>> > >>> > >> > >> > > > > > >
