This will happen, but I am holding off for a bit more, as meta-data was
used to implement some new requirements, so I am waiting for a bit to
make sure I am meeting those before making any further change. I will
update when that happens.

Kyriacos

Giulio Harding wrote:
> FYI, with the simple tests I had, this patch fixes the problem - I
> guess the true test is for Kyriacos to put it into production, and
> resume using POSTs, if he feels brave enough :)
>
> Thanks again Alex!
>
> On 25/01/2008, at 12:51 AM, Alexander Malysh wrote:
>
>> Hi again,
>>
>> seems the fix is also really simple :) Please try attached patch.
>>
>> Giulio Harding wrote:
>>
>>> Ok, I've just reproduced Kyriacos' problem - it seems to be an issue
>>> with MT HTTP POST with the TLV HTTP header set.
>>>
>>> This is Kannel from the meta_data branch, with a couple of site-
>>> specific patches (though they shouldn't have any effect - I get the
>>> same results as Kyriacos does, and he's not using our patches)
>>>
>>> Kannel bearerbox version `cvs-20080121'. Build `Jan 24 2008
>>> 20:04:12', compiler `3.4.6 20060404 (Red Hat 3.4.6-9)'. System Linux,
>>> release 2.6.9-67.plus.c4smp, version #1 SMP Mon Nov 26 17:09:43 EST
>>> 2007, machine i686. Hostname kang.adl.mnetcorporation.com, IP
>>> 10.0.0.25. Libxml version 2.6.16. Using OpenSSL 0.9.7a Feb 19 2003.
>>> Using native malloc.
>>>
>>> I'm using Kyriacos' mblox TLV configuration (see his post on 27
>>> November 2007)
>>>
>>> Using the following POST (run with php from commandline)
>>>
>>> <?php
>>>
>>> $post="POST /cgi-bin/sendsms HTTP/1.1
>>> Host: localhost:13189
>>> X-Kannel-Username: xxx
>>> X-Kannel-Password: xxx
>>> X-Kannel-SMSC: mbloxdirectplus
>>> X-Kannel-From: test
>>> X-Kannel-To: xxx
>>> X-Kannel-DLR-Mask: 31
>>> X-Kannel-DLR-Url: http://127.0.0.1/dlr?smsc-id=%i&status=%d&answer=%
>>> A&to=%P&from=%p&ts=%t&o=%o&I=%I
>>> X-Kannel-Meta-Data: ?smpp?MBbilling=0&MBoperator=50503
>>> Content-Type: text/plain
>>> Content-Length: 74
>>>
>>> let me know if you are still there now though cause i was hoping you
>>> were.
>>>
>>> ";
>>>
>>>                  $h=fsockopen('localhost','13189');
>>>                  stream_set_timeout($h, 1);
>>>                  fwrite($h,$post);
>>>                  for($a=0,$r='';!$a;){
>>>                          $b=fread($h,1024);
>>>                          $r.=$b;
>>>                          $a=(($b=='')?1:0);
>>>                  }
>>>                  fclose($h);
>>>                  $c=$c+1;
>>>
>>> ?>
>>>
>>> If the POST is made with X-Kannel-Meta-Data present, smsbox panics
>>> like so:
>>>
>>> ...
>>> 2008-01-24 23:30:20 [6178] [3] INFO: smsbox: Got HTTP request </cgi-
>>> bin/sendsms> from <127.0.0.1>
>>> 2008-01-24 23:30:20 [6178] [3] INFO: sendsms used by <xxx>
>>> 2008-01-24 23:30:20 [6178] [3] INFO: sendsms sender:<xxx:test>
>>> (127.0.0.1) to:<xxx> msg:<let me know if you are still there now
>>> though cause i was hoping you were.>
>>> 2008-01-24 23:30:20 [6178] [3] DEBUG: Stored UUID afd59b9f-5771-496d-
>>> bc02-66151ef95e6d
>>> 2008-01-24 23:30:20 [6178] [3] DEBUG: message length 74, sending 1
>>> messages
>>> 2008-01-24 23:30:20 [6178] [3] PANIC: gwlib/octstr.c:2491:
>>> seems_valid_real: Assertion `ostr->data[ostr->len] == '\0'' failed.
>>> (Called from gwlib/octstr.c:324:octstr_destroy.)
>>> 2008-01-24 23:30:20 [6178] [3] PANIC: /opt/kannel/sbin/smsbox(gw_panic
>>> +0x9e) [0x8080632]
>>> 2008-01-24 23:30:20 [6178] [3] PANIC: /opt/kannel/sbin/smsbox
>>> [0x8081314]
>>> 2008-01-24 23:30:20 [6178] [3] PANIC: /opt/kannel/sbin/smsbox
>>> (octstr_destroy+0x25) [0x80819d9]
>>> 2008-01-24 23:30:20 [6178] [3] PANIC: /opt/kannel/sbin/smsbox
>>> [0x80597e5]
>>> 2008-01-24 23:30:20 [6178] [3] PANIC: /opt/kannel/sbin/smsbox
>>> [0x805a14d]
>>> 2008-01-24 23:30:20 [6178] [3] PANIC: /opt/kannel/sbin/smsbox
>>> [0x807805b]
>>> 2008-01-24 23:30:20 [6178] [3] PANIC: /lib/tls/libpthread.so.0
>>> [0x9cf3cc]
>>> 2008-01-24 23:30:20 [6178] [3] PANIC: /lib/tls/libc.so.6(__clone
>>> +0x5e) [0x7391ae]
>>>
>>> If the POST is made with X-Kannel-Meta-Data removed, everything works
>>> fine.
>>>
>>> MTs sent via GET with meta-data parameter included work fine.
>>>
>>> Amongst the many tests that Kyriacos and I have done, we saw some
>>> different behaviour, including smsbox crashing with nothing output to
>>> its log (it just disappears!), to different panics, like this one
>>> that Kyriacos sent a little earlier:
>>>
>>> 6454403-2008-01-22 12:56:25 [11220] [3] INFO: sendsms sender:<test:
>>> 44777> (10.10.3.27) to:<xxx> msg:<SMART Plan Subscription: $9.99 per
>>> month for 100 credits.  Send Y to accept, STOP to end, for help txt
>>> HELP or 1-888-218-4144 T&C + More at www.SmartLogos.tv>
>>> 6454663-2008-01-22 12:56:25 [11220] [3] DEBUG: Stored UUID ebb82188-
>>> da6c-449a-9b42-11dc143d748a
>>> 6454751-2008-01-22 12:56:25 [11220] [3] DEBUG: message length 157,
>>> sending 1 messages
>>> 6454829-2008-01-22 12:56:25 [11220] [3] ERROR: Start marker was
>>> damaged for area 0xe5d2b08
>>> 6454912-2008-01-22 12:56:25 [11220] [3] ERROR: Could not find area
>>> information.
>>> 6454984:2008-01-22 12:56:25 [11220] [3] PANIC: gwlib/octstr.c:2472:
>>> seems_valid_real: Assertion `gw_check_is_allocated(ostr)' failed.
>>> (Called from gwlib/octstr.c:324:octstr_destroy.)
>>> 6455159:2008-01-22 12:56:25 [11220] [3] PANIC: /usr/local/sbin/smsbox
>>> (gw_panic+0xdc) [0x808ae9c]
>>> 6455248:2008-01-22 12:56:25 [11220] [3] PANIC: /usr/local/sbin/smsbox
>>> [0x808b628]
>>> 6455322:2008-01-22 12:56:25 [11220] [3] PANIC: /usr/local/sbin/smsbox
>>> (octstr_destroy+0x26) [0x808dc46]
>>> 6455417:2008-01-22 12:56:25 [11220] [3] PANIC: /usr/local/sbin/smsbox
>>> [0x8059493]
>>> 6455491:2008-01-22 12:56:25 [11220] [3] PANIC: /usr/local/sbin/smsbox
>>> [0x8080b6e]
>>> 6455565:2008-01-22 12:56:25 [11220] [3] PANIC: /lib/tls/i686/cmov/
>>> libpthread.so.0 [0xb7ed8240]
>>> 6455652:2008-01-22 12:56:25 [11220] [3] PANIC: /lib/tls/i686/cmov/
>>> libc.so.6(__clone+0x5e) [0xb7d533de]
>>>
>>> Hope this is enough information to track down the bug! Unfortunately,
>>> I'm still not up to scratch with tracing execution in GDB, so I can't
>>> quite track down where those bad octstr_destroys are being called
>>> from :(
>>>
>>> Thanks,
>>>
>>>
>>> On 23/01/2008, at 9:42 PM, Kyriacos Sakkas wrote:
>>>
>>>>
>>>>
>>>> Founf some PANIC lines is smsbox.log
>>>>
>>>>
>>>>
>>>>
>>>> Kyriacos Sakkas wrote:
>>>>> My stability issues are in HTTP in both directions it would seem.
>>>>> I get
>>>>> no detailed error messages but it appears that smsbox dies after
>>>>> either
>>>>> forwarding more than 2-3 MOs to my app, or after it receives more
>>>>> than
>>>>> 2-3 MTs from my app. It then gets regenerated, but seems unable to
>>>>> talk
>>>>> properly to bearerbox. Unfortunately the logs show nearly nothing
>>>>> so I
>>>>> do not have something more detailed to share.
>>>>>
>>>>> Do you have another way of reading custom TLV values from DLR
>>>>> messages?
>>>>> The only thing I know that does it is the meta-data patches, and I
>>>>> need
>>>>> to have that functionality urgently, so for me there seems to be no
>>>>> other option, than to get it to work.
>>>>>
>>>>> Kyriacos
>>>
>>> -- 
>>> Giulio Harding
>>> Systems Administrator
>>>
>>> m.Net Corporation
>>> Level 2, 8 Leigh Street
>>> Adelaide SA 5000, Australia
>>>
>>> Tel: +61 8 8210 2041
>>> Fax: +61 8 8211 9620
>>> Mobile: 0432 876 733
>>> Yahoo: giulio.harding
>>> MSN: [EMAIL PROTECTED]
>>>
>>> http://www.mnetcorporation.com
>>
>> -- 
>> Thanks,
>> Alex<mdata-smsbox.diff>
>
> -- 
> Giulio Harding
> Systems Administrator
>
> m.Net Corporation
> Level 2, 8 Leigh Street
> Adelaide SA 5000, Australia
>
> Tel: +61 8 8210 2041
> Fax: +61 8 8211 9620
> Mobile: 0432 876 733
> Yahoo: giulio.harding
> MSN: [EMAIL PROTECTED]
>
> http://www.mnetcorporation.com
>
>


-- 
Kyriacos Sakkas
Development Team
Netsmart
Tel: + 357 22 452565
Fax: + 357 22 452566
Email: [EMAIL PROTECTED]
http://www.netsmart.com.cy

Taking Business to a New Level!

** Confidentiality Notice: The information contained in this email
message may be privileged, confidential and protected from disclosure.
If you are not the intended recipient, any dissemination, distribution,
or copying of this  email message is strictly prohibited.
If you think that you have received this email message in error, please
email the sender at [EMAIL PROTECTED] **


Reply via email to