Re: REDIS: redisCommand() failed: ERR unknown command
After receiving any deliver_sm (DLR-4, DLR-1 or DLR-2), kannel checks the dlr-storage (REDIS in yours) to find the entry and call the specified dlr-url if available. Both DLRs seem OK to me. As you mentioned, still *dlr:?:?* is the problem in both versions. Let me check more. On Fri, Apr 15, 2022 at 7:47 PM lbrezs...@gmx.co.uk wrote: > We considered DLR 27, but unfortunately some small number of ISPs don't > send DLR 1 or 2 at all. > > They just acknowledged they received the request, but not that end user > (mobile phone) received it. > > Question: why code handling DLR1 and DLR4 is different? I compared the > structure of both DLRa and they are the same: > > DLR4: > id:0273822961 sub:001 dlvrd:000 submit date:2204142257 done date > 2204142257 stat ACCEPTD err:003 text:Test DLR 4 > DLR1 > id:0274640129 sub:001 dlvrd:001 submit date:2204151041 done date > 2204151041 stat DELIVRD err:000 text:Test DLR 1 > > Why even make a trip to REDIS? As you need to wait for DLR 1/2 anyways, > why even bother? > They are still forwarded to smsbox, no? Shouldn't be just an "IF" > statement that DLR 1 or DLR 2 make a trip to REDIS, everything else is > forwarded to smsbox as is? > > By the way, I double-check the WARNING exists on 1.4.4 > (redis_version:3.2.6) vs ERROR on 1.4.5 (redis_version:6.0.16) > > old message, 1.4.4 (redis_version:3.2.6) : > > 2022-04-15 02:57:01 [24496] [6] DEBUG: DLR[redis]: DLR not destroyed, > still waiting for other delivery report > 2022-04-15 02:57:01 [24496] [6] DEBUG: Updating DLR status in keystore > 2022-04-15 02:57:01 [24496] [6] WARNING: DLR: REDIS: No dlr found to > update for dlr:?:? > 2022-04-15 02:57:01 [24496] [6] DEBUG: new group created `smpp' > 2022-04-15 02:57:01 [24496] [6] DEBUG: group=`smpp' key=`dlr_err' value=' > > new message, 1.4.5 (redis_version:6.0.16): > > 2022-04-07 16:05:40 [612] [6] ERROR: REDIS: redisCommand() failed: `ERR > unknown command `smsc_id`, with args beginning with: `1117930062`, `4`, ' > 2022-04-07 16:05:40 [612] [6] ERROR: DLR: REDIS: Error while updating > dlr entry for dlr:?:? > > On 4/14/2022 20:55, lbrezs...@gmx.co.uk wrote: > > I don't think it's the message. > > > > bearer-box access-log looks ordinary > > > > 2022-04-14 18:49:56 send-SMS request added - sender:smsuser:XX999 > > 192.168.27.35 target:1XXX9562019 request: 'Test DLR 4' > > > > Hower, there is an important piece of information I forgot to mention. > > > > Machine that handles DLR 4s correctly: > > > > Kannel bearerbox version 1.4.4. > > Compiler 6.2.1 20161124. > > System Linux, release 4.9.0-13-amd64 > > debian 10 = SMP Debian 4.9.228-1 (2020-07-05), machine x86_64 > > hiredis API 0.13.3 > > redis_version:3.2.6 > > > > Machine that handles DLR 4s incorrectly: > > > > Kannel bearerbox version 1.4.5. > > Compiler 10.1.0. > > System Linux, release 5.10.0-13-amd64, > > debian 11 = SMP Debian 5.10.106-1 (2022-03-17), machine x86_64 > > Using hiredis API 0.14.1 > > redis_version:6.0.16 > > > > On 4/14/2022 18:38, Sayed Hadi Rastgou Haghi wrote: > >> REDIS: redisCommand() > > > > -- Sincerely, Sayed Hadi Rastgou Haghi
Re: REDIS: redisCommand() failed: ERR unknown command
We considered DLR 27, but unfortunately some small number of ISPs don't send DLR 1 or 2 at all. They just acknowledged they received the request, but not that end user (mobile phone) received it. Question: why code handling DLR1 and DLR4 is different? I compared the structure of both DLRa and they are the same: DLR4: id:0273822961 sub:001 dlvrd:000 submit date:2204142257 done date 2204142257 stat ACCEPTD err:003 text:Test DLR 4 DLR1 id:0274640129 sub:001 dlvrd:001 submit date:2204151041 done date 2204151041 stat DELIVRD err:000 text:Test DLR 1 Why even make a trip to REDIS? As you need to wait for DLR 1/2 anyways, why even bother? They are still forwarded to smsbox, no? Shouldn't be just an "IF" statement that DLR 1 or DLR 2 make a trip to REDIS, everything else is forwarded to smsbox as is? By the way, I double-check the WARNING exists on 1.4.4 (redis_version:3.2.6) vs ERROR on 1.4.5 (redis_version:6.0.16) old message, 1.4.4 (redis_version:3.2.6) : 2022-04-15 02:57:01 [24496] [6] DEBUG: DLR[redis]: DLR not destroyed, still waiting for other delivery report 2022-04-15 02:57:01 [24496] [6] DEBUG: Updating DLR status in keystore 2022-04-15 02:57:01 [24496] [6] WARNING: DLR: REDIS: No dlr found to update for dlr:?:? 2022-04-15 02:57:01 [24496] [6] DEBUG: new group created `smpp' 2022-04-15 02:57:01 [24496] [6] DEBUG: group=`smpp' key=`dlr_err' value=' new message, 1.4.5 (redis_version:6.0.16): 2022-04-07 16:05:40 [612] [6] ERROR: REDIS: redisCommand() failed: `ERR unknown command `smsc_id`, with args beginning with: `1117930062`, `4`, ' 2022-04-07 16:05:40 [612] [6] ERROR: DLR: REDIS: Error while updating dlr entry for dlr:?:? On 4/14/2022 20:55, lbrezs...@gmx.co.uk wrote: I don't think it's the message. bearer-box access-log looks ordinary 2022-04-14 18:49:56 send-SMS request added - sender:smsuser:XX999 192.168.27.35 target:1XXX9562019 request: 'Test DLR 4' Hower, there is an important piece of information I forgot to mention. Machine that handles DLR 4s correctly: Kannel bearerbox version 1.4.4. Compiler 6.2.1 20161124. System Linux, release 4.9.0-13-amd64 debian 10 = SMP Debian 4.9.228-1 (2020-07-05), machine x86_64 hiredis API 0.13.3 redis_version:3.2.6 Machine that handles DLR 4s incorrectly: Kannel bearerbox version 1.4.5. Compiler 10.1.0. System Linux, release 5.10.0-13-amd64, debian 11 = SMP Debian 5.10.106-1 (2022-03-17), machine x86_64 Using hiredis API 0.14.1 redis_version:6.0.16 On 4/14/2022 18:38, Sayed Hadi Rastgou Haghi wrote: REDIS: redisCommand()
Re: REDIS: redisCommand() failed: ERR unknown command
I don't think it's the message. bearer-box access-log looks ordinary 2022-04-14 18:49:56 send-SMS request added - sender:smsuser:XX999 192.168.27.35 target:1XXX9562019 request: 'Test DLR 4' Hower, there is an important piece of information I forgot to mention. Machine that handles DLR 4s correctly: Kannel bearerbox version 1.4.4. Compiler 6.2.1 20161124. System Linux, release 4.9.0-13-amd64 debian 10 = SMP Debian 4.9.228-1 (2020-07-05), machine x86_64 hiredis API 0.13.3 redis_version:3.2.6 Machine that handles DLR 4s incorrectly: Kannel bearerbox version 1.4.5. Compiler 10.1.0. System Linux, release 5.10.0-13-amd64, debian 11 = SMP Debian 5.10.106-1 (2022-03-17), machine x86_64 Using hiredis API 0.14.1 redis_version:6.0.16 On 4/14/2022 18:38, Sayed Hadi Rastgou Haghi wrote: REDIS: redisCommand()
Re: REDIS: redisCommand() failed: ERR unknown command
Dear akamat, Can you send the failed DLR message as well? In my opinion, the problem is in connection with dlr-message parsing. It can be found in bearer-box access-log or captured with wireshark. On Fri, Apr 15, 2022 at 12:28 AM lbrezs...@gmx.co.uk wrote: > Using Redis for dlr-storage. > > dlr-mask=31, which means everything. > > Lately getting redis errors when receiving DLR 4 > > Anybody came across the same issue? > > Logs: > > 2022-04-14 19:03:08 [2603] [6] DEBUG: DLR[redis]: DLR not destroyed, still > waiting for other delivery report > 2022-04-14 19:03:08 [2603] [6] DEBUG: Updating DLR status in keystore > 2022-04-14 19:03:08 [2603] [6] ERROR: REDIS: redisCommand() failed: `ERR > unknown command `*smsc_id*`, with args beginning with: `27807`, `4`, ' > 2022-04-14 19:03:08 [2603] [6] ERROR: DLR: REDIS: Error while updating dlr > entry for dlr:?:? > 2022-04-14 19:03:08 [2603] [6] DEBUG: new group created `orig_msg' > 2022-04-14 19:03:08 [2603] [6] DEBUG: group=`orig_msg' key=`dlr_mask' > value=`31' > 2022-04-14 19:03:08 [2603] [6] DEBUG: new group created `orig_msg' > 2022-04-14 19:03:08 [2603] [6] DEBUG: group=`orig_msg' key=`dlr_mask' > value=`31' > 2022-04-14 19:03:08 [2603] [6] DEBUG: new group created `smpp' > 2022-04-14 19:03:08 [2603] [6] DEBUG: group=`smpp' key=`dlr_err' value=`' > 2022-04-14 19:03:08 [2603] [6] DEBUG: SMPP[smsc_id]: Sending PDU: > 2022-04-14 19:03:08 [2603] [6] DEBUG: SMPP PDU 0x7faa36eee9f0 dump: > 2022-04-14 19:03:08 [2603] [6] DEBUG: type_name: deliver_sm_resp > 2022-04-14 19:03:08 [2603] [6] DEBUG: command_id: 2147483653 = 0x8005 > 2022-04-14 19:03:08 [2603] [6] DEBUG: command_status: 0 = 0x > 2022-04-14 19:03:08 [2603] [6] DEBUG: sequence_number: 25058 = 0x61e2 > 2022-04-14 19:03:08 [2603] [6] DEBUG: message_id: NULL > 2022-04-14 19:03:08 [2603] [6] DEBUG: SMPP PDU dump ends. > > > On 3/31/2022 03:23, akamat sarat wrote: > > Dear All, > Thank you for your replies. > > We are using kannel 1.4.5 with the following setup: sqlbox -> bearerbox > -> smsc and connected in transceiver mode to SMSC. > we are inserting into mysql send_sms table for sending. > We are working with several SMSC and they where able to provide us with > logs clearly showing that they have submitted a DLR to our kannel server > and have received ACK from our kannel server. > In the example below the final Deliver_sm WE DO NOT see in any of the logs > (access or SMSC) once or ever and the DLR is stuck in dlr table with where > ts = 150903932114 > There aren't any errors in sql box logs (we are using mysql). > We do not see any errors in SMSC logs except: "Could not parse DLR string > sscanf way, fallback to old way. Please report!" > I will reiterate that missing DLRs are happening intermittently about 25% > of them are stuck in dlr table, and even with the error above 75% of them > still come in normally. > Also in the BB logs we have a lot of the following: > " > sms_router: handling message > Routing failed, re-queued > " > Not sure if it is all connected or not ... > Any help would be much appreciated! > > here is an example: ( sensitive parts were redacted) > Our Submit_sm as logged on our server: > 022-03-30 07:11:59 [9] [11] DEBUG: type_name: submit_sm > 2022-03-30 07:11:59 [9] [11] DEBUG: command_id: 4 = 0x0004 > 2022-03-30 07:11:59 [9] [11] DEBUG: command_status: 0 = 0x > 2022-03-30 07:11:59 [9] [11] DEBUG: sequence_number: 8513 = 0x2141 > 2022-03-30 07:11:59 [9] [11] DEBUG: service_type: "" > 2022-03-30 07:11:59 [9] [11] DEBUG: source_addr_ton: 5 = 0x0005 > 2022-03-30 07:11:59 [9] [11] DEBUG: source_addr_npi: 0 = 0x > 2022-03-30 07:11:59 [9] [11] DEBUG: source_addr: "srcaddr" > 2022-03-30 07:11:59 [9] [11] DEBUG: dest_addr_ton: 0 = 0x > 2022-03-30 07:11:59 [9] [11] DEBUG: dest_addr_npi: 0 = 0x > 2022-03-30 07:11:59 [9] [11] DEBUG: destination_addr: "***" > 2022-03-30 07:11:59 [9] [11] DEBUG: esm_class: 3 = 0x0003 > 2022-03-30 07:11:59 [9] [11] DEBUG: protocol_id: 0 = 0x > 2022-03-30 07:11:59 [9] [11] DEBUG: priority_flag: 0 = 0x > 2022-03-30 07:11:59 [9] [11] DEBUG: schedule_delivery_time: NULL > 2022-03-30 07:11:59 [9] [11] DEBUG: validity_period: NULL > 2022-03-30 07:11:59 [9] [11] DEBUG: registered_delivery: 1 = 0x0001 > 2022-03-30 07:11:59 [9] [11] DEBUG: replace_if_present_flag: 0 = > 0x > 2022-03-30 07:11:59 [9] [11] DEBUG: data_coding: 0 = 0x > 2022-03-30 07:11:59 [9] [11] DEBUG: sm_default_msg_id: 0 = 0x > 2022-03-30 07:11:59 [9] [11] DEBUG: sm_length: 48 = 0x0030 > 2022-03-30 07:11:59 [9] [11] DEBUG: short_message: > 2022-03-30 07:11:59 [9] [11] DEBUG:Octet string at 0x7ffb08002320: > 2022-03-30 07:11:59 [9] [11] DEBUG: len: 48 > 2022-03-30 07:11:59 [9] [11] DEBUG: size: 50 > 2022-03-30 07:11:59 [9] [11] DEBUG: immutable: 0 > 2022-03-30 07:11:59 [9] [11] DEBUG: data: MY >
