[PATCH] Memory leak in smpp_pdu.c
Hi all, I have been assisting with a KSMPPD implementation and couldn't figure out why the application was leaking memory. After a long search I found that an SMPP client was sending the same TLV multiple times which was causing lost pointers/memory leaks. I believe this would effect all Kannel derivatives (OpenSMPPBox, Commercial SMPPBox and Bearerbox) in the cases where an incorrectly implemented (or malicious?) client or gateway could be the cause of memory leaks. Herewith patch to fix. Thanks, Donald smpp_pdu_tlv_memory_leak.patch Description: Binary data
[PATCH] Reduce logging in dbpool_mysql.c
Hi there, This is a simple patch to reduce excessive logging output of dbpool_mysql.c As we know many people run their Kannel systems with debug logging enabled so running with '-v 1' isn't a solution to this problem and I see no benefit of having this repetitive logging. Thanks, Donald dbpool_mysql_reduce_logging.patch Description: Binary data
[PATCH] KSMPPD (and other?) utility methods for smpp_pdu.c
Hi all, Currently KSMPPD runs a patch against Kannel SVN trunk, I believe it would be better if we could just include this patch in the mainline Kannel as they don't have any negative implications. Currently the smpp_pdu_unpack() function takes data without length but the smpp_pdu_pack() function provides length so these two functions are not compatible with each other. This simple patch just allows for compatibility convenience. Thanks, Donald smpp_pdu_pack.patch Description: Binary data
RE: [PATCH] Memory leak in smpp_pdu.c
+1 from me. Van: devel [mailto:devel-boun...@kannel.org] Namens Donald Jackson Verzonden: zaterdag 24 september 2016 12:00 Aan: kannel_dev_mailinglist Onderwerp: [PATCH] Memory leak in smpp_pdu.c Hi all, I have been assisting with a KSMPPD implementation and couldn't figure out why the application was leaking memory. After a long search I found that an SMPP client was sending the same TLV multiple times which was causing lost pointers/memory leaks. I believe this would effect all Kannel derivatives (OpenSMPPBox, Commercial SMPPBox and Bearerbox) in the cases where an incorrectly implemented (or malicious?) client or gateway could be the cause of memory leaks. Herewith patch to fix. Thanks, Donald
RE: [PATCH] Reduce logging in dbpool_mysql.c
I don’t agree completely with your reasoning. Either you want debug information or you don’t. Enabling debug information yields a lot of information. What about if you want to debug the mysql pool usage? Still +0 from me in case it’s redundant info. Van: devel [mailto:devel-boun...@kannel.org] Namens Donald Jackson Verzonden: zaterdag 24 september 2016 12:03 Aan: kannel_dev_mailinglist Onderwerp: [PATCH] Reduce logging in dbpool_mysql.c Hi there, This is a simple patch to reduce excessive logging output of dbpool_mysql.c As we know many people run their Kannel systems with debug logging enabled so running with '-v 1' isn't a solution to this problem and I see no benefit of having this repetitive logging. Thanks, Donald
RE: [PATCH] KSMPPD (and other?) utility methods for smpp_pdu.c
Sure, but why not change KSMPPD to use smpp_pdu_pack() function without the length? == Rene Van: devel [mailto:devel-boun...@kannel.org] Namens Donald Jackson Verzonden: zaterdag 24 september 2016 12:07 Aan: kannel_dev_mailinglist Onderwerp: [PATCH] KSMPPD (and other?) utility methods for smpp_pdu.c Hi all, Currently KSMPPD runs a patch against Kannel SVN trunk, I believe it would be better if we could just include this patch in the mainline Kannel as they don't have any negative implications. Currently the smpp_pdu_unpack() function takes data without length but the smpp_pdu_pack() function provides length so these two functions are not compatible with each other. This simple patch just allows for compatibility convenience. Thanks, Donald
Re: [PATCH] KSMPPD (and other?) utility methods for smpp_pdu.c
Yes that how it is currently, just semantically I think it would be better to have all the PDU assembly/disassembly functions in one place. It may also benefit others in future to have compatible pack/unpack functions out the box. On Saturday, 24 September 2016, Rene Kluwen wrote: > Sure, but why not change KSMPPD to use smpp_pdu_pack() function without > the length? > > > > == Rene > > > > > > *Van:* devel [mailto:devel-boun...@kannel.org > ] *Namens *Donald > Jackson > *Verzonden:* zaterdag 24 september 2016 12:07 > *Aan:* kannel_dev_mailinglist > > *Onderwerp:* [PATCH] KSMPPD (and other?) utility methods for smpp_pdu.c > > > > Hi all, > > > > Currently KSMPPD runs a patch against Kannel SVN trunk, I believe it would > be better if we could just include this patch in the mainline Kannel as > they don't have any negative implications. > > > > Currently the smpp_pdu_unpack() function takes data without length but the > smpp_pdu_pack() function provides length so these two functions are not > compatible with each other. This simple patch just allows for > compatibility convenience. > > > > Thanks, > > Donald > -- Donald Jackson http://www.elite-sms-software.com http://www.ddj.co.za http://www.thearchitech.com donald(a)thearchitech.com
Re: [PATCH] Reduce logging in dbpool_mysql.c
I'm on your side but many Kannel users run in debug log level, and this particular information is the same every time - it doesn't change from request to request. It's a non essential patch just 'nice to have' for most. On Saturday, 24 September 2016, Rene Kluwen wrote: > I don’t agree completely with your reasoning. > > Either you want debug information or you don’t. > > Enabling debug information yields a lot of information. > > What about if you want to debug the mysql pool usage? > > > > Still +0 from me in case it’s redundant info. > > > > *Van:* devel [mailto:devel-boun...@kannel.org > ] *Namens *Donald > Jackson > *Verzonden:* zaterdag 24 september 2016 12:03 > *Aan:* kannel_dev_mailinglist > > *Onderwerp:* [PATCH] Reduce logging in dbpool_mysql.c > > > > Hi there, > > > > This is a simple patch to reduce excessive logging output of dbpool_mysql.c > > > > As we know many people run their Kannel systems with debug logging enabled > so running with '-v 1' isn't a solution to this problem and I see no > benefit of having this repetitive logging. > > > > Thanks, > > Donald > -- Donald Jackson http://www.elite-sms-software.com http://www.ddj.co.za http://www.thearchitech.com donald(a)thearchitech.com