Hi Alex, We would like to fix the v1.4.3 since v1.5.0 is not officially released.
I think we detected what type of MO is causing the problems, it is one with no data in the Data_sm message: Flags: 0x18 (PSH, ACK) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...1 .... = Acknowledgement: Set .... 1... = Push: Set .... .0.. = Reset: Not set .... ..0. = Syn: Not set .... ...0 = Fin: Not set Window size: 32768 Short Message Peer to Peer, Command: Data_sm, Seq: 175, Len: 59 Length : 59 Operation : Data_sm (0x00000103) Sequence #: 175 Service type: (Default) Type of number (originator): International (0x01) Numbering plan indicator (originator): ISDN (E163/E164) (0x01) Originator address: 525534097529 Type of number (recipient): International (0x01) Numbering plan indicator (recipient): ISDN (E163/E164) (0x01) Recipient address: 5220302030000000 .... ..00 = Messaging mode: Default SMSC mode (0x00) ..00 00.. = Message type : Default message type (0x00) 00.. .... = GSM features : No specific features selected (0x00) .... ..00 = Delivery receipt : No SMSC delivery receipt requested (0x00) .... 00.. = Message type : No recipient SME acknowledgement requested (0x00) ...0 .... = Intermediate notif: No intermediate notification requested (0x00) Data coding: 0x00 SMPP Data Coding Scheme: SMSC default alphabet (0x00) GSM SMS Data Coding 0000 .... = DCS Coding Group for SMS: SMS DCS: General Data Coding indication - Uncompressed text, no message class (0x00) ..0. .... = DCS Text compression: Uncompressed text ...0 .... = DCS Class present: No message class .... 00.. = DCS Character set: GSM 7-bit default alphabet (0x00) GSM CBS Data Coding 0000 .... = DCS Coding Group for CBS: CBS DCS: Language using the GSM 7-bit default alphabet (0x00) ..00 0000 = DCS CBS Message language: German (0x00) Optional parameters Optional parameter: source_network_type (0x000e) Tag: 0x000e Length: 1 Originator network: GSM (0x01) We think Kannel hits the assert != null error when it tries to parse the URL used for pushing the message to our server. Do you know what patch we could apply to fix this problem? Thanks indeed. ///RGB ---------------------------------------- > Subject: Re: Kannel PANICS octstr_convert_range > From: [email protected] > Date: Thu, 27 Sep 2012 10:30:25 +0200 > CC: [email protected] > To: [email protected] > > Hi Rob, > > you are looking in the wrong direction. As far as I see from your crash it's > so that bearerbox send message to smsbox > and not another way around. Therefore you have to check, what you still have > in the store file (if you delete it then also delete .bak files) > and see in the access log of bearerbox which message cause crash. > > Alex > > P.S. I would suggest to upgrade to SVN version, it's more stable and > maintained as 1.4.3. 1.4.3 is very very old. > > On 27.09.2012, at 10:06, Rob GB <[email protected]> wrote: > > > > > Hi Alex, > > > > I'm using Kannel 1.4.3, sorry for not mentioning this before. > > > > Do you know by chance the context of where the error appeared in smsbox? I > > would like to understand the possible ways we can trigger the “assert != > > null” to fail. > > > > Back-tracking from the error I find the following places the error could > > have come from: > > > > ~/tmp/kannel$ find . -name "*.c" -exec grep -iH octstr_convert_range {} \; > > > > ./gateway-1.4.3/gw/xml_shared.c: octstr_convert_range(charset, 0, > > octstr_len(charset), toupper); > > ./gateway-1.4.3/gw/urltrans.c: octstr_convert_range(tmp, 0, > > octstr_len(tmp), tolower); > > ./gateway-1.4.3/gw/urltrans.c: octstr_convert_range(os, 0, octstr_len(os), > > tolower); > > ./gateway-1.4.3/gw/urltrans.c: octstr_convert_range(data, 0, > > octstr_len(data), tolower); > > ./gateway-1.4.3/gw/wap_push_pap_compiler.c: octstr_convert_range(nameos, 0, > > octstr_len(nameos), tolower); > > ./gateway-1.4.3/gw/wap_push_pap_compiler.c: octstr_convert_range(*address, > > 0, octstr_len(*address), tolower); > > ./gateway-1.4.3/gw/wml_compiler.c: octstr_convert_range(escape, 0, > > octstr_len(escape), tolower); > > ./gateway-1.4.3/gwlib/octstr.c:void octstr_convert_range(Octstr *ostr, long > > pos, long len, > > ./gateway-1.4.3/gwlib/octstr.c: octstr_convert_range(ostr, 0, ostr->len, > > make_printable); > > > > To me they all seem to point to an URL being bad or similar in a PAP > > request. However I have not changed anything in my config and underlaying > > APP for months. > > > > I also wonder about the spool directory. Why does Kannel continue to crash > > unless we clean the spool directory? > > > > Why are some messages left in the spool directory? The normal behaviour for > > in-/out-bound messages is for them to be stored in the spool directory and > > then deleted once they have been acknowledged to be received. So the > > question then becomes; What’s so “special” with the messages that remains > > in the spool directory? > > > > Looking at the logs from today I find that we end keeping the message with > > ID d4e378df-8fa7-4d7b-83a3-bc28dfc44b12 in the spool directory and not the > > message with ID a45dd024-55dc-46f8-aefa-15d0bb321a73. > > I cannot see any difference in the log file on why the first one is stored > > and the second isn’t. > > > > 2012-09-27 08:14:49 [28185] [3] INFO: smsbox: Got HTTP request > > </cgi-bin/sendsms> from <10.223.205.193> > > 2012-09-27 08:14:49 [28185] [3] INFO: sendsms used by <smsc1> > > 2012-09-27 08:14:49 [28185] [3] INFO: sendsms sender:<smsc1:LabelSMS> > > (10.223.205.193) to:<522225257465> msg:<> > > 2012-09-27 08:14:49 [28185] [3] DEBUG: Stored UUID > > d4e378df-8fa7-4d7b-83a3-bc28dfc44b12 > > 2012-09-27 08:14:49 [28185] [3] DEBUG: message length 0, sending 1 messages > > 2012-09-27 08:14:49 [28185] [3] DEBUG: Status: 202 Answer: <Sent.> > > 2012-09-27 08:14:49 [28185] [3] DEBUG: Delayed reply - wait for bearerbox > > 2012-09-27 08:14:49 [28185] [0] DEBUG: Got ACK (0) of > > d4e378df-8fa7-4d7b-83a3-bc28dfc44b12 > > 2012-09-27 08:14:49 [28185] [0] DEBUG: HTTP: Resetting HTTPClient for > > `10.223.205.193'. > > > > (...) > > > > 2012-09-27 08:14:49 [28185] [3] INFO: smsbox: Got HTTP request > > </cgi-bin/sendsms> from <10.223.205.193> > > 2012-09-27 08:14:49 [28185] [3] INFO: sendsms used by <smsc2> > > 2012-09-27 08:14:49 [28185] [3] INFO: sendsms sender:<smsc2:LabelSMS> > > (10.223.205.193) to:<524423191572> msg:<> > > 2012-09-27 08:14:49 [28185] [3] DEBUG: Stored UUID > > a45dd024-55dc-46f8-aefa-15d0bb321a73 > > 2012-09-27 08:14:49 [28185] [3] DEBUG: message length 0, sending 1 messages > > 2012-09-27 08:14:49 [28185] [3] DEBUG: Status: 202 Answer: <Sent.> > > 2012-09-27 08:14:49 [28185] [3] DEBUG: Delayed reply - wait for bearerbox > > 2012-09-27 08:14:49 [28185] [0] DEBUG: Got ACK (0) of > > a45dd024-55dc-46f8-aefa-15d0bb321a73 > > 2012-09-27 08:14:49 [28185] [0] DEBUG: HTTP: Resetting HTTPClient for > > `10.223.205.193'. > > > > > > Thanks a lot. > > > > ///RGB > > > > > > > > > > > > > > > > ---------------------------------------- > >> Subject: Re: Kannel PANICS octstr_convert_range > >> From: [email protected] > >> Date: Wed, 26 Sep 2012 18:58:32 +0200 > >> CC: [email protected] > >> To: [email protected] > >> > >> Hi, > >> > >> seems some queued message within bearerbox cause this panic. Try ether to > >> upgrade to the latest SVN version > >> or delete bearerbox.store file. > >> > >> Alex > >> > >> On 26.09.2012, at 17:28, Rob GB <[email protected]> wrote: > >> > >>> > >>> Hi Kannel people, > >>> > >>> I have been using Kannel for almost 2 year, but today it has crashed and > >>> cannot make it work: > >>> > >>> > >>> 2012-09-26 17:15:23 [28324] [0] INFO: Added logfile > >>> `/opt/kannel/log/smsbox.log' with level `1'. > >>> 2012-09-26 17:15:23 [28324] [0] INFO: Logging accesses to > >>> '/opt/kannel/log/access.log'. > >>> 2012-09-26 17:15:23 [28324] [0] INFO: Started access logfile > >>> `/opt/kannel/log/access.log'. > >>> 2012-09-26 17:15:23 [28324] [0] INFO: HTTP: Opening server at port 13013. > >>> 2012-09-26 17:15:23 [28324] [0] INFO: Set up send sms service at port > >>> 13013 > >>> 2012-09-26 17:15:23 [28324] [0] INFO: Connected to bearerbox at localhost > >>> port 13001. > >>> 2012-09-26 14:59:38 [754] [4] PANIC: gwlib/octstr.c:2481: > >>> seems_valid_real: Assertion `ostr != NULL' failed. (Called from > >>> gwlib/octstr.c:836:octstr_convert_range.) > >>> 2012-09-26 14:59:38 [754] [4] PANIC: > >>> /opt/kannel/sbin/smsbox(gw_panic+0x15b) [0x43c74b] > >>> 2012-09-26 14:59:38 [754] [4] PANIC: /opt/kannel/sbin/smsbox [0x43cfc9] > >>> 2012-09-26 14:59:38 [754] [4] PANIC: > >>> /opt/kannel/sbin/smsbox(octstr_convert_range+0x3d) [0x43d49d] > >>> 2012-09-26 14:59:38 [754] [4] PANIC: > >>> /opt/kannel/sbin/smsbox(urltrans_find+0x55) [0x41cf75] > >>> 2012-09-26 14:59:38 [754] [4] PANIC: /opt/kannel/sbin/smsbox [0x4156e0] > >>> 2012-09-26 14:59:38 [754] [4] PANIC: /opt/kannel/sbin/smsbox [0x4337d5] > >>> 2012-09-26 14:59:38 [754] [4] PANIC: /lib64/libpthread.so.0 [0x372c20673d] > >>> 2012-09-26 14:59:38 [754] [4] PANIC: /lib64/libc.so.6(clone+0x6d) > >>> [0x372b6d3d1d] > >>> > >>> Neither Kannel nor our app nor the operating system have changed, Kannel > >>> just entered in PANIC and stopped working. > >>> > >>> Kindly assist. Thanks. > >>> > >>> ///RGB > >>> > >>> > >> > > >
