Re: Malformed addr for Incoming short code
On Mon, 2006-02-06 at 20:10 +0100, Stipe Tolj wrote: But this brings us up again to the point do we hence support protocol misbehaviours?. The answer SHOULD be no. But it's the same answer for the question should we allow to much individual patching and hence branch diversification. Ideas, comments welcome. I'm a bit late here (been away etc.) but my opinion on these is that as it is often very difficult or even impossible to say to operator that their SMSC works badly (yes, I have been there several times) I would write code in Kannel and then put it behind configuration variable (accept-bad-...) - and that in main trunk instead of branches. There was this 'alt-charset' thing long time ago in Kannel. We cannot change the world always. The answer should be no, but I prefer to choose flexibility over banging my head against the wall. And yes I know the implications, and thus such code should be very well commented in the code. -- Kalle Marjola :: EME Development :: Enpocket Inc. Helsinki Finland
Re: [patch] RE: immediate-sendsms-reply
On Mon, 2005-03-21 at 13:11, Alexander Malysh wrote: Hi, Kalle Marjola wrote: Ok, I though over this and a bit updated your patch so that it only waits if there are 'partially handled HTTP request' in the air (i.e. has already sent the message onward to bearerbox but has not yet stored the http client into disctionary). Moreover, the processing time between sending the message to bb and saving the client into dictionary has been minimized.. why not first put http client into dictionary and then send msg to bearerbox? I thought about that and did not do that way because that would overload several functions with a list of new parameters, -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
[patch] RE: immediate-sendsms-reply
Ok, I though over this and a bit updated your patch so that it only
waits if there are 'partially handled HTTP request' in the air (i.e. has
already sent the message onward to bearerbox but has not yet stored the
http client into disctionary). Moreover, the processing time between
sending the message to bb and saving the client into dictionary has been
minimized..
If you (or anybody else) could test this patched (diff -u) smsbox then
that would be great. I already run 'make check' etc. with it and worked
fine but currently I'm a bit busy to do more testing... :/
--
Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Index: gw/smsbox.c
===
RCS file: /home/cvs/gateway/gw/smsbox.c,v
retrieving revision 1.257
diff -u -r1.257 smsbox.c
--- gw/smsbox.c 22 Feb 2005 16:22:03 - 1.257
+++ gw/smsbox.c 18 Mar 2005 08:24:06 -
@@ -138,6 +138,7 @@
static int immediate_sendsms_reply = 0;
static Dict *client_dict = NULL;
static List *sendsms_reply_hdrs = NULL;
+static Counter *partway_http_requests = NULL;
/***
* Communication with the bearerbox.
@@ -172,7 +173,17 @@
uuid_unparse(msg-ack.id, id);
os = octstr_create(id);
debug(sms.http, 0, Got ACK (%ld) of %s, msg-ack.nack,
octstr_get_cstr(os));
+ retry_remove:
client = dict_remove(client_dict, os);
+if (client == NULL counter_value(partway_http_requests)) {
+ /*
+* most probably the bearerbox answers us faster than we have added
+* the new request into our dictionary. So give some extra time for
+* http request thread
+*/
+ gwthread_sleep(0.1);
+ goto retry_remove;
+}
if (client == NULL) {
debug(sms.http, 0, No client - multi-send or ACK to pull-reply);
octstr_destroy(os);
@@ -3137,65 +3148,73 @@
info(0, smsbox: Got HTTP request %s from %s,
octstr_get_cstr(url), octstr_get_cstr(ip));
-/*
- * determine which kind of HTTP request this is any
- * call the necessary routine for it
- */
-
-/* sendsms */
-if (octstr_compare(url, sendsms_url) == 0)
-{
- /*
-* decide if this is a GET or POST request and let the
-* related routine handle the checking
+ if (partway_http_requests)
+ counter_increase(partway_http_requests);
+
+ /*
+* determine which kind of HTTP request this is any
+* call the necessary routine for it
*/
- if (body == NULL)
- answer = smsbox_req_sendsms(args, ip, status, stored_uuid);
- else
- answer = smsbox_sendsms_post(hdrs, body, ip, status, stored_uuid);
-}
-/* XML-RPC */
-else if (octstr_compare(url, xmlrpc_url) == 0)
-{
-/*
- * XML-RPC request needs to have a POST body
- */
-if (body == NULL) {
-answer = octstr_create(Incomplete request.);
-status = HTTP_BAD_REQUEST;
-} else
-answer = smsbox_xmlrpc_post(hdrs, body, ip, status);
-}
-/* sendota */
-else if (octstr_compare(url, sendota_url) == 0)
-{
- if (body == NULL)
-answer = smsbox_req_sendota(args, ip, status, stored_uuid);
-else
-answer = smsbox_sendota_post(hdrs, body, ip, status,
stored_uuid);
-}
-/* add aditional URI compares here */
-else {
-answer = octstr_create(Unknown request.);
-status = HTTP_NOT_FOUND;
-}
- debug(sms.http, 0, Status: %d Answer: %s, status,
- octstr_get_cstr(answer));
+ /* sendsms */
+ if (octstr_compare(url, sendsms_url) == 0)
+ {
+ /*
+* decide if this is a GET or POST request and let the
+* related routine handle the checking
+*/
+ if (body == NULL)
+ answer = smsbox_req_sendsms(args, ip, status,
stored_uuid);
+ else
+ answer = smsbox_sendsms_post(hdrs, body, ip, status,
stored_uuid);
+ }
+ /* XML-RPC */
+ else if (octstr_compare(url, xmlrpc_url) == 0)
+ {
+ /*
+* XML-RPC request needs to have a POST body
+*/
+ if (body == NULL) {
+ answer = octstr_create(Incomplete request.);
+ status = HTTP_BAD_REQUEST;
+ } else
+ answer = smsbox_xmlrpc_post(hdrs, body, ip, status);
+ }
+ /* sendota */
+ else if (octstr_compare(url, sendota_url) == 0)
+ {
+ if (body == NULL)
+ answer = smsbox_req_sendota(args, ip, status,
stored_uuid);
+ else
+ answer = smsbox_sendota_post(hdrs, body, ip, status,
stored_uuid);
+ }
+ /* add aditional URI compares here
RE: [RFC] --disable-panics configuration option
On Wed, 2005-03-16 at 19:09, Pommnitz, Jörg wrote: But this just confirms what I wrote: such a panic is obviously inappropriate and should be replaced by a warning. So, I stand by what I wrote earlier: just audit the panics and make sure Kannel panics in only *REALLY* hopeless situations. This would IMHO be the Right Thing (TM) to do. I fully agree here. It is so bad that Kannel PANICs when it is not really a PANIC situation, but we should not make things worse by allowing it to continue when it really panics because of some unrecoverable problems (I recall rising this issue of 'too easily used panics' many months ago..) -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
RE: immediate-sendsms-reply
On Thu, 2005-03-17 at 09:49, [EMAIL PROTECTED] wrote: i loop test_http (forever) then after x number of loops it receive the message below. maybe its not really a bug but rather a misconfiguration, below is my config for your perusal No, it is a bug. This bug appears when bearerbox answers to smsbox faster than smsbox writes the uuid into its store. Your fix works but might cause delays on other situations, I will take a look that how the entire situation can be avoided... (interesting here is that the log file does not show the out-of-sequence problem) 2005-03-17 15:40:55 [24266] [3] DEBUG: message length 8, sending 1 messages 2005-03-17 15:40:55 [24266] [3] DEBUG: Stored UUID 4ab36a75-c469-4b11-aee8-6c58109a0e97 2005-03-17 15:40:55 [24266] [3] DEBUG: Status: 202 Answer: Sent. 2005-03-17 15:40:55 [24266] [3] DEBUG: Delayed reply - wait for bearerbox 2005-03-17 15:40:55 [24260] [0] DEBUG: Got ACK (0) of 4ab36a75-c469-4b11-aee8-6c58109a0e97 2005-03-17 15:40:55 [24260] [0] DEBUG: No client - multi-send or ACK to pull-reply -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [PATCH] curl
right. That was the main intention of the clause. I don't see an active reason to remove it. Seeing the clause in such a context in legitim and holds still with current policy on how to add optional features, IMO. Maybe Kalle could shed some light on the matter. yep, Kalle may know it best. ;) I could say that Lasu knows best :] By digging deep into my memories and doing some deductive thinking, I'd say this is because if there is optional modules, automatic checking and keeping it all working is a nightmare. Even one optional module means that all tests should be done 2 times (once without module, once with the module). With 3 optional modules, tests should be run 2^3 (8) times whenever core is changed, and 4 times if certain module is changed. However, on this entire subject, Kannel has always had this problem of being tied to certain decisions and having problems adopting to new needs.. Full ahead with core changes which are needed for better dlr/sending support I say - even if this would require us to have like 2 different supported 'stable' releases (like 1.4 and 1.6) (but also full -600 to any new high-level feature adds (ringtones, wallpapers, whatever), as they should be outside Kannel) -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
[Fwd: Kannel]
-Forwarded Message- From: Fernando Montenegro [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Kannel Date: Tue, 01 Feb 2005 09:24:53 -0500 Hello, I have been cruising the Kannel source for the SMS Gategay. I am looking for the module that contains the source to send SMPP WAP Push. I was told such a thing was available in Kennel. Do you know where in the source this is? Best regards, Fernando Montenegro -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [PATCH] preliminary confirmed sendsms
To allow old behavior, add to the smsbox group: immediate-sendsms-reply = true I think this is a bit confusing and we should look for a better name and explanation. Also we need proper changes in user guide I think. There is changes in user guide (second commit), but if you come up with better name, surely it can be changed.. But hopefully no one really needs that variable anyway =] -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [PATCH] preliminary confirmed sendsms
On Fri, 2005-01-28 at 09:29, Kalle Marjola wrote: AFAIK, this has yet not been commited to cvs, right? Nope, I just digged it out.. I can commit it to CVS (change things commented when I last time sent it out) right now.. This is now committed to CVS. Please all note that this is COMPATIBILITY breaker to those sendsms HTTP clients who are actively investigating the content of the reply sent by Kannel. To allow old behavior, add to the smsbox group: immediate-sendsms-reply = true -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [PATCH] preliminary confirmed sendsms
I'm +1 for a)! without reviewing the code, but from the semantical perspective. AFAIK, this has yet not been commited to cvs, right? Nope, I just digged it out.. I can commit it to CVS (change things commented when I last time sent it out) right now.. Kalle, what is the consensus about it in the group?` As normally, consensus is based on 2-3 voices =] So I implemented new configuration variable for this, 'immediate-sendsms-reply' which must be set to 'true' to make it behave like it did earlier; as a default, new system is going to be used. (it is a compatibility breaker then as it changes the HTTP reply text content/code) -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [RFC] how to rename gw_list_XXX or gwlist_XXX ?
On Mon, 2005-01-24 at 17:49, Alexander Malysh wrote: P.S. I'm +1 for gwlist_XXX notation and +0 for gw_list_XXX. Btw. patch for gwlist_XXX notation is already available as well. Same from me. -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [PATCH] http server fixes
Looks great, and this is a _must_ for 1.4.1 I think. 1.4.1 and 1.5.0 would be nice to get out at some point.. we did not get it out before end of the year but how about now? -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [PATCH] http server fixes
On Thu, 2005-01-20 at 17:26, Alexander Malysh wrote: Hi Kalle, I don't think it's the right time now. see mantis ML (users and devel) for bugs that should be fixed first... As I know it takes some time to get it finally out, my comment meant mainly 'let's try to get it out, with current features but bugfixing them first' :] -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [PATCH] Kannel bug #0000032 otherwise known as kannel's list function naming clashes with latest mysql list function naming
On Fri, 2005-01-21 at 05:58, Davy Chan wrote: I've also got another patch I wish to submit on the Kannel docs. I've updated, unobfuscated, verified, linkified, and expanded the docs. Some things include: snip Well that is something great! This is exactly what Kannel needs :] -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: WTLS?
On Thu, 2005-01-13 at 18:47, Marcus Schmöger wrote: Hi, I would like to know about the current status of WTLS integration into Kannel. The info on the website is somewhate ambiguous about this. Most info there is years old, including WTLS stuff. I will do some update to that page to stop confusing people... -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: WTLS?
On Fri, 2005-01-14 at 11:32, Kalle Marjola wrote: On Thu, 2005-01-13 at 18:47, Marcus Schmöger wrote: Hi, I would like to know about the current status of WTLS integration into Kannel. The info on the website is somewhate ambiguous about this. Most info there is years old, including WTLS stuff. I will do some update to that page to stop confusing people... I removed the page (or more accurately, commented out links to it) as most data there was deprecated and we have not been very active in updating it.. I think better to have no info there than misleading and very old info.. naturally if someone wants to update it, that would be very nice and the page returned :] -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
[patch] bearerbox acknowledged sendsms (fixed)
Attached is a patch to CVS head which makes smsbox sendsms wait until bearerbox has received the SMS, thus avoiding possibility to lose messages if system goes down between http-request and before bearerbox receives the SMS to store it. The patch also gives better information on what happened to SMS, i.e. accepted for delivery (some smsc driver has accepted it), queued for later delivery (no smsc to take it) and rejected (cannot be handled with current setup) As a side-effect, it makes smsbox just a tiny bit slower. And naturally HTTP sendsms requests 'linger' until bearerbox replies (usually like after 0.1 seconds...) The patch is basically the same I posted some months ago except that I have removed 'the horrible kludge' :] As there was debate on how this system should be used, this patch now introduces 'immediate-sendsms-reply' boolean config value for smsbox. As it is false by default, it means that this new behaviour is _default_ and is a compatibility breaker if sendsms callers check the exact body of the reply. (I made this default as this is how it should be.) A patch to wait ack from smsc is the next step but a bit more complicated... PS: there is no update to userguide in patch; I will do that if this patch is accepted when I commit it.. -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [patch] bearerbox acknowledged sendsms (fixed)
(patch attached)
Why am I using this FC2 when all it causes is problems..
--
Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
? access.log
? check.log.new
? check_bb.log
? check_bb.tmp
? check_fake.log
? check_headers.log
? check_http.log
? check_http_list.log
? check_http_server.log
? check_https_server.log
? check_ppg.tmp
? check_sendsms.log
? check_sendsms_bb.log
? check_sendsms_sms.log
? check_sendsms_smsc.log
? check_smpp_bb.log
? check_smpp_drive.log
? check_wap.log
? check_wap.tmp
? confirmed_sendsms.patch
? kannel.log
? kannel.store
? store-spool
? gwlib/gw_uuid_types.h
? test/test_boxc
? test/test_mime_multipart
? test/test_pcre
? test/test_prioqueue
? test/test_regex
? test/test_uuid
Index: gw/smsbox.c
===
RCS file: /home/cvs/gateway/gw/smsbox.c,v
retrieving revision 1.252
diff -u -r1.252 smsbox.c
--- gw/smsbox.c 3 Sep 2004 12:42:33 - 1.252
+++ gw/smsbox.c 15 Dec 2004 08:52:25 -
@@ -130,6 +130,15 @@
int charset_processing (Octstr *charset, Octstr *text, int coding);
static long get_tag(Octstr *body, Octstr *tag, Octstr **value, long pos, int nostrip);
+/* for delayed HTTP answers.
+ * Dict key is uuid, value is HTTPClient pointer
+ * of open transaction
+ */
+
+static int immediate_sendsms_reply = 0;
+static Dict *client_dict = NULL;
+static List *sendsms_reply_hdrs = NULL;
+
/***
* Communication with the bearerbox.
*/
@@ -150,6 +159,60 @@
write_to_bearerbox(msg);
}
+/*
+ * Handle delayed reply to HTTP sendsms client, if any
+ */
+static void delayed_http_reply(Msg *msg)
+{
+HTTPClient *client;
+Octstr *os, *answer;
+char id[UUID_STR_LEN + 1];
+int status;
+
+uuid_unparse(msg-ack.id, id);
+os = octstr_create(id);
+debug(sms.http, 0, Got ACK (%d) of %s, msg-ack.nack, octstr_get_cstr(os));
+client = dict_remove(client_dict, os);
+if (client == NULL) {
+debug(sms.http, 0, No client - multi-send or ACK to pull-reply);
+octstr_destroy(os);
+return;
+}
+/* XXX this should be fixed so that we really wait for DLR
+ * SMSC accept/deny before doing this - but that is far
+ * more slower, a bit more complex, and is done later on
+ */
+
+switch (msg-ack.nack) {
+ case ack_success:
+status = HTTP_ACCEPTED;
+answer = octstr_create(0: Accepted for delivery);
+break;
+ case ack_buffered:
+status = HTTP_ACCEPTED;
+answer = octstr_create(3: Queued for later delivery);
+break;
+ case ack_failed:
+status = HTTP_FORBIDDEN;
+answer = octstr_create(Not routable. Do not try again.);
+break;
+ case ack_failed_tmp:
+status = HTTP_SERVICE_UNAVAILABLE;
+answer = octstr_create(Temporal failure, try again later.);
+break;
+ default:
+ error(0, Strange reply from bearerbox!);
+status = HTTP_SERVICE_UNAVAILABLE;
+answer = octstr_create(Temporal failure, try again later.);
+break;
+}
+
+http_send_reply(client, status, sendsms_reply_hdrs, answer);
+
+octstr_destroy(answer);
+octstr_destroy(os);
+}
+
/*
* Read an Msg from the bearerbox and send it to the proper receiver
@@ -189,10 +252,9 @@
total++;
list_produce(smsbox_requests, msg);
} else if (msg_type(msg) == ack) {
- /*
- * do nothing for now. Later we will handle this
- * gracefully...
- */
+
+ if (!immediate_sendsms_reply)
+ delayed_http_reply(msg);
msg_destroy(msg);
} else {
warning(0, Received other message than sms/admin, ignoring!);
@@ -1874,9 +1936,27 @@
+static void store_uuid(Msg *msg, Octstr **stored_uuid)
+{
+char id[UUID_STR_LEN + 1];
+
+gw_assert(msg != NULL);
+gw_assert(*stored_uuid == NULL);
+gw_assert(!immediate_sendsms_reply);
+
+uuid_unparse(msg-sms.id, id);
+*stored_uuid = octstr_create(id);
+
+debug(sms.http, 0, Stored UUID %s, octstr_get_cstr(*stored_uuid));
+
+/* this octstr is then used to store the HTTP client into
+ * client_dict, if need to, in sendsms_thread */
+}
+
static Octstr *smsbox_req_handle(URLTranslation *t, Octstr *client_ip,
+ Octstr **stored_uuid,
Octstr *from, Octstr *to, Octstr *text,
Octstr *charset, Octstr *udh, Octstr *smsc,
int mclass, int mwi, int coding, int compress,
@@ -2231,6 +2311,14 @@
udh == NULL ? ( text == NULL ? : octstr_get_cstr(text) ) : UDH );
}
}
+/* Store id if needed for a delayed HTTP reply */
+
+if (!immediate_sendsms_reply) {
+ store_uuid(msg, stored_uuid);
+}
+
+
+
msg_destroy(msg);
list_destroy(receiver, octstr_destroy_item);
list_destroy(allowed, octstr_destroy_item);
@@ -2379,7 +2467,8 @@
* Create and send an SMS message from an HTTP request.
* Args: args contains the CGI parameters
Re: [RFT] new store file/spool approach (fixed)
On Fri, 2004-12-10 at 17:41, Alexander Malysh wrote: hmm, I don't see difference... If user has enabled store-dir then 'static Octstr *spool' is not NULL and we store messages... if while starting spooldir doesn't exists we return -1 to higher layer and this should decide how to process further. (or I'm on the wrong trip?;)) Maybe we have to change behavior of the higher level then yep should work too... would you please patch current/old bb_store and I will create patch against this version? There is is, in CVS I also updated smskannel.conf to have much more text (possibly to reduce [EMAIL PROTECTED] mails a bit =) and fixed fakesmsc to tell that -r is used for port setting, not -p Next, where was that 'answer from bearerbox' patch... -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [RFT] new store file/spool approach (fixed)
Comments/votes please! I did a quick test and seemed to work fine, thanks! Some comments: a) seems like the directory must exist already or bad things happen b) should we rename config value it as 'store-dir' or 'store-spool-dir' or something? otherwise +1 P.S. should we have multiple types of store-file support in kannel? it would be easy to add config option like 'store-type=[file|spool]'. what are you think about? What would be the _real_ benefits of using the old 'file'? If there really are, then yes, but otherwise not - maybe not need backward compatibility? PS. Am I the only one who gets a bit annoyed of all the still reserved memory areas reported when Kannel exits? Back in old times all of those would have been cleansed... :] -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [RFT] new store file/spool approach (fixed)
a) seems like the directory must exist already or bad things happen hmm, store_init returns -1 if directory doesn't exists and it's up to higher layer to check this (bearerbox init code). I don't like the idea to create directory if it doesn't exists and also the idea to panic in this case. IMHO we have to much panics spread across kannel for such low level things and higher layer should check return values and make decisions. However there is one difference: in old store, if the file did not exist that only meant that well there is no old messages; new ones were still stored. In this case nothing will get stored, but unless the user is observant, he won't notice this (or I'm missing something here) (okay, I'm not sure what happens if the store file cannot be later on created.. just errors I guess..) Hence, either panic or create the directory. But I can live with current behaviour, too.. yep, good point... 'store-dir' is a good one? Yes, see below. real benefit is that store spool dir is slower as e.g. store file + your patch (dict approach) (if your gateway has enough RAM to store messages twice). so user will make decision which type to use (but default: store-dir :)). Well in that case I would suggest that we have both :] Which one is used depends on config setting: store-file : the old (and I will patch it with that previous patch) store-dir: the new one ..and yell if both set... -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
[Fwd: Patch to Kannel 1.4.0]
Forwarded to correct address. -Forwarded Message- From: Lubor Kolar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Patch to Kannel 1.4.0 Date: Fri, 03 Dec 2004 18:01:47 +0200 Hello Kalle! I am sending you a patch I made for Kannel. In our country, all mobile operators are blocking UDP ports 9200-3 when connecting using GPRS APN internet. These ports are allowed only when connecting using GPRS APN wap (which has of course much higher price per one kilobyte). Some phones (like Siemenses) allow to use custom defined WAP-gateway port. But Kannel had UDP ports hardcoded. I made the changes so now it is possible in the configuration file under core group define your own ports like this: wsp-port = 81 wtp-port = 82 wsps-port = 83 wtps-port = 84 If any of these lines are ommited, the defaults are used. You will find my patch attached. I didn't made any changes in documentation because up to now I used it just for my own purposes, but I think someone else could find this feature usefull. Sincerely, Lubor -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket custom_ports.patch.bz2 Description: BZip2 compressed data
Re: ... Kannel 1.4.0 stable release available
Thanks Stipe! Now I propose that we add to CVS head: * new smsstore (that directory thing I guess, unfortunately I have had no time to test it... is there limit to how many files can be in a directory?) * reply-to-sendsms (this patch I did, I can fig that horrible kludge first) * other pending new features...? ..and then get 1.5.0 out quite soon (this year?) -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [PATCH] daemonize change user fixes
On Thu, 2004-11-04 at 00:25, Alexander Malysh wrote: Hi, Kalle, do you still have objections for this patch or is it ok to commit as is? Feel free; just comment it to docs that directory is changes and it should be noted as 'compatibility breaker' ... :] -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [PATCH] daemonize change user fixes
On Tue, 2004-11-02 at 02:48, Alexander Malysh wrote: Hi, attached patch fixes daemonize mode (make sure stdin/stdout/sdterr are opened and do chdir(/)) and change user code (set supplementary group id's and don't destroy passwd struct). +1 for all except that '/' -thing: - /* XXX chdir breaks restart of boxes when started w/o a full path to binary */ -/* chdir(/); */ +chdir(/); - Seems like there was reason not to do it. I do not say that this isn't right thing to do, but then if parachute is used, then Kannel should make sure that the path is full, not relative - can it like test, in daemon mode, that it can find itself before starting up? This patch should go into 1.4.0 stable. Yes except notes above. -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [PATCH] improved store-file
On Fri, 2004-10-29 at 12:57, Alexander Malysh wrote: Hi Kalle, some comments to your patch... 1) don't use dict if you don't know how many items will be stored (dict filled to more as 80% works very slow). Here we should use something like red-black-tree. Hm.. then this is a bit problematic. I really do not have time right now to create new systems, so I have to think about this a bit more.. 2) don't call any functions in signal handler that are not signal safe (you call gwthread_wakeup_all()) 3) check for 'file != NULL' in 'int store_save(Msg *msg)'. Because file != NULL is our marker for enabled store-file support (store-file support is optional). Thanks, fixed. I should have guessed that I have good reasons for doing that 2) some years ago ;] -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [PATCH] X-Wap-Initiator-URI to test_ppg
I believe, that web pages update is a simple cvs commit to www.kannel.org module?! Are you volunteering for web pages updates ;)? I did some updates as can be seen when surfing to www.kannel.org But I did not double check all pages nor is completely aware of status of various parts, especially WAP. So I ask all you to either fix 'Status' page directly or point out any inaccuracies so they can be fixed now. (other pages, too, but especially that :) -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [PATCH] improved store-file
On Fri, 2004-10-29 at 12:57, Alexander Malysh wrote: Hi Kalle, some comments to your patch... 1) don't use dict if you don't know how many items will be stored (dict filled to more as 80% works very slow). Here we should use something like red-black-tree. Hm, I took a look at dict.c and while yes, it could slow down considerably after getting filled, in any case this new system is like 10 times as fast as the old one - as the old one used single list, now at least it has 200 Lists =] Yes, there is room for improvement, but this is far better this way than it was earlier. I'd use it this way and just put into projects 'make it even more efficient' ... =] -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
release 1.4.0
I have a release proposition, to be done ASAP: * release current CVS as 1.4.0 (ChangeLog seems to be mainly fixes) * then (after one week or so) release CVS as 1.5.0, I will add my bearerbox-ack -patch to CVS before this release, possible add other patches lying around to it, too I can also do some update to Kannel web page. Not much but at least remove lots of old data or mark it as such, at least :] -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: Kannel tested on Red Hat Linux 9 ?
On Fri, 2004-10-22 at 06:25, Alejandro Guerrieri wrote: I'd suggest you to use 1.3.2. It is as stable as 1.2.1 but it's a lot more functional. This reminds: could we get new stable release at some point? (new devel release wouldn't hurt that much either ... no matter if there has not been many updates, we could simply say like '1.3.3 is almost like 1.3.2, no need to upgrade unless...) Maybe just release 1.3.2 as 1.4.0, perhaps with some little patches.. (is there?) This way more probably we would get rid of 1.2.x based problems on lists. New releases would also be a good sign to show that the project is alive and kicking. -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: Reliable message queue?
On Tue, 2004-10-19 at 12:41, Enver ALTIN wrote: Hi, As far as I can understand, Kannel's current implementation of outgoing and incoming SMS queue is internal and implemented using the List structure of gwlib. This is not good, we can't safely restart processes this way because it would lose any data in the queue. Try enabling store-file (yes, the current implementation has problems under heavy load. Maybe I could salvage the better one from NMGW some day. And in any case, push message can be lost if it is 'in air' between smsbox and bearerbox unless my patch is applied) -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [PATCH] preliminary confirmed sendsms
On Thu, 2004-10-14 at 04:17, Alejandro Guerrieri wrote: Well, I've just patched my 1.3.2 with this and so far it seems to work ok. I've checked trying to send messages without defining an smsc and I've got: Not routable. Do not try again. What I'm missing is the capability to detect wrong numbers, ie. if I try to send a message to 12345678 or 000 I've got an 0: Accepted for delivery, but I think I need DLR's for that isn't it? Isn't there any way to detect that kind of errors without DLR's? Yes and no. What I understood from previous posts, these can be detected with these 'accepted/rejected by SMSC' DLRs (not real DLRs, i.e. work even when operator does not allow DLRs) However, this patch does not wait for that data as it can be delayed lots more (queue inside SMSC driver etc.) - this will be the next patch and even then that would be optional as it could easily result in HTTP timeouts etc. (moreover, that patch is far more complicated because of split messages etc.) -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [PATCH] X-Wap-Initiator-URI to test_ppg
On Tue, 2004-10-05 at 12:20, Alexander Malysh wrote: Hi, if this patch doesn't break other handsets then +1 from me... As no one else said anything I applied it to CVS as this patch does absolutely nothing unless explicitly used.. (I also fixed 'if' clause in utils/run-checks as 'make check' wrongly seemed to fail with most checks. Also seems that 'checks/check_smpp.sh' is stuck...) PS: how is Kannel web pages updated? There seems to be list of old data still lying around there (for example, projects) and Yesterday again I heard about this that Kannel project seems to be dead, according to its web page which is so frozen -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [PATCH] preliminary confirmed sendsms
On Thu, 2004-10-07 at 23:36, Alan McNatty wrote: Hi Kalle, It would be good to understand more the impact on doing this (as you note). Please consider the following scenario ... Often connections to SMSC are bandwidth limited (we have some SMPP links over limited FR for example). What this can mean is (under load) that there is not as much traffic inbound as out. Please note that this patch does NOT wait that message is handled by SMSC driver (which would take time if there are queues), but instead gets an immediate response as soon as bearerbox replies. Thus the delay is milliseconds when compared to old one. The idea of waiting for SMSC ack/nack is in my plan. However, as this could be delayed even seconds, THAT feature would only be used if so configured/requested as it cannot be used with heavy traffic. (that feature would be based on current DLR implementation and there would be a list of possible problematic scenarios) Also if load balancing with internal queues - in the event one SMSC link is dropped the message queues are effectively shuffled. What would happen if we're waiting to hear back from SMSC about message and the link is dropped, etc? We would need to cope with these scenarios. See above. This current reply is based on what bearerbox _immediately_ replies when it receives SMS from smsbox (and which was previously just discarded by smsbox). So, in exchange for some milliseconds, the caller gets information if there is some basic problems.. (no SMSCes connected, bad configuration,...) If you check out the original code (bb_boxc.c, line 253 and smsbox.c, line 191-196) these messages are already flying around (in fact, have been there for over 4 years...). They were just not used... (blame me =) -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [PATCH] preliminary confirmed sendsms
And here is the patch itself =]
--
Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
? gwlib/gw_uuid_types.h
? test/test_boxc
? test/test_mime_multipart
? test/test_pcre
? test/test_prioqueue
? test/test_regex
? test/test_uuid
Index: gw/smsbox.c
===
RCS file: /home/cvs/gateway/gw/smsbox.c,v
retrieving revision 1.252
diff -u -r1.252 smsbox.c
--- gw/smsbox.c 3 Sep 2004 12:42:33 - 1.252
+++ gw/smsbox.c 6 Oct 2004 12:34:55 -
@@ -130,6 +130,15 @@
int charset_processing (Octstr *charset, Octstr *text, int coding);
static long get_tag(Octstr *body, Octstr *tag, Octstr **value, long pos, int nostrip);
+/* for delayed HTTP answers.
+ * Dict key is uuid, value is HTTPClient pointer
+ * of open transaction
+ */
+
+static Dict *client_dict = NULL;
+static Octstr *stored_uuid_os = NULL; // horrible kludge!
+static List *sendsms_reply_hdrs = NULL;
+
/***
* Communication with the bearerbox.
*/
@@ -150,6 +159,60 @@
write_to_bearerbox(msg);
}
+/*
+ * Handle delayed reply to HTTP sendsms client, if any
+ */
+static void delayed_http_reply(Msg *msg)
+{
+HTTPClient *client;
+Octstr *os, *answer;
+char id[UUID_STR_LEN + 1];
+int status;
+
+uuid_unparse(msg-ack.id, id);
+os = octstr_create(id);
+debug(sms.http, 0, Got ACK (%d) of %s, msg-ack.nack, octstr_get_cstr(os));
+client = dict_remove(client_dict, os);
+if (client == NULL) {
+warning(0, No client? (multi-send?));
+octstr_destroy(os);
+return;
+}
+/* XXX this should be fixed so that we really wait for DLR
+ * SMSC accept/deny before doing this - but that is far
+ * more slower, a bit more complex, and is done later on
+ */
+
+switch (msg-ack.nack) {
+ case ack_success:
+status = HTTP_ACCEPTED;
+answer = octstr_create(0: Accepted for delivery);
+break;
+ case ack_buffered:
+status = HTTP_ACCEPTED;
+answer = octstr_create(3: Queued for later delivery);
+break;
+ case ack_failed:
+status = HTTP_FORBIDDEN;
+answer = octstr_create(Not routable. Do not try again.);
+break;
+ case ack_failed_tmp:
+status = HTTP_SERVICE_UNAVAILABLE;
+answer = octstr_create(Temporal failure, try again later.);
+break;
+ default:
+ error(0, Strange reply from bearerbox!);
+status = HTTP_SERVICE_UNAVAILABLE;
+answer = octstr_create(Temporal failure, try again later.);
+break;
+}
+
+http_send_reply(client, status, sendsms_reply_hdrs, answer);
+
+octstr_destroy(answer);
+octstr_destroy(os);
+}
+
/*
* Read an Msg from the bearerbox and send it to the proper receiver
@@ -189,11 +252,9 @@
total++;
list_produce(smsbox_requests, msg);
} else if (msg_type(msg) == ack) {
- /*
-* do nothing for now. Later we will handle this
-* gracefully...
-*/
- msg_destroy(msg);
+
+ delayed_http_reply(msg);
+ msg_destroy(msg);
} else {
warning(0, Received other message than sms/admin, ignoring!);
msg_destroy(msg);
@@ -2231,6 +2292,19 @@
udh == NULL ? ( text == NULL ? : octstr_get_cstr(text) ) :
UDH );
}
}
+/* XXX UGLY kludge, to be used in sendsms_thread */
+if (stored_uuid_os == NULL) {
+char id[UUID_STR_LEN + 1];
+
+uuid_unparse(msg-sms.id, id);
+stored_uuid_os = octstr_create(id);
+
+debug(sms.http, 0, Stored UUID %s, octstr_get_cstr(stored_uuid_os));
+
+/* this octstr is then used to store the HTTP client into
+* client_dict, if need to, in sendsms_thread */
+}
+
msg_destroy(msg);
list_destroy(receiver, octstr_destroy_item);
list_destroy(allowed, octstr_destroy_item);
@@ -3018,17 +3092,12 @@
static void sendsms_thread(void *arg)
-{
+ {
HTTPClient *client;
Octstr *ip, *url, *body, *answer;
-List *hdrs, *args, *reply_hdrs;
+List *hdrs, *args;
int status;
-reply_hdrs = http_create_empty_headers();
-http_header_add(reply_hdrs, Content-type, text/html);
-http_header_add(reply_hdrs, Pragma, no-cache);
-http_header_add(reply_hdrs, Cache-Control, no-cache);
-
for (;;) {
client = http_accept_request(sendsms_port, ip, url, hdrs, body,
args);
@@ -3084,18 +3153,23 @@
debug(sms.http, 0, Status: %d Answer: %s, status,
octstr_get_cstr(answer));
-octstr_destroy(ip);
-octstr_destroy(url);
-http_destroy_headers(hdrs);
-octstr_destroy(body);
-http_destroy_cgiargs(args);
-
-http_send_reply(client, status, reply_hdrs, answer);
+ octstr_destroy(ip);
+ octstr_destroy(url
Re: [PATCH] preliminary confirmed sendsms
On Thu, 2004-10-07 at 12:52, Alexander Malysh wrote: Hi Kalle, patch looks good except this really horrible kludge... Well I thought that first check it out and if people like it and we decide what to do about it (see choices a, b and c) then I bother fixing that horrible kludge :] -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: sendsms and wait-for-reply
On Mon, 2004-10-04 at 15:46, Alexander Malysh wrote: Hi Kalle, why not just use dlr's with mask SMSC_[SUCCESS|FAILED] and handle these in smsbox? Ah, very true. I do not know what I was thinking, maybe this idea that 'some operators do not support DLRs' made me think that these messages will not be gained either.. but I check of code confirmed that they are not linked, so the procedure you described sounds good. (hm, I wonder if this store-file is still the old problematic one; I could take a look of that improved one in NMGW if I have time at some point and then provide a patch) with following procedure: 1) sendsms request forward to bearerbox with no reply and dlr mask SMSC_[SUCCESS|FAILED] set (store e.g. in dict: uuid + http client) 2) handle msg in bearerbox w/o any changes 3) if msg sent/failed you will get dlr for this and can forward status to HTTP client (get http-client from dict for dlr uuid) -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
[PATCH] X-Wap-Initiator-URI to test_ppg
Attached (small) patch adds possibility to define X-Wap-Initiator-URI
when running test_ppg (use -I command line option). This initiator is
shown in limited handsets as sender 'From', either in message details or
in message list (instead of *unknown*)
--
Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
? confdefs.h
? initiator_patch.txt
Index: doc/userguide/userguide.xml
===
RCS file: /home/cvs/gateway/doc/userguide/userguide.xml,v
retrieving revision 1.286
diff -u -r1.286 userguide.xml
--- doc/userguide/userguide.xml 28 Sep 2004 15:01:33 - 1.286
+++ doc/userguide/userguide.xml 5 Oct 2004 09:04:59 -
@@ -8299,6 +8299,14 @@
Use literalstring/literal as a X-WAP-Application-Id
header (You must supply whole header).
/entry/row
+
+ rowentryliteral-I/literal/entry
+ entryemphasisstring/emphasis/entry
+ entry valign=bottom
+ Use literalstring/literal as a X-WAP-Initiator-URI
+ header (You must supply whole header).
+ /entry/row
+
rowentryliteral-B/literal/entry
entryemphasisboolean/emphasis/entry
entry valign=bottom
Index: test/test_ppg.c
===
RCS file: /home/cvs/gateway/test/test_ppg.c,v
retrieving revision 1.28
diff -u -r1.28 test_ppg.c
--- test/test_ppg.c 20 Jun 2004 18:11:57 - 1.28
+++ test/test_ppg.c 5 Oct 2004 09:04:59 -
@@ -101,6 +101,7 @@
static Octstr *content_transfer_encoding = NULL;
static Octstr *connection = NULL;
static Octstr *delimiter = NULL;
+static Octstr *initiator_uri = NULL;
enum { SSL_CONNECTION_OFF = 0,
DEFAULT_NUMBER_OF_RELOGS = 2};
@@ -329,6 +330,11 @@
octstr_destroy(mos);
+/* add initiator... */
+if (initiator_uri)
+ http_header_add(push_headers, X-Wap-Initiator-URI,
+ octstr_get_cstr(initiator_uri));
+
return push_headers;
}
@@ -705,6 +711,9 @@
info(0, supply a message header as a plain string. For instance);
info(0, -s x-wap-application-id:mms.ua equals -a ua. Default is);
info(0, x-wap-application-id:mms.ua.);
+info(0, -I string);
+info(0, supply an initiator header as a plain string. For instance);
+info(0, -I x-wap-application-id:http://foo.bar equals -I http://foo.bar;);
info(0, -S string);
info(0, supply an additional part header (for push content) as a string.);
info(0, For instance, -S Content-Language: en. Default no additional part);
@@ -760,7 +769,7 @@
gwlib_init();
num_threads = 1;
-while ((opt = getopt(argc, argv, HhBbnEpv:qr:t:c:a:i:e:k:d:s:S:)) != EOF) {
+while ((opt = getopt(argc, argv, HhBbnEpv:qr:t:c:a:i:e:k:d:s:S:I:)) != EOF) {
switch(opt) {
case 'v':
log_set_output_level(atoi(optarg));
@@ -886,7 +895,11 @@
add_preamble = 1;
break;
- case '?':
+case 'I':
+initiator_uri = octstr_create(optarg);
+ break;
+
+ case '?':
default:
error(0, TEST_PPG: Invalid option %c, opt);
help();
Re: [PATCH] X-Wap-Initiator-URI to test_ppg
On Tue, 2004-10-05 at 12:20, Alexander Malysh wrote: Hi, if this patch doesn't break other handsets then +1 from me... Well, if this header does break, then simply do not use it :] (it is not set if no command line option used). So far this header is tested in some phones which do not show it (S30), some which show it in details (S60 v1.x) and one which shows it in message list (S60 v2) As a sidenote, in (at least some version) of Nokia 6600 the sender is broken in message details, i.e. http://foo.bar/ becomes ttp://foo.bar/[[vgdsds[[[gsssgs. However, in the message list it is shown correctly - I guess it is bug in 6600. (and there must be trailing '/' in some handsets) -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
sendsms and wait-for-reply
When using Kannel, one very common problem people have is that sendsms interface replies 'sent' even if it really does not mean anything else than 'your request seems to be correct, we will try to send it'. The optimal situation would be that if Kannel replies 'sent' it really means that, but as we all know, because of queues and multiple processes, that is far from trivial and in most cases, practical. Yes, I know there is DLRs, but they are a) sometimes not supported, and b) much more complex in a way that Kannel does HTTP later on back to originator So, back in NMGW I made it that way that as a reply to sendsms request, the user received either 'accepted for delivery' or 'queued', but it was easier to do it as it used merged bearerbox and smsbox (same process) and thus sendsms interface directly called smsc2_rout(..). Moreover, still if the message was queued inside a SMSC driver that would be classified as 'acceped for delivery' - not a perfect, then, as what users want is a guarantee that the SMSC has accepted the message.. So, I was thinking how to implement this feature. I came up with following procedure: 1) get sendsms request, send it onward to bearerbox, but do not reply to HTTP client but instead go to sleep 2) in bearerbox, message is handled almost normally. When smsc driver returns a reply (the moment when the message would be removed from store-file), a message of operation status would be sent to smsbox.. 3) and when this reply arrives, original thread is awaken and the client gets its response So, this would mean that such a sendsms request would hang for a while (depending on SMSC speed, more if the system is slowed down or have problems). Thus this feature would be inpractical for mass sendings, as it would result in a) more traffic (reply messages to smsbox) and b) lots of open connections (resource usage), and so it should only be used if so desired, like sendsms? wait-for-reply=1 (or as sendsms user, wait-for-reply = true). But it would be very useful for low-rate services. Any comments before I might start implementing this..? :] -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
kannel sms-features: limited smsc links, aggregator use
Hi, I'm back and a bit out-of-touch of the current situation of my lovely child ;] Anyway, I was wondering how to do following operations with current Kannel, and came up with bad solutions and possible new features.. So, things needed: 1) SMSC (SMPP) connection that needs to be broken after one sent message, i.e. non-persistent operation. Maybe this one (1) could be something else, I was thinking about general 'max-sends-before-reconnect' generic SMSC variable but before doing any hacking, have to check out if there is already some ways to do it.. 2) Aggregator use, i.e. message from one SMSC to another (with sender kept as original) If I'm right, this could only be done with http/send-sms trick (to keep the sender). Some better ways: a) keep-numbers (or maybe use-original-numbers), as a sms-service directive (this would still require that messages are routed to smsbox, and then bearerbox routing to replies) b) some aggregation support directly in bearerbox (e.g. smsc-aggregate-to directive to smsc?) Any comments? -- Kalle Marjola Development Helsinki
Re: [RFC] switching the licensing text
On Thu, 13 Nov 2003, Stipe Tolj wrote: Developers, CVS commiters, I'd like to go ahead and change the copyright owner from WapIT Ltd to Kannel Group, as I mentioned this in a previous announcement. Please complain *NOW* if you have cerious concerns. Okay, nitpicking again these 2 things I stated earlier... :] /* * The Kannel Software License, Version 1.0 * * Copyright (c) 2001-2003 Kannel Group * Copyright (c) 2000-2001 WapIT OY Ltd. * All rights reserved. * From original Kannel COPYING: -snip Kannel license: Copyright (c) 1998 WAPIT OY LTD. All rights reserved. snip Thus, I would change it to 1998-2001... * * Portions of this software are based upon software originally written at * WapIT OY Ltd., Helsinki, Finnland for the Kannel project. */ Finland is still with 2 'n's, not three :] (not interesting nitpickdetail: 'OY' = osakeyhtiö =~ share company, i.e. ~equal to 'ltd.' so simply 'WapIT Ltd.' should be sufficient) -- kalle marjola
Re: binary sms
On Thu, 7 Aug 2003, Benjamin Lee wrote: In both cases, it looks as if you have not URL encoded your 'text' values. As Shridhar Raju wrote recently, you need something like: (Ringtone) http://198.198.1.150:13013/cgi-bin/sendsms?username=testerpassword=foobart o=91234567udh=%06%05%04%15%81%15%81text=%02%4A%3A%51%D1%95%CD%D0%04%00%1B% 20%55%05%90%61%05%60%55%85%50%54%85%40%82%08%49%90%00%00 And yes, you need the UDH. You might want to import from nmgw two 'new' sendsms interface variables: 'hexudh' and 'hexdata' For these, you simply give the data as 'hexcoded', ie. ..sendsms?user=foopass=barto=040500hexudh=06050415821582hexdata=42F41900480E010020CF... makes much more prettier urls ;] (and easier to edit) Ok, no need t oimport anything, they are quite easily re-coded, too. (and no, sorry, I do not have time to do that) -- kalle marjola
