Opensmppbox Issue
Hi Kannel Users, I have an issue where recently user is constatly reconnecting to the opensmppbox. Digging into the logs found below information. 1008761:2017-03-29 09:50:23 [17929] [3595] ERROR: SMPP: PDU length was too small (4, minimum is 16). 1008762:2017-03-29 09:50:23 [17929] [3595] ERROR: opensmppbox[Zen]: Server sent garbage, ignored. 1008763:2017-03-29 09:50:23 [17929] [3595] ERROR: Invalid SMPP PDU received. 1008764:2017-03-29 09:50:23 [17929] [3595] DEBUG: Thread 3595 (opensmppbox.c:smpp_to_bearerbox) terminates. This only occur recently since few days ago for that particular user. Can't find anything weird or what sequence caused that in the logs aside from above. Kindly advise. Kannel Version : Kannel bearerbox version `svn-r5154M'. Opensmppbox version 1.5.0 Thanks, Arif Noor
RE: Opensmppbox Issue
Hi Rene, I don’t quite understand what you mean by something different from smpp, is there any way for me to trace which transaction / sequence was causing this error, I already done a tcpdump but can’t really find anything peculiar. Thanks again, Arif Noor From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Monday, April 03, 2017 9:26 PM To: Wan Md Arif Noor Bin. Wan Nizam; users@kannel.org Subject: Re: Opensmppbox Issue Most probable cause is that they connect with something different from smpp. -- Origineel bericht -- Van: "Wan Md Arif Noor Bin. Wan Nizam" <md.a...@forest-interactive.com<mailto:md.a...@forest-interactive.com>> Aan: "users@kannel.org<mailto:users@kannel.org>" <users@kannel.org<mailto:users@kannel.org>> Verzonden: 29-3-2017 4:22:28 Onderwerp: Opensmppbox Issue Hi Kannel Users, I have an issue where recently user is constatly reconnecting to the opensmppbox. Digging into the logs found below information. 1008761:2017-03-29 09:50:23 [17929] [3595] ERROR: SMPP: PDU length was too small (4, minimum is 16). 1008762:2017-03-29 09:50:23 [17929] [3595] ERROR: opensmppbox[Zen]: Server sent garbage, ignored. 1008763:2017-03-29 09:50:23 [17929] [3595] ERROR: Invalid SMPP PDU received. 1008764:2017-03-29 09:50:23 [17929] [3595] DEBUG: Thread 3595 (opensmppbox.c:smpp_to_bearerbox) terminates. This only occur recently since few days ago for that particular user. Can’t find anything weird or what sequence caused that in the logs aside from above. Kindly advise. Kannel Version : Kannel bearerbox version `svn-r5154M'. Opensmppbox version 1.5.0 Thanks, Arif Noor
RE: Opensmppbox Issue
I think he replied to the wrong case maybe? Regards, Arif Noor. From: users [mailto:users-boun...@kannel.org] On Behalf Of Vangelis Typaldos Sent: Thursday, April 06, 2017 4:51 PM To: René Kapayo; Stipe Tolj Cc: users@kannel.org Subject: Re: Opensmppbox Issue Rene which was the issue? I have the same issue and these garbage generate nack pdu to the client and disconnections. BR Από: René Kapayo<mailto:yagb...@gmail.com> Αποστολή: Πέμπτη, 6 Απριλίου 2017 11:18 Προς: Stipe Tolj<mailto:st...@kannel.org> Κοιν.: users@kannel.org<mailto:users@kannel.org> Θέμα: Re: Opensmppbox Issue Hi Stipe, Sorry for delay. The issue was resolved. Thanks 2017-04-05 15:48 GMT+01:00 Stipe Tolj <st...@kannel.org<mailto:st...@kannel.org>>: Am 05.04.17 03:25, schrieb Wan Md Arif Noor Bin. Wan Nizam: Hi Rene, I don’t quite understand what you mean by something different from smpp, is there any way for me to trace which transaction / sequence was causing this error, I already done a tcpdump but can’t really find anything peculiar. if you can share the tcpdump capture file to Rene and me, we can have a chance to look into it. -- Best Regards, Stipe Tolj --- Düsseldorf, NRW, Germany Kannel Foundation tolj.org<http://tolj.org> system architecture http://www.kannel.org/http://www.tolj.org/ st...@kannel.org<mailto:st...@kannel.org> s...@tolj.org<mailto:s...@tolj.org> --- -- Rene KAPAYO Ingenieur Informaticien Certifié Prince 2 Fundation Tél.(portable) : +236 75 20 25 79 Domicile (portable) : +236 77 06 40 43 B.P. 2533 Bangui Republique Centrafricaine
Wrong DLR ID.
Hi Users, I found weird thing with kannel today, where when submit an MT it was tagged with different ID but when I checked inside debug log, the ID was correct. This causing "got DLR but could not find message or was not interested in it id<31943697>" error. I don't know where this 831017801 come from. Appreciate your help on this. Kannel bearerbox version `svn-r5186M'. Logs : 2017-08-16 17:11:28 [SMSC:6SeriesConn13] [from:*] [to:**] [msg:82:RM0: To unsubscribe, send OUT 69111..Tel] [FID:831017801] [State:?smpp_resp?] 2017-08-16 17:11:32 [SMSC:6SeriesConn13] [from:+**] [to:*] [msg:0:] [FID:31885349] [State:?smpp?Message+State=2&] 1687656:2017-08-16 17:11:28 [3552] [22] DEBUG: type_name: submit_sm 1687657:2017-08-16 17:11:28 [3552] [22] DEBUG: command_id: 4 = 0x0004 1687658:2017-08-16 17:11:28 [3552] [22] DEBUG: command_status: 0 = 0x 1687659:2017-08-16 17:11:28 [3552] [22] DEBUG: sequence_number: 619 = 0x026b 1687660:2017-08-16 17:11:28 [3552] [22] DEBUG: service_type: NULL 1687661:2017-08-16 17:11:28 [3552] [22] DEBUG: source_addr_ton: 0 = 0x 1687662:2017-08-16 17:11:28 [3552] [22] DEBUG: source_addr_npi: 1 = 0x0001 1687663:2017-08-16 17:11:28 [3552] [22] DEBUG: source_addr: "*" 1687664:2017-08-16 17:11:28 [3552] [22] DEBUG: dest_addr_ton: 1 = 0x0001 1687665:2017-08-16 17:11:28 [3552] [22] DEBUG: dest_addr_npi: 1 = 0x0001 1687666:2017-08-16 17:11:28 [3552] [22] DEBUG: destination_addr: "***" 1687667:2017-08-16 17:11:28 [3552] [22] DEBUG: esm_class: 0 = 0x 1687668:2017-08-16 17:11:28 [3552] [22] DEBUG: protocol_id: 0 = 0x 1687669:2017-08-16 17:11:28 [3552] [22] DEBUG: priority_flag: 0 = 0x 1687670:2017-08-16 17:11:28 [3552] [22] DEBUG: schedule_delivery_time: NULL 1687671:2017-08-16 17:11:28 [3552] [22] DEBUG: validity_period: NULL 1687672:2017-08-16 17:11:28 [3552] [22] DEBUG: registered_delivery: 1 = 0x0001 1687673:2017-08-16 17:11:28 [3552] [22] DEBUG: replace_if_present_flag: 0 = 0x 1687674:2017-08-16 17:11:28 [3552] [22] DEBUG: data_coding: 0 = 0x 1687675:2017-08-16 17:11:28 [3552] [22] DEBUG: sm_default_msg_id: 0 = 0x 1687676:2017-08-16 17:11:28 [3552] [22] DEBUG: sm_length: 82 = 0x0052 1687677:2017-08-16 17:11:28 [3552] [22] DEBUG: short_message: 1687678:2017-08-16 17:11:28 [3552] [22] DEBUG:Octet string at 0x7f32c4000b30: 1687679:2017-08-16 17:11:28 [3552] [22] DEBUG: len: 82 1687680:2017-08-16 17:11:28 [3552] [22] DEBUG: size: 83 1687681:2017-08-16 17:11:28 [3552] [22] DEBUG: immutable: 0 1687682:2017-08-16 17:11:28 [3552] [22] DEBUG: data: 52 4d 30 3a 20 54 6f 20 75 6e 73 75 62 73 63 72 RM0: To unsubscr 1687683:2017-08-16 17:11:28 [3552] [22] DEBUG: data: 69 62 65 2c 20 73 65 6e 64 20 4f 55 54 20 36 39 ibe, send OUT 69 1687684:2017-08-16 17:11:28 [3552] [22] DEBUG: data: 31 31 31 2e 0a 54 65 6c 3a 20 36 30 33 38 36 30 111..Tel: 603860 1687685:2017-08-16 17:11:28 [3552] [22] DEBUG: data: 31 30 31 30 37 2c 49 6e 6x 6x 6x 6x 7x 2x 4x 7x 10107 1687686:2017-08-16 17:11:28 [3552] [22] DEBUG: data: 69 61 20 50 61 63 69 66 69 63 20 53 64 6e 20 42 1687687:2017-08-16 17:11:28 [3552] [22] DEBUG: data: 68 64 1687688:2017-08-16 17:11:28 [3552] [22] DEBUG:Octet string dump ends. 1687689:2017-08-16 17:11:28 [3552] [22] DEBUG: SMPP PDU dump ends. 1687692:2017-08-16 17:11:28 [3552] [22] DEBUG: SMPP[6SeriesConn13]: Got PDU: 1687693:2017-08-16 17:11:28 [3552] [22] DEBUG: SMPP PDU 0x7f32c4001e40 dump: 1687694:2017-08-16 17:11:28 [3552] [22] DEBUG: type_name: submit_sm_resp 1687695:2017-08-16 17:11:28 [3552] [22] DEBUG: command_id: 2147483652 = 0x8004 1687696:2017-08-16 17:11:28 [3552] [22] DEBUG: command_status: 0 = 0x 1687697:2017-08-16 17:11:28 [3552] [22] DEBUG: sequence_number: 619 = 0x026b 1687698:2017-08-16 17:11:28 [3552] [22] DEBUG: message_id: "31885349" 1687699:2017-08-16 17:11:28 [3552] [22] DEBUG: SMPP PDU dump ends. 1687802:2017-08-16 17:11:32 [3552] [22] DEBUG: SMPP PDU 0x7f32c4006850 dump: 1687803:2017-08-16 17:11:32 [3552] [22] DEBUG: type_name: deliver_sm 1687804:2017-08-16 17:11:32 [3552] [22] DEBUG: command_id: 5 = 0x0005 1687805:2017-08-16 17:11:32 [3552] [22] DEBUG: command_status: 0 = 0x 1687806:2017-08-16 17:11:32 [3552] [22] DEBUG: sequence_number: 31885417 = 0x01e68869 1687807:2017-08-16 17:11:32 [3552] [22] DEBUG: service_type: NULL 1687808:2017-08-16 17:11:32 [3552] [22] DEBUG: source_addr_ton: 1 = 0x0001 1687809:2017-08-16 17:11:32 [3552] [22] DEBUG: source_addr_npi: 1 = 0x0001 1687810:2017-08-16 17:11:32 [3552] [22] DEBUG: source_addr: "***" 1687811:2017-08-16 17:11:32 [3552] [22] DEBUG: dest_addr_ton: 0 = 0x 1687812:2017-08-16 17:11:32 [3552] [22] DEBUG: dest_addr_npi: 1 = 0x0001 1687813:2017-08-16 17:11:32 [3552] [22] DEBUG: destination_addr:
RE: Wrong DLR ID.
Hi Davor, Super, I didn’t notice the msg-id type in my configuration. I changed it and its working properly now. Thanks a lot for the assist. Best Regards, Arif Noor. From: Davor Spasoski [mailto:davor.spaso...@onevip.mk] Sent: Wednesday, August 16, 2017 6:41 PM To: Wan Md Arif Noor Bin. Wan Nizam; users@kannel.org Subject: RE: Wrong DLR ID. Check your ID numbering bases for submit_sm and deliver_sm. Looks like you are not using the same base for submit and deliver. 3188534916 = 83101780110 Msg-id-type is the parameter you should be looking at Davor Spasoski From: users [mailto:users-boun...@kannel.org] On Behalf Of Wan Md Arif Noor Bin. Wan Nizam Sent: Wednesday, August 16, 2017 11:40 AM To: users@kannel.org<mailto:users@kannel.org> Subject: Wrong DLR ID. Hi Users, I found weird thing with kannel today, where when submit an MT it was tagged with different ID but when I checked inside debug log, the ID was correct. This causing “got DLR but could not find message or was not interested in it id<31943697>” error. I don’t know where this 831017801 come from. Appreciate your help on this. Kannel bearerbox version `svn-r5186M'. Logs : 2017-08-16 17:11:28 [SMSC:6SeriesConn13] [from:*] [to:**] [msg:82:RM0: To unsubscribe, send OUT 69111..Tel] [FID:831017801] [State:?smpp_resp?] 2017-08-16 17:11:32 [SMSC:6SeriesConn13] [from:+**] [to:*] [msg:0:] [FID:31885349] [State:?smpp?Message+State=2&] 1687656:2017-08-16 17:11:28 [3552] [22] DEBUG: type_name: submit_sm 1687657:2017-08-16 17:11:28 [3552] [22] DEBUG: command_id: 4 = 0x0004 1687658:2017-08-16 17:11:28 [3552] [22] DEBUG: command_status: 0 = 0x 1687659:2017-08-16 17:11:28 [3552] [22] DEBUG: sequence_number: 619 = 0x026b 1687660:2017-08-16 17:11:28 [3552] [22] DEBUG: service_type: NULL 1687661:2017-08-16 17:11:28 [3552] [22] DEBUG: source_addr_ton: 0 = 0x 1687662:2017-08-16 17:11:28 [3552] [22] DEBUG: source_addr_npi: 1 = 0x0001 1687663:2017-08-16 17:11:28 [3552] [22] DEBUG: source_addr: "*" 1687664:2017-08-16 17:11:28 [3552] [22] DEBUG: dest_addr_ton: 1 = 0x0001 1687665:2017-08-16 17:11:28 [3552] [22] DEBUG: dest_addr_npi: 1 = 0x0001 1687666:2017-08-16 17:11:28 [3552] [22] DEBUG: destination_addr: "***" 1687667:2017-08-16 17:11:28 [3552] [22] DEBUG: esm_class: 0 = 0x 1687668:2017-08-16 17:11:28 [3552] [22] DEBUG: protocol_id: 0 = 0x 1687669:2017-08-16 17:11:28 [3552] [22] DEBUG: priority_flag: 0 = 0x 1687670:2017-08-16 17:11:28 [3552] [22] DEBUG: schedule_delivery_time: NULL 1687671:2017-08-16 17:11:28 [3552] [22] DEBUG: validity_period: NULL 1687672:2017-08-16 17:11:28 [3552] [22] DEBUG: registered_delivery: 1 = 0x0001 1687673:2017-08-16 17:11:28 [3552] [22] DEBUG: replace_if_present_flag: 0 = 0x 1687674:2017-08-16 17:11:28 [3552] [22] DEBUG: data_coding: 0 = 0x 1687675:2017-08-16 17:11:28 [3552] [22] DEBUG: sm_default_msg_id: 0 = 0x 1687676:2017-08-16 17:11:28 [3552] [22] DEBUG: sm_length: 82 = 0x0052 1687677:2017-08-16 17:11:28 [3552] [22] DEBUG: short_message: 1687678:2017-08-16 17:11:28 [3552] [22] DEBUG:Octet string at 0x7f32c4000b30: 1687679:2017-08-16 17:11:28 [3552] [22] DEBUG: len: 82 1687680:2017-08-16 17:11:28 [3552] [22] DEBUG: size: 83 1687681:2017-08-16 17:11:28 [3552] [22] DEBUG: immutable: 0 1687682:2017-08-16 17:11:28 [3552] [22] DEBUG: data: 52 4d 30 3a 20 54 6f 20 75 6e 73 75 62 73 63 72 RM0: To unsubscr 1687683:2017-08-16 17:11:28 [3552] [22] DEBUG: data: 69 62 65 2c 20 73 65 6e 64 20 4f 55 54 20 36 39 ibe, send OUT 69 1687684:2017-08-16 17:11:28 [3552] [22] DEBUG: data: 31 31 31 2e 0a 54 65 6c 3a 20 36 30 33 38 36 30 111..Tel: 603860 1687685:2017-08-16 17:11:28 [3552] [22] DEBUG: data: 31 30 31 30 37 2c 49 6e 6x 6x 6x 6x 7x 2x 4x 7x 10107 1687686:2017-08-16 17:11:28 [3552] [22] DEBUG: data: 69 61 20 50 61 63 69 66 69 63 20 53 64 6e 20 42 1687687:2017-08-16 17:11:28 [3552] [22] DEBUG: data: 68 64 1687688:2017-08-16 17:11:28 [3552] [22] DEBUG:Octet string dump ends. 1687689:2017-08-16 17:11:28 [3552] [22] DEBUG: SMPP PDU dump ends. 1687692:2017-08-16 17:11:28 [3552] [22] DEBUG: SMPP[6SeriesConn13]: Got PDU: 1687693:2017-08-16 17:11:28 [3552] [22] DEBUG: SMPP PDU 0x7f32c4001e40 dump: 1687694:2017-08-16 17:11:28 [3552] [22] DEBUG: type_name: submit_sm_resp 1687695:2017-08-16 17:11:28 [3552] [22] DEBUG: command_id: 2147483652 = 0x8004 1687696:2017-08-16 17:11:28 [3552] [22] DEBUG: command_status: 0 = 0x 1687697:2017-08-16 17:11:28 [3552] [22] DEBUG: sequence_number: 619 = 0x026b 1687698:2017-08-16 17:11:28 [3552] [22] DEBUG: message_id: "31885349" 1687699:2017-08-16 17:11:28 [3552] [22] DEBUG: SMPP PDU dump ends. 1687802:2017-08-16 17:11:32 [3552] [22] DEBUG: SMPP PDU 0x7f32c4006850 dump: 1687803:2017
OPENSMPPBOX Panic
Hi Kannel Users, I'm having issues with Opensmppbox which will go into PANIC with below error every day after upgrading to new SVN 'svn-r5186M' 09th May 2017-05-09 05:52:42 [29877] [97] PANIC: gwlib/octstr.c:2564: seems_valid_real: Assertion `ostr->data != NULL' failed. (Called from gwlib/octstr.c:325:octstr_destroy.) 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox(gw_backtrace+0xae) [0x45db6e] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox(gw_panic+0x159) [0x45dcd9] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x45fb60] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox(octstr_destroy+0x1d) [0x461c8d] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x40e787] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x41105f] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x4546a9] 2017-05-09 05:52:42 [29877] [97] PANIC: /lib64/libpthread.so.0(+0x7aa1) [0x7fde85adeaa1] 2017-05-09 05:52:42 [29877] [97] PANIC: /lib64/libc.so.6(clone+0x6d) [0x7fde851da93d] 2017-05-09 12:53:12 [6023] [88] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x46b3fc] 2017-05-09 12:53:12 [6023] [88] PANIC: /lib64/libpthread.so.0(+0xf7e0) [0x7f27f82977e0] 2017-05-09 12:53:12 [6023] [88] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x45f8fb] 2017-05-09 12:53:12 [6023] [88] PANIC: /usr/local/kannel2/sbin/opensmppbox(octstr_get_cstr_real+0x13) [0x45fb83] 2017-05-09 12:53:12 [6023] [88] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x41051a] 2017-05-09 12:53:12 [6023] [88] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x4546a9] 2017-05-09 12:53:12 [6023] [88] PANIC: /lib64/libpthread.so.0(+0x7aa1) [0x7f27f828faa1] 2017-05-09 12:53:12 [6023] [88] PANIC: /lib64/libc.so.6(clone+0x6d) [0x7f27f798b93d] 10th May 2017-05-10 16:00:40 [27593] [72] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x46b3fc] 2017-05-10 16:00:40 [27593] [72] PANIC: /lib64/libpthread.so.0(+0xf7e0) [0x7f1b36cd17e0] 2017-05-10 16:00:40 [27593] [72] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x45f8fb] 2017-05-10 16:00:40 [27593] [72] PANIC: /usr/local/kannel2/sbin/opensmppbox(octstr_get_cstr_real+0x13) [0x45fb83] 2017-05-10 16:00:40 [27593] [72] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x41051a] 2017-05-10 16:00:40 [27593] [72] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x4546a9] 2017-05-10 16:00:40 [27593] [72] PANIC: /lib64/libpthread.so.0(+0x7aa1) [0x7f1b36cc9aa1] 2017-05-10 16:00:40 [27593] [72] PANIC: /lib64/libc.so.6(clone+0x6d) [0x7f1b363c593d] Opensmppbox Configuration group = core dlr-storage = mysql group = opensmppbox opensmppbox-id = FSMPP opensmppbox-port = 3476 bearerbox-host = localhost bearerbox-port = 14002 log-level = 0 log-file = "/var/log/kannel/smppbox/debug.log" our-system-id = fSystem use-systemid-as-smsboxid = 1 smpp-logins = "/opt/kannel/smpplogins.txt" group = mysql-connection id = mydlr host = localhost username = * password = * database = kannel max-connections = 6 group = dlr-db id = mydlr table = dlr_smpp 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 = boxcid Kindly assist Regards and thanks, Arif Noor
RE: OPENSMPPBOX Panic
Hi Users, Anyone having this same issue? Need assist urgently. Thank you and Regards, Arif Noor From: users [mailto:users-boun...@kannel.org] On Behalf Of Wan Md Arif Noor Bin. Wan Nizam Sent: Thursday, May 11, 2017 9:49 AM To: users@kannel.org Subject: OPENSMPPBOX Panic This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing> Feedback<http://aka.ms/SafetyTipsFeedback> Hi Kannel Users, I'm having issues with Opensmppbox which will go into PANIC with below error every day after upgrading to new SVN 'svn-r5186M' 09th May 2017-05-09 05:52:42 [29877] [97] PANIC: gwlib/octstr.c:2564: seems_valid_real: Assertion `ostr->data != NULL' failed. (Called from gwlib/octstr.c:325:octstr_destroy.) 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox(gw_backtrace+0xae) [0x45db6e] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox(gw_panic+0x159) [0x45dcd9] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x45fb60] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox(octstr_destroy+0x1d) [0x461c8d] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x40e787] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x41105f] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x4546a9] 2017-05-09 05:52:42 [29877] [97] PANIC: /lib64/libpthread.so.0(+0x7aa1) [0x7fde85adeaa1] 2017-05-09 05:52:42 [29877] [97] PANIC: /lib64/libc.so.6(clone+0x6d) [0x7fde851da93d] 2017-05-09 12:53:12 [6023] [88] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x46b3fc] 2017-05-09 12:53:12 [6023] [88] PANIC: /lib64/libpthread.so.0(+0xf7e0) [0x7f27f82977e0] 2017-05-09 12:53:12 [6023] [88] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x45f8fb] 2017-05-09 12:53:12 [6023] [88] PANIC: /usr/local/kannel2/sbin/opensmppbox(octstr_get_cstr_real+0x13) [0x45fb83] 2017-05-09 12:53:12 [6023] [88] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x41051a] 2017-05-09 12:53:12 [6023] [88] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x4546a9] 2017-05-09 12:53:12 [6023] [88] PANIC: /lib64/libpthread.so.0(+0x7aa1) [0x7f27f828faa1] 2017-05-09 12:53:12 [6023] [88] PANIC: /lib64/libc.so.6(clone+0x6d) [0x7f27f798b93d] 10th May 2017-05-10 16:00:40 [27593] [72] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x46b3fc] 2017-05-10 16:00:40 [27593] [72] PANIC: /lib64/libpthread.so.0(+0xf7e0) [0x7f1b36cd17e0] 2017-05-10 16:00:40 [27593] [72] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x45f8fb] 2017-05-10 16:00:40 [27593] [72] PANIC: /usr/local/kannel2/sbin/opensmppbox(octstr_get_cstr_real+0x13) [0x45fb83] 2017-05-10 16:00:40 [27593] [72] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x41051a] 2017-05-10 16:00:40 [27593] [72] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x4546a9] 2017-05-10 16:00:40 [27593] [72] PANIC: /lib64/libpthread.so.0(+0x7aa1) [0x7f1b36cc9aa1] 2017-05-10 16:00:40 [27593] [72] PANIC: /lib64/libc.so.6(clone+0x6d) [0x7f1b363c593d] Opensmppbox Configuration group = core dlr-storage = mysql group = opensmppbox opensmppbox-id = FSMPP opensmppbox-port = 3476 bearerbox-host = localhost bearerbox-port = 14002 log-level = 0 log-file = "/var/log/kannel/smppbox/debug.log" our-system-id = fSystem use-systemid-as-smsboxid = 1 smpp-logins = "/opt/kannel/smpplogins.txt" group = mysql-connection id = mydlr host = localhost username = * password = * database = kannel max-connections = 6 group = dlr-db id = mydlr table = dlr_smpp 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 = boxcid Kindly assist Regards and thanks, Arif Noor
RE: OPENSMPPBOX Panic
Hi Again, I'm getting the PANIC more and more each day and I still can't find what causing it. I can just revert to the old version, however the old version has another issue with "Garbage PDU" which I like to avoid as it keeps disconnecting user, but PANIC issue is more troubling as it crashed and disconnecting all user instead of one. Below are the latest 2 crashes log : 2017-05-22 23:03:34 [3366] [83] PANIC: gwlib/octstr.c:2569: seems_valid_real: Assertion `ostr->data[ostr->len] == '\0'' failed. (Called from gwlib/octstr.c:325:octstr_destroy.) 2017-05-22 23:03:34 [3366] [83] PANIC: /usr/local/kannel2/sbin/opensmppbox(gw_backtrace+0xae) [0x45db6e] 2017-05-22 23:03:34 [3366] [83] PANIC: /usr/local/kannel2/sbin/opensmppbox(gw_panic+0x159) [0x45dcd9] 2017-05-22 23:03:34 [3366] [83] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x45f95b] 2017-05-22 23:03:34 [3366] [83] PANIC: /usr/local/kannel2/sbin/opensmppbox(octstr_destroy+0x1d) [0x461c8d] 2017-05-22 23:03:34 [3366] [83] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x40e7bd] 2017-05-22 23:03:34 [3366] [83] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x41105f] 2017-05-22 23:03:34 [3366] [83] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x4546a9] 2017-05-22 23:03:34 [3366] [83] PANIC: /lib64/libpthread.so.0(+0x7aa1) [0x7fa32a0eaaa1] 2017-05-22 23:03:34 [3366] [83] PANIC: /lib64/libc.so.6(clone+0x6d) [0x7fa3297e693d] addr2line -e /usr/local/kannel2/sbin/opensmppbox 0x45db6e 0x45dcd9 0x45f95b 0x461c8d 0x40e7bd 0x41105f 0x4546a9 /home/trunk/gwlib/log.c:572 /home/trunk/gwlib/log.c:608 /home/trunk/gwlib/octstr.c:2571 /home/trunk/gwlib/octstr.c:326 /home/opensmppbox/trunk/gw/opensmppbox.c:1788 /home/opensmppbox/trunk/gw/opensmppbox.c:2150 /home/trunk/gwlib/gwthread-pthread.c:391 2017-05-22 23:21:28 [31827] [79] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x46b3fc] 2017-05-22 23:21:28 [31827] [79] PANIC: /lib64/libpthread.so.0(+0xf7e0) [0x7fd664b747e0] 2017-05-22 23:21:28 [31827] [79] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x45f992] 2017-05-22 23:21:28 [31827] [79] PANIC: /usr/local/kannel2/sbin/opensmppbox(octstr_destroy+0x1d) [0x461c8d] 2017-05-22 23:21:28 [31827] [79] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x40e787] 2017-05-22 23:21:28 [31827] [79] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x41105f] 2017-05-22 23:21:28 [31827] [79] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x4546a9] 2017-05-22 23:21:28 [31827] [79] PANIC: /lib64/libpthread.so.0(+0x7aa1) [0x7fd664b6caa1] 2017-05-22 23:21:28 [31827] [79] PANIC: /lib64/libc.so.6(clone+0x6d) [0x7fd66426893d] addr2line -e /usr/local/kannel2/sbin/opensmppbox 0x46b3fc 0x45f992 0x461c8d 0x40e787 0x41105f 0x4546a9 /home/trunk/gwlib/utils.c:168 /home/trunk/gwlib/octstr.c:2568 /home/trunk/gwlib/octstr.c:326 /home/opensmppbox/trunk/gw/opensmppbox.c:1779 /home/opensmppbox/trunk/gw/opensmppbox.c:2150 /home/trunk/gwlib/gwthread-pthread.c:391 Kindly need your assistance on this, do let me know if you need more information. Thanks! Arif Noor From: users [mailto:users-boun...@kannel.org] On Behalf Of Wan Md Arif Noor Bin. Wan Nizam Sent: Tuesday, May 16, 2017 10:42 AM To: users@kannel.org Subject: RE: OPENSMPPBOX Panic Hi Users, Anyone having this same issue? Need assist urgently. Thank you and Regards, Arif Noor From: users [mailto:users-boun...@kannel.org] On Behalf Of Wan Md Arif Noor Bin. Wan Nizam Sent: Thursday, May 11, 2017 9:49 AM To: users@kannel.org<mailto:users@kannel.org> Subject: OPENSMPPBOX Panic This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing> Feedback<http://aka.ms/SafetyTipsFeedback> Hi Kannel Users, I'm having issues with Opensmppbox which will go into PANIC with below error every day after upgrading to new SVN 'svn-r5186M' 09th May 2017-05-09 05:52:42 [29877] [97] PANIC: gwlib/octstr.c:2564: seems_valid_real: Assertion `ostr->data != NULL' failed. (Called from gwlib/octstr.c:325:octstr_destroy.) 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox(gw_backtrace+0xae) [0x45db6e] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox(gw_panic+0x159) [0x45dcd9] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x45fb60] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox(octstr_destroy+0x1d) [0x461c8d] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x40e787] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x41105f] 2017-05-09 05:52:42 [29877] [97] PANIC: /usr/local/kannel2/sbin/opensmppbox() [0x4546a9] 2017-05-09 05:52:42 [29877] [97] PANIC: /lib64/libpthread.so.0(+0x7aa1) [0x7fde85adeaa1] 2017-05-09 05:52:42 [29877] [97] PANIC: /lib64/libc.so.6(clone+0x6d) [0x7fde851da93d] 2017-05-09 12:53:12 [6023] [88] PANIC: /usr/local/kannel2/sbin
MO Routing to Different Host
Hi Users, We have two host running kannel connecting to the same SMSC. The issue is with Long MO where SMSC tend to split it and send to host 1 and host 2 respectively and this causing kannel on each host waiting for the MO parts. My question to this, Is it possible to route inbound MO to kannel in different machine/host as in MO receive on Host 2 rerouted to Host 1. Kannel Host 1 <--| |--->SMSC Kannel Host 2 <--| Logs of MO (MO discarded after some time has passed). Host 1 2017-09-27 17:39:47 [2207] [7] DEBUG: Got part 2 [ref 227, total parts 2] of message Host 2 2017-09-27 17:39:43 [2185] [7] DEBUG: Got part 1 [ref 227, total parts 2] of message Thank you and Regards, Arif Noor
UDH Length Question
Hi Users,
It's been a while, I have a question regarding UDH, currently I have few smpp
connections to SMSC and sometimes when kannel submit the long sms, it will get
rejected with 'Message length is invalid'.
Further check with the SMSC they mentioned that the UDH Contains 'Extended GSM
Characters ( ^ \ { } [ ] ~ |' that take 2 of the 160 characters of an sms.
Exp :
05 00 03 5c 02 01 49 54 6c 65 61 64 65 72 73 73 ...\..ITleaderss
[cid:image001.jpg@01D35979.30EC1710]
Is there any way to exclude this characters from being used in UDH?
Regards,
Arif Noor
[event]
Incoming MO UDH
Hi Kannel User, Based from the user guide using sms-combine-concatenated-mo to true will instruct kannel to combine MO before sending to smsbox, however I want kannel to forward the MO our application without combining it thus I set it to false, Here is the issue, the UDH from smsbox is weird. In the access logs it looked fine but the one in smsbox isn't In access log : udh:0500036C0201 In smsbox log : udh=%05%00%03l%02%01 Why it become like that and is there any configuration that I need to set so it doesn't become like that? Thanks. Regards, Arif Noor
RE: Inverted Exclamation mark and question mark issue.
Hi All,
Thanks for the response, I have removed alt-charset from the config but now all
I get is @.
curl
http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=601132495424=%C2%A1=0
curl
http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=601132495424=%C2%A1=UTF-8
curl
http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=601132495424=%A1=ISO-8859-1
2018-04-05 10:21:02 [16025] [7] DEBUG: SMPP PDU 0x7f69dc000a10 dump:
2018-04-05 10:21:02 [16025] [7] DEBUG: type_name: submit_sm
2018-04-05 10:21:02 [16025] [7] DEBUG: command_id: 4 = 0x0004
2018-04-05 10:21:02 [16025] [7] DEBUG: command_status: 0 = 0x
2018-04-05 10:21:02 [16025] [7] DEBUG: sequence_number: 31 = 0x001f
2018-04-05 10:21:02 [16025] [7] DEBUG: service_type: NULL
2018-04-05 10:21:02 [16025] [7] DEBUG: source_addr_ton: 0 = 0x
2018-04-05 10:21:02 [16025] [7] DEBUG: source_addr_npi: 1 = 0x0001
2018-04-05 10:21:02 [16025] [7] DEBUG: source_addr: "6"
2018-04-05 10:21:02 [16025] [7] DEBUG: dest_addr_ton: 1 = 0x0001
2018-04-05 10:21:02 [16025] [7] DEBUG: dest_addr_npi: 1 = 0x0001
2018-04-05 10:21:02 [16025] [7] DEBUG: destination_addr: "601132495424"
2018-04-05 10:21:02 [16025] [7] DEBUG: esm_class: 3 = 0x0003
2018-04-05 10:21:02 [16025] [7] DEBUG: protocol_id: 0 = 0x
2018-04-05 10:21:02 [16025] [7] DEBUG: priority_flag: 0 = 0x
2018-04-05 10:21:02 [16025] [7] DEBUG: schedule_delivery_time: NULL
2018-04-05 10:21:02 [16025] [7] DEBUG: validity_period: NULL
2018-04-05 10:21:02 [16025] [7] DEBUG: registered_delivery: 0 = 0x
2018-04-05 10:21:02 [16025] [7] DEBUG: replace_if_present_flag: 0 = 0x
2018-04-05 10:21:02 [16025] [7] DEBUG: data_coding: 0 = 0x
2018-04-05 10:21:02 [16025] [7] DEBUG: sm_default_msg_id: 0 = 0x
2018-04-05 10:21:02 [16025] [7] DEBUG: sm_length: 1 = 0x0001
2018-04-05 10:21:02 [16025] [7] DEBUG: short_message: "@"
2018-04-05 10:21:02 [16025] [7] DEBUG: SMPP PDU dump ends.
Tested all the character of GSM only
@£$¥èéùìòÇØøÅåΔ_ΦΓΛΩΠΨΣΘΞ^{}\[~]|€ÆæßÉ!\"#%&'()*+,-./:;<=>? Is working while
the ¤¡ÄÖÑܧ¿äöñüà is not regardless of charset used in the parameter.
¤¡ÄÖÑܧ¿äöñüà
curl
http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=601132495424=%C2%A4%C2%A1%C3%84%C3%96%C3%91%C3%9C%C2%A7%C2%BF%C3%A4%C3%B6%C3%B1%C3%BC%C3%A0
2018-04-05 10:54:07 [16129] [7] DEBUG: SMPP PDU 0x7f09c8000a10 dump:
2018-04-05 10:54:07 [16129] [7] DEBUG: type_name: submit_sm
2018-04-05 10:54:07 [16129] [7] DEBUG: command_id: 4 = 0x0004
2018-04-05 10:54:07 [16129] [7] DEBUG: command_status: 0 = 0x
2018-04-05 10:54:07 [16129] [7] DEBUG: sequence_number: 56 = 0x0038
2018-04-05 10:54:07 [16129] [7] DEBUG: service_type: NULL
2018-04-05 10:54:07 [16129] [7] DEBUG: source_addr_ton: 0 = 0x
2018-04-05 10:54:07 [16129] [7] DEBUG: source_addr_npi: 1 = 0x0001
2018-04-05 10:54:07 [16129] [7] DEBUG: source_addr: "6"
2018-04-05 10:54:07 [16129] [7] DEBUG: dest_addr_ton: 1 = 0x0001
2018-04-05 10:54:07 [16129] [7] DEBUG: dest_addr_npi: 1 = 0x0001
2018-04-05 10:54:07 [16129] [7] DEBUG: destination_addr: "601132495424"
2018-04-05 10:54:07 [16129] [7] DEBUG: esm_class: 3 = 0x0003
2018-04-05 10:54:07 [16129] [7] DEBUG: protocol_id: 0 = 0x
2018-04-05 10:54:07 [16129] [7] DEBUG: priority_flag: 0 = 0x
2018-04-05 10:54:07 [16129] [7] DEBUG: schedule_delivery_time: NULL
2018-04-05 10:54:07 [16129] [7] DEBUG: validity_period: NULL
2018-04-05 10:54:07 [16129] [7] DEBUG: registered_delivery: 0 = 0x
2018-04-05 10:54:07 [16129] [7] DEBUG: replace_if_present_flag: 0 = 0x
2018-04-05 10:54:07 [16129] [7] DEBUG: data_coding: 0 = 0x
2018-04-05 10:54:07 [16129] [7] DEBUG: sm_default_msg_id: 0 = 0x
2018-04-05 10:54:07 [16129] [7] DEBUG: sm_length: 13 = 0x000d
2018-04-05 10:54:07 [16129] [7] DEBUG: short_message:
2018-04-05 10:54:07 [16129] [7] DEBUG:Octet string at 0x7f09c8000c70:
2018-04-05 10:54:07 [16129] [7] DEBUG: len: 13
2018-04-05 10:54:07 [16129] [7] DEBUG: size: 27
2018-04-05 10:54:07 [16129] [7] DEBUG: immutable: 0
2018-04-05 10:54:07 [16129] [7] DEBUG: data: 24 40 5b 5c 5d 5e 5f 60 7b 7c
7d 7e 7f$@[\]^_`{|}~.
2018-04-05 10:54:07 [16129] [7] DEBUG:Octet string dump ends.
2018-04-05 10:54:07 [16129] [7] DEBUG: SMPP PDU dump ends.
Kindly do let me know if there’s anything else that I can try, appreciate it.
Regards
Arif Noor
From: Alexander Malysh <malys...@gmail.com> On Behalf Of amal...@kannel.org
Sent: Wednesday, April 04, 2018 11:46 PM
To: Wan Md Arif Noor Bin. Wan Nizam <md.a...@forest-interactive.com>
Cc: users@kannel.org
Subject: Re: Inverted Exclamation mark and question mark issue.
This is in most cases wrong:
2018-
RE: Inverted Exclamation mark and question mark issue.
Hi Davor,
I get @ for "¡” while for” ¤ÄÖÑܧ¿äöñüà” it converted into “$[\]^_`{|}~.”
Tried with your suggestion with
“http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=601132495424=¤¡ÄÖÑܧ¿äöñüà=1=0=;
and
“http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=601132495424%C2%A4%C2%A1%C3%84%C3%96%C3%91%C3%9C%C2%A7%C2%BF%C3%A4%C3%B6%C3%B1%C3%BC%C3%A0=1=0=;
And from the debug log it still converted into $@[\]^_`{|}~.
29300427:2018-04-09 09:59:15 [28605] [7] DEBUG: SMPP PDU 0x7f14e4000a10 dump:
29300428:2018-04-09 09:59:15 [28605] [7] DEBUG: type_name: submit_sm
29300429:2018-04-09 09:59:15 [28605] [7] DEBUG: command_id: 4 = 0x0004
29300430:2018-04-09 09:59:15 [28605] [7] DEBUG: command_status: 0 = 0x
29300431:2018-04-09 09:59:15 [28605] [7] DEBUG: sequence_number: 16137 =
0x3f09
29300432:2018-04-09 09:59:15 [28605] [7] DEBUG: service_type: NULL
29300433:2018-04-09 09:59:15 [28605] [7] DEBUG: source_addr_ton: 0 =
0x
29300434:2018-04-09 09:59:15 [28605] [7] DEBUG: source_addr_npi: 1 =
0x0001
29300435:2018-04-09 09:59:15 [28605] [7] DEBUG: source_addr: "6"
29300436:2018-04-09 09:59:15 [28605] [7] DEBUG: dest_addr_ton: 1 = 0x0001
29300437:2018-04-09 09:59:15 [28605] [7] DEBUG: dest_addr_npi: 1 = 0x0001
29300438:2018-04-09 09:59:15 [28605] [7] DEBUG: destination_addr:
"601132495424"
29300439:2018-04-09 09:59:15 [28605] [7] DEBUG: esm_class: 3 = 0x0003
29300440:2018-04-09 09:59:15 [28605] [7] DEBUG: protocol_id: 0 = 0x
29300441:2018-04-09 09:59:15 [28605] [7] DEBUG: priority_flag: 0 = 0x
29300442:2018-04-09 09:59:15 [28605] [7] DEBUG: schedule_delivery_time: NULL
29300443:2018-04-09 09:59:15 [28605] [7] DEBUG: validity_period: NULL
29300444:2018-04-09 09:59:15 [28605] [7] DEBUG: registered_delivery: 0 =
0x
29300445:2018-04-09 09:59:15 [28605] [7] DEBUG: replace_if_present_flag: 0 =
0x
29300446:2018-04-09 09:59:15 [28605] [7] DEBUG: data_coding: 241 = 0x00f1
29300447:2018-04-09 09:59:15 [28605] [7] DEBUG: sm_default_msg_id: 0 =
0x
29300448:2018-04-09 09:59:15 [28605] [7] DEBUG: sm_length: 13 = 0x000d
29300449:2018-04-09 09:59:15 [28605] [7] DEBUG: short_message:
29300450:2018-04-09 09:59:15 [28605] [7] DEBUG:Octet string at
0x7f14e4005690:
29300451:2018-04-09 09:59:15 [28605] [7] DEBUG: len: 13
29300452:2018-04-09 09:59:15 [28605] [7] DEBUG: size: 27
29300453:2018-04-09 09:59:15 [28605] [7] DEBUG: immutable: 0
29300454:2018-04-09 09:59:15 [28605] [7] DEBUG: data: 24 40 5b 5c 5d 5e 5f
60 7b 7c 7d 7e 7f$@[\]^_`{|}~.
29300455:2018-04-09 09:59:15 [28605] [7] DEBUG:Octet string dump ends.
29300456:2018-04-09 09:59:15 [28605] [7] DEBUG: SMPP PDU dump ends.
Regards less of charset used I’m still getting result as above. I understand
that hex 24 is ¤ but why it shows $ instead?
This might sounds dumb, how do I force kannel to use GSM charset?
Thanks for all the response so far, cheers,
Arif Noor.
From: Davor Spasoski <davor.spaso...@onevip.mk>
Sent: Friday, April 06, 2018 7:02 PM
To: Wan Md Arif Noor Bin. Wan Nizam <md.a...@forest-interactive.com>
Cc: amal...@kannel.org; users@kannel.org
Subject: Re: Inverted Exclamation mark and question mark issue.
Do you mean you get “@“ for any of the "¤¡ÄÖÑܧ¿äöñüà" or just for “¡” ?
If so, the SMPP part of the SMSC does some strange character conversions. From
my experience, the SMSC usually sets some sort of ISO-8859-1 as a default
alphabet on SMPP level and than converts (with losses) to GSM alphabet. GSM
7-bit is usually supported with DCS above 240 so try setting alt-dcs =1, coding
= 0 and charset left blank (utf-8).
Lately, some SMSCs support UTF-8 as default and even something called
"Esaped-Latin-1" or "X-ISO-8859-GSM-escaped" for which I could not find any
standardization, but that is basically an 8-bit alphabet, having the common
GSM/ASCII characters plus the extension with the GSM only characters. In order
to support that, you will need a custom charset translation on your side.
Try the alt-dcs with coding=0 and if not successful, ask to set the default
SMSC/SMPP alphabet as GSM.
BR,
Davor
On Apr 5, 2018, at 4:56 AM, Wan Md Arif Noor Bin. Wan Nizam
<md.a...@forest-interactive.com<mailto:md.a...@forest-interactive.com>> wrote:
http://span.st<%3ca%20href=>" class="">span.st<http://span.st>
{mso-style-name:st;} span.EmailStyle21 {mso-style-type:personal-reply;
font-family:"Century Gothic",sans-serif; color:windowtext;} .MsoChpDefault
{mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in
11.0in; margin:99.25pt 85.05pt 85.05pt 85.05pt;} div.WordSection1
{page:WordSection1;} -->
Hi All,
Thanks for the response, I have removed alt-charset from the config but now all
I get is @.
Inverted Exclamation mark and question mark issue.
Hello Users, I’m having an issue with sending both inverted exclamation mark (¡) and inverted question mark (¿) , it seems like it was converted to B! and B? instead. Tried with all below parameter but none working except for UCS-2 which I want to avoid. curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=¿; Result : B? curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=%C2%BF; Result :B? curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=¿=0=1; Result : ‘ curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=%C2%BF=0=1; Result : ‘ curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=¿=0=0; Result : B? curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=%C2%BF=0=0; Result : B? curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=¿=0=ISO-8859-1=1; Result : ?’ curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=¿=0=ISO-8859-1=1; Result : ?’ Tried with charset UTF-8 and ASCII, but same with same result. Please advise what else can be done to get this working? Config: group = core admin-port = 13005 smsbox-port = 13007 sms-resend-retry = 10 admin-password = admin box-deny-ip = "*.*.*.*" box-allow-ip = "" access-log = /opt/kannel/smpp_access.log access-log-format = "[SMSC:%i] [from:%p] [to:%P] [msg:%L:%b] [FID:%F]" store-type = file store-location = "/opt/kannel/smpp.store" store-dump-freq = 100 group = smsbox bearerbox-host = 127.0.0.1 sendsms-port = 13017 http-request-retry = 3 http-queue-delay = 5 reply-couldnotfetch = "Please wait" log-file = "/opt/kannel/smsbox/smsbox.log" log-level = 0 group = smsc smsc = smpp smsc-id = smppConnection2 allowed-smsc-id = "smppConnection2" host = port = system-type = "" address-range = "1234" smsc-username = "" smsc-password = "" source-addr-ton = 0 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 interface-version = 52 throughput = 15 alt-charset = "utf-8" connection-timeout = 60 max-pending-submits = 10 enquire-link-interval = 20 transceiver-mode = 0 log-file = "/opt/kannel/bearerbox/debug.log" log-level = 0 reconnect-delay = 2 group = sendsms-user username = smsSMPP2 password = smsPass max-messages = 10 concatenation = true default-smsc = smppConnection2 group = sms-service keyword = default accepted-smsc = smppConnection2 get-url = " max-messages = 0 concatenation = true
RE: Inverted Exclamation mark and question mark issue.
Hi There, Thanks for replying, I already tested using that parameter, but I keep receiving “B?”. Below are the debug log. curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=601132495424=%C2%A1=0=UTF-8; 2018-04-04 17:17:39 [10745] [7] DEBUG: SMPP PDU 0x7efe78000a10 dump: 2018-04-04 17:17:39 [10745] [7] DEBUG: type_name: submit_sm 2018-04-04 17:17:39 [10745] [7] DEBUG: command_id: 4 = 0x0004 2018-04-04 17:17:39 [10745] [7] DEBUG: command_status: 0 = 0x 2018-04-04 17:17:39 [10745] [7] DEBUG: sequence_number: 56414 = 0xdc5e 2018-04-04 17:17:39 [10745] [7] DEBUG: service_type: NULL 2018-04-04 17:17:39 [10745] [7] DEBUG: source_addr_ton: 0 = 0x 2018-04-04 17:17:39 [10745] [7] DEBUG: source_addr_npi: 1 = 0x0001 2018-04-04 17:17:39 [10745] [7] DEBUG: source_addr: "6" 2018-04-04 17:17:39 [10745] [7] DEBUG: dest_addr_ton: 1 = 0x0001 2018-04-04 17:17:39 [10745] [7] DEBUG: dest_addr_npi: 1 = 0x0001 2018-04-04 17:17:39 [10745] [7] DEBUG: destination_addr: "601132495424" 2018-04-04 17:17:39 [10745] [7] DEBUG: esm_class: 3 = 0x0003 2018-04-04 17:17:39 [10745] [7] DEBUG: protocol_id: 0 = 0x 2018-04-04 17:17:39 [10745] [7] DEBUG: priority_flag: 0 = 0x 2018-04-04 17:17:39 [10745] [7] DEBUG: schedule_delivery_time: NULL 2018-04-04 17:17:39 [10745] [7] DEBUG: validity_period: NULL 2018-04-04 17:17:39 [10745] [7] DEBUG: registered_delivery: 0 = 0x 2018-04-04 17:17:39 [10745] [7] DEBUG: replace_if_present_flag: 0 = 0x 2018-04-04 17:17:39 [10745] [7] DEBUG: data_coding: 0 = 0x 2018-04-04 17:17:39 [10745] [7] DEBUG: sm_default_msg_id: 0 = 0x 2018-04-04 17:17:39 [10745] [7] DEBUG: sm_length: 2 = 0x0002 2018-04-04 17:17:39 [10745] [7] DEBUG: short_message: 2018-04-04 17:17:39 [10745] [7] DEBUG:Octet string at 0x7efe78000c40: 2018-04-04 17:17:39 [10745] [7] DEBUG: len: 2 2018-04-04 17:17:39 [10745] [7] DEBUG: size: 3 2018-04-04 17:17:39 [10745] [7] DEBUG: immutable: 0 2018-04-04 17:17:39 [10745] [7] DEBUG: data: c2 a1 .. 2018-04-04 17:17:39 [10745] [7] DEBUG:Octet string dump ends. 2018-04-04 17:17:39 [10745] [7] DEBUG: SMPP PDU dump ends. However it works correctly when sending with coding=2, but by using that it halved the SMS length. Appreciate your help in this. Cheers, Arif Noor From: Alexander Malysh <malys...@gmail.com> On Behalf Of amal...@kannel.org Sent: Wednesday, April 04, 2018 4:40 PM To: Wan Md Arif Noor Bin. Wan Nizam <md.a...@forest-interactive.com> Cc: users@kannel.org Subject: Re: Inverted Exclamation mark and question mark issue. Hi, you have to send in UTF-8 with coding=0 (for inverted exclamation mark: text=%C2%A1=0). If it doesn’t work please check your smpp debug logs and check if submit_sm has correct values in message body and if yes then SMSC doing something wrong. Thanks, Alex Am 04.04.2018 um 07:27 schrieb Wan Md Arif Noor Bin. Wan Nizam <md.a...@forest-interactive.com<mailto:md.a...@forest-interactive.com>>: Hello Users, I’m having an issue with sending both inverted exclamation mark (¡) and inverted question mark (¿) , it seems like it was converted to B! and B? instead. Tried with all below parameter but none working except for UCS-2 which I want to avoid. curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=¿<http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=%C2%BF>" Result : B? curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=%C2%BF; Result :B? curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=¿=0=1<http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=%C2%BF=0=1>" Result : ‘ curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=%C2%BF=0=1; Result : ‘ curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=¿=0=0<http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=%C2%BF=0=0>" Result : B? curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=%C2%BF=0=0; Result : B? curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=¿=0=ISO-8859-1=1<http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=%C2%BF=0=ISO-8859-1=1>"Result : ?’ curl "http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=¿=0=ISO-8859-1=1<http://localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=6=60113**=%C2%BF=0=ISO-8859-1=1>"Result : ?’ Tried with charset UTF-8 and ASCII, but same with same result. Ple
RE: UDH Length Question
Hi Users, Revisiting this case as I still getting this kind of errors when sending long concatenated message, is there any way that I can avoid this issue aside from limiting the octets by using max-sms-octets? We have no issue with other provider only for this particular one. Thank you and Regards, Arif Noor From: users <users-boun...@kannel.org> On Behalf Of Wan Md Arif Noor Bin. Wan Nizam Sent: Thursday, November 09, 2017 7:14 PM To: KUMAR Deepak (MORPHO) <deepak.ku...@morpho.com>; users <users@kannel.org> Subject: RE: UDH Length Question This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing> Feedback<http://aka.ms/SafetyTipsFeedback> Hi There, Data coding used is data_coding: 0 = 0x Debug log : 40001:2017-11-08 15:06:00 [1563] [10] DEBUG: SMPP PDU 0x7ffadc00a940 dump: 40002:2017-11-08 15:06:00 [1563] [10] DEBUG: type_name: submit_sm 40003:2017-11-08 15:06:00 [1563] [10] DEBUG: command_id: 4 = 0x0004 40004:2017-11-08 15:06:00 [1563] [10] DEBUG: command_status: 0 = 0x 40005:2017-11-08 15:06:00 [1563] [10] DEBUG: sequence_number: 161 = 0x00a1 40006:2017-11-08 15:06:00 [1563] [10] DEBUG: service_type: NULL 40007:2017-11-08 15:06:00 [1563] [10] DEBUG: source_addr_ton: 0 = 0x 40008:2017-11-08 15:06:00 [1563] [10] DEBUG: source_addr_npi: 1 = 0x0001 40009:2017-11-08 15:06:00 [1563] [10] DEBUG: source_addr: "6" 40010:2017-11-08 15:06:00 [1563] [10] DEBUG: dest_addr_ton: 1 = 0x0001 40011:2017-11-08 15:06:00 [1563] [10] DEBUG: dest_addr_npi: 1 = 0x0001 40012:2017-11-08 15:06:00 [1563] [10] DEBUG: destination_addr: "6010***" 40013:2017-11-08 15:06:00 [1563] [10] DEBUG: esm_class: 64 = 0x0040 40014:2017-11-08 15:06:00 [1563] [10] DEBUG: protocol_id: 0 = 0x 40015:2017-11-08 15:06:00 [1563] [10] DEBUG: priority_flag: 0 = 0x 40016:2017-11-08 15:06:00 [1563] [10] DEBUG: schedule_delivery_time: NULL 40017:2017-11-08 15:06:00 [1563] [10] DEBUG: validity_period: NULL 40018:2017-11-08 15:06:00 [1563] [10] DEBUG: registered_delivery: 1 = 0x0001 40019:2017-11-08 15:06:00 [1563] [10] DEBUG: replace_if_present_flag: 0 = 0x 40020:2017-11-08 15:06:00 [1563] [10] DEBUG: data_coding: 0 = 0x 40021:2017-11-08 15:06:00 [1563] [10] DEBUG: sm_default_msg_id: 0 = 0x 40022:2017-11-08 15:06:00 [1563] [10] DEBUG: sm_length: 159 = 0x009f 40023:2017-11-08 15:06:00 [1563] [10] DEBUG: short_message: 40024:2017-11-08 15:06:00 [1563] [10] DEBUG:Octet string at 0x7ffadc000c40: 40025:2017-11-08 15:06:00 [1563] [10] DEBUG: len: 159 40026:2017-11-08 15:06:00 [1563] [10] DEBUG: size: 1024 40027:2017-11-08 15:06:00 [1563] [10] DEBUG: immutable: 0 40028:2017-11-08 15:06:00 [1563] [10] DEBUG: data: 05 00 03 5c 02 01 52 4d 30 2e 54 65 73 74 69 6e ...\..RM0.Testin 40029:2017-11-08 15:06:00 [1563] [10] DEBUG: data: 67 20 66 6f 72 20 46 49 20 2c 20 50 6c 65 61 73 g for FI , Pleas 40030:2017-11-08 15:06:00 [1563] [10] DEBUG: data: 65 20 6c 65 74 20 75 73 20 6b 6e 6f 77 20 69 66 e let us know if 40031:2017-11-08 15:06:00 [1563] [10] DEBUG: data: 20 79 6f 75 20 61 72 65 20 72 65 63 69 76 69 6eyou are recivin 40032:2017-11-08 15:06:00 [1563] [10] DEBUG: data: 67 20 74 68 69 73 20 6d 65 73 73 61 67 65 2c 20 g this message, 40033:2017-11-08 15:06:00 [1563] [10] DEBUG: data: 54 68 61 6e 6b 20 79 6f 75 2c 20 67 6f 64 20 62 Thank you, god b 40034:2017-11-08 15:06:00 [1563] [10] DEBUG: data: 6c 65 73 73 20 79 6f 75 2e 20 53 6f 6f 6e 20 79 less you. Soon y 40035:2017-11-08 15:06:00 [1563] [10] DEBUG: data: 6f 75 20 54 65 73 74 69 6e 67 20 66 6f 72 20 46 ou Testing for F 40036:2017-11-08 15:06:00 [1563] [10] DEBUG: data: 49 20 2c 20 50 6c 65 61 73 65 20 6c 65 74 20 75 I , Please let u 40037:2017-11-08 15:06:00 [1563] [10] DEBUG: data: 73 20 6b 6e 6f 77 20 69 66 20 79 6f 75 20 61 s know if you a 40038:2017-11-08 15:06:00 [1563] [10] DEBUG:Octet string dump ends. 40039:2017-11-08 15:06:00 [1563] [10] DEBUG: SMPP PDU dump ends. 40044:2017-11-08 15:06:00 [1563] [10] DEBUG: SMPP PDU 0x7ffadc0088a0 dump: 40045:2017-11-08 15:06:00 [1563] [10] DEBUG: type_name: submit_sm 40046:2017-11-08 15:06:00 [1563] [10] DEBUG: command_id: 4 = 0x0004 40047:2017-11-08 15:06:00 [1563] [10] DEBUG: command_status: 0 = 0x 40048:2017-11-08 15:06:00 [1563] [10] DEBUG: sequence_number: 162 = 0x00a2 40049:2017-11-08 15:06:00 [1563] [10] DEBUG: service_type: NULL 40050:2017-11-08 15:06:00 [1563] [10] DEBUG: source_addr_ton: 0 = 0x 40051:2017-11-08 15:06:00 [1563] [10] DEBUG: source_addr_npi: 1 = 0x0001 40052:2017-11-08 15:06:00 [1563] [10] DEBUG: source_addr: "6" 40053:2017-11-08 15:06:00 [1563] [10] DEBUG: dest_addr_ton: 1 = 0x0001
UDH Inquiries
Hi There,
Is there any way to exclude these ^,{,},\,[,],~ from being used automatically
by the kannel in the UDHI?
Such as below :
data: 05 00 03 5b 02 02 73 74 74 65 73 74 74 65 73 74 ...[..sttesttest
BR.
[MWC 2019]
DLR but could not find message or was not interested Issue
Hello Guys, I’ve been struggling to find what is the issue with the DLR which regularly getting error “DLR but could not find message or was not interested”. From the debug logs it looks just fine but from the access logs it becomes like those normal MO instead of DN. 38029:2020-05-12 05:07:42 [1640] [9] DEBUG: SMPP[6SeriesSHT]: Got PDU: 38030:2020-05-12 05:07:42 [1640] [9] DEBUG: SMPP PDU 0x7f087c014d70 dump: 38031:2020-05-12 05:07:42 [1640] [9] DEBUG: type_name: deliver_sm 38032:2020-05-12 05:07:42 [1640] [9] DEBUG: command_id: 5 = 0x0005 38033:2020-05-12 05:07:42 [1640] [9] DEBUG: command_status: 0 = 0x 38034:2020-05-12 05:07:42 [1640] [9] DEBUG: sequence_number: 253886944 = 0x0f2201e0 38035:2020-05-12 05:07:42 [1640] [9] DEBUG: service_type: NULL 38036:2020-05-12 05:07:42 [1640] [9] DEBUG: source_addr_ton: 1 = 0x0001 38037:2020-05-12 05:07:42 [1640] [9] DEBUG: source_addr_npi: 1 = 0x0001 38038:2020-05-12 05:07:42 [1640] [9] DEBUG: source_addr: "601" 38039:2020-05-12 05:07:42 [1640] [9] DEBUG: dest_addr_ton: 0 = 0x 38040:2020-05-12 05:07:42 [1640] [9] DEBUG: dest_addr_npi: 1 = 0x0001 38041:2020-05-12 05:07:42 [1640] [9] DEBUG: destination_addr: "63660" 38042:2020-05-12 05:07:42 [1640] [9] DEBUG: esm_class: 4 = 0x0004 38043:2020-05-12 05:07:42 [1640] [9] DEBUG: protocol_id: 0 = 0x 38044:2020-05-12 05:07:42 [1640] [9] DEBUG: priority_flag: 0 = 0x 38045:2020-05-12 05:07:42 [1640] [9] DEBUG: schedule_delivery_time: NULL 38046:2020-05-12 05:07:42 [1640] [9] DEBUG: validity_period: NULL 38047:2020-05-12 05:07:42 [1640] [9] DEBUG: registered_delivery: 0 = 0x 38048:2020-05-12 05:07:42 [1640] [9] DEBUG: replace_if_present_flag: 0 = 0x 38049:2020-05-12 05:07:42 [1640] [9] DEBUG: data_coding: 0 = 0x 38050:2020-05-12 05:07:42 [1640] [9] DEBUG: sm_default_msg_id: 0 = 0x 38051:2020-05-12 05:07:42 [1640] [9] DEBUG: sm_length: 122 = 0x007a 38052:2020-05-12 05:07:42 [1640] [9] DEBUG: short_message: 38053:2020-05-12 05:07:42 [1640] [9] DEBUG:Octet string at 0x7f087c014330: 38054:2020-05-12 05:07:42 [1640] [9] DEBUG: len: 122 38055:2020-05-12 05:07:42 [1640] [9] DEBUG: size: 123 38056:2020-05-12 05:07:42 [1640] [9] DEBUG: immutable: 0 38057:2020-05-12 05:07:42 [1640] [9] DEBUG: data: 69 64 3a 30 34 31 36 32 39 33 38 30 38 20 73 75 id:0416293808 su 38058:2020-05-12 05:07:42 [1640] [9] DEBUG: data: 62 3a 30 30 30 20 64 6c 76 72 64 3a 30 30 30 20 b:000 dlvrd:000 38059:2020-05-12 05:07:42 [1640] [9] DEBUG: data: 73 75 62 6d 69 74 20 64 61 74 65 3a 32 30 30 35 submit date:2005 38060:2020-05-12 05:07:42 [1640] [9] DEBUG: data: 31 32 30 35 30 37 20 64 6f 6e 65 20 64 61 74 65 120507 done date 38061:2020-05-12 05:07:42 [1640] [9] DEBUG: data: 3a 32 30 30 35 31 32 30 35 30 37 20 73 74 61 74 :2005120507 stat 38062:2020-05-12 05:07:42 [1640] [9] DEBUG: data: 3a 55 4e 44 45 4c 49 56 20 65 72 72 3a 32 34 35 :UNDELIV err:245 38063:2020-05-12 05:07:42 [1640] [9] DEBUG: data: 20 74 65 78 74 3a 52 4d 30 2e 30 30 20 3a 20 59text:RM0.00 : Y 38064:2020-05-12 05:07:42 [1640] [9] DEBUG: data: 6f 75 72 20 53 68 6f 70 65 65 our Shopee 38065:2020-05-12 05:07:42 [1640] [9] DEBUG:Octet string dump ends. 38066:2020-05-12 05:07:42 [1640] [9] DEBUG: message_state: 5 = 0x0005 38067:2020-05-12 05:07:42 [1640] [9] DEBUG: receipted_message_id: "18D023B0" 38068:2020-05-12 05:07:42 [1640] [9] DEBUG: SMPP PDU dump ends. 38069:2020-05-12 05:07:42 [1640] [9] DEBUG: SMPP[6SeriesSHT] handle_pdu, got DLR 38070:2020-05-12 05:07:42 [1640] [9] DEBUG: DLR[mysql]: Looking for DLR smsc=6SeriesSHT, ts=18D023B0, dst=601, type=2 38071:2020-05-12 05:07:42 [1640] [9] DEBUG: sql: SELECT `mask`, `service`, `url`, `source`, `destination`, `boxcid` FROM `smpp_dlr` WHERE `smsc`=? AND `ts`=? LIMIT 1 38072:2020-05-12 05:07:42 [1640] [9] DEBUG: column=mask buffer_type=3 max_length=0 length=10 38073:2020-05-12 05:07:42 [1640] [9] DEBUG: column=service buffer_type=253 max_length=0 length=40 38074:2020-05-12 05:07:42 [1640] [9] DEBUG: column=url buffer_type=253 max_length=0 length=255 38075:2020-05-12 05:07:42 [1640] [9] DEBUG: column=source buffer_type=253 max_length=0 length=40 38076:2020-05-12 05:07:42 [1640] [9] DEBUG: column=destination buffer_type=253 max_length=0 length=40 38077:2020-05-12 05:07:42 [1640] [9] DEBUG: column=boxcid buffer_type=253 max_length=0 length=40 38078:2020-05-12 05:07:42 [1640] [9] WARNING: DLR[mysql]: DLR from SMSC<6SeriesSHT> for DST<601 > not found. 38079:2020-05-12 05:07:42 [1640] [9] ERROR: SMPP[6SeriesSHT]: got DLR but could not find message or was not interested in it id<18D023B0> dst<601 >, type<2> Access Logs 2020-05-12 05:07:42 [SMSC:6SeriesSHT] [from:+601] [to:63660] [msg:122:id:0416293808 sub:000 dlvrd:000 submit date:2005120507 done
RE: DLR but could not find message or was not interested Issue
Hi, Thanks for the reply, tried it and same issue. Just to note that the issue is pretty random but happening regularly. Logs : 2020-05-12 11:16:34 [SMSC:6SeriesSHT] [from:62033] [to:601] [msg:154:RM0 <#> Kod WhatsApp Anda: 664-190..Anda boleh ketik pautan ini untuk mengesahkan nombor anda: v.whatsapp.com/..Jangan kongsikan kod ini.4sgLq1p5sV6] [FID:1A7A1C61] 2020-05-12 11:22:57 [SMSC:6SeriesSHT] [from:+601] [to:62033] [msg:122:id:0444210273 sub:000 dlvrd:000 submit date:2005121116 done date:2005121122 stat:DELIVRD err:000 text:RM0 <#> Kod WhatsApp] [FID:1A7A1C61] 2020-05-12 11:22:57 [85037] [7] ERROR: SMPP[6SeriesSHT]: got DLR but could not find message or was not interested in it id<444210273> dst<601>, type<1> Best Regards. Arif Noor From: Gorki Alfaro Sent: Tuesday, May 12, 2020 11:19 AM To: Wan Md Arif Noor Bin. Wan Nizam Cc: kannel users@kannel.org Subject: Re: DLR but could not find message or was not interested Issue Hello Try to changing your msg-id-type = 0x01 Regards Gorki On Mon, May 11, 2020 at 9:12 PM Wan Md Arif Noor Bin. Wan Nizam mailto:md.a...@forest-interactive.com>> wrote: Hello Guys, I’ve been struggling to find what is the issue with the DLR which regularly getting error “DLR but could not find message or was not interested”. From the debug logs it looks just fine but from the access logs it becomes like those normal MO instead of DN. 38029:2020-05-12 05:07:42 [1640] [9] DEBUG: SMPP[6SeriesSHT]: Got PDU: 38030:2020-05-12 05:07:42 [1640] [9] DEBUG: SMPP PDU 0x7f087c014d70 dump: 38031:2020-05-12 05:07:42 [1640] [9] DEBUG: type_name: deliver_sm 38032:2020-05-12 05:07:42 [1640] [9] DEBUG: command_id: 5 = 0x0005 38033:2020-05-12 05:07:42 [1640] [9] DEBUG: command_status: 0 = 0x 38034:2020-05-12 05:07:42 [1640] [9] DEBUG: sequence_number: 253886944 = 0x0f2201e0 38035:2020-05-12 05:07:42 [1640] [9] DEBUG: service_type: NULL 38036:2020-05-12 05:07:42 [1640] [9] DEBUG: source_addr_ton: 1 = 0x0001 38037:2020-05-12 05:07:42 [1640] [9] DEBUG: source_addr_npi: 1 = 0x0001 38038:2020-05-12 05:07:42 [1640] [9] DEBUG: source_addr: "601" 38039:2020-05-12 05:07:42 [1640] [9] DEBUG: dest_addr_ton: 0 = 0x 38040:2020-05-12 05:07:42 [1640] [9] DEBUG: dest_addr_npi: 1 = 0x0001 38041:2020-05-12 05:07:42 [1640] [9] DEBUG: destination_addr: "63660" 38042:2020-05-12 05:07:42 [1640] [9] DEBUG: esm_class: 4 = 0x0004 38043:2020-05-12 05:07:42 [1640] [9] DEBUG: protocol_id: 0 = 0x 38044:2020-05-12 05:07:42 [1640] [9] DEBUG: priority_flag: 0 = 0x 38045:2020-05-12 05:07:42 [1640] [9] DEBUG: schedule_delivery_time: NULL 38046:2020-05-12 05:07:42 [1640] [9] DEBUG: validity_period: NULL 38047:2020-05-12 05:07:42 [1640] [9] DEBUG: registered_delivery: 0 = 0x 38048:2020-05-12 05:07:42 [1640] [9] DEBUG: replace_if_present_flag: 0 = 0x 38049:2020-05-12 05:07:42 [1640] [9] DEBUG: data_coding: 0 = 0x 38050:2020-05-12 05:07:42 [1640] [9] DEBUG: sm_default_msg_id: 0 = 0x 38051:2020-05-12 05:07:42 [1640] [9] DEBUG: sm_length: 122 = 0x007a 38052:2020-05-12 05:07:42 [1640] [9] DEBUG: short_message: 38053:2020-05-12 05:07:42 [1640] [9] DEBUG:Octet string at 0x7f087c014330: 38054:2020-05-12 05:07:42 [1640] [9] DEBUG: len: 122 38055:2020-05-12 05:07:42 [1640] [9] DEBUG: size: 123 38056:2020-05-12 05:07:42 [1640] [9] DEBUG: immutable: 0 38057:2020-05-12 05:07:42 [1640] [9] DEBUG: data: 69 64 3a 30 34 31 36 32 39 33 38 30 38 20 73 75 id:0416293808 su 38058:2020-05-12 05:07:42 [1640] [9] DEBUG: data: 62 3a 30 30 30 20 64 6c 76 72 64 3a 30 30 30 20 b:000 dlvrd:000 38059:2020-05-12 05:07:42 [1640] [9] DEBUG: data: 73 75 62 6d 69 74 20 64 61 74 65 3a 32 30 30 35 submit date:2005 38060:2020-05-12 05:07:42 [1640] [9] DEBUG: data: 31 32 30 35 30 37 20 64 6f 6e 65 20 64 61 74 65 120507 done date 38061:2020-05-12 05:07:42 [1640] [9] DEBUG: data: 3a 32 30 30 35 31 32 30 35 30 37 20 73 74 61 74 :2005120507 stat 38062:2020-05-12 05:07:42 [1640] [9] DEBUG: data: 3a 55 4e 44 45 4c 49 56 20 65 72 72 3a 32 34 35 :UNDELIV err:245 38063:2020-05-12 05:07:42 [1640] [9] DEBUG: data: 20 74 65 78 74 3a 52 4d 30 2e 30 30 20 3a 20 59text:RM0.00 : Y 38064:2020-05-12 05:07:42 [1640] [9] DEBUG: data: 6f 75 72 20 53 68 6f 70 65 65 our Shopee 38065:2020-05-12 05:07:42 [1640] [9] DEBUG:Octet string dump ends. 38066:2020-05-12 05:07:42 [1640] [9] DEBUG: message_state: 5 = 0x0005 38067:2020-05-12 05:07:42 [1640] [9] DEBUG: receipted_message_id: "18D023B0" 38068:2020-05-12 05:07:42 [1640] [9] DEBUG: SMPP PDU dump ends. 38069:2020-05-12 05:07:42 [1640] [9] DEBUG: SMPP[6SeriesSHT] handle_pdu, got DLR 38070:2020-05-12 05:07:42 [1640] [9] DEBUG: DLR[mysql]: Looking for DLR smsc=6SeriesSHT, ts=18D023B0,
Long Message Issue
Hi Kannel Users, Based on the logs below it seems like Kannel is exceeding 160 characters when sending concatenated long SMS which in result rejected by the operator, is this a bug? Please advise how to fix this. Using Kannel bearerbox version `svn-r5201M' 356089:2020-10-14 01:24:29 [13820] [27] DEBUG: SMPP PDU 0x7fea5002a680 dump: 356090:2020-10-14 01:24:29 [13820] [27] DEBUG: type_name: submit_sm 356091:2020-10-14 01:24:29 [13820] [27] DEBUG: command_id: 4 = 0x0004 356092:2020-10-14 01:24:29 [13820] [27] DEBUG: command_status: 0 = 0x 356093:2020-10-14 01:24:29 [13820] [27] DEBUG: sequence_number: 19309 = 0x4b6d 356094:2020-10-14 01:24:29 [13820] [27] DEBUG: service_type: NULL 356095:2020-10-14 01:24:29 [13820] [27] DEBUG: source_addr_ton: 0 = 0x 356096:2020-10-14 01:24:29 [13820] [27] DEBUG: source_addr_npi: 1 = 0x0001 356097:2020-10-14 01:24:29 [13820] [27] DEBUG: source_addr: "" 356098:2020-10-14 01:24:29 [13820] [27] DEBUG: dest_addr_ton: 1 = 0x0001 356099:2020-10-14 01:24:29 [13820] [27] DEBUG: dest_addr_npi: 1 = 0x0001 356100:2020-10-14 01:24:29 [13820] [27] DEBUG: destination_addr: "" 356101:2020-10-14 01:24:29 [13820] [27] DEBUG: esm_class: 64 = 0x0040 356102:2020-10-14 01:24:29 [13820] [27] DEBUG: protocol_id: 0 = 0x 356103:2020-10-14 01:24:29 [13820] [27] DEBUG: priority_flag: 0 = 0x 356104:2020-10-14 01:24:29 [13820] [27] DEBUG: schedule_delivery_time: NULL 356105:2020-10-14 01:24:29 [13820] [27] DEBUG: validity_period: NULL 356106:2020-10-14 01:24:29 [13820] [27] DEBUG: registered_delivery: 1 = 0x0001 356107:2020-10-14 01:24:29 [13820] [27] DEBUG: replace_if_present_flag: 0 = 0x 356108:2020-10-14 01:24:29 [13820] [27] DEBUG: data_coding: 0 = 0x 356109:2020-10-14 01:24:29 [13820] [27] DEBUG: sm_default_msg_id: 0 = 0x 356110:2020-10-14 01:24:29 [13820] [27] DEBUG: sm_length: 161 = 0x00a1 356111:2020-10-14 01:24:29 [13820] [27] DEBUG: short_message: 356112:2020-10-14 01:24:29 [13820] [27] DEBUG:Octet string at 0x7fea5000e7d0: 356113:2020-10-14 01:24:29 [13820] [27] DEBUG: len: 161 356114:2020-10-14 01:24:29 [13820] [27] DEBUG: size: 1024 356115:2020-10-14 01:24:29 [13820] [27] DEBUG: immutable: 0 356116:2020-10-14 01:24:29 [13820] [27] DEBUG: data: 05 00 03 7d 02 01 52 4d 30 20 66 69 71 73 2a 2a 356117:2020-10-14 01:24:29 [13820] [27] DEBUG: data: 2a 2a 2a c2 a1 2a 2a 2a 69 6c 2e 63 6f 6d 20 68 356118:2020-10-14 01:24:29 [13820] [27] DEBUG: data: 61 73 20 62 65 65 6e 20 73 65 74 20 61 73 20 74 356119:2020-10-14 01:24:29 [13820] [27] DEBUG: data: 68 65 20 73 65 63 75 72 69 74 79 20 65 6d 61 69 356120:2020-10-14 01:24:29 [13820] [27] DEBUG: data: 6c 20 61 64 64 72 65 73 73 20 66 6f 72 20 79 6f 356121:2020-10-14 01:24:29 [13820] [27] DEBUG: data: 75 72 20 48 55 41 57 45 49 20 49 44 20 66 69 6b 356122:2020-10-14 01:24:29 [13820] [27] DEBUG: data: 72 75 6c 6c 61 68 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 356123:2020-10-14 01:24:29 [13820] [27] DEBUG: data: 2a 2a 2a c2 a1 2a 2a 2a 69 6c 2e 63 6f 6d 2e 20 356124:2020-10-14 01:24:29 [13820] [27] DEBUG: data: 49 66 20 74 68 69 73 20 77 61 73 6e 27 74 20 79 356125:2020-10-14 01:24:29 [13820] [27] DEBUG: data: 6f 75 2c 20 70 6c 65 61 73 65 20 72 65 73 65 74 356126:2020-10-14 01:24:29 [13820] [27] DEBUG: data: 20 356127:2020-10-14 01:24:29 [13820] [27] DEBUG:Octet string dump ends. 356128:2020-10-14 01:24:29 [13820] [27] DEBUG: SMPP PDU dump ends. 356133:2020-10-14 01:24:29 [13820] [27] DEBUG: SMPP PDU 0x7fea5002a680 dump: 356134:2020-10-14 01:24:29 [13820] [27] DEBUG: type_name: submit_sm 356135:2020-10-14 01:24:29 [13820] [27] DEBUG: command_id: 4 = 0x0004 356136:2020-10-14 01:24:29 [13820] [27] DEBUG: command_status: 0 = 0x 356137:2020-10-14 01:24:29 [13820] [27] DEBUG: sequence_number: 19310 = 0x4b6e 356138:2020-10-14 01:24:29 [13820] [27] DEBUG: service_type: NULL 356139:2020-10-14 01:24:29 [13820] [27] DEBUG: source_addr_ton: 0 = 0x 356140:2020-10-14 01:24:29 [13820] [27] DEBUG: source_addr_npi: 1 = 0x0001 356141:2020-10-14 01:24:29 [13820] [27] DEBUG: source_addr: "" 356142:2020-10-14 01:24:29 [13820] [27] DEBUG: dest_addr_ton: 1 = 0x0001 356143:2020-10-14 01:24:29 [13820] [27] DEBUG: dest_addr_npi: 1 = 0x0001 356144:2020-10-14 01:24:29 [13820] [27] DEBUG: destination_addr: "" 356145:2020-10-14 01:24:29 [13820] [27] DEBUG: esm_class: 64 = 0x0040 356146:2020-10-14 01:24:29 [13820] [27] DEBUG: protocol_id: 0 = 0x 356147:2020-10-14 01:24:29 [13820] [27] DEBUG: priority_flag: 0 = 0x 356148:2020-10-14 01:24:29 [13820] [27] DEBUG: schedule_delivery_time: NULL 356149:2020-10-14 01:24:29 [13820] [27] DEBUG: validity_period: NULL 356150:2020-10-14 01:24:29 [13820] [27] DEBUG: registered_delivery: 0 = 0x 356151:2020-10-14 01:24:29 [13820] [27]
Pipe Symbol Issue
Hi There, I've notice that sending | symbol converted into @ instead regardless alt-charset set to UTF-8 or not. Kindly assist. CGI : curl "localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=68123=601132495424=%7c" Kannel bearerbox version `svn-r5299M'. Debug Log : 291852:2020-08-18 17:44:37 [62170] [7] DEBUG: SMPP PDU 0x7fa23c01c3a0 dump: 291853:2020-08-18 17:44:37 [62170] [7] DEBUG: type_name: submit_sm 291854:2020-08-18 17:44:37 [62170] [7] DEBUG: command_id: 4 = 0x0004 291855:2020-08-18 17:44:37 [62170] [7] DEBUG: command_status: 0 = 0x 291856:2020-08-18 17:44:37 [62170] [7] DEBUG: sequence_number: 9333 = 0x2475 291857:2020-08-18 17:44:37 [62170] [7] DEBUG: service_type: NULL 291858:2020-08-18 17:44:37 [62170] [7] DEBUG: source_addr_ton: 0 = 0x 291859:2020-08-18 17:44:37 [62170] [7] DEBUG: source_addr_npi: 1 = 0x0001 291860:2020-08-18 17:44:37 [62170] [7] DEBUG: source_addr: "68123" 291861:2020-08-18 17:44:37 [62170] [7] DEBUG: dest_addr_ton: 1 = 0x0001 291862:2020-08-18 17:44:37 [62170] [7] DEBUG: dest_addr_npi: 1 = 0x0001 291863:2020-08-18 17:44:37 [62170] [7] DEBUG: destination_addr: "601132495424" 291864:2020-08-18 17:44:37 [62170] [7] DEBUG: esm_class: 3 = 0x0003 291865:2020-08-18 17:44:37 [62170] [7] DEBUG: protocol_id: 0 = 0x 291866:2020-08-18 17:44:37 [62170] [7] DEBUG: priority_flag: 0 = 0x 291867:2020-08-18 17:44:37 [62170] [7] DEBUG: schedule_delivery_time: NULL 291868:2020-08-18 17:44:37 [62170] [7] DEBUG: validity_period: NULL 291869:2020-08-18 17:44:37 [62170] [7] DEBUG: registered_delivery: 1 = 0x0001 291870:2020-08-18 17:44:37 [62170] [7] DEBUG: replace_if_present_flag: 0 = 0x 291871:2020-08-18 17:44:37 [62170] [7] DEBUG: data_coding: 0 = 0x 291872:2020-08-18 17:44:37 [62170] [7] DEBUG: sm_default_msg_id: 0 = 0x 291873:2020-08-18 17:44:37 [62170] [7] DEBUG: sm_length: 7 = 0x0007 291874:2020-08-18 17:44:37 [62170] [7] DEBUG: short_message: 291875:2020-08-18 17:44:37 [62170] [7] DEBUG:Octet string at 0x7fa23c0107c0: 291876:2020-08-18 17:44:37 [62170] [7] DEBUG: len: 7 291877:2020-08-18 17:44:37 [62170] [7] DEBUG: size: 1024 291878:2020-08-18 17:44:37 [62170] [7] DEBUG: immutable: 0 291879:2020-08-18 17:44:37 [62170] [7] DEBUG: data: 52 4d 30 2e 20 1b 40 RM0. .@ Config : group = smsc smsc = smpp smsc-id = allowed-smsc-id = "" host = port = 13042 system-type = "" address-range = "" smsc-username = "" smsc-password = "" source-addr-ton = 0 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 interface-version = 52 throughput = 30 connection-timeout = 120 max-pending-submits = 10 enquire-link-interval = 60 transceiver-mode = 1 log-file = "/opt/kannel/bearerbox/6.log" log-level = 1 reconnect-delay = 5 group = sendsms-user username = smsSMPP2 password = smsPass max-messages = 10 concatenation = true default-smsc = group = sms-service keyword = default accepted-smsc = * get-url = "" max-messages = 0 concatenation = true Thank you and Regards, Arif Noor
RE: Pipe Symbol Issue
Hi Anyone? I've updated to svn-r5302M and still seeing the same problem. 26892:2020-08-19 02:45:42 [9506] [7] DEBUG: SMPP PDU 0x7efcd8006d30 dump: 26893:2020-08-19 02:45:42 [9506] [7] DEBUG: type_name: submit_sm 26894:2020-08-19 02:45:42 [9506] [7] DEBUG: command_id: 4 = 0x0004 26895:2020-08-19 02:45:42 [9506] [7] DEBUG: command_status: 0 = 0x 26896:2020-08-19 02:45:42 [9506] [7] DEBUG: sequence_number: 8 = 0x0008 26897:2020-08-19 02:45:42 [9506] [7] DEBUG: service_type: NULL 26898:2020-08-19 02:45:42 [9506] [7] DEBUG: source_addr_ton: 0 = 0x 26899:2020-08-19 02:45:42 [9506] [7] DEBUG: source_addr_npi: 1 = 0x0001 26900:2020-08-19 02:45:42 [9506] [7] DEBUG: source_addr: "" 26901:2020-08-19 02:45:42 [9506] [7] DEBUG: dest_addr_ton: 1 = 0x0001 26902:2020-08-19 02:45:42 [9506] [7] DEBUG: dest_addr_npi: 1 = 0x0001 26903:2020-08-19 02:45:42 [9506] [7] DEBUG: destination_addr: "" 26904:2020-08-19 02:45:42 [9506] [7] DEBUG: esm_class: 3 = 0x0003 26905:2020-08-19 02:45:42 [9506] [7] DEBUG: protocol_id: 0 = 0x 26906:2020-08-19 02:45:42 [9506] [7] DEBUG: priority_flag: 0 = 0x 26907:2020-08-19 02:45:42 [9506] [7] DEBUG: schedule_delivery_time: NULL 26908:2020-08-19 02:45:42 [9506] [7] DEBUG: validity_period: NULL 26909:2020-08-19 02:45:42 [9506] [7] DEBUG: registered_delivery: 0 = 0x 26910:2020-08-19 02:45:42 [9506] [7] DEBUG: replace_if_present_flag: 0 = 0x 26911:2020-08-19 02:45:42 [9506] [7] DEBUG: data_coding: 0 = 0x 26912:2020-08-19 02:45:42 [9506] [7] DEBUG: sm_default_msg_id: 0 = 0x 26913:2020-08-19 02:45:42 [9506] [7] DEBUG: sm_length: 2 = 0x0002 26914:2020-08-19 02:45:42 [9506] [7] DEBUG: short_message: 26915:2020-08-19 02:45:42 [9506] [7] DEBUG:Octet string at 0x7efcd80058f0: 26916:2020-08-19 02:45:42 [9506] [7] DEBUG: len: 2 26917:2020-08-19 02:45:42 [9506] [7] DEBUG: size: 1024 26918:2020-08-19 02:45:42 [9506] [7] DEBUG: immutable: 0 26919:2020-08-19 02:45:42 [9506] [7] DEBUG: data: 1b 40 .@ 26920:2020-08-19 02:45:42 [9506] [7] DEBUG:Octet string dump ends. 26921:2020-08-19 02:45:42 [9506] [7] DEBUG: SMPP PDU dump ends. Best Regards From: users On Behalf Of Wan Md Arif Noor Bin. Wan Nizam Sent: Tuesday, August 18, 2020 6:05 PM To: kannel users@kannel.org Subject: Pipe Symbol Issue Hi There, I've notice that sending | symbol converted into @ instead regardless alt-charset set to UTF-8 or not. Kindly assist. CGI : curl "localhost:13017/cgi-bin/sendsms?username=smsSMPP2=smsPass=68123=601132495424=%7c" Kannel bearerbox version `svn-r5299M'. Debug Log : 291852:2020-08-18 17:44:37 [62170] [7] DEBUG: SMPP PDU 0x7fa23c01c3a0 dump: 291853:2020-08-18 17:44:37 [62170] [7] DEBUG: type_name: submit_sm 291854:2020-08-18 17:44:37 [62170] [7] DEBUG: command_id: 4 = 0x0004 291855:2020-08-18 17:44:37 [62170] [7] DEBUG: command_status: 0 = 0x 291856:2020-08-18 17:44:37 [62170] [7] DEBUG: sequence_number: 9333 = 0x2475 291857:2020-08-18 17:44:37 [62170] [7] DEBUG: service_type: NULL 291858:2020-08-18 17:44:37 [62170] [7] DEBUG: source_addr_ton: 0 = 0x 291859:2020-08-18 17:44:37 [62170] [7] DEBUG: source_addr_npi: 1 = 0x0001 291860:2020-08-18 17:44:37 [62170] [7] DEBUG: source_addr: "68123" 291861:2020-08-18 17:44:37 [62170] [7] DEBUG: dest_addr_ton: 1 = 0x0001 291862:2020-08-18 17:44:37 [62170] [7] DEBUG: dest_addr_npi: 1 = 0x0001 291863:2020-08-18 17:44:37 [62170] [7] DEBUG: destination_addr: "601132495424" 291864:2020-08-18 17:44:37 [62170] [7] DEBUG: esm_class: 3 = 0x0003 291865:2020-08-18 17:44:37 [62170] [7] DEBUG: protocol_id: 0 = 0x 291866:2020-08-18 17:44:37 [62170] [7] DEBUG: priority_flag: 0 = 0x 291867:2020-08-18 17:44:37 [62170] [7] DEBUG: schedule_delivery_time: NULL 291868:2020-08-18 17:44:37 [62170] [7] DEBUG: validity_period: NULL 291869:2020-08-18 17:44:37 [62170] [7] DEBUG: registered_delivery: 1 = 0x0001 291870:2020-08-18 17:44:37 [62170] [7] DEBUG: replace_if_present_flag: 0 = 0x 291871:2020-08-18 17:44:37 [62170] [7] DEBUG: data_coding: 0 = 0x 291872:2020-08-18 17:44:37 [62170] [7] DEBUG: sm_default_msg_id: 0 = 0x 291873:2020-08-18 17:44:37 [62170] [7] DEBUG: sm_length: 7 = 0x0007 291874:2020-08-18 17:44:37 [62170] [7] DEBUG: short_message: 291875:2020-08-18 17:44:37 [62170] [7] DEBUG:Octet string at 0x7fa23c0107c0: 291876:2020-08-18 17:44:37 [62170] [7] DEBUG: len: 7 291877:2020-08-18 17:44:37 [62170] [7] DEBUG: size: 1024 291878:2020-08-18 17:44:37 [62170] [7] DEBUG: immutable: 0 291879:2020-08-18 17:44:37 [62170] [7] DEBUG: data: 52 4d 30 2e 20 1b 40 RM0. .@ Config : group = smsc smsc = smpp smsc-id = allowed-smsc-id = ""
RE: Long Message Issue
Hi, Thank you for your reply. Kindly find below : http://x.x.x.x:13017/cgi-bin/sendsms?username==smsPass===RM0+fiqs*%c2%a1***il.com+has+been+set+as+the+security+email+address+for+your+HUAWEI+ID+fikrullah*%c2%a1***il.com.+If+this+wasn%27t+you%2c+please+reset+your+account+password+and+remove+the+security+email+address+immediately.=3=http://x.x.x.x/BulkDN/BulkDN.aspx?type='%d',FID=%F Config with alt-charset = "utf-8" Thank you and Regards, Arif Noor -Original Message- From: Stipe Tolj Sent: Tuesday, November 24, 2020 7:52 PM To: Wan Md Arif Noor Bin. Wan Nizam Cc: kannel users@kannel.org Subject: Re: Long Message Issue Am 14.10.20, 04:24, schrieb Wan Md Arif Noor Bin. Wan Nizam: > Hi Kannel Users, > > Based on the logs below it seems like Kannel is exceeding 160 > characters when sending concatenated long SMS which in result rejected > by the operator, is this a bug? Hi Arif, let us try to look into this. Can you please provide the corresponding sendsms HTTP API call that you used to generate the message? In addition the .data_coding = 0x00 is set, so per SMPP protocol the default SMSC alphabet, which is "mostly" GSM 03.38 throughout the world. But your payload looks more like UTF-8 encoded, at least the byte codes are larger the 0x7F which is the max limit of the 7bit GSM encoding. -- Best Regards, Stipe Tolj --- Düsseldorf, NRW, Germany Kannel Foundation tolj.org system architecture http://www.kannel.org/http://www.tolj.org/ st...@kannel.org s...@tolj.org ---
