[FYI] fixed WTP bogus PDU handling bug and commited octstr_dump() enhancements

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[FYI] fixed WTP bogus PDU handling bug and commited octstr_dump() enhancements

Stipe Tolj
Hi list,

two commits from my side for today:

2006-02-23  Stipe Tolj  <stolj at kannel.org>
   * wap/wtp.c: fixing bug #310, causing wapbox to panic while gwlist_append()
     produces an assertion error if a malformed WTP datagram is tried to be
     processes and we try to send an RcvError PDU deducing the TID value from
     the WTP datagram, causing us to push the WAPEvent into a wrong list.

This was causing wapbox to panic on a high-loaded system. Now we're supposed to
consider us immunic for bogus WTP data. We simply don't reply to the WTP initiator.

2006-02-23  Stipe Tolj  <stolj at kannel.org>
   * gwlib/octstr.[ch]: adding a more flexible octstr_dump() call via a variadic
     macro call. Allowing a third argument specifying the log-level of the
     Octstr dump. Ie. octstr_dump(ost, 0, GW_ERROR) will dump in ERROR log level.
     The variadic macro will allow the current usage without a third parameter
     and hence doesn't require mass patching of existing code. This more flexible
     octstr_dump() is intended to be used for higher log level runs, where we
     still want to dump particular data in case we run into warnings or errors.
     Running in debug log level for real-life production systems in order to get
     full data dumps is not suitable for a long period, so this allows a shorted
     log level with reduced log sizes, but octstr_dumps where we need.

This is a feature improvement. Actually I always hated the idea to have debug
log-level active in order to get flow-through data via ocstr_dump() calls.

On high-load systems your debug log-level will run you out of disk space very
fast. So this is an approach to let developers log octstr data in a higher
log-level.

This was applied for the above WTP layer fixing directly ;)

Stipe

-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany

tolj.org system architecture      Kannel Software Foundation (KSF)
http://www.tolj.org/              http://www.kannel.org/

mailto:st_{at}_tolj.org           mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: [FYI] fixed WTP bogus PDU handling bug and commited octstr_dump() enhancements

Deon van der Merwe-2
Hi Stipe,

On 2/23/06, Stipe Tolj <[hidden email]> wrote:

> Hi list,
>
> two commits from my side for today:
>
> 2006-02-23  Stipe Tolj  <stolj at kannel.org>
>    * wap/wtp.c: fixing bug #310, causing wapbox to panic while gwlist_append()
>      produces an assertion error if a malformed WTP datagram is tried to be
>      processes and we try to send an RcvError PDU deducing the TID value from
>      the WTP datagram, causing us to push the WAPEvent into a wrong list.
>
> This was causing wapbox to panic on a high-loaded system. Now we're supposed to
> consider us immunic for bogus WTP data. We simply don't reply to the WTP initiator.
>

Is this realted to PANIC's like this:
2006-02-23 09:42:46 [7958] [0] PANIC: gwlib/list.c:502: lock:
Assertion `list != NULL' failed.
2006-02-23 09:42:46 [7958] [0] PANIC:
/usr/local/sbin/wapbox(gw_panic+0x16b) [0x80d2b8a]
2006-02-23 09:42:46 [7958] [0] PANIC: /usr/local/sbin/wapbox [0x80d1a94]
2006-02-23 09:42:46 [7958] [0] PANIC:
/usr/local/sbin/wapbox(gwlist_append+0x11) [0x80d0eec]
2006-02-23 09:42:46 [7958] [0] PANIC:
/usr/local/sbin/wapbox(gwlist_produce+0x14) [0x80d1782]
2006-02-23 09:42:46 [7958] [0] PANIC:
/usr/local/sbin/wapbox(wtp_initiator_dispatch_event+0x17) [0x80a7f8e]
2006-02-23 09:42:46 [7958] [0] PANIC:
/usr/local/sbin/wapbox(wap_dispatch_datagram+0x11c) [0x808606c]
2006-02-23 09:42:46 [7958] [0] PANIC:
/usr/local/sbin/wapbox(main+0x45e) [0x805bafd]
2006-02-23 09:42:46 [7958] [0] PANIC:
/lib/libc.so.6(__libc_start_main+0xc6) [0x4bcde6]
2006-02-23 09:42:46 [7958] [0] PANIC: /usr/local/sbin/wapbox [0x8059e4d]

This has happenned before, and again now with the "Kannel wapbox
version cvs-20060223 starting up" version.