Did you discover anything out of the ordinary?

On Wed, Mar 6, 2013 at 9:22 PM, Rene Kluwen <rene.klu...@chimit.nl> 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:is.mu...@gmail.com]
> Sent: woensdag 6 maart 2013 18:40
> To: Rene Kluwen
> Cc: Alexander Malysh; users@kannel.org
> 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 <rene.klu...@chimit.nl> wrote:
>> Could you maybe share some log files details of the appropriate message?
>>
>> -----Original Message-----
>> From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On
>> Behalf Of Jam Hitz
>> Sent: woensdag 6 maart 2013 16:34
>> To: Alexander Malysh
>> Cc: users@kannel.org
>> 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 <amal...@kannel.org>
> wrote:
>>> And Kannel send generick NACK for unknown/wrong commands.
>>>
>>> Alex
>>>
>>> Am 05.03.2013 um 16:01 schrieb Jason Mule <jason.m...@gmail.com>:
>>>
>>>> Jam,
>>>>
>>>> The SMSC should send messages to you using either deliver_sm or
>>>> data_sm
>> PDUs.
>>>>
>>>> On 5 March 2013 09:24, Jam Hitz <is.mu...@gmail.com> 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
>>>>
>>>
>>
>>
>
>

Reply via email to