Re: Logging based on date
[EMAIL PROTECTED] schrieb:
Hi,
I would like to ask was it possible for kannel to write the log file
based on date? Which mean every day/week a new log file is created for the
purpose of logging. The current logging will only log on the same log
file. Ie. Current log file name : smsbox.log --> become
2008-01-01-smsbox.log, 2008-01-02-smsbox.log.
now, a lot of users use logrotate for this, my suggestion:
$ man logrotate
;)
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
---
Re: Segfault in Kannel meta-data (TLV) branch with certain DLR
Kyriacos Sakkas schrieb:
I am currently running my full live load via GET request on the version
before the patch fixing the POST method. The wait is until me (or
someone else that can put some stress on it) confirms operation of the
current meta-data cvs under some sort of heavy load via POST as well as
GET, to confirm resilience. On my side that will happen sometime after
the first week of February.
ok, perfect... please keep us updated on the results, so we can consider merging
the meta-data CVS branch to the main tree after we have a confirmed stress test.
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
---
Re: [PATCH] empty msg->sms.sender support
Vincent CHAVANIS schrieb:
Specs 4.6 says that these fileds (oadc, adc) are only mendatory.
IMO, NULL or empty will result in writing the same way the request.
what does that mean "...writing the same way the request..."?
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
---
Re: [PATCH] empty msg->sms.sender support
Andreas Fink schrieb:
I think the EMI/UCP SMSC's reject it.
so if we don't have a clear statement in the spec, we're banned to "trial and
error" on the various EMI/UCP vendors? :(
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
---
[PATCH] empty msg->sms.sender support
Hi all,
attached is a patch (work in progress) which allows us to support MT messages
that have no sender address set. Meaning we change the current behavior of
smsbox, and remove the error condition if no 'to' URI is passed.
The main reason for this is the fact that SMPP v3.4 allows
submit_sm.source_address = NULL to be passed. But technically we can't do it,
since smsbox will already claim for the missing piece.
Constraints/TODOs:
- smsbox changes are for the GET variant only, I haven't touched the POST things
yet.
- SMPP client module has been addopted to work for the condition.
- Other SMSC client modules need to be adopted too?
BTW, introduces some macros in smsbox that make the conditional checks a bit
more easier to read.
Before committing the TODOs need to get touched of course.
Comments?
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
---
### Eclipse Workspace Patch 1.0
#P gateway-cvs-head
Index: gw/smsc/smsc_smpp.c
===
RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v
retrieving revision 1.102
diff -u -r1.102 smsc_smpp.c
--- gw/smsc/smsc_smpp.c 9 Jan 2008 20:06:52 - 1.102
+++ gw/smsc/smsc_smpp.c 1 Feb 2008 12:19:38 -
@@ -760,8 +760,13 @@
}
if (smpp->autodetect_addr) {
+ /* check if we have an empty source address */
+if (octstr_len(pdu->u.submit_sm.source_addr) == 0) {
+pdu->u.submit_sm.source_addr_ton = GSM_ADDR_TON_UNKNOWN;
+pdu->u.submit_sm.source_addr_npi = GSM_ADDR_NPI_UNKNOWN;
+}
/* lets see if its international or alphanumeric sender */
-if (octstr_get_char(pdu->u.submit_sm.source_addr, 0) == '+') {
+else if (octstr_get_char(pdu->u.submit_sm.source_addr, 0) == '+') {
if (!octstr_check_range(pdu->u.submit_sm.source_addr, 1, 256,
gw_isdigit)) {
pdu->u.submit_sm.source_addr_ton = GSM_ADDR_TON_ALPHANUMERIC;
/* alphanum */
pdu->u.submit_sm.source_addr_npi = GSM_ADDR_NPI_UNKNOWN;/*
short code */
Index: gw/smsbox.c
===
RCS file: /home/cvs/gateway/gw/smsbox.c,v
retrieving revision 1.277
diff -u -r1.277 smsbox.c
--- gw/smsbox.c 9 Jan 2008 20:06:58 - 1.277
+++ gw/smsbox.c 1 Feb 2008 12:19:34 -
@@ -1968,6 +1968,7 @@
List *denied = NULL;
int no_recv, ret = 0, i;
long del;
+struct sms *p;
/*
* Multi-cast messages with several receivers in 'to' are handled
@@ -1975,7 +1976,7 @@
* loop below, because everything else is identical for all receivers.
* If receiver is not null, to list is already present on it
*/
-if(receiver == NULL) {
+if (receiver == NULL) {
receiver = octstr_split_words(to);
}
no_recv = gwlist_len(receiver);
@@ -2007,14 +2008,14 @@
for (i = 0; i < no_recv; i++) {
receiv = gwlist_get(receiver, i);
- /*
-* Check if there are any illegal characters in the 'to' scheme
-*/
- if (strspn(octstr_get_cstr(receiv), sendsms_number_chars) <
octstr_len(receiv)) {
- info(0,"Illegal characters in 'to' string ('%s') vs '%s'",
- octstr_get_cstr(receiv), sendsms_number_chars);
+/*
+ * Check if there are any illegal characters in the 'to' scheme
+ */
+if (strspn(octstr_get_cstr(receiv), sendsms_number_chars) <
octstr_len(receiv)) {
+info(0,"Illegal characters in 'to' string ('%s') vs '%s'",
+ octstr_get_cstr(receiv), sendsms_number_chars);
gwlist_append_unique(denied, receiv, octstr_item_match);
- }
+}
/*
* First of all fill the two lists systematicaly by the rules,
@@ -2111,17 +2112,14 @@
}
if (urltrans_faked_sender(t) != NULL) {
- /* discard previous from */
- newfrom = octstr_duplicate(urltrans_faked_sender(t));
+/* discard previous from */
+newfrom = octstr_duplicate(urltrans_faked_sender(t));
} else if (octstr_len(from) > 0) {
- newfrom = octstr_duplicate(from);
+newfrom = octstr_duplicate(from);
} else if (urltrans_default_sender(t) != NULL) {
- newfrom = octstr_duplicate(urltrans_default_sender(t));
+newfrom = octstr_duplicate(urltrans_default_sender(t));
} else if (global_sender != NULL) {
- newfrom = octstr_duplicate(global_sender);
-} else {
- returnerror = octstr_create("Sender missing and no global set,
rejected");
- goto field_error;
+newfrom = octstr_duplicate(global_sender);
Re: [PATCH] empty msg->sms.sender support
Andreas Fink schrieb:
EMI/UCP supports missing sender address in operation 01 but I dont think
it does it in operation 51
yep, the specs are a bit unclear for EMI/UCP. How about converting the
msg->sms.sender = NULL in this case into an "" (emptry string) and pass it as
"empty alphanumeric OAdC?
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
---
Re: [PATCH] empty msg->sms.sender support
Vincent CHAVANIS schrieb:
this means we will get the same UCP 51 request
18/00113/O/51/012345/09876//1/1920870340125000/4/0539//3012961212//3//4D657373616765203531/CD
so if it's null or empty we will get
18/00113/O/511/1920870340125000/4/0539//3012961212//3//4D657373616765203531/CD
And will probably result as an SMSC error as Andreas said as OADC and
ADC is mandatory.
yep, checked the specs again. Section 5.3, page 51, shows those two as mandatory
fields.
Hmm, that's a problem here. This results in:
EMI/UCP does NOT allow "empty" source addr.
SMPP does allow "empty" source addr.
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
---
Re: [PATCH] empty msg->sms.sender support
Andreas Fink schrieb:
the only way to have it empty is to use an operation 01 instead of 51...
is that transparently?
Which means we check within gw/smsc/smsc_emi.c if we have source addr, if we
have use UCP 51, if not (hence empty) use UCP 01. With the same "rest" of the data?
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
---
Re: Serious bug in the WBXML compiler
Maxim Sobolev schrieb:
Hi,
I reported reported to Mantis about 6 months ago
(http://bugs.kannel.org/view.php?id=405), but since there were no answer
I am copying it here. This issue prevents correct OTA provisioning of
Nokia phones, so that it's quite important.
Please see the description below and patch attached.
-Maxim
When processing INLINE value WBXML compiler "forgets" to emit
instruction to switch codepage to 0 if necessary. This may result in
unparseable WBXML if the current codepage differs from 0. It has been
verified that both wbxml2 package and Now SMS gateway software do emit
this instruction in the same condition.
For example:
http://www.wapforum.org/DTD/prov.dtd";> [^]
Correct byte sequence (generated by wbxml2 for example) would be:
03 0b 6a 00 c5 45 03 31 2e 31 00 01 c6 00 01 55
0010 01 87 36 00 00 06 03 32 35 00 01 87 05 03 46 52
^ missed codepage switch 0
While Kannel generates:
03 0b 6a 00 c5 45 03 31 2e 31 00 01 c6 00 01 55
0010 01 87 36 06 03 32 35 00 01 87 05 03 46 52 4f 4d
^ INLINE token
Thanks again for being pedantic on getting the issues resolved.
You're absolutely right, +1 for the patch, committed to CVS HEAD:
2008-02-02 Stipe Tolj
* gw/ota_compiler.c: fix bug #405, where we forget to switch codepage
when no inline value is processed for WBXML compilation. Thanks go to
Maxim Sobolev for reporting and proving patch.
[Msg-Id: <[EMAIL PROTECTED]>]
Thanks a lot! Appropriate your contribution.
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
---
Re: Fwd: sendota with kannel 1.4.1
Vitaliyi schrieb:
Phones says "message format not supported".
Tried phones: nokia E51, Asus p535
at least the Nokia E51 should be supporting OMA OTA configs. Can you please use
the CVS HEAD version of Kannel, since we had an update in the OTA compiler 2
days ago.
Please checkout the CVS HEAD version and try it again for the Nokia device.
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
---
Re: System error 24: Too many open files
Illimar Reinbusch - Telejazz.com schrieb:
Hi
Im running Kannel 1.2 and i get the following error on my Linux RH8 box
with high SMS traffic.
1.2 ??
Obviously you're triggering some kind of old bug we already fixed long time ago.
Please use latest stable 1.4.1, or even better CVS HEAD which is a release
candidate for 1.4.2.
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
---
Re: [PATCH] empty msg->sms.sender support
Alexander Malysh schrieb:
Hi,
I don't think it's worth the effort to implement NULL source address because
most protocols just don't allow empty source address and many places in
kannel expect source addr not NULL.
yep, I admit it would touch a lot of places in the code.
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
---
Re: [PATCH] empty msg->sms.sender support
Vincent CHAVANIS schrieb:
Yep,
But UCP 01 is stated as legacy operation.
And should be remove in the future version of the UCP protocol.
This has been keeped for backward compatibility.
hmmm... so we don't have a chance to map the "empty source addr" issue to some
valid UCP 51 operation?
We could do some "all nasty all we should not do it" approach and simply send
"0" as numeric source addr? ;)
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
---
Re: [PATCH] empty msg->sms.sender support
Andreas Fink schrieb:
how about using empty string instead of NULL?
octstr_create("") I mean...
yep, that's ok with me... this would result in a "failure" on the smsc_emi.c
level. But that's ok, since user has requested this "empty source", so if we get
a SMSC specific failure, this reflects the SMSCs compatibility.
I agree here.
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
---
Re: added OMA-EMN support to Kannel PPG
Paul Flanagan schrieb:
Hi there
I needed a way to test a PAP interface I wrote to send OMA Email
Notifications as defined in
http://www.openmobilealliance.org/release_program/emn_v10.html
so I added OMA-EMN support to kannel.
OMA Email Notification (EMN) enables the mobile e-mail client to be notified
of a new e-mail via wappush.
Attached is diff of gateway/gw/wap_push_ppg.c and 2 new files. Code is
closely based on wap_push_sl_compiler.c
actually I have been looking in certain WAP PPG issues here, and I missed the
diff that you wanted to attach?
Can you please re-post your patch in 'diff -u' format, so we can work on this.
Some of the PPG app-id things seem to be very requesting.
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
---
Re: 100% cpu usage fix
Ernestas Vaiciukevičius schrieb:
Hi,
I was using debian version of kannel (1.4.1-2) and noticed that if
initialization of GSM modem fail (for example, USB cable is not connected and
modem device doesn't exist), bearerbox uses 100% CPU.
I've modified smsc_at.c so that it sleeps for reconnect-delay seconds between
retries even when failures occur early in initialization process.
Also now it should exit the retry loop if privdata->shutdown is set.
If someone is interested - my changes are attached to this message. Of course
if it isn't already fixed in the CVS :)
thanks Ernestas for reporting and providing patch immediately.
Can anyone else confirm this with current CVS HEAD?
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
---
Re: 100% cpu usage fix
Alexander Malysh schrieb:
Hi,
if I remember correctly, it's already fixed in CVS.
user claims:
If someone is interested - my changes are attached to this message. Of
course if it isn't already fixed in the CVS :)
can you confirm Alex?
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
---
Re: 100% cpu usage fix
Alexander Malysh schrieb:
Hi,
if I remember correctly, it's already fixed in CVS.
grr, we need to enage to 1.4.2 to have all that fixed post-1.4.1 not referenced
a thousand times in the lists.
Let me prepare this weekend for 1.4.2 stable. The OMA OTA bug that is claimed is
an issue I need to get my hands on and confirm. Any other "major showstoppers" ?
I have another serious SMPP client side issue that I haven't reported to mantis yet.
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
---
Re: 100% cpu usage fix
Alexander Malysh schrieb:
Hi,
I believe this commit fixed it in CVS:
2007-10-05 Alexander Malysh
* gw/smsc/smsc_at.c: reset reconnecting.
Ernestas, can you confirm that you CAN reproduce the bug with CVS HEAD?
Alex claims it has been fixed, see above.
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
---
Re: [RFC] variable sms_split() length per SMSCConn
Alexander Malysh schrieb:
Hi,
I believe we should get user possibility to send longer messages if he
wants. Attached simple patch allows it.
yep, thanks for the agreeing Alex :)
Anybody write userguide for it?
isn't this supposed to be the job of the one who sends in the patch itself? ;)
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
---
[RFC] variable sms_split() length per SMSCConn
Hi list,
a user has pushed me to the fact that we do sms_split() on all MTs we pass along
bearerbox's abstraction layer to the smsc module specific send callback.
The call stack is (generally):
gw/bb_boxc.c:deliver_sms_to_queue()
gw/bb_smscconn.c:smsc2_rout()
gw/smsconn.c:smscconn_send()
gw/smsconn.c:sms_split() < here the splitting happens.
then conn->send_msg() is called which passes to gw/smsc/smsc_foobar.c layer
I'm not sure if we could handle a "generally do no split for 140 octets (160
septets)" logic inside here, as the sms_split() is called with MAX_SMS_OCTETS
(140 octets) for all types of smsc modules.
Think of a smsc_http.c type implementation that will require a binary SMS (ie.
WAP push or whatever) to be passed in 1 HTTP call. I guess we wouldn't support
this, since sms_split() would split the MT already in the abstraction layer.
Idea:
Add a generic config directive to 'smsc' group that defines the max. allowed
octets per smsc type.
Side effect:
In SMPP the submit_sm.short_message is allowed to be 255 octets, and even the
TLV submit_sm.message_payload is much higher. We currently "cut" all MTs to SMPP
SMSC. Some SMSC may support that "long" processing in one PDU call. So we could
allow the user here to use it with the same mechanism.
Comments? Volunteers for implementation?
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
---
Re: Change Max Chars/SMS using HTTP SMSC With Kannel 1.4.1
Guillaume Cottenceau schrieb:
"[EMAIL PROTECTED]" writes:
Hi List,
Which file should be patched to be able to handle MT with more than 160
chars without concatenate it? In the other word I want to do a MT in 1
You can't, the limit is not set by Kannel, it's defined by the SMS
protocol (GSM). You simply cannot carry larger messages over the
operator's line.
Hi Guillaume,
yep, GSM is the limiting factor. But NOT for a protocol we use to get to the
final SMSC.
Keep in mind that we're still ABOVE the signaling (SS7) layer. Ie. SMPP allows
submit_sm PDUs with a payload more then the 140 octets.
From an architectural point of view, we "could" pass a long message in whole to
the SMSC, as it would be in charge to segment while switching from IP layer to
signaling layer and hence hitting the "physical boundary".
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
---
Re: [RFC] variable sms_split() length per SMSCConn
Andreas Fink schrieb:
The known GSM SMSC's dont accept longer SMS because the GSM
infrastructure does not allow longer SMS than the 140 octets.
some CDMA SMSC's might accept longer SMS and some GSM SMSc's might split
it on their side but so far I have not seen any really supporting it or
at least not with asking a fortune to the operator for a useless feature.
I don't see a real need for this.
I do. From an achitecure point of view we (kannel) is beyond the signaling
layer. So taking it strictly, we COULD use protocols towards SMSC that allow
long messages to be passed in one PDU, as SMPP per spec does. Or consider HTTP
as a simple example.
I understand that most vendors leaverage the underlying signaling limits (140
octets per GSM SMS message) to the SMSC clients, but this is actually not
conceptualls correct.
What I want is to give the user an "option" to define the max octets we are
allowed to pass to the SMSC. Which SHOULD BE allowed, hence we're still above
the signaling layer.
Think of Kannel instance concatenation as another example:
client <-> smsbox(2) <-> bearerbox(2)[smsc_http] <-> smsbox(1) <->
bearerbox(1)[smsc_smpp] <-> SMSC
so if a client injects a large msg at the left hand side, this would result in a
sms_split() segmentation within bearerbox(2), even while we know that smsbox(1)
could handle the "whole message".
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
---
Re: Anyone in GSMA MWC?
Enver ALTIN schrieb:
Hi all,
I'm at Barcelona for GSMA Mobile World Congress; my company (Telenity) is
exhibiting at Hall 1 and I'm usually around. If there's someone in the area,
I'd be more than happy to meet for a drink.
I'm at the show. I'll give you a handshake during the morning hours tomorrow
(Wed), when I will be examining the booths ;)
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
---
Re: added OMA-EMN support to Kannel PPG
Paul Flanagan schrieb:
Hi Stipe
Attached are 2 new OMA-EMN files plus a diff and full listing of
wap_push_ppg.c
As mentioned in original email, in addtion to the complier I have
hardcoded wap_push_ppg.c
to remove some non-essential headers that prevented the SE K800i from
reacting to the OMA-EMN
It was my intention to add a config setting to allow this behaviour (header
removal) to be configurable but I have changed role at work and have not
been able to get back to it.
Btw a few people have contacted me directly looking for this code. I have
provided it and have got reports that it worked fine.
Hi Paul,
thanks a lot for providing us the patches and the code. I'm currently in
Barcelona on the show and will get to it as soon as I get back to the main office.
This needs to get incorporated to CVS HEAD before we're pushing the 1.4.2 stable
release button.
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
---
Re: Bug on kannel
Djiby SY schrieb:
When updating de mysql DB, the pointer msg->sms.msgdata was passed as
parametter of function and modified inside the function.
This is why the MT message has "\'" in the phone instead of "'".
I have modified the function static Octstr
*get_string_value_or_return_null(Octstr *) in sqlbox_mysql.c
now, this is all about mysql client library code "securing" the input data
against messing to inject a remote SQL attack.
We should mention that using sqlbox is NOT secure for various conditions,
because character encoding can mess up, due to the fact that sqlbox seems to use
a specific "encoding" for it's payload data. Which means it's not a pure BLOB
type, hence transcoding of the character set is happening.
@Rene: are you still actively maintaining the sqlbox module within
cvs.kannel.org?
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
---
[PATCH] [Fwd: Re: Kannel AT smsc CNMA-OK patch]
Hi list,
forwarding this patch from Marius Huysamen... even thou I have instructed him to
subscribe to the devel list and re-submit.
Can you guys that use our AT modem module a lot have a look on it. Thanks.
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
---
--- Begin Message ---
Hi
I've been trying to submit this patch as described in the FAQ, but
neither [EMAIL PROTECTED] nor [EMAIL PROTECTED] work. The messages
bounce with "unknown username". I've thus tried to send it to
[EMAIL PROTECTED]
If I am following the incorrect procedure for submitting this patch,
please update your website with the relevant information.
Regards
Marius Huysamen
[EMAIL PROTECTED] wrote:
You are not allowed to post to this mailing list, and your message has
been automatically rejected. If you think that your messages are
being rejected in error, contact the mailing list owner at
[EMAIL PROTECTED]
Subject:
Kannel AT smsc CNMA-OK patch
From:
Marius Huysamen <[EMAIL PROTECTED]>
Date:
Fri, 29 Feb 2008 09:22:32 +0200
To:
devel@kannel.org
To:
devel@kannel.org
Hello
The following patch is against the stable version of Kannel 1.4.1, but
I've made these changes against 1.4.0 as well.
The at2_wait_modem_command function would prematurely return when
receiving an OK, which is actually the modems response to that functions
own CNMA acknowledgment. at2_send_one_message would then go through its
retry cycle, since it is looking for '>' but receiving 'OK's. After all
the retries have been exhausted, smsc_at would inform the bearerbox that
messages are failing, at which time the bearerbox then instructs sms_at
to reset itself.
This patch consumes an OK for every CNMA that gets sent.
diff -ru gateway-1.4.1-orig/gw/smsc/smsc_at.c
gateway-1.4.1-mhg/gw/smsc/smsc_at.c
--- gateway-1.4.1-orig/gw/smsc/smsc_at.c2006-05-23
15:27:31.0 +0200
+++ gateway-1.4.1-mhg/gw/smsc/smsc_at.c 2008-01-29 14:38:24.0
+0200
@@ -622,6 +622,7 @@
Msg*msg;
int len;
int cmgr_flag = 0;
+int cnma_ok = 0;
time(&end_time);
if (timeout == 0)
@@ -644,8 +645,12 @@
goto end;
}
if (octstr_search(line, octstr_imm("OK"), 0) != -1) {
-ret = 0;
-goto end;
+if(!cnma_ok) {
+ret = 0;
+goto end;
+}
+else
+--cnma_ok;
}
if ((gt_flag ) && (octstr_search(line, octstr_imm(">"), 0)
!= -1)) {
ret = 1;
@@ -712,8 +717,10 @@
}
if (!cmgr_flag) {
-if (privdata->phase2plus)
+if (privdata->phase2plus) {
at2_write_line(privdata, "AT+CNMA");
+++cnma_ok;
+}
}
O_DESTROY(pdu);
Regards
Marius Huysamen
Linux Administrator
Metropolitan Health Group
P.S: I've tried sending this to [EMAIL PROTECTED] but it bounced
with username doesn't exist.
--- End Message ---
Re: An Invitation from Hammad Aslam Khan
Hammad Aslam Khan schrieb:
Dear ,
I want to introduce you to an interesting company that I just registered with -
Blue Chip Expert. It's a job site for high-end professionals and consultants.
The basic idea is that social networking can do a better job than traditional
recruiting methods if the right platform and financial incentives are in place.
The referral fees they offer can really add up, and definitely make it worth a
look. If you are interested, click on the link below to register:
Hammad,
this list is not for "selling purposes", please use our dedicated
'[EMAIL PROTECTED]' list for this.
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
---
[FYI] eComm 2008 - Emerging Communications Conference
Hi lists,
I am encouraging anyone who is available at place and has time to attend to
eComm 2008 which is taking place in some days:
eComm 2008 - Emerging Communications Conference
Mar 12-14, 2008
Computer History Museum, 1401 N. Shoreline Blvd.,
Mountain View, CA 94043
phone (650) 810-1010
It will be a great telecom event for those interested in radical innovation and
seizing the next opportunity wave. Keynotes include Google, Skype and Ribbit.
I will be speaking on Mar 12, 4:30pm about "Integration Aspects of Mobile
Internet Strategies". Feel free to drop me a note if you are present at the venue.
For more information on the event, please visit http://ecommmedia.com/.
Regards,
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
---
Re: Shared Memory, semaphores and a new "box"
Alejandro,
great progress here! We apritiate it!
I'd be pleased if we can move the development effort code into CVS and
hence incubate the code, so others can join the development efforts.
Is this ok for you? I'd like to promote CVS access for you and let you
develop on within a seperate CVS module 'membox'.
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
---
Re: Shared Memory, semaphores and a new "box"
Andreas Fink schrieb:
How many 10'000 messages per second do you need to transport that you
have bottlenecks like that?
consider using this "box" for inter-exchnage at operator level. Which
means bottlenecks on the signaling layer disappear and we have a fast
way to inject message where the pipe at the outbound side is much higher
then for normal SMSC accounts.
Well thats why there is locking...
yep, you can't operate on the same variables (shared memory) via 2
interdependently scheduled logic.
Semaphores are to sync inside a process in multiple threads. They dont
work between multiple processes. You would need a file locking mechanism
or the like.
@Alejandro: please have a view here:
http://www.ossp.org/pkg/lib/mm/
this is obviously you're locking for ;)
I would say the whole design is wrong. Shared memory is different in
most operating systems and frankly I don't think your real problem is
there. Maybe you share the real issue you are facing?
Ralf's MM lib layer may be an acceptable approach to have an OS
abstractive approach.
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
---
Re: Shared Memory, semaphores and a new "box"
Alejandro Guerrieri schrieb:
Stipe,
Of course it's ok, I'll be honored to contribute my code to the project.
perfect. I'm pleased to get you closer to the project by incubating as
CVS writer permission user.
I'll have to go our standard voting procedure, advocating to have you
boarded.
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
---
[REQ] CVS write permission for Alejandro (for his 'membox' project)
Hi core group,
I'd like to advocate for CVS permission for Alejandro Guerrieri
<[EMAIL PROTECTED]> to let him incubate his multi-language
'membox' as seperate CVS module.
If you're a CVS commiter, your supposed to vote, please!
We need at least 2x +1 votes and no vetos to give Alejandro access. At
first instance we will require him to do commits on his own CVS module.
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
---
Re: [REQ] CVS write permission for Alejandro (for his 'membox' project)
Great. Thanks to all core developer's voting! Apritiate it.
@Alejandro: I will create the required CVS repository module for you and ask
your for initial credentials on a private mail basis.
Thanks,
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
---
Re: smsc_at and CNMA+OK
Marius Huysamen schrieb:
Function at2_wait_modem_command in smsc_at.c exits prematurely if
messages were received, and acknowledged with AT+CNMA, since the modem
will respond to the CNMA with an OK.
This patch keeps a counter for every OK that should be ignored within
the function's main loop.
I have been running Kannel versions 1.4.0 and 1.4.1 for more than a year
with this change in place, and I haven't experienced a "random" modem
reset since.
Thanks a lot Marius for your patch. As per Hillel (+1) vote commited to cvs:
2008-03-23 Stipe Tolj
* gw/smsc/smsc_at.c: fix at2_wait_modem_command() to ignore specific OK
responses for AT+CNMA acknowledges.
Thanks to Marius Huysamen for providing patch.
[Msg-Id: <[EMAIL PROTECTED]>]
Great work! Keep on going.
Please can you and Hillel check if we have any open bug reports concerning this
AT+CNMA issue which can be resolved then in the bug tracking database?
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
---
Re: Submitting patch from Marius Huysamen
Hillel schrieb:
We gave this patch a +1 after your email request below as we use the
SMPP module and the AT module for clients that can’t use the SMPP module.
Any idea why it’s not yet submitted to CSV, or is there something Marius
can do to fix it?
commited to CVS.
Thanks for reviewing and voting.
Can you please check the bug tracking database if we have any open issues
regarding this? If yes, please let me know, I'd love to provide you "moderator"
rights for the bug tracking database, so you can resolve open issues on your own.
Thanks.
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
---
[FYI] Kannel foobox module stub
Hi list,
I have committed an initial version of 'membox' to the CVS repository, which
will act as generic foobox template stub, in order to ease Alejandros start in
developing his membox module.
Please consider this module, and specifically the CVS tag 'foobox_template_stub'
of the 'membox' module as a core template in developing own smsbox connection
modules.
To create the stub, you can do this:
$ cd ~/src
$ cvs checkout gateway
$ cd gateway
$ ./configure --prefix=/opt/kannel
$ make
$ sudo make install
which creates core Kannel gateway package and installs it to the defined
location. Then we pick our foobox package and build it too via:
$ cd ~/src
$ cvs checkout membox
$ cd membox
$ ./configure --with-kannel=/opt/kannel
$ make
$ sudo make install
Anyone willing to morph the current 'sqlbox' CVS module to this approach and use
the stub to do it? So we have a "unified way" to allow users
configure/build/install additional foobox modules that dock to Kannel's bearerbox.
Comments and ideas welcome ;)
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
---
Re: msg-id-type
Hillel schrieb:
We have been testing with cvs-20080323 and for some reason one of our
binds that was getting DLRs is now not getting them back. That bind is
using msg-id-type 0x03 and Kannel is not finding the DLR.
As anyone else had a problem using cvs-20080323 or later with DLRs?
The Mobile Operator says nothing has changed on their side.
nothing changed on our side regarding DLR handling AFAIR. Please provide debug
level log parts to review what happens exactly.
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
---
[REQ] morping 'sqlbox' to "mainline" CVS module approach
Hi list,
I'm looking for a volunteer, in case Rene (our original contributor and
developer) is too busy to morph the existing sqlbox CVS parts into the next
"sub-module" CVS approach I committed to CVS ('membox').
Main goals should be:
- Morph the source tree to use the configure/make construct available, so we
eliminate the patch dependency. We want all other (forein) sub-module to see
'gateway' as a "core installation" and use it's gw-config script as
configuration awareness discovery point.
- Incubate Rene's MS SQL server support for our abstractive DBPool layer
structure to the 'gateway' module. So others can benefit from the code that use
the gw and gwlib libraries.
As always, ideas etc. welcome...
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
---
Re: msg-id-type
Hillel schrieb:
Thanks for coming back to me.
It appears the mobile operator made changes and initially denied it.
The latest Kannel CVS is now working well with the operator.
yeah, it's always the "little customer" that is failing to do ;) (let me be a
bit ironic on such a rainy sunday ;)
Thanks to all for the wonderful product.
you're welcome ;)
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
---
Re: membox progress
Alejandro Guerrieri schrieb:
I'm fixing some stuff on my local version, will update it probably on
the weekend.
Hi Alejandro,
it would be great if you use the CVS module really actively. I just want to
avoid you run into the same "caveats" we (the other Kannel developers) do for
the 'gateway' module, where we develop in local working copies and commit after
we "stabilize" code.
The membox module should run a faster commit/review cycle in the CVS repository,
to allow OTHERS to participate actively. Otherwise all others have to "wait"
until you commit your "milestone points" to the CVS, which makes cycles again
too long.
It's ok if when you commit code to the CVS module, even if it's not "finished"
and considered unstable. That's why we have the TAG and BRANCH constructs in CVS.
I simply want others to "join you", since the interest will be present a lot.
I'm also encouraging anyone interested to create a multi-language bridge for
Kannel to look at SWIG (http://www.swig.org). Emagining a lot of application
people out there would love to see a native Kannel bearerbox <-> Java bridge.
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
---
Re: [PATCH] wapbox SSL config loads
Vincent CHAVANIS schrieb:
Hi all,
Is there any reasons why we load ssl config
into wapbox without checking if we HAVE_LIBSSL ?
We do not want to load unused variables.
here is a patch that fix this.
any comments ?
Vincent.
diff -rauw /gateway-cvs/gw/wapbox.c /gateway/gw/wapbox.c
--- /gateway-cvs/gw/wapbox.c2008-01-09 21:06:57.0 +0100
+++ /gateway/gw/wapbox.c2008-03-20 18:45:34.0 +0100
@@ -147,7 +147,9 @@
/* load parameters that could be later reloaded */
config_reload(0);
+#ifdef HAVE_LIBSSL
conn_config_ssl(grp);
+#endif /* HAVE_LIBSSL */
/*
* And the rest of the pull info comes from the wapbox group.
-1, the patch is not required. Why? Follow the 'conn_config_ssl()' call, and you
see:
...
void conn_config_ssl (CfgGroup *grp)
{
info(0, "SSL not supported, no SSL initialization done.");
}
#endif /* HAVE_LIBSSL */
which means we have this already covered in the #else branch to inform the user
we didn't do any SSL init, since no support is compiled in.
;)
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
---
Re: membox progress
Alejandro Guerrieri schrieb:
Stipe,
Ok, acknowledged. Makes a lot of sense, in fact.
I'll commit what I've done so far (even unstable) during the weekend, so
others can join the effort.
perfect, thanks a lot :)
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
---
Re: MEMBOX - First deployment
Alejandro Guerrieri schrieb:
Dear Devs,
I've commited the first deployment of membox to CVS.
The goal for this box is to provide a simple yet fast method for MT
injection, and also to provide a bridge to kannel from other languages.
The box waits on a shared memory queue for messages to come in. When
received, it sends the messages to bearerbox. Since messages are being
passed using shared memory, it's _very_ fast.
A model client application is on the "test/" folder. It enqueues 10.000
messages in just a couple of seconds (to smsc "test"). I'm planning to
add some more control to this (control the smsc, from, to and message
fields). At the end, it would be very similar to fakesmsc, but on the
client side.
From a single client test, sometimes the queue get stuck on message
#43, and the only fix is to stop the box, remove the ipc queue (ipcrm -q
#id) and start again. I'm still clueless about what could be causing
this, maybe someone with more IPC experience than me could see where the
problem is.
I'm still have to do some concurrency tests (I mean, run two or more
test_send instances at the same time and see if messages are lost/mixed)
but I want first to solve the "message #43 bug".
Anyway, please feel free to jump into the project, make changes and
suggestions.
great news Alejandro. A cheering applause please for Alejandro!
Let's get kicking. Anyone interested, please checkout CVS module 'membox' or
review via our ViewCVS interface at http://cvs.kannel.org/.
In additional I will add a corresponding 'membox' module to Mantis (our bug
tracking system) at http://bugs.kannel.org/.
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
---
Re: Optional TLVs/SMPP parameters
Alexander Malysh schrieb:
Hi,
cvsview bug? just try checkout meta-data branch...
was a permission issue in the /home/cvs/gateway CVS repository file
system. viewvc needs a 444 mask, fixed.
Can be accessed via viewvc now.
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
---
Re: [PATCH] Minor Issue when alt-host is set on EMI/UCP
Alexander Malysh schrieb:
hi,
++1, sorry unable to commit now...
I'm willing to commit.
Vincent, can you resend the patch as attachment, so I can apply it directly to
CVS HEAD and commit?!
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
---
Re: [PATCH] WSP Content-ID header encoding fix
P. A. Bagyenda schrieb:
Attached is a small patch to wsp_headers.[ch] to fix the encoding of the
Content-ID header. According to WAP-203-WSP (Sec. 8.4.2.67) the
content-id value should be encoded as a quoted string. I've come across
one or two devices that insist on this -- as they should. This kills MMS
parsing for the devices.
Votes please.
+1, committed to CVS.
Thanks a lot Paul.
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
---
Re: ussd protocol stack in kannel
Bambang Sadikin schrieb:
dear All :
has anyone put or starting to put ussd protocol stack in kannel software
systems ?
the USSD subystem as defined by GSM 03.90 spec is "beyond" the IP layer on which
Kannel interacts with the SMSCs of a network. In fact USSD is more related to
the MAP/TCAP signaling layer (ss7), then on the pure SMSC inter-connection.
Some protocols, i.e. SMPP v3.4 allow connecting to USSD gateways (or other
network elements) that provide a SMPP interface to the USSD string exchange. But
this depends on the capabilities of the SMPP server.
There is no standardized IP based protocol to use for USSD gateway connectivity.
So most USSD gateway vendors use their own protocol, or try to use a well-known,
like XML over HTTP (SOAP) or SMPP.
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
---
Re: [PATCH] Minor Issue when alt-host is set on EMI/UCP
Alexander Malysh schrieb:
Hi,
this patch has had memory leak, conn->name was never freed.
I commited my version ;)
thanks Alex for reviewing and committing.
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
---
Re: Bug in Postgresql implementation
P. A. Bagyenda schrieb:
Automatic OIDs on each table row were removed from PostgreSQL a while
back (v7.3?), so it is time they got removed from Kannel's code. You can
still of course use OIDs if you create your tables with a syntax
something like:
CREATE TABLE (
) WITH OIDS;
I agree with Hillel's argumentation.
patches are welcome :)
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
---
Re: SIGTERM Error
Carlos G. Pachas Boza schrieb:
Hi, I'm implementing the 1,4,1 version and I got this error.
It works ok for a while but suddenly it shutdown.
Wapbox:
2008-06-14 18:50:51 [13855] [6] DEBUG: WTP: resp_machine 17897, state
RESULT_WAIT, event RcvAbort.
2008-06-14 18:50:51 [13855] [6] DEBUG: WTP 17897: New state LISTEN
2008-06-14 18:50:51 [13855] [6] DEBUG: WTP: Destroying WTPRespMachine
0x8724c88 (17897)
2008-06-14 18:50:51 [13850] [1] DEBUG: WSP: machine 0x445efbb0, state
CONNECTED, event TR-Abort.ind
2008-06-14 18:50:51 [13850] [1] DEBUG: WSP: method 17897, state
PROCESSING, event TR-Abort.ind
2008-06-14 18:50:51 [13850] [1] DEBUG: WSP 597/17897: New method state
NULL_METHOD
2008-06-14 18:50:51 [13850] [1] DEBUG: Destroying WSPMethodMachine 17897
2008-06-14 18:50:51 [13850] [1] DEBUG: WSP 597: New state CONNECTED
2008-06-14 18:50:51 [13843] [0] ERROR: SIGINT or SIGTERM received, let's
die.
2008-06-14 18:50:51 [13843] [0] INFO: Kannel wapbox terminating.
2008-06-14 18:50:51 [13865] [15] DEBUG: Thread 15
(gw/heartbeat.c:heartbeat_thread) terminates.
2008-06-14 18:50:51 [13843] [0] DEBUG: Waiting for 5
(wap/wtp_init.c:main_thread) to terminate
2008-06-14 18:50:51 [13854] [5] DEBUG: Thread 5
(wap/wtp_init.c:main_thread) terminates.
2008-06-14 18:50:51 [13843] [0] DEBUG: wtp_initiator_shutdown: 0
init_machines left
2008-06-14 18:50:51 [13843] [0] DEBUG: Waiting for 6
(wap/wtp_resp.c:main_thread) to terminate
Bearerbox:
008-06-14 18:51:00 [13866] [12] DEBUG: send_msg: sending msg to box:
<127.0.0.1>
2008-06-14 18:51:00 [13866] [12] DEBUG: boxc_sender: sent message to
<127.0.0.1>
2008-06-14 18:51:00 [13866] [12] DEBUG: send_msg: sending msg to box:
<127.0.0.1>
2008-06-14 18:51:00 [13866] [12] DEBUG: boxc_sender: sent message to
<127.0.0.1>
2008-06-14 18:51:01 [13816] [0] WARNING: Killing signal or HTTP admin
command received, shutting down...
2008-06-14 18:51:01 [13816] [0] DEBUG: Shutting down Kannel...
2008-06-14 18:51:01 [13816] [0] DEBUG: shutting down smsc
2008-06-14 18:51:01 [13816] [0] DEBUG: shutting down udp
2008-06-14 18:51:01 [13816] [0] DEBUG: udp_shutdown: Starting avalanche
2008-06-14 18:51:01 [13821] [4] DEBUG: Thread 4
(gw/bb_udp.c:udp_receiver) terminates.
2008-06-14 18:51:01 [13823] [6] DEBUG: Thread 6
(gw/bb_udp.c:udp_receiver) terminates.
Somebody help me, please!
now, it's obvious what happens here: both processes get a SIGTERM signal and go
into shutdown phase.
So someone did INTEND to stop the processes by signaling them. This is no
"sudden dead" ;)
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
---
Re: Bug in Postgresql implementation
Enver ALTIN schrieb:
Hey Stipe,
It's been a while since I last read any message on this list but
PostgreSQL on the subject line caught my attention immediately. I think
I can fix this sometime this weekend if nobody else wants to work it out.
Hi Enver,
great to hear from you... it's some time ago we meat in Barcelona ;)
Please, if you don't mind, go ahead and post a patch that we can apply.
I and most others would appreciate it obviously.
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
---
Re: Moving to git? [was: Re: [RFC] variable sms_split() length per SMSCConn]
Guillaume Cottenceau schrieb:
Alexander Malysh writes:
diff --git a/gw/smscconn.c b/gw/smscconn.c
index 21e824d..6654665 100644
Does that mean Alex has some git experience and could positively
examine a request to migrating to git? Kannel still uses CVS, and
it would probably make developers and contributors life easier to
use a more powerful VCS.
Hosting the git repo on the fedora box behind kannel.org should
be pretty easy; there is a lot of documentation out there,
including that one from me if needed (though it's normally aimed
at "shared servers").
yep, Alex uses git for his own repository management. We should switch
to svn (subversion) instead for the first instance, in order to let
others follow the contribution commits more easily. Subversion is still
more "convenient" then git from old cvs users.
Alex, is there an easy way to have a local git reposiroty that is
"exported" to a centralized svn repo?
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
---
Re: Moving to git? [was: Re: [RFC] variable sms_split() length per SMSCConn]
Guillaume Cottenceau schrieb:
http://zarb.org/~gc/html/git-on-a-shared-server.html
Hi Guillaume,
didn't realize this was your own HOWTO explaining the basic steps. So I
could ask you too :)
First of all: is git available on the most Linux flavor distros; the
major ones mainly, so Debian, Fedora, SuSE, Ubuntu et al?
Users tend to be lazy. svn is available at all flavors. I'm not sure how
compatible the tagging and branching system of git is with svn. If it
is, I'd prefer a centalized svn repos, with a de-centralized git
infrastructure on the developers end. How about that?
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
---
Re: Moving to git?
Guillaume Cottenceau schrieb: Don't overestimate the complexity of git; AFAIK, it was really complicated when Linus wrote it, but it was 3 years ago. Since then, a lot of auxiliary utilities making git usable for mortals were integrated into main git; and then, a lot of free software projects have moved from cvs, svn or even mercurial to git (the kernel, e2fs, alsa and probably a lot of kernel-related projects, yet also xorg, wine, cairo, ruby on rails..) which is quite meaningful to me. now, I know... but these are for "hack-alike" people more. Our user base isn't usually that C-affine and tend to come from the Java corner mainly, so svn is a term for them more then git. That's my major concern: making the handling for the user side easy. As for the complexity, the easiest way of posting patches is really as simple as: # git clone # ... hack, hack, hack ... # git diff > /tmp/foo.patch Alex, is there an easy way to have a local git reposiroty that is "exported" to a centralized svn repo? AFAIK, if you decide for svn - boo! don't! :) - there are svn-git tools which allow to use a local git repo, commit in it, and then "export" the commit to the master svn repo. ok, that was a solution I would go for. Having git local repos and export (remote commit) to a svn master. Eh, I'm really not an expert in git :) I'm rather a beginner to intermediate user, who has been quite convinced by it. ;) Yes, of course - don't forget that the kernel and many other projects use git now. Either by the package name "git", or "git-core", it's available everywhere. http://packages.debian.org/search?keywords=git-core https://admin.fedoraproject.org/pkgdb/packages/name/git http://www.gentoo-portage.com/dev-util/git http://download.opensuse.org/distribution/10.3/repo/oss/suse/i586/git-1.5.2.4-23.i586.rpm - sorry didn't find better for suse, is there? - http://en.opensuse.org/Package_List is a joke :) The Fedora project even hosts quite some git repos, showing off what their views on git are: http://git.fedoraproject.org/git/ ok, great. Thanks for the research here. That makes a major step towards it. We could postulate a master svn and a shared git repo on kannel.org I guess simultaneously, right? Not quite sure if it would be intelligent to let the user "decide" which VC to use. But contributors also tend to be lazy, and being able to contribute more effectively is a big plus :) A single example is that browsing a git repo on the web is much more powerful than using cvsweb or equivalents, because it shows commits globally and time-ordered rather than by file, which is more meaningful. yep, agree. While using svn via Eclipse IDE would have also a powerfull source/revision tracing functionality. That's what I do ;) Also, branching is powerful with git; it would help branch desires of contributors becoming reality more easily. Lastly, if you want to cherry pick some bugfixes and include them into stable kannel releases, you will also benefit from branches (I do use branches in CVS, I know it's possible, but it's painful). yep, that's right. While branching/merging in svn is way more easier then cvs. Still, svn is a re-architectured VC and has more advanced concepts then CVS. (mainly each commit results in a whole revision tag, rather then revisioning single files like CVS does). Depends on what you mean by "compatible". Git can import cvs and svn repositories including tags and branches, AFAIK. now, not looking for pure import compatibility, more into branching and merge applying compatibility. Which means, can we develop within git locally for the developers, and "clone" each operation within the central svn master? A lot of people do not use git as Linus does - e.g., it is possible to have a centralized git repo where everyone pulls from, and only a selected group of users can write to; that's actually how I use git for my projects (the "everyone will publish their modified repos" is a marketing argument, it's not practical for projects as long as no forking is desired). understand. Then, what git allows for contributors is easily commit on their side, management of their changes, and then a unique patch posting; it makes contributors life easier because they can commit locally (so they can split their work in logical parts easily), even undo or amend commits before sending them; and then, it makes your life easier because they can submit their patches with "git-format-patch" which includes all modifications in a single file, and embeds their name and email, so that when you will commit upstream, the "author" name is kept (the contributor) and the "commiter" name also (you). Here's an example of such a commit on one of my projects: http://frozen-bubble.org/cgi-bin/gitweb.cgi?p=frozen-bubble;a=commit;h=3ca6c2413a62f68c6f48a854b52018fda8c7dd42 There's another nice benefit I already experience with git, even in the "one commiter" or even "one developer" architecture: w
Re: Moving to git? [was: Re: [RFC] variable sms_split() length per SMSCConn]
Andreas Fink schrieb:
On 18.06.2008, at 17:05, Guillaume Cottenceau wrote:
Alexander Malysh writes:
diff --git a/gw/smscconn.c b/gw/smscconn.c
index 21e824d..6654665 100644
Does that mean Alex has some git experience and could positively
examine a request to migrating to git? Kannel still uses CVS, and
it would probably make developers and contributors life easier to
use a more powerful VCS.
Some platforms dont have GIT (like mine).
CVS is old I must admit. My favour would be SVN though.
Things like non deletable directories are really stone age...
Hosting the git repo on the fedora box behind kannel.org should
be pretty easy; there is a lot of documentation out there,
including that one from me if needed (though it's normally aimed
at "shared servers").
The hosting server are not the problem. Users are.
Have you seen GIT for Windows for example? or for Solaris 8 , HP/UX etc?
cvs is there by default often where git is not.
yep, I agree with Andreas here. My major concern is the user side. I
know that git is used for the kernel and kernel-close projects. But
these are all C hard coders, they "know what they do" (now, I guess we
hope so :p), but Kannel users are more the application users.
Question: Is git POSIX.1 compliant? In terms of platform abstraction?
There is no Linux specific requirements I guess? What is the underlying
repo storage type? Berkeley DB?
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
---
Re: Moving to git?
ok, I'll try to sum up the discussion here:
- user side: git is available at most Linux flavors, but not directly to
other Unix/BSD flavors; git is still more developer affine then user
affine (my perspective on it)
- developer side: git makes life easier in terms that we can commit to
local repos and then "commit remotely" to the master (right?); branch
handling seems to be more effective (Guillaume and Alex claimed this).
My suggestion:
We move to svn on kannel.org, and leave the normal (anonymous) checkout
access to the master repository via svn.
Underneath we can switch to git for those developers who want to.
So a hybrid architecture would be possible IMO. Comments please?!
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
---
Re: Moving to git?
Andreas Fink schrieb:
Stipe: how big is our current repository?
134M under cvs.
Machines filesystem usage is 20% only, constantly.
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
---
Re: PATCH: Postgresql Patch
Guillaume Cottenceau schrieb:
"Hillel" writes:
Hi Kannel Devel,
Attached and included in this email, is a postgresql patch that does not use
Automatic OIDs, which has been removed from Postgresql.
You can make smsc,ts the primary key or as suggested by Guillaume Cottenceau
you can set smsc,ts as an index.
diff -u gateway/gw/dlr_pgsql.c gateway/gw/dlr_pgsql.c
--- gateway/gw/dlr_pgsql.c 2008-06-23 08:16:34.0 +0200
+++ gateway/gw/dlr_pgsql.c 2008-06-22 12:27:38.0 +0200
@@ -220,12 +220,11 @@
Octstr *sql;
debug("dlr.pgsql", 0, "removing DLR from database");
-sql = octstr_format("DELETE FROM %s WHERE (%s,%s) IN (SELECT %s,%s
WHERE %s='%s' AND %s='%s' LIMIT 1);",
The general contract of the code at that point is to delete only
one row even if there are multiple smsc,ts rows, which your
change breaks.
dn=# create table foo ( bar int, baz int );
CREATE TABLE
dn=# insert into foo ( bar, baz ) values ( 1, 2 );
INSERT 447809901 1
dn=# insert into foo ( bar, baz ) values ( 1, 2 );
INSERT 447809902 1
dn=# delete from foo where ( bar, baz ) in ( select 1, 2 limit 1 );
DELETE 2
Same for the UPDATE statement, actually.
So this shall be a -1 vote by Guillaume I guess.
Hillel, can you please revise and update the patch?
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
---
Re: Ldap MSISDN provisioning patch for 1.4.1
Artem Pylypchuk schrieb:
Hello users Kannel mailing list!
I would like to inform you, that I've written some code for Kannel that can be
used for MSISDN provisioning over LDAP queries, with a flexible
failover/fallback mechanism (as required by our carrier partner). Please
consider adding it to your addons page.
The page with the addon is http://juice.org.ua (merged with my personal page),
the patch is at http://juice.org.ua/patch
Please note, that it's still just a sketch (i.e. [pre-]alpha), so it's not
integrated into configure script, and also, the question remains what to do
with the existing RADIUS accounting module (disable by config?). Everything
else works just fine (lookups, failover, failover fallback dummy checking &
configuration reading).
Hi Artem,
thanks a lot for sharing your work with us. We appreciate your
contribution highly. And I'd like to advocate and support you in getting
the code into our main CVS HEAD branch so we see it available in
upcoming releases.
First of all, please switch to the 'devel' mailing list instead for
this, since it's more related to development itself then usage
questions. That's why I have cross-posted to devel@ too in this response.
I see 4 points here we need to do to get the code into the mainline CVS
branch:
- apply our doc/CodingStyle guide lines to your source code files. To be
honest, they are way to "sloppy" and don't match our "style" ;)
- apply your changes to CVS HEAD instead of 1.4.1 stable and create a
'diff -u' patch, so we can post a clean patch to the mailing list for
letting other developers review it and vote on it's commitment.
- I guess OpenLDAP is the point of choice for the LDAP directory
backend? I can do the configure[.in] et al preparation for this, so we
have a clean build process w/o LDAP support.
- Concerning RADIUS acct vs. LDAP I would suggest the following way:
make the backend storage type configurable via config directive
'msisdn-storage' in the wapbox group. This config directive will be
interpreted and we simply use a neutral function pointer that is pointed
to the implementation function call name, ergo we don't need runtime
checks, it's just one check while startup and while runtime our module
calls the function it has been configured for. The function calls are
defined as public functions in it's modules, as is.
Looking forward to your updates patch to devel mailing list ;)
Thanks for your attention.
You're welcome. Good work so far. I hope you understand that we need to
fit our guide lines before applying changes to the CVS branch.
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
---
Re: [PATCH] urltrans keyword handling cleanup
Alexander Malysh schrieb:
Hi,
as no objections were here, commited to cvs.
thanks Alex.
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
---
Re: Moving to git?
Andreas Fink schrieb:
Andreas: +1
and Stipe: +1.
---
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
---
Re: PATCH: Postgresql Patch
Alexander Malysh schrieb:
this is not true. UUID is to 99% unique even in a cluster. We have log
tabel in the DB with over 500K inserts per day and UUID will be
generated not only by one instance and I never seen clash since 2years.
agree'ing here to Alex. The UUID heuristic is _very_ safe and can be
used as a key identifier, even in a non-coordinated cluster node
architecture.
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
---
Re: PATCH: Postgresql Patch
Alexander Malysh schrieb:
you didn't get the point. UUID is generated for each msg in kannel and
kannel depends all over the place that this UUID is unique (see: store,
queue ...). UUID is already in place IMHO we don't need yet another
SERIAL for this purpose.
yep, again, Alex is right here. The only thing that would switch my mind
to the db-internal generation of the key is if the UUID would break
version compatibility.
If we can use UUID Kannel generated IDs, that would be feasable IMO.
Hillel, Guillaume, any comments on this? Does it solve the discussion?
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
---
Re: PATCH: Postgresql Patch
Guillaume Cottenceau schrieb:
Can you show us the code? Difficult to make one's mind without
more information.
I don't know the UUID thing but what may make a difference would
be a little performance penalty (inserting a value instead of
letting postgres handle the SERIAL its way). But it should be
minimal, I think.
Also, let's not forget to document the importance of creating an
index on the UUID column, if we're going to select by UUID, which
I guess will be the case.
the code is in gwlib/gw_uuid.[ch].
Alex did a lot for research at the time he introduced the UUID implementation as
a message ID for the transport layers in Kannel. And he did a great work to
explain the necessary parts at that time. From my perspective I trust his
research and words, even while I never tried to "understand" the UUID heuristics
in detail by the code. (I admit I reviewed some other projects and references
for UUID and have been simply convinced.)
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
---
Re: PATCH: Postgresql Patch
Guillaume Cottenceau schrieb:
I was referring to the actual difference planned to use the UUID
stuff for DLRs. E.g. see what were your actual plans with using
that data; even if it's guessable at that point of the
discussion, it's always more precise and less error prone to see
the code rather than intentions :)
agree ;)
Alex did a lot for research at the time he introduced the UUID
implementation as a message ID for the transport layers in Kannel. And
That looks great, granted.
all applause here goes to Alex ;)
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
---
Re: Kannel on AIX
Vincent CHAVANIS schrieb:
Yeah, i'm also suprised !!!
(X25 is dead, long live TCP/IP ! )=)
The EMI patch looks good but, we need to check if everything goes fine
in changing speed.
Andreas Fink a écrit :
so theres still people using X.25 with EMI UCP ;-)
I'm surprised...
On 01.07.2008, at 11:16, Bostock James wrote:
Hi,
I am trying to get Kannel 1.4.1 to compile and run on AIX 5.2 using
gcc 4.0 and libxml2 2.6.23. To do so, I had to make two small changes
to the source code:
--- gateway-1.4.1.orig/gw/smsc/smsc_emi_x25.c 2005-02-11
15:35:48.0 +
+++ gateway-1.4.1/gw/smsc/smsc_emi_x25.c2008-07-01
08:51:47.0 +0100
@@ -496,8 +496,17 @@
/* The speed initialisation is pretty important. */
tcgetattr(fd, &tios);
+/* Choose the fastest speed available (assuming at least 38400 baud).
+*/ #if defined(B115200)
cfsetospeed(&tios, B115200);
cfsetispeed(&tios, B115200);
+#elif defined(B57600)
+cfsetospeed(&tios, B57600);
+cfsetispeed(&tios, B57600);
+#elif defined(B38400)
+cfsetospeed(&tios, B38400);
+cfsetispeed(&tios, B38400);
+#endif
kannel_cfmakeraw(&tios);
tios.c_cflag |= (HUPCL | CREAD | CRTSCTS);
tcsetattr(fd, TCSANOW, &tios);
that patch makes sense.
Vincent: so a +1 for committing to CVS?
wouldn't the following be more appropriate:
#if !defined(int64)
typedef int64_t int64
#endif
James: can you confirm that this suggestion from Vincent works too on the AIX
platform? If yes, I'm going to commit to CVS.
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
---
Re: Kannel on AIX
Bostock James schrieb:
I also tried building using the native AIX compiler which, in addition to the
above changes, requires that all the C++-style comments be converted to C-style
comments (there's probably a compiler switch that allows C++-style comments but
by default they are rejected).
The build system assumes gcc (for the generation of include dependencies via
the -MM option) which is unfortunate.
did the AIX native C compiler work with changes on configure.in?
We can add support for AIX directly to configure.in I guess, since we handle
some fractions of platform specific parts already inside:
case "$host" in
*-sun-solaris*)
CFLAGS="$CFLAGS -DSunOS=1"
;;
*-cygwin*)
EXE_EXT=".exe"
;;
*apple-darwin*)
# MacOS X
[...]
;;
*-linux-*)
CFLAGS="$CFLAGS -D_XOPEN_SOURCE=600 -D_BSD_SOURCE"
LDFLAGS="$LDFLAGS -rdynamic"
;;
*-*-openbsd* | *-*-freebsd*)
CFLAGS="$CFLAGS -pthread"
AC_CHECK_LIB(c_r, pthread_exit, [LIBS="$LIBS -lc_r"; pthread="yes"])
AC_CHECK_LIB(kse, pthread_exit, [LIBS="$LIBS -lkse"; pthread="yes"])
;;
esac
If you can provide a normal ssh account for me to board a corresponding box, I'd
be willing to work it out on the machine, so we have it supported out-of-the-box.
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
---
Re: [PATCH] multipart MIME output
P. A. Bagyenda schrieb:
hi,
For a while I've noticed spurious CRLF at the end of body parts inside
multipart MIME messages. I believe I have tracked this down to a couple
of bugs in the gwlib/mime.c module, which is used heavily by Mbuni MMS
Gateway.
Attached patch fixes these. Broadly, the code was too complicated for
what should have been a simpler task (thanks partly to your truly!).
I've tried to simplify the code to be true to RFC 2046 Sec. 5. Tests
confirm that it is doing the right thing now.
In addition, the test case for multipart mime is actually mal-formed
itself :(, lacking CRLF after each header, and at certain boundaries. A
cleaner one is attached.
Hi Paul,
thanks again providing the necessary changes. Looks good so far.
I'm +0 at the moment, due to the fact that I see
$ ./test/test_mime_multipart multipart-msg.txt
failing for it's own self-check constrain, complaining that the decoded and
re-encoded MIME entity result file differs.
Output is attached, could you have a deeper view into it please and confirm if
it's still "ok" semantically and we should change something in the test case
constrain, or it the re-encoded output is really bogus.
Thanks.
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
---
2008-07-01 14:11:01 [1556] [0] INFO: MIME Octstr from file
`desktop/multipart-msg.txt':
2008-07-01 14:11:01 [1556] [0] DEBUG: Octet string at 0x73faa0:
2008-07-01 14:11:01 [1556] [0] DEBUG: len: 819
2008-07-01 14:11:01 [1556] [0] DEBUG: size: 1024
2008-07-01 14:11:01 [1556] [0] DEBUG: immutable: 0
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 43 6f 6e 74 65 6e 74 2d 54 79 70
65 3a 20 6d 75 Content-Type: mu
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 6c 74 69 70 61 72 74 2f 72 65 6c
61 74 65 64 3b ltipart/related;
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 20 73 74 61 72 74 3d 3c 41 41 41
3e 3b 20 62 6fstart=; bo
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 75 6e 64 61 72 79 3d 6d 79 5f 62
6f 75 6e 64 61 undary=my_bounda
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 72 79 0d 0d 0a 58 2d 53 6f 6d 65
2d 48 65 61 64 ry...X-Some-Head
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 65 72 3a 20 53 6f 6d 65 2d 56 61
6c 75 65 0d 0d er: Some-Value..
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 0a 4d 49 4d 45 2d 56 65 72 73 69
6f 6e 3a 20 31 .MIME-Version: 1
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 2e 30 0d 0d 0a 0d 0d 0a 0d 0d 0a
2d 2d 6d 79 5f .0.--my_
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 62 6f 75 6e 64 61 72 79 0d 0d 0a
43 6f 6e 74 65 boundary...Conte
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 6e 74 2d 54 79 70 65 3a 20 74 65
78 74 2f 70 6c nt-Type: text/pl
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 61 69 6e 0d 0d 0a 0d 0d 0a 74 68
69 73 20 69 73 ain..this is
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 20 74 68 65 20 74 65 78 74 20 69
6e 20 74 68 69the text in thi
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 73 20 65 6e 74 69 74 79 0d 0a 0d
0d 0a 2d 2d 6d s entity.--m
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 79 5f 62 6f 75 6e 64 61 72 79 0d
0d 0a 43 6f 6e y_boundary...Con
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 74 65 6e 74 2d 54 79 70 65 3a 20
6d 75 6c 74 69 tent-Type: multi
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 70 61 72 74 2f 6d 69 78 65 64 3b
20 62 6f 75 6e part/mixed; boun
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 64 61 72 79 3d 6d 6d 73 5f 62 6f
75 6e 64 61 72 dary=mms_boundar
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 79 0d 0d 0a 4d 49 4d 45 2d 56 65
72 73 69 6f 6e y...MIME-Version
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 3a 20 31 2e 30 0d 0d 0a 0d 0d 0a
0d 0d 0a 2d 2d : 1.0.--
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 6d 6d 73 5f 62 6f 75 6e 64 61 72
79 0d 0d 0a 43 mms_boundary...C
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 6f 6e 74 65 6e 74 2d 54 79 70 65
3a 20 74 65 78 ontent-Type: tex
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 74 2f 70 6c 61 69 6e 0d 0d 0a 0d
0d 0a 74 68 69 t/plain..thi
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 73 20 69 73 20 74 68 65 20 6d 6d
73 20 6d 65 73 s is the mms mes
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 73 61 67 65 20 74 65 78 74 0d 0a
0d 0d 0a 2d 2d sage text.--
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 6d 6d 73 5f 62 6f 75 6e 64 61 72
79 0d 0d 0a 43 mms_boundary...C
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 6f 6e 74 65 6e 74 2d 54 79 70 65
3a 20 61 70 70 ontent-Type: app
2008-07-01 14:11:01 [1556] [0] DEBUG: data: 6c 69 63 61 74 69 6f 6e 2f 78 6d
6c 0d 0d 0a 0d lication/xml
2008-07-01 14:11:0
Re: [PATCH] multipart MIME output
P. A. Bagyenda schrieb:
Stipe,
I did that test before sending the patch. Basically that test is broken
because the multipart-msg.txt is not strictly speaking a well-formed
multipart/mime message. In particular, some message headers are
terminated by CR instead of CRLF. This is why I attached a new
multipart-msg.txt, which is MIME conformant. On that one we pass with
flying colours. (I guess I should have made a patch!)
Note of course that mime.[ch] is forgiving of improperly constructed
MIME such as the above when parsing. It does however generate correct
MIME on the output side. Hence the discrepancy.
ok, understand. Can you post the "new" multipart-msg.txt as attachement, so we
can confirm the patched test program runs as expected? So I can commit the
changes to CVS.
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
---
Re: [PATCH] multipart MIME output
P. A. Bagyenda schrieb:
Here you go:
thanks Paul.
test/test_mime_multipart still complains with the new input, and I see that the
orginal is 819 bytes in size, and the re-encoded "only" 815. So what are the 4
missing bytes? Any clue, relevance here?
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
---
Re: PATCH: Microsecond sleep time
Werner Coetzee schrieb:
Hi
Can anyone explain why gwthread is using the poll function to sleep (using
milliseconds as timeout), and not maybe the select function (using microseconds
as timeout)?
We have the requirement to be able to sleep for less than a millisecond, which
the current gwthread_sleep can't provide.
Below is a patch to do just that, using the select function.
I have tested it, so if anyone has any comments, please let me hear them.
The diff is from our own SVN repository, but as far as I know, it is up-to-date
with the cvs.
Hi Werner,
I'm +0 for applying the patch to CVS, since it's an additive feature and doesn't
hurt any existing core bricks of the gwlib.
The calls should be POSIX.1 compliant and portable hence I guess.
Werner, could you do me a favor and resend the patch in a single file as mail
attachment please. This ensures we don't get truncated end of line chars etc,
which is a mess to correct by hand while patching ;)
And thanks a lot for contributing.
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
---
Re: Kannel on AIX - is it necessary to explicitly link against wtc8/wtc9?
Hi James,
Bostock James schrieb:
Hi,
If Kannel is configured with --with-oracle, it tries to link the wtc8
library or, if the file $ORACLE_HOME/lib/libwtc8.so does not exist, the
wtc9 library.
On AIX, with Oracle 9.2, linking explicitly against libwtc9 also
requires explicitly linking against libclntst9 and libodm (a system
library).
so this means our current --with-oracle option won't work out-of-the-box for AIX
and Oracle 9.2, right?
My question is whether it is necessary to explicitly check for libwtc8
or libwtc9 (note that there is no corresponding library for Oracle 10)?
Is it not sufficient to link against libclntsh?
good question; we should have someone with all the Oracle 8,9,10,11 versions
installed and test.
Note that for certain configurations of HP-UX, the shared library
extension is ".sl" not ".so" so the existing check is inherently
non-portable.
which one do you refer to here?
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
---
Re: [PATCH] multipart MIME output
P. A. Bagyenda schrieb:
hi,
For a while I've noticed spurious CRLF at the end of body parts inside
multipart MIME messages. I believe I have tracked this down to a couple
of bugs in the gwlib/mime.c module, which is used heavily by Mbuni MMS
Gateway.
Attached patch fixes these. Broadly, the code was too complicated for
what should have been a simpler task (thanks partly to your truly!).
I've tried to simplify the code to be true to RFC 2046 Sec. 5. Tests
confirm that it is doing the right thing now.
In addition, the test case for multipart mime is actually mal-formed
itself :(, lacking CRLF after each header, and at certain boundaries. A
cleaner one is attached.
Thanks again Paul. Committed to CVS:
2008-07-02 Stipe Tolj
* gwlib/mime.c: fix and relax function mime_entity_to_octstr() for end of
line chars. Thanks to Paul Bagyenda for providing the patch.
[Msg-Id: <[EMAIL PROTECTED]>]
* test/mime-multipart.txt: demo MIME multipart input file for test/
test_mime_multipart.c.
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
---
Re: Kannel on AIX - is it necessary to explicitly link against wtc8/wtc9?
Bostock James schrieb:
My question is whether it is necessary to explicitly check for libwtc8
or libwtc9 (note that there is no corresponding library for Oracle 10)?
Is it not sufficient to link against libclntsh?
we have a more recent version of configure.in's oracle detection logic in CVS
HEAD branch:
[...]
dnl Check for Oracle 10g instant client
if test -f "$ORACLE_LIB_PATH/libnnz10.so" && \
test -f "$ORACLE_LIB_PATH/libclntsh.so.10.1"; then
LIBS="$LIBS -lnnz10"
AC_CHECK_LIB(clntsh,OCIEnvCreate,[ LIBS="$LIBS -lclntsh -lnnz10"
],exit)
else
AC_CHECK_LIB(clntsh,OCIEnvCreate,[ LIBS="$LIBS -lclntsh" ],exit)
fi
dnl Beware that Oracle 10g doesn't use anymore the libwtcX.so libs,
dnl so we don't break hard in case they are not present.
if test -f "$ORACLE_HOME/lib/libwtc8.so"; then
AC_CHECK_LIB(wtc8,wtcstu,[ LIBS="$LIBS -lwtc8" ],AC_MSG_ERROR([Oracle
libwtc8.so not found]))
fi
if test -f "$ORACLE_HOME/lib/libwtc9.so"; then
AC_CHECK_LIB(wtc9,wtcstu,[ LIBS="$LIBS -lwtc9" ],AC_MSG_ERROR([Oracle
libwtc9.so not found]))
fi
[...]
which only tries to run the AC_CECK_LIB() macros if the library files are really
present.
Can you please checkout a CVS working copy, since this is way more recent then
1.4.1 stable.
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
---
Re: PATCH: Microsecond sleep time
Werner Coetzee schrieb:
Hi Stipe
Patch attached.
Hi Werner,
you attached a file micro.c, but not a 'diff -u' formated patch ;)
Can you please resend in diff style as you did in your initial posting, but
simply attach the patch file so we don't get it clobbered. Thanks.
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
---
Re: PATCH: kannel on AIX - override ar
Bostock James schrieb:
Hi,
To build kannel in 64 bit mode, you need to use "ar -X64" instead of
"ar" to build archive libraries. The following patch to configure.in
allows the ar program to be specified by the AR environment variable.
Thanks James for providing the patch for AIX 64bit builds.
Commited to CVS:
2008-07-02 Stipe Tolj
* configure[.in]: add support for AIX 64bit builds via setting the ar
archiever call in $AR env variable.
Thanks to James Bostock for his AIX
contributions.
[Msg-Id:
<[EMAIL PROTECTED]>]
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
---
Re: CVS port number
Werner Coetzee schrieb:
Hi what is the port number for Kannel CVS?
I'm using the command as on www.kannel.org:
cvs -d:pserver:[EMAIL PROTECTED]:/home/cvs login
but get: cvs [login aborted]: connect to cvs.kannel.org(193.53.0.98):2401
failed: Connection timed out
Is the port number maybe different from 2401?
nop, it's the standard cvs server port, hence 2401.
Here is a telnet session from outside:
$ telnet cvs.kannel.org 2401
Trying 193.53.0.98...
Connected to cvs.kannel.org.
Escape character is '^]'.
cvs [pserver aborted]: bad auth protocol start:
Connection closed by foreign host.
so thing should work. Maybe an short network outage either on your side or
ours? ;)
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
---
Re: Kannel on AIX - is it necessary to explicitly link against wtc8/wtc9?
Alexander Malysh schrieb:
Hi,
even recent CVS version doesn't work for OSX because .so is hardcoded.
Please try this patch that fixed this issue for me:
http://dev.kannel.org/~amalysh/configure.diff
checking...
Thanks,
Alex
P.S. @Stipe, could you please increase message limit this is annoying?
Your mail to 'devel' with the subject
Re: Kannel on AIX - is it necessary to explicitly link against
wtc8/wtc9?
Is being held until the list moderator can review it for approval.
The reason it is being held:
Message body is too big: 640506 bytes with a limit of 40 KB
now, do we really want to send attachement chunkds of 640K to 800-900
subscribers via mail?
I can update the limit to 128K, which seems reasonable for me for patches or
bzip2'ed tarballs, but more then 500K seems really to much IMO.
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
---
Re: PATCH: Microsecond sleep time
Werner Coetzee schrieb:
Hi Stipe
Diffs attached.
I hope it's the right format this time.
almost ;)
Never mind, I have committed to CVS:
2008-07-03 Stipe Tolj
* gwlib/gwthread[-pthread].[ch]: add function gwthread_sleep_micro() which
allows sleep of microseconds. Thanks to Werner Coetzee
for providing this contribution.
[Msg-Id:
<[EMAIL PROTECTED]>]
Thanks again.
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
---
Re: Kannel on AIX - is it necessary to explicitly link against wtc8/wtc9?
Alexander Malysh schrieb:
Hi,
even recent CVS version doesn't work for OSX because .so is hardcoded.
Please try this patch that fixed this issue for me:
http://dev.kannel.org/~amalysh/configure.diff
Alex, I can't see any relevant changes in configure.in (autconf input file) for
the related .so hardcoding?
We don't want to mangle configure script itself?!
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
---
Re: Kannel on AIX - is it necessary to explicitly link against wtc8/wtc9?
Alexander Malysh schrieb:
P.S. @Stipe, could you please increase message limit this is annoying?
upgraded both lists 'devel,users' to 128K limit.
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
---
Re: PATCH: Only print OCI version if OCI_MAJOR_VERSION and OCI_MINOR_VERSION are defined
Bostock James schrieb:
The patch seemed to have been mangled during the copy paste operation.
Attached as a separate file.
+1, and commited to CVS:
2008-07-04 Stipe Tolj
* gw/shared.c: ensure we handle OCI_[MINOR|MAJOR]_VERSION only if they
are defined in the oci.h header. Pre Oracle 10 versions seem to lack this.
Thanks to James Bostock for the patch.
[Msg-Id:
<[EMAIL PROTECTED]>]
Thanks a lot James! Good work.
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
---
Re: PATCH: only generate dependencies if using gcc
Bostock James schrieb:
Hi,
The attached patch changes the build process so that dependencies are
only generated if gcc is being used. The patch only includes the changes
to configure.in and Makefile.in - I left out the changes to configure
because I have a different version of autoconf.
looks good for me, voting +0.
Can you point out why you need to omit the .depend file creation if the compiler
is not gcc?
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
---
Re: PATCH: only generate dependencies if using gcc
Stipe Tolj schrieb:
Can you point out why you need to omit the .depend file creation if the
compiler is not gcc?
i.e. the Intel CC handles the options and can build without changes.
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
---
Re: PATCH: only generate dependencies if using gcc
Andreas Fink schrieb:
MacOS X also often has issues with precompiled headers due to the fact
that Apple's GCC variant can compile multiple architectures in one go
(for example if you pass -arch ppc -arch i386 -arch ppc64 -arch x86_64).
In this case the precompiled headers can be different as things like
size of () do return different values and endianness is different. So
instead of one .depend it would have to create multiple ones.
So gcc does return:
gcc-4.0: -E, -S, -save-temps and -M options are not allowed with
multiple -arch flags
> So under MacOS X I often use --disable-dependency-tracking or I compile
> for every architecture once and merge the binaries it with "lipo"
> lateron. Kannel doesnt have this issue as I fixed the endianness and
> sizeof issues. In the case of kannel its compiling for multiple
> architectures and disables -M.
so there is no way with the current build system to compile "multi-arch
binaries" for Kannel?
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
---
Re: PATCH: only generate dependencies if using gcc
Bostock James schrieb:
Hi,
The attached patch changes the build process so that dependencies are
only generated if gcc is being used. The patch only includes the changes
to configure.in and Makefile.in - I left out the changes to configure
because I have a different version of autoconf.
any other votes from the core developers on this one?
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
---
Re: PATCH: only typedef int64 if type does not already exist
Bostock James schrieb:
Hi,
The attached patch causes the int64 type to only be defined (in
gw/smsc/smsc_soap.c) if it does not already exist (as determined by the
autoconf AC_CHECK_TYPES macro). This patch fixes a compilation failure
on AIX when compiling in 64 bit mode.
first of all thanks a lot James, we appreciate your work highly.
hmmm, -0 on the patch. Reason: I don't like the idea to have
#define HAVE_
statements in the gw-config.h.in autoconf macro.
The "mapping" of 32bit and 64bit integer/long should be done by the OS layer
headers underneath /usr/include itself, IMO.
Any one other please comment on this issue. How does linux-x86_64 does it for
the referred gw/smsc/smsc_soap.c file?
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
---
Re: PATCH: only typedef int64 if type does not already exist
Bostock James schrieb:
Fair enough.
How about instead of using the name int64, using a name less likely to
conflict with a name defined by the OS. Say, gw_int64?
now, what I don't understand is: why doesn't the OS layer headers map
transparently for any upper layer application (Kannel)?
The linux-x86_64, along macosx, [free|open|ned]bsd seem to do.
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
---
Re: PATCH: Memory leak in Clickatell + Brunet HTTP SMSC
Donald Jackson schrieb:
Hi everyone,
Attached is a diff for memory leak found in smsc_http.c for Clickatell
and Brunet specific implementations. The message ID Octstr's never get
destroyed when the dictionary gets destroyed.
-1 on this patch. Reason: we do a double free() on the Octstr pointers and cause
a segfault.
The issue is:
- octstr_split_words() malloc()s the new items in the list.
- then we inject to Dict the pointer refrence, that's the "original", not a
copy.
- then we gwlist_destroy() and hence all items of the list are freed, also
the one we put into the dict.
- later on we dict_destroy() _WITH_ the octstr_destroy() callback and hence
we'll try to double free. Bang.
Attached is a revised patch, that takes care we duplicate the items that we put
into the Dict hash, so we have a clean destruction later, as the
gwlist_destroy() took care of the original ones.
Please review and vote.
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
---
### Eclipse Workspace Patch 1.0
#P gateway-cvs-head
Index: gw/smsc/smsc_http.c
===
RCS file: /home/cvs/gateway/gw/smsc/smsc_http.c,v
retrieving revision 1.56
diff -u -r1.56 smsc_http.c
--- gw/smsc/smsc_http.c 14 Jul 2008 14:50:12 - 1.56
+++ gw/smsc/smsc_http.c 14 Jul 2008 15:09:12 -
@@ -726,16 +726,16 @@
words = octstr_split_words(body);
if ((len = gwlist_len(words)) > 1) {
- word = gwlist_extract_first(words);
- if (octstr_compare(word, octstr_imm("ID:")) == 0) {
- value = gwlist_extract_first(words);
- param = dict_create(4, NULL);
- dict_put(param, octstr_imm("ID"), value);
- } else if (octstr_compare(word, octstr_imm("ERR:")) == 0) {
- value = gwlist_extract_first(words);
- param = dict_create(4, NULL);
- dict_put(param, octstr_imm("ERR"), value);
- }
+word = gwlist_extract_first(words);
+if (octstr_compare(word, octstr_imm("ID:")) == 0) {
+value = gwlist_extract_first(words);
+param = dict_create(4, (void(*)(void *)) octstr_destroy);
+dict_put(param, octstr_imm("ID"), octstr_duplicate(value));
+} else if (octstr_compare(word, octstr_imm("ERR:")) == 0) {
+value = gwlist_extract_first(words);
+param = dict_create(4, (void(*)(void *)) octstr_destroy);
+dict_put(param, octstr_imm("ERR"), octstr_duplicate(value));
+}
octstr_destroy(word);
}
gwlist_destroy(words, (void(*)(void *)) octstr_destroy);
@@ -1017,13 +1017,13 @@
words = octstr_split_words(body);
if ((len = gwlist_len(words)) > 0) {
-param = dict_create(4, NULL);
+param = dict_create(4, (void(*)(void *)) octstr_destroy);
while ((word = gwlist_extract_first(words)) != NULL) {
List *l = octstr_split(word, octstr_imm("="));
Octstr *key = gwlist_extract_first(l);
Octstr *value = gwlist_extract_first(l);
if (octstr_len(key))
-dict_put(param, key, value);
+dict_put(param, key, octstr_duplicate(value));
octstr_destroy(key);
octstr_destroy(word);
gwlist_destroy(l, (void(*)(void *)) octstr_destroy);
Re: PATCH: Memory leak in Clickatell + Brunet HTTP SMSC
Werner Coetzee schrieb:
Hi Stipe
I must disagree with you (unfortunately).
If you look closely, you'll see that:
word = gwlist_extract_first(words);
and
value = gwlist_extract_first(words);
is used on the list, (i.e. 2 elements removed from the list), and when
gwlist_destroy is called, 'word' and 'value' is not destroyed.
There is an octstr_destroy(word), but there is no octstr_destroy(value), and
because there is no callback for the 'param' dictionary, 'value' never will be
destroyed, resulting in a memory leak.
The patch you provided creates a copy of 'value' which will be destroyed via
the callback when dict_destroy is called, but the original 'value' will still
reside in memory indefinitely. So I would go for the patch provided by Mr.
Jackson, or you should add a octstr_destroy(value) to your patch.
yup Werner, thanks for the shot here. You're of course right. I wasn't having my
eyes on the missing octstr_destroy(value) itself. Credits on your eyes here ;)
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
---
Re: PATCH: Memory leak in Clickatell + Brunet HTTP SMSC
Donald Jackson schrieb:
Hi everyone,
Attached is a diff for memory leak found in smsc_http.c for Clickatell
and Brunet specific implementations. The message ID Octstr's never get
destroyed when the dictionary gets destroyed.
and after Werner's correction to my mail, +1, and committed to CVS:
2008-07-15 Stipe Tolj
* gw/smsc/smsc_http.c: memory leak fix for Clickatell and Brunet HTTP API.
Thanks to Donald Jackson for the patch.
[Msg-Id: <[EMAIL PROTECTED]>]
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
---
Re: sms-service
Kaneza Innocent schrieb:
As you can see, I have different sms-services configured and one of them
which is default handles all the services I didn’t configure directly in
kannel. But what is happening is that when I do a request it matches the
first character (in this situation g like if I have a keyword called
giraffe kannel interprets it as it is the game keyword)
Is it a bug in the CVS version or there is an error in my configuration?
Hi Kaneza,
it's no bug, it's a semantical error in your interpretation how the keyword
matching happens inside Kannel.
The first 'alias = g;gme' causes to catch _ANY_ word starting with g.
I suggest using 'keyword-regex' on all groups, and leave the final group as
'default' to catch-all others that didn't match in the previous regex patterns.
With regex you can specify more complex match patterns.
Check out the web about regular expressions (regex).
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
---
[PATCH] Cygwin 1.2.25+ support via gix in gwlib/conn.c (openssl thread callbacks)
Hi list,
as many of you may now, we support the Cygwin 1.2.x (POSIX.1 layer on Win32)
natively, but claimed always to be "unstable" on this platform due to lacks in
the pthreads implementation of Cygwin.
I tried to debug the "manged to lock the mutex twice" bug we face on higher load
of the daemons. It seems that our callback scheme has an issue, presumably the
gwthread_self() way we provide to the openssl core to identify the associated
thread. Our mutex struct is based on pthreads itself. Now, what I did is to
"exchange" our wrapped way by native pthread calls in the gwlib/conn.c layer for
the openssl thread callback scheme, and voila it works without crashing.
Asking anyone interested in running on Win32 via Cygwin to test and vote.
Thanks,
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
---
### Eclipse Workspace Patch 1.0
#P gateway-cvs-head
Index: gwlib/conn.c
===
RCS file: /home/cvs/gateway/gwlib/conn.c,v
retrieving revision 1.86
diff -u -r1.86 conn.c
--- gwlib/conn.c9 Jan 2008 20:06:55 - 1.86
+++ gwlib/conn.c18 Jul 2008 13:28:03 -
@@ -1237,43 +1237,57 @@
}
*/
-static Mutex **ssl_static_locks = NULL;
+static pthread_mutex_t *ssl_static_locks = NULL;
+static int ssl_lock_num_locks = 0;
/* the call-back function for the openssl crypto thread locking */
static void openssl_locking_function(int mode, int n, const char *file, int
line)
{
-if (mode & CRYPTO_LOCK)
-mutex_lock(ssl_static_locks[n-1]);
-else
-mutex_unlock(ssl_static_locks[n-1]);
+if (n < ssl_lock_num_locks) {
+if (mode & CRYPTO_LOCK) {
+pthread_mutex_lock(&(ssl_static_locks[n]));
+} else {
+pthread_mutex_unlock(&(ssl_static_locks[n]));
+}
+}
+}
+
+static unsigned long openssl_thread_id(void)
+{
+return (unsigned long) pthread_self();
}
void openssl_init_locks(void)
{
-int c, maxlocks = CRYPTO_num_locks();
+int c;
+
+ssl_lock_num_locks = CRYPTO_num_locks();
gw_assert(ssl_static_locks == NULL);
-ssl_static_locks = gw_malloc(sizeof(Mutex *) * maxlocks);
-for (c = 0; c < maxlocks; c++)
-ssl_static_locks[c] = mutex_create();
+ssl_static_locks = gw_malloc(sizeof(pthread_mutex_t) * ssl_lock_num_locks);
+for (c = 0; c < ssl_lock_num_locks; c++) {
+pthread_mutex_init(&(ssl_static_locks[c]), NULL);
+}
/* after the mutexes have been created, apply the call-back to it */
+CRYPTO_set_id_callback(openssl_thread_id);
CRYPTO_set_locking_callback(openssl_locking_function);
-CRYPTO_set_id_callback((CRYPTO_CALLBACK_PTR)gwthread_self);
}
void openssl_shutdown_locks(void)
{
-int c, maxlocks = CRYPTO_num_locks();
+int c;
gw_assert(ssl_static_locks != NULL);
/* remove call-back from the locks */
CRYPTO_set_locking_callback(NULL);
+CRYPTO_set_id_callback(NULL);
-for (c = 0; c < maxlocks; c++)
-mutex_destroy(ssl_static_locks[c]);
+for (c = 0; c < ssl_lock_num_locks; c++) {
+pthread_mutex_destroy(&(ssl_static_locks[c]));
+}
gw_free(ssl_static_locks);
ssl_static_locks = NULL;
Re: [PATCH] Cygwin 1.2.25+ support via gix in gwlib/conn.c (openssl thread callbacks)
Alexander Malysh schrieb:
I don't like the idea to use pthread_mutex directly instaed of our
wrapper. If this change make a panic go away then we doing something
wrong in our wrapper and wrapper should be fixed.
Only and only when it is not fixable (I don't think so because apr
(apache) uses wrapper), we should commit this patch.
the patch is considered as "proof of concept", that the direct pthreads hooks
for the openssl callback do work. I agree that it would make more sense, and is
cleaner from the architecture concept to haver our own mutex structs inside.
I'll need to dig deeper to the cause of the "managed to lock mutex twice" issue
on Cygwin.
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
---
Re: Kannel SVN repo
Alexander Malysh schrieb:
4) how write access should be handled via svn+ssh, https, ...? (I think
https should be enough)
as of my previous mail, regarding HTTPS and SSL client certs, here is a
reference for the Eclipse CDT IDE:
http://svn.collab.net/subclipse/help/index.jsp?topic=/org.tigris.subversion.subclipse.doc/html/reference/protocol.html
The native svn command line client should work too.
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
---
Re: Kannel SVN repo
Alexander Malysh schrieb:
Hello all,
I have setup test SVN repo for kannel and installed viewvc for it.
viewvc: http://svn.kannel.org
or
svn co http://svn.kannel.org/repos/gateway
Please test...
thanks Alex.
I have few questions, what we need:
1) do we need daily diff mail or should we setup post-commit hook to
mail diffs?
I'm for the post-commit hook, as this is a svn feature and doen't bulk
subscribed mailboxes with "no changes" mails and only issues a mail if a
corresponding commit has been applied.
Can we setup to pipe it via the existing mailman subscribers to the
'devel-reports' mailing list? So +1 for post-commit hook.
2) should we check in pre-commit hook for existance of log message and
if not reject commit?
yep, we want a clean ChangeLog entry and a corresponding log message to be
existing. (Andreas will hate it ;) ++1.
3) I don't see any sense to use Changelog anymore, because 'svn log'
produce better log :) but require (2)...
Now, the ChangeLog is a construct since decades for the CVS repos. If we use (2)
and we can "reproduce" the same ChangeLog "on request", then I'm +0 for it.
4) how write access should be handled via svn+ssh, https, ...? (I think
https should be enough)
HTTPS _AND_ SSL client certificates. So we ensure that write commit to the SVN
repos is always identified by a corresponding user. This means we will have to
establish a Kannel CA too, which issues the certs.
Is SSL cert client-side authentication possible with svn client directly and any
common IDE, i.e. Eclipse?
5) when should we switch to SVN and set cvs repo to read-only?
IMO, as soon as we have tagged the CVS HEAD branch for version 1.4.2 we should
set the CVS repo to read-only and switch SVN to write, keeping the CVS in
operation (in read-only) for a couple of weeks to allow users relying on the
repo to migrate.
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
---
Re: Kannel SVN repo
Alexander Malysh schrieb:
Hi,
I don't think we need SSL client certs... username+password should be OK
but SSL will be required if you want to commit.
now passwords are "simple" layer security, 4096 bit cipher certs are something
"harder" ;)
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
---
Re: [PATCH] fix mem leak in gwlib/mime.c
P. A. Bagyenda schrieb:
We have a memory leak in gwlib/mime.c which the attached patch should
fix. We replace the header field of the MIMEEntity object without first
freeing it.
absolutely correct, +1, and committed to CVS:
2008-07-19 Stipe Tolj
* gwlib/mime.c: memory leak fix while duplicating headers.
Thanks to Paul Bagyenda for providing the patch.
[Msg-Id: <[EMAIL PROTECTED]>]
Thanks Paul!
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
---
Re: [PATCH] Cygwin 1.2.25+ support via gix in gwlib/conn.c (openssl thread callbacks)
some more debug information for the pthread issues on Cygwin:
as gwlib/conn.c uses our gwthread_self() as callback function for openssl's
CRYPTO_set_id_callback():
/* Return the thread id of this thread. */
long gwthread_self(void)
{
struct threadinfo *threadinfo;
threadinfo = pthread_getspecific(tsd_key);
if (threadinfo)
return threadinfo->number;
else {
printf("XXX gwthread_self with empty threadinfo\n");
return -1;
}
}
we face this output while hitting the mutex panic:
XXX openssl_locking_function 1 u
XXX openssl_locking_function 1 l
XXX openssl_locking_function 1 u
XXX openssl_locking_function 1 l
XXX openssl_locking_function 1 u
XXX openssl_locking_function 1 l
XXX openssl_locking_function 1 2008-07-19 19:37:48.769 [5532] [-1] PANIC:
gwlib/thread.c:142: mutex_lock_real: Managed t
o lock the mutex twice! (Called from
gwlib/conn.c:1251:openssl_locking_function.)
XXX openssl_thread_id 14
XXX openssl_thread_id return 16
XXX openssl_locking_function 1 l
XXX openssl_locking_function 1 u
XXX openssl_locking_function 1 l
XXX openssl_locking_function 1 u
XXX openssl_locking_function 1 l
XXX openssl_locking_function 1 u
XXX gwthread_self with empty threadinfo
XXX openssl_thread_id -1
which means the pthread_getspecific() call fails with return value NULL, meaning
that we don't have an associated thread value for the calling thread.
This shouldn't happen, right?
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
---
