Hi Alex,
Thanks a lot for your help, we applied the patch days ago and our Kannel 
instance has been stable since then.
Best regards

Subject: Re: Kannel PANICS octstr_convert_range
From: [email protected]
Date: Thu, 27 Sep 2012 15:03:48 +0200
CC: [email protected]
To: [email protected]

http://www.kannel.org/pipermail/devel/attachments/20090826/42b1df45/attachment-0001.obj
On 27.09.2012, at 13:37, Rob GB <[email protected]> wrote:
Hi,

I think the fix was commited in this bug, but cannot find in the repo:

http://www.kannel.org/pipermail/devel/2009-August/002872.html

Could you guide me where the fix is?

Thanks.

----------------------------------------
From: [email protected]
To: [email protected]
CC: [email protected]
Subject: RE: Kannel PANICS octstr_convert_range
Date: Thu, 27 Sep 2012 05:19:31 -0500


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






                                          
                                          

Reply via email to