Two (possible) bugs with 1.4.0
Hi, I installed Kannel 1.4.0 on a Fedora core 2 box and it is working fine. Thanks for all your efforts. However, I discovered the following two things which I think may be bugs: 1. I use postgresql (v 7.4.6) for dlr-storage, as can be seen from my config file below. However, I get the following error when it seems that Kannel wants to delete the entries from the database: 2005-02-01 07:41:08 [1628] [6] ERROR: PGSQL: DELETE FROM dlr WHERE smsc='vodacom' AND ts='01/00/213d14b8/1127828553923' LIMIT 1; 2005-02-01 07:41:08 [1628] [6] ERROR: PGSQL: ERROR: syntax error at or near "LIMIT" at character 76 2005-02-01 07:41:08 [1628] [6] ERROR: PGSQL: DB update failed! 2. I cannot, for the life of me, get aliases to work for sms-services. None of the aliases for any of the services specified below works. Thanks again for a great piece of software. Johann kannel.conf group = core admin-port = 13000 admin-password = log-file = "/var/log/kannel/bearerbox.log" log-level = 1 access-log = "/var/log/kannel/beareraccess.log" smsbox-port = 13001 dlr-storage = pgsql # SMSC SMPP group = smsc smsc = smpp smsc-id = vodacom host = port = 1060 receive-port = 1060 smsc-username = smsc-password = system-type = "CMT" transceiver-mode = 1 source-addr-ton = 1 dest-addr-ton = 1 throughput = 5 source-addr-autodetect = no # SMSBOX SETUP group = smsbox bearerbox-host = localhost sendsms-port = 13013 global-sender = xxx log-file = "/var/log/kannel/smsbox.log" log-level = 1 access-log = "/var/log/kannel/smsaccess.log" # SEND-SMS USERS group = sendsms-user username = xx password = x dlr-url = "http://localhost/dlr/?msisdn=%p&msg=%a&smscid=%i&smsid=%I&dlrtype=%d&dlrsmsc=%A&time=%t"; # SMS SERVICES group = sms-service name = sdt keyword = sdt aliases = shinfo;sharedata url = "http://22.22.22.22/jse/scripts/sd.asp?ticker=%s"; catch-all = true omit-empty = true group = sms-service name = slots keyword = slots aliases = spin;play url = "http://localhost:8080/play?cell=%p"; catch-all = true omit-empty = true #A simple test service group = sms-service name = nop keyword = nop text = "You asked nothing and I did it!" # SMS SERVICE Default # there should be default always group = sms-service keyword = default text = "No service specified. Please try again." group = pgsql-connection id = mydlr host = localhost username = xx password = xx database = kannel max-connections = 1 group = dlr-db id = mydlr table = dlr field-smsc = smsc field-timestamp = ts field-destination = destination field-source = source field-service = service field-url = url field-mask = mask field-status = status field-boxc-id = boxc
WAP test set up with Kannel gateway
I need to set up a test environment using Kannel as the gateway. I need this for testing my WAP system from my mobile phone. Can somebody share their ideas on how should I go about in setting up the environment? What infrastructure support should I have? Thanks and Regards, Shashi Anand B
[PATCH] glibc malloc hooks for gwmem-check
Hi together,
please find attached patch that adds support for glibc malloc hooks and so
make it possible to debug memory problems in external libraries.
Comments?
--
Thanks,
AlexIndex: gwlib/thread.h
===
RCS file: /home/cvs/gateway/gwlib/thread.h,v
retrieving revision 1.23
diff -a -u -p -r1.23 thread.h
--- gwlib/thread.h 22 Jan 2004 14:08:25 - 1.23
+++ gwlib/thread.h 2 Feb 2005 17:04:02 -
@@ -85,6 +85,25 @@ typedef struct {
#endif
} Mutex;
+#ifdef MUTEX_STATS
+#define GW_MUTEX_INITIALIZER\
+{ \
+.mutex = PTHREAD_MUTEX_INITIALIZER, \
+.owner = -1,\
+.dynamic = 0, \
+.filename = __FILE__, \
+.lineno = __LINE__, \
+.locks = 0, \
+.collisions = 0,\
+}
+#else
+#define GW_MUTEX_INITIALIZER\
+{ \
+.mutex = PTHREAD_MUTEX_INITIALIZER, \
+.owner = -1,\
+.dynamic = 0, \
+}
+#endif
/*
* Create a Mutex.
Index: gwlib/gwmem-check.c
===
RCS file: /home/cvs/gateway/gwlib/gwmem-check.c,v
retrieving revision 1.27
diff -a -u -p -r1.27 gwmem-check.c
--- gwlib/gwmem-check.c 21 Jan 2005 13:50:46 - 1.27
+++ gwlib/gwmem-check.c 2 Feb 2005 17:04:02 -
@@ -131,7 +131,7 @@ static int slow = 0;
/* We have to use a static mutex here, because otherwise the mutex_create
* call would try to allocate memory with gw_malloc before we're
* initialized. */
-static Mutex gwmem_lock;
+static Mutex gwmem_lock = GW_MUTEX_INITIALIZER;
struct location
{
@@ -192,6 +192,76 @@ static long highest_total_size;
/* Current sum of allocated areas */
static long total_size;
+
+/* glibc malloc debugging */
+#ifdef __GLIBC__
+#include
+static void *gw_check_malloc_hook(size_t, const void*);
+static void gw_check_free_hook(void*, const void*);
+static void *gw_check_realloc_hook(void*, size_t, const void*);
+static void switch_to_gw_hook(void);
+static void init_gw_hook(void);
+
+static void *(*old_malloc_hook)(size_t, const void*);
+static void (*old_free_hook)(void*, const void*);
+static void *(*old_realloc_hook)(void*, size_t, const void*);
+
+void (*__malloc_initialize_hook)(void) = init_gw_hook;
+
+static pthread_mutex_t hook_lock = PTHREAD_MUTEX_INITIALIZER;
+
+static void init_gw_hook(void)
+{
+gw_check_init_mem(1);
+old_malloc_hook = __malloc_hook;
+__malloc_hook = gw_check_malloc_hook;
+old_free_hook = __free_hook;
+__free_hook = gw_check_free_hook;
+old_realloc_hook = __realloc_hook;
+__realloc_hook = gw_check_realloc_hook;
+}
+
+static void switch_to_gw_hook(void)
+{
+old_malloc_hook = __malloc_hook;
+__malloc_hook = gw_check_malloc_hook;
+old_free_hook = __free_hook;
+__free_hook = gw_check_free_hook;
+old_realloc_hook = __realloc_hook;
+__realloc_hook = gw_check_realloc_hook;
+pthread_mutex_unlock(&hook_lock);
+}
+
+static void switch_to_glibc_hook(void)
+{
+pthread_mutex_lock(&hook_lock);
+/* restore old hoocks */
+__malloc_hook = old_malloc_hook;
+__free_hook = old_free_hook;
+__realloc_hook = old_realloc_hook;
+}
+
+
+static void *gw_check_malloc_hook(size_t size, const void *caller)
+{
+return gw_check_malloc(size, "?", 0, "?");
+}
+
+static void gw_check_free_hook(void *p, const void *caller)
+{
+gw_check_free(p, "?", 0, "?");
+}
+
+static void *gw_check_realloc_hook(void *ptr, size_t size, const void *caller)
+{
+return gw_check_realloc(ptr, size, "?", 0, "?");
+}
+#else
+#define switch_to_glibc_hook() do{}while(0)
+#define switch_to_gw_hook() do{}while(0)
+#endif /* __GLIBC__ */
+
+
/* Static functions */
static inline void lock(void)
@@ -341,7 +411,10 @@ static void dump_area(struct area *area)
#if HAVE_BACKTRACE
{
size_t i;
-char **strings = backtrace_symbols(area->frames, area->frame_size);
+char **strings;
+switch_to_glibc_hook();
+strings = backtrace_symbols(area->frames, area->frame_size);
+switch_to_gw_hook();
debug("gwlib.gwmem", 0, "Backtrace of last malloc/realloc:");
for (i = 0; i < area->frame_size; i++) {
if (strings != NULL)
@@ -349,7 +422,9 @@ static void dump_area(struct area *area)
else
debug("gwlib.gwmem", 0, "%p", area->frames[i]);
}
+switch_to_glibc_hook();
free(strings);
+switch_to_gw_hook();
}
#endif
}
@@ -415,7 +490,7 @@ static void change_total_size(long chang
}
static struct area *record_allocation(unsigned char *p, size_t size,
- const char *filename, long lineno, const char *function)
+ const char *filename, long l
Re: [PATCH] WSP headers with value
Hi, Stipe.
I've tested it with Nokia 3660 (which uses exactly this Accept header in
Connect PDU and doesn't work without patch). Everything is ok.
Stipe Tolj wrote:
Aarno Syvänen wrote:
Have you tested the modification ? What will be result of parsing 0x80
0x00 ? Accept:
is ok according the rfc 2616. (Because this is a low level parsing
function, you definitely want to test.)
Aarno, did you have chances to test this with various phones?
Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
--
Vjacheslav Chekushinmailto:[EMAIL PROTECTED]
Latvian Mobile Phone Companyhttp://www.lmt.lv
Re: Config-based Optional Parameter Functionality
Peter Beckman wrote:
Dear Kannel Developers:
I've written about this before, but I thought I would bring it up again
because I hate patching.
Many SMSC's are starting to use the optional SMPP parameters for
information like billing issues, carrier failures, etc. Kannel really
doesn't allow for this -- it detects the parameters, but is unable to
actually turn them into some sort of passable escape code(s) via
sms-service.
Take for example this log dump:
2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x0427)
2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read as 1
2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x001e)
2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read as 29
2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1402)
2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read as 1
2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1404)
2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read as 22
2005-01-27 16:46:56 [30186] [7] ERROR: SMPP: Unknown
TLV(0x1404,0x0016,4154265420576972656c657373205365727669636573) for PDU
type (deliver_sm) received!
2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1530)
2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read as 3
2005-01-27 16:46:56 [30186] [7] ERROR: SMPP: Unknown
TLV(0x1530,0x0003,504244) for PDU type (deliver_sm) received!
2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1531)
2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read as 90
2005-01-27 16:46:56 [30186] [7] ERROR: SMPP: Unknown
TLV(0x1531,0x005a,4e6f2050686f6e65204e756d6265723a20537562736372696265722070686f6e65206e756d62657220776173206e6f74206d617463686
56420696e2074686520515073732073797374656d206f722041575320506f7274616c20)
for PDU type (deliver_sm) received!
2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1532)
2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read as 6
2005-01-27 16:46:56 [30186] [7] ERROR: SMPP: Unknown
TLV(0x1532,0x0006,2d3230313030) for PDU type (deliver_sm) received!
2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1533)
2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read as 90
2005-01-27 16:46:56 [30186] [7] ERROR: SMPP: Unknown
TLV(0x1533,0x005a,4e6f2050686f6e65204e756d6265723a20537562736372696265722070686f6e65206e756d62657220776173206e6f74206d617463686
56420696e2074686520515073732073797374656d206f722041575320506f7274616c20)
for PDU type (deliver_sm) received!
2005-01-27 16:46:56 [30186] [7] DEBUG: SMPP[mysmsc]: Got PDU:
2005-01-27 16:46:56 [30186] [7] DEBUG: SMPP PDU 0xb5c9a5e0 dump:
2005-01-27 16:46:56 [30186] [7] DEBUG: type_name: deliver_sm
2005-01-27 16:46:56 [30186] [7] DEBUG: command_id: 5 = 0x0005
2005-01-27 16:46:56 [30186] [7] DEBUG: command_status: 0 = 0x
2005-01-27 16:46:56 [30186] [7] DEBUG: sequence_number: 877 = 0x036d
[...]
My dream for the config file:
group = smsbox
smsc-id = mysmsc
[...]
optparam = 0x1404:22:N:billerr_msg
optparam = 0x1530:3:M:happy_tag
optparam = 0x1531:90:K:secret_code
optparam = 0x1532:6:J:test_msg_id
optparam = 0x1533:90:L:secret_code2
Now the following takes place:
When an SMS arrives, it can be passed to sms-service, using %N, %M, %K,
%J and %L (assuming those are available), so I can grab them with a PHP
script and do something with them.
When submitting an SMS to kannel, I can set the URL to:
http://localhost:13013/cgi-bin/sendsms?user=[...]&billerr_msg=you+spent+too+much&happy_tag=fun&text_msg_id=123FFF
And kannel will modify the PDU to include the data passed and send that
to the SMSC.
now, this approach does not "handle" on how you pass the SMPP specific optional
parameters in the Kannel internal msg structure to smsbox.
I see (and I agree) that we may have a generic way in passing SMSC specific
optional parameters up to the application layer and vice versa. But it should be
as clean as possible and transparently configurable for all SMSC protocols.
Therefore we need a sort of Dict that contains key:value pairs within the msg
structure. Any ideas on how we could handle this? Alex?
Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
Re: [PATCH] WSP headers with value
Aarno Syvänen wrote:
Have you tested the modification ? What will be result of parsing 0x80
0x00 ? Accept:
is ok according the rfc 2616. (Because this is a low level parsing
function, you definitely want to test.)
Aarno, did you have chances to test this with various phones?
Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
Re: [Fwd: Requesting DLR for binary messages]
AFAIK, DLR's are NOT encoded on UDH. They are a quite different kind of beast, they are encoded on the PDU and delivered back on another PDU. If you think it a little, it makes no sense at all: UDH data is expected to be sent to terminals, while DLR requests are meant to be dealt with on the SMSC: You are asking the _SMSC_, not the terminal that you want to be notified when a message was delivered (or not) to a terminal. How could a turned-off terminal notify you about a message not being delivered? ;) Try first to get DLR's to work with regular text messages (no concatenetion nor UDH being set). And then try with messages carrying an UDH... It 'should' work (note the single quotes meaning "it should, I've never tried it myself"), maybe there is some bug or something similar, but it is surely not a protocol limitation. BTW, except that you've really found out a bug or something similar, maybe we should follow the thread on the users list. Regards, On Wed, 2 Feb 2005 20:53:59 +1100, Benjamin Lee <[EMAIL PROTECTED]> wrote: > Er... I'm not sure if I understand the question... so if I'm answering > the wrong thing... please excuse... ;-))) > > Correct me if I'm wrong... but I thought DLR was specific to the SMSC > protocol. e.g. SMPP 3.4 Issue 1.2 p.124 / 5.2.17 registered_delivery > *not* in the UDH. > > So the value of dlr-mask *should* work. I haven't used this in a long > time... so I could be completely wrong... > > Looks OK for smsc_smpp.c: > >/* ask for the delivery reports if needed */ >if (DLR_IS_SUCCESS_OR_FAIL(msg->sms.dlr_mask)) >pdu->u.submit_sm.registered_delivery = 1; >else if (DLR_IS_FAIL(msg->sms.dlr_mask) && > !DLR_IS_SUCCESS(msg->sms.dlr_mask)) >pdu->u.submit_sm.registered_delivery = 2; > > What do you mean by "delivery tracking bits"? ;-P > > On Wednesday, 2005-02-02 at 01:16:09 AM, Enver ALTIN scribbled: > > Hi, > > > > Forwarding here with hope to find an answer :) > > > > Thanks, > > > > Forwarded Message > > From: Enver ALTIN <[EMAIL PROTECTED]> > > To: users@kannel.org > > Subject: Requesting DLR for binary messages > > Date: Mon, 31 Jan 2005 16:39:10 +0200 > > Hi, > > > > I'm developing an application which sends binary messages with UDH, and > > I'd love to add delivery tracking bits here and there. > > > > Seems like DLR-related stuff is transmitted in UDH, and that's what I'm > > overriding so Kannel's dlr-mask just doesn't seem to work. > > > > What can I do? What actually I'm looking for is a brief 10-lines > > explanation about that, which fields of UDH are used for what. Alex > > suggested me to take a look at ETSI 03.38 and 03.40, although they look > > a bit like Cyrillic to me ;) > > > > Any clues? > > > > Thanks a lot, > > -- > > Enver ALTIN |http://skyblue.gen.tr/ > > Software developer @ Parkyeri | http://www.parkyeri.com/ > > -- > Benjamin Lee > Melbourne, AU +61.4.16.BEN.LEE http://www.realthought.net/ > Open Source / Linux / BSD > __ > Only a fool has no doubts. > > -- Alejandro Guerrieri Magicom http://www.magicom-bcn.net/
Re: [Fwd: Requesting DLR for binary messages]
Er... I'm not sure if I understand the question... so if I'm answering the wrong thing... please excuse... ;-))) Correct me if I'm wrong... but I thought DLR was specific to the SMSC protocol. e.g. SMPP 3.4 Issue 1.2 p.124 / 5.2.17 registered_delivery *not* in the UDH. So the value of dlr-mask *should* work. I haven't used this in a long time... so I could be completely wrong... Looks OK for smsc_smpp.c: /* ask for the delivery reports if needed */ if (DLR_IS_SUCCESS_OR_FAIL(msg->sms.dlr_mask)) pdu->u.submit_sm.registered_delivery = 1; else if (DLR_IS_FAIL(msg->sms.dlr_mask) && !DLR_IS_SUCCESS(msg->sms.dlr_mask)) pdu->u.submit_sm.registered_delivery = 2; What do you mean by "delivery tracking bits"? ;-P On Wednesday, 2005-02-02 at 01:16:09 AM, Enver ALTIN scribbled: > Hi, > > Forwarding here with hope to find an answer :) > > Thanks, > > Forwarded Message > From: Enver ALTIN <[EMAIL PROTECTED]> > To: users@kannel.org > Subject: Requesting DLR for binary messages > Date: Mon, 31 Jan 2005 16:39:10 +0200 > Hi, > > I'm developing an application which sends binary messages with UDH, and > I'd love to add delivery tracking bits here and there. > > Seems like DLR-related stuff is transmitted in UDH, and that's what I'm > overriding so Kannel's dlr-mask just doesn't seem to work. > > What can I do? What actually I'm looking for is a brief 10-lines > explanation about that, which fields of UDH are used for what. Alex > suggested me to take a look at ETSI 03.38 and 03.40, although they look > a bit like Cyrillic to me ;) > > Any clues? > > Thanks a lot, > -- > Enver ALTIN |http://skyblue.gen.tr/ > Software developer @ Parkyeri | http://www.parkyeri.com/ -- Benjamin Lee Melbourne, AU +61.4.16.BEN.LEE http://www.realthought.net/ Open Source / Linux / BSD __ Only a fool has no doubts.
