Re: GSM modem
Hi, Just ordered this https://www.smsfoxbox.it/en/usb-gsm-gprs-modem.html/ Expecting it some time next week, so not yet tested, but with OpenAT support I am expecting it to work fine. On 14/10/2016 11:54, Andreas Constantinou wrote: Hello, Anyone can recommend any GSM Modem (usb) integrated with kannel ? Brand/model specific? Thank you. --Andreas -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at kyria...@netsmart.com.cy **
Re: [RFC] New 'box' Kannel Pluginbox
Hi, First thought, yep would be really useful as for me it would allow removing the (or at least some) sms routing logic from the backend application and keep it within kannel, where it logically fits better. Additional thoughts: 1) Although HTTP as the initial plugin provides something straight forward for all to use, I would find very useful if in addition there was some (XML?) rules plugin. I can elaborate on it if you wish. Unfortunately my skills would only let me build it as something that can be called via HTTP right now, which is at least ironic :) . 2) Have the ability (via a config parameter to activate) to cache responses from the various plugins. A pluggin might need to read for example only keyword and destination address. An in memory hash table of the X most recent (or time limited) queries will have a huge speed boost to many traffic patterns, especially if the plugin is something that makes an external call or must be launched per request. Thanks, Kyriacos On 06/10/2016 10:25, Donald Jackson wrote: Hi everyone, I have started laying the foundations for a new 'box' for Kannel which intends to allow users more flexibility in terms of the platform. At the moment there are many ways to get messages into the bearerbox, namely: smsbox, wapbox, opensmppbox, smppbox, ksmppd, sqlbox. Some rely on routing in their own process and others allow bearerbox to do the routing. What they all have in common is they don't allow external or third party applications help make decisions at processing time (with the exception of ksmppd/smppbox). My new planned box is called pluginbox which will basically be like SQLBox - but instead of using database callbacks, it will allow linking of dynamic libraries (.so|.dylib) which will allow custom interception/filtering/modification of message packages to and from various boxes. So a hypothetical scenario for this box could be something like SMSBox, SMPPBox/KSMPPD, WapBox <--> PluginBox <--> Bearerbox Or even SMSBox, SMPPBox/KSMPPD, WapBox <--> SQLBox <--> PluginBox <--> Bearerbox For those who want to still make use of SQLBox. My initial design is to use an asynchronous callback chain to allow slow plugins to not hold up the processing of faster messages. This would be especially useful in the context of people using HTTP and other external services to process routing decisions. The plugin would also be able to return a status to 'reject' a message packet which would in turn not submit to the target receiver. My plan is also to implement at least one example plugin (probably an HTTP plugin?) which can show the submission and manipulation of a message packet in both directions. So here I am looking for comments. 1) Is this something worthwhile doing, does anyone else have a need for this? 2) Are there any considerations you wish to add at this time? 3) Are there any features you would like to see added? 4) Would there be any problem including this in the Kannel repository? Here is the initial version : https://github.com/donald-jackson/kannel-pluginbox Thanks Alejandro for SQLBox, its largely based on your code. Regards, -- Donald Jackson http://www.ddj.co.za <http://www.ddj.co.za/> -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at kyria...@netsmart.com.cy **
Re: Patch: EMI UUCP DLRs (final)
Hi Nikos, Thanks for the assist, in any case since Alexander committed I compiled from that on Friday. All seems to be working as expected. thanks, Kyriacos Sakkas On 29/07/2010 04:15, Nikos Balkanas wrote: Hi Kyriaco, Seems your patch flags were messing things up. I tried both patches to a Linux box I got, and they both worked flawlessly against svn 4833: SUSE Linux 2.6.25.5-1.1-pae #1 SMP 2008-06-07 01:55:22 +0200 i686 i686 i386 GNU/Linux Linux1:~/work/trunk/- patch -p0 kannel.diff patching file gw/dlr_mysql.c patching file gw/dlr_oracle.c patching file gw/dlr_pgsql.c patching file gw/dlr_mem.c patching file gw/dlr_mssql.c patching file gw/dlr_sdb.c patching file gw/dlr.c patching file gw/dlr.h patching file gw/dlr_p.h patching file gw/smsc/smsc_cimd2.c patching file gw/smsc/smsc_soap.c patching file gw/smsc/smsc_oisd.c patching file gw/smsc/smsc_at.c patching file gw/smsc/smsc_fake.c patching file gw/smsc/smsc_http.c patching file gw/smsc/smsc_smpp.c patching file gw/smsc/smsc_cgw.c BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Kyriacos Sakkas kyria...@netsmart.com.cy Cc: Kannel Devel devel@kannel.org Sent: Monday, July 26, 2010 7:14 PM Subject: Re: Patch: EMI UUCP DLRs (final) Kyriaco, Previous svn diff I got with -ub, which may be relevant. Try this one which is only -u. BR, Nikos - Original Message - From: Kyriacos Sakkas kyria...@netsmart.com.cy To: Nikos Balkanas nbalka...@gmail.com Cc: Kannel Devel devel@kannel.org Sent: Monday, July 26, 2010 5:04 PM Subject: Re: Patch: EMI UUCP DLRs (final) Hi Nikos, I got the svn snapshot today. Don't think its an SVN problem, possibly some flag needed for patch. patch 2.5.9 svn, version 1.4.2 (r22196) Running on Debian Etch. I should be able to hand patch the files where it is giving errors. Some from what I saw were due to different indentation. If you wish I can post the files detailing the rejected patches. Kyriacos On 26/07/2010 16:50, Nikos Balkanas wrote: Sorry for the irrelevant question. I tried from a fresh downloaded svn: zdev:~/work/kannel/gateway- patch kannel.diff Looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. done This is from Solaris using sunfreeware's gnu svn: svn, version 1.6.9 (r901367) compiled Mar 20 2010, 16:02:58 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme Hope this helps, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Kyriacos Sakkas kyria...@netsmart.com.cy; Kannel Devel devel@kannel.org Sent: Monday, July 26, 2010 4:04 PM Subject: Re: Patch: EMI UUCP DLRs (final) Hi Kyriaco, Are you patching against latest svn? BR, Nikos - Original Message - From: Kyriacos Sakkas kyria...@netsmart.com.cy To: Kannel Devel devel@kannel.org Sent: Monday, July 26, 2010 2:08 PM Subject: Re: Patch: EMI UUCP DLRs (final) Trying to patch to svn downloaded today (same version as in diff) and getting some errors. I will try to change the diff to work, but id someone has already done this, please forward, or let me know whats wrong with my patch command line. Patch file is from Nikos on the 20th. /opt/svn/26072010/trunk# patch --dry-run -p0 -b cimd_dlr.diff (Stripping trailing CRs from patch.) patching file gw/dlr_mysql.c (Stripping trailing CRs from patch.) patching file gw/dlr_oracle.c (Stripping trailing CRs from patch.) patching file gw/dlr_pgsql.c
Re: Patch: EMI UUCP DLRs (final)
) + if (octstr_compare(dlr-smsc, smsc) == 0 octstr_compare(dlr- + timestamp, ts) == 0 memcmp(p1 + len1 - size, p2 + len2 - size, + size) == 0) + return 0; memcmp??? why not just use truncated destination and do: octstr_search??? Actually octstr_truncate won't work since it truncates from the end. octstr_delete, would work, however, destroying the original Octstr in the process, unless I duplicated them. It would need to be done on both destinations to work. Code would be more, and the malloc, free and copy, have an overhead. Memcmp doesn't change the original Octstr and is natural for such operations. However, it is out of kannel style, so you have every right to ask me to change it. Do you? yes, please change it. +Msg *dlr_find(const Octstr *smsc, const Octstr *ts, const Octstr *dst, int typ, int use_dst) you don't need to change function. Just use dst = NULL and check it. No. dst is needed for debug msgs inside dlr_find. Furthermore, use_dst, currently is set only for EMI. Decision is made at driver level so it can easily change to an smsc configuration variable if needed. ok, maybe you are right. What other people think about this ? Am 26.06.2010 um 10:23 schrieb Nikos Balkanas: Hi, I believe I have accounted for almost all your comments to produce the final working patch. I have no way of testing, other than compilation. This patch will povide: 1) Align dlr_oracle.c with the rest. Currently, Oracle does a full dst find/remove/update on each DLR. 2) Dst use on find/remove/update is controlled in dlr_find by a single variable, use_dst. This is currently set only at driver level and only in the emi driver, while everyone else has it false. However, very easily, if need arises, it can be set in smsc configuration. 3) All DLR handling for all smscs will remain as it used to be till now. Only emi handling changes, hopefully for the better (that is the purpose of the patch :-)). 4) It will try to match the last 7 digits of the destination or the length of the destination if it smaller. This is defined in gw/dlr_p.h as MIN_DST_LEN. Didn't want to make it larger, wanted to avoid prefix territory at all costs, since I have seen a lot of mangling there by the SMScs. Besides, I believe that 7 digits give enough resolution 5) People using emi, should rebuild their indeces, especially if they are running large batch jobs through EMI. The LIKE % construction is not very efficient. Enjoy, Nikos kannel.diff kannel.diff kannel.diff -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at kyria...@netsmart.com.cy **
Re: Patch: EMI UUCP DLRs (final)
Trying to patch to svn downloaded today (same version as in diff) and
getting some errors. I will try to change the diff to work, but id
someone has already done this, please forward,
or let me know whats wrong with my patch command line. Patch file is
from Nikos on the 20th.
/opt/svn/26072010/trunk# patch --dry-run -p0 -b cimd_dlr.diff
(Stripping trailing CRs from patch.)
patching file gw/dlr_mysql.c
(Stripping trailing CRs from patch.)
patching file gw/dlr_oracle.c
(Stripping trailing CRs from patch.)
patching file gw/dlr_pgsql.c
(Stripping trailing CRs from patch.)
patching file gw/dlr_mem.c
(Stripping trailing CRs from patch.)
patching file gw/dlr_mssql.c
(Stripping trailing CRs from patch.)
patching file gw/dlr_sdb.c
Hunk #1 FAILED at 212.
Hunk #2 FAILED at 256.
Hunk #3 FAILED at 285.
3 out of 5 hunks FAILED -- saving rejects to file gw/dlr_sdb.c.rej
(Stripping trailing CRs from patch.)
patching file gw/dlr.c
Hunk #1 FAILED at 371.
1 out of 4 hunks FAILED -- saving rejects to file gw/dlr.c.rej
(Stripping trailing CRs from patch.)
patching file gw/dlr.h
(Stripping trailing CRs from patch.)
patching file gw/dlr_p.h
(Stripping trailing CRs from patch.)
patching file gw/smsc/smsc_cimd2.c
Hunk #1 FAILED at 2114.
1 out of 1 hunk FAILED -- saving rejects to file gw/smsc/smsc_cimd2.c.rej
(Stripping trailing CRs from patch.)
patching file gw/smsc/smsc_soap.c
(Stripping trailing CRs from patch.)
patching file gw/smsc/smsc_oisd.c
(Stripping trailing CRs from patch.)
patching file gw/smsc/smsc_at.c
Hunk #1 succeeded at 2124 with fuzz 1.
(Stripping trailing CRs from patch.)
patching file gw/smsc/smsc_fake.c
(Stripping trailing CRs from patch.)
patching file gw/smsc/smsc_http.c
Hunk #2 succeeded at 931 with fuzz 1.
(Stripping trailing CRs from patch.)
patching file gw/smsc/smsc_smpp.c
(Stripping trailing CRs from patch.)
patching file gw/smsc/smsc_cgw.c
On 26/07/2010 12:40, Kyriacos Sakkas wrote:
Hi All,
Was away last week too :).
Is this patch already committed to CVS? If not I will patch locally.
Should be able to start running it tomorrow.
Kyriacos
On 22/07/2010 10:51, Byron Kiourtzoglou wrote:
Hello Niko,
I was away for a short vacation. I will try the patch as soon as possible
(but
I won't be able to test it until mid next week)
BRs
Byron
On Wednesday 21 July 2010 00:47, Nikos Balkanas wrote:
Hi Byrona Kyriaco,
Did you get the chance to test the patch? The final one submitted is
identical in function, except for some cosmetic changes. I am mostly
concerned about the correct behaviour of the concat statement in Mysql
Oracle, and of course the overall compatibility with EMI CIMD2, and SMPP
for positive control.
BR,
Nikos
- Original Message -
From: Alexander Malysh amal...@kannel.org
To: Nikos Balkanas nbalka...@gmail.com
Cc: devel@kannel.org
Sent: Wednesday, July 21, 2010 12:05 AM
Subject: Re: Patch: EMI UUCP DLRs (final)
Hi Nikos,
+1 except some indents issues but I will fix it myself...
Any test results from users?
Thanks,
Alexander Malysh
Am 20.07.2010 um 12:07 schrieb Nikos Balkanas:
OK. I believe this is it.
BR,
Nikos
- Original Message - From: Alexander Malysh
amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com
Cc: Byron Kiourtzoglou ki...@intracom.gr; devel@kannel.org
Sent: Tuesday, July 20, 2010 12:14 PM
Subject: Re: Patch: EMI UUCP DLRs (final)
Hi Nikos,
see below ...
Am 20.07.2010 um 03:03 schrieb Nikos Balkanas:
Hi Alex,
Please see inlined comments: I am still waiting feedback from some users
testing it.
- Original Message - From: Alexander Malysh
amal...@kannel.org
To: Nikos Balkanas nbalka...@gmail.com
Cc: Byron Kiourtzoglou ki...@intracom.gr; devel@kannel.org
Sent: Tuesday, July 20, 2010 1:14 AM
Subject: Re: Patch: EMI UUCP DLRs (final)
Hi Nikos,
I'm back from vacation and here are comments to your patch. Patch looks
OK but still some things to fix:
--- gw/dlr_mem.c (revision 4833)
+++ gw/dlr_mem.c (working copy)
@@ -125,8 +125,28 @@
/* XXX: check destination addr too, because e.g. for UCP is not enough
to check only
* smsc and timestamp (timestamp is even without
milliseconds)
*/
-if(octstr_compare(dlr-smsc,smsc) == 0
octstr_compare(dlr-timestamp,ts) == 0)
+if (dst){
+ Octstr *dst_min;
+ int len1 = octstr_len(dlr-destination), len2 =
octstr_len(dst); +
+ if (len1 len2)
+ return(1);
+
+ dst_min = octstr_duplicate(dlr-destination);
+ if (len1 len2)
+ octstr_delete(dst_min, 0, len1 - len2);
+
+ if (octstr_compare(dlr-smsc, smsc) == 0
octstr_compare(dlr- + timestamp, ts) == 0
octstr_compare(dst_min, dst) == 0) { +
octstr_destroy(dst_min);
return 0;
+ }
+ octstr_destroy(dst_min);
+}
+else
+ if (octstr_compare(dlr-smsc, smsc) == 0
octstr_compare
Re: Patch: EMI UUCP DLRs (final)
Hi Nikos, I got the svn snapshot today. Don't think its an SVN problem, possibly some flag needed for patch. patch 2.5.9 svn, version 1.4.2 (r22196) Running on Debian Etch. I should be able to hand patch the files where it is giving errors. Some from what I saw were due to different indentation. If you wish I can post the files detailing the rejected patches. Kyriacos On 26/07/2010 16:50, Nikos Balkanas wrote: Sorry for the irrelevant question. I tried from a fresh downloaded svn: zdev:~/work/kannel/gateway- patch kannel.diff Looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. done This is from Solaris using sunfreeware's gnu svn: svn, version 1.6.9 (r901367) compiled Mar 20 2010, 16:02:58 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme Hope this helps, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Kyriacos Sakkas kyria...@netsmart.com.cy; Kannel Devel devel@kannel.org Sent: Monday, July 26, 2010 4:04 PM Subject: Re: Patch: EMI UUCP DLRs (final) Hi Kyriaco, Are you patching against latest svn? BR, Nikos - Original Message - From: Kyriacos Sakkas kyria...@netsmart.com.cy To: Kannel Devel devel@kannel.org Sent: Monday, July 26, 2010 2:08 PM Subject: Re: Patch: EMI UUCP DLRs (final) Trying to patch to svn downloaded today (same version as in diff) and getting some errors. I will try to change the diff to work, but id someone has already done this, please forward, or let me know whats wrong with my patch command line. Patch file is from Nikos on the 20th. /opt/svn/26072010/trunk# patch --dry-run -p0 -b cimd_dlr.diff (Stripping trailing CRs from patch.) patching file gw/dlr_mysql.c (Stripping trailing CRs from patch.) patching file gw/dlr_oracle.c (Stripping trailing CRs from patch.) patching file gw/dlr_pgsql.c (Stripping trailing CRs from patch.) patching file gw/dlr_mem.c (Stripping trailing CRs from patch.) patching file gw/dlr_mssql.c (Stripping trailing CRs from patch.) patching file gw/dlr_sdb.c Hunk #1 FAILED at 212. Hunk #2 FAILED at 256. Hunk #3 FAILED at 285. 3 out of 5 hunks FAILED -- saving rejects to file gw/dlr_sdb.c.rej (Stripping trailing CRs from patch.) patching file gw/dlr.c Hunk #1 FAILED at 371. 1 out of 4 hunks FAILED -- saving rejects to file gw/dlr.c.rej (Stripping trailing CRs from patch.) patching file gw/dlr.h (Stripping trailing CRs from patch.) patching file gw/dlr_p.h (Stripping trailing CRs from patch.) patching file gw/smsc/smsc_cimd2.c Hunk #1 FAILED at 2114. 1 out of 1 hunk FAILED -- saving rejects to file gw/smsc/smsc_cimd2.c.rej (Stripping trailing CRs from patch.) patching file gw/smsc/smsc_soap.c (Stripping trailing CRs from patch.) patching file gw/smsc/smsc_oisd.c (Stripping trailing CRs from patch.) patching file gw/smsc/smsc_at.c Hunk #1 succeeded at 2124 with fuzz 1. (Stripping trailing CRs from patch.) patching file gw/smsc/smsc_fake.c (Stripping trailing CRs from patch.) patching file gw/smsc/smsc_http.c Hunk #2 succeeded at 931 with fuzz 1. (Stripping trailing CRs from patch.) patching file gw/smsc/smsc_smpp.c (Stripping trailing CRs from patch.) patching file gw/smsc/smsc_cgw.c On 26/07/2010 12:40, Kyriacos Sakkas wrote: Hi All, Was away last week too :). Is this patch already committed to CVS? If not I will patch locally. Should be able to start running it tomorrow. Kyriacos On 22/07/2010 10:51, Byron Kiourtzoglou wrote
Re: Patch: EMI UUCP DLRs (final)
Hi All,
It might be possible for me to do some testing with the mysql dlr storage.
One point is that at least on my system the connection ID for CIMD
(smsc) used for the dlr store is not the name set in the conf file but
rather a long string: CIMD2:server.ip:server.port:login .
This can be problematic if two connections on different IPs or ports
exist for the same service.
My planned solution was to use a LIKE statement here as well and use
only the login part somehow, which in my case at least happens to be
unique per service and the same on multiple connects for the same service.
Regards,
Kyriacos Sakkas
On 16/07/2010 11:43, Nikos Balkanas wrote:
Hi Byron,
Any news? Were you able to test?
BR,
Nikos
- Original Message - From: Nikos Balkanas nbalka...@gmail.com
To: Alexander Malysh amal...@kannel.org; Byron Kiourtzoglou
ki...@intracom.gr
Cc: devel@kannel.org
Sent: Wednesday, July 14, 2010 3:38 PM
Subject: Re: Patch: EMI UUCP DLRs (final)
Here it is. Added support for dest also for cimd2 as reported by Byron.
I have tested thoroughly dlr_mem.c, but only compilation for DBs,
since i
have no access to them.
@Byron: Could you please test patch for CIMD2 against some of the DBs
you
use?
Thanks,
Nikos
- Original Message - From: Alexander Malysh
amal...@kannel.org
To: Nikos Balkanas nbalka...@gmail.com
Cc: devel@kannel.org
Sent: Wednesday, July 07, 2010 6:11 PM
Subject: Re: Patch: EMI UUCP DLRs (final)
Hi,
sorry for delay... I have limited inet access now... see answers bellow.
Am 30.06.2010 um 19:30 schrieb Nikos Balkanas:
Hi,
Please see inlined answers.
Thanks for the comments and corrections. Please confirm a few remaining
choices.
BR,
Nikos
- Original Message - From: Alexander Malysh
amal...@kannel.org
To: Nikos Balkanas nbalka...@gmail.com
Cc: devel@kannel.org
Sent: Wednesday, June 30, 2010 12:02 PM
Subject: Re: Patch: EMI UUCP DLRs (final)
Hi,
IMO we don't need to handle no destination case in DLR lookup but
maybe
it's not a wrong idea to be able to ignore destination for some
reasons when SMSC send some junk to us.
Not doing it, could miss some queries altogether. It would still
work for
the large majority, but could miss a few matches that would have gotten
otherwise.
this is ok for me, we make it optional...
ok here is the review for your patch:
+if (dst){
+ int len = octstr_len(dst);
+ char *p = octstr_get_cstr(dst);
+ if (len MIN_DST_LEN)
+ p += len - MIN_DST_LEN; /* get last MIN_DST_LEN
digits */
+ like = octstr_create(strcat(%, p));
+ gwlist_append(binds, like);
+}
why is this in every dlr implementation? we have abstraction for this,
see dlr.c
I don't know where in dlr.c you are referring, but I see your
reasoning.
This is leftover from a previous implementation, where I passed
use_dest
in the dlr_DB. I considered it at the time important to pass the
whole
dest to dlr_db so that debug messages get the whole dest. Since I
started passing NULL for dest, this serves no more purpose. I will
abstract it in dlr_find and use octstr_delete instead. Will also
correct
debug messages accordingly in dlr_db.c.
you have to abstract it in dlr_find and not repeat the same code in each
dlr_db driver.
-sql = octstr_format(SELECT `%S`, `%S`, `%S`, `%S`, `%S`, `%S`
FROM
`%S` WHERE `%S`=? AND `%S`=? LIMIT 1,
+if (dst)
+ sql = octstr_format(SELECT `%S`, `%S`, `%S`, `%S`, `%S`, `%S`
FROM `%S` WHERE `%S`=? AND `%S`=? AND `%S` LIKE ? LIMIT 1,
fields-field_mask, fields-field_serv,
fields-field_url, fields-field_src,
fields-field_dst, fields-field_boxc,
fields-table, fields-field_smsc,
+fields-field_ts, fields-field_dst);
...
First of all: like ? doesn't work as you expect... it should be
something
like: LIKE CONCAT('%%', ?) and
Thanks. I will look into it.
this is too much maintenance for SQL that defined two times, how about
like this:
if (dst)
like = octstr_format('LIKE CONCAT('%%', ?)' ...);
else
like = octstr_create();
You probably mean:
like = octstr_create(=?);
no, I mean octstr_create() or better use octstr_imm()
sql = ...( %S, like)
This is a classical maintenance vs overhead. Malloc is expensive, much
more so in Linux than in Solaris. Furthermore, sql=%s%S is more
difficult to read and understand, since SQL mechanism is not
explicit, but
hidden in variables. Do you really want that?
yes, because maintenance is then easier and malloc overhead is in
linux not
so much expensive as you think because glibc has preallocated memory
pools
and not always is system call
needed.
The same is for DELETE, UPDATE...
+if (like) octstr_destroy(like);
octstr_destroy will check for NULL for you...
I am aware of that, but it costs a function call
Re: CIMD DLRs, reading field 062
Hi, Is anyone working on meta-data for CIMD? I would prefer to avoid recoding something someone else already has, and my coding is not that good in general :). Kyriacos On 13/04/2010 19:53, Alexander Malysh wrote: Hi, CIMD2 doesn't have any meta-data code now. But you have to adapt you patch to use meta-data instead of hardcode values. Thanks, Alexander Malysh Am 13.04.2010 um 13:09 schrieb Kyriacos Sakkas: Hi, That was part of my inital questions, I had not used meta-data with CIMD2 only SMPP and so was not sure if that was available on cimd and how to setup properly. Since that is available on meta-data, yes that is a much better global solution. Does someone have meta-data going on cimd? All is well and tested? I would rather use that rather than my own custom code. Kyriacos On 12/04/2010 23:03, Alexander Malysh wrote: HI, this will break backwards compatibility... Why do you change this and not just put it into meta-data? something like ?cimd2?errorcode=XXX ? meta-data was designed for such things... Thanks, Alexander Malysh Am 12.04.2010 um 17:57 schrieb Kyriacos Sakkas: Hi, Sorry for the cross-posting,, was looking at finding an existing solution, as well as comments on the diff. I should be able to comment better on stability and function on this patch tomorrow. Kyriacos On 12/04/2010 18:16, Nikos Balkanas wrote: Hi Kyriaco, Such issues are best addressed to devel group. Please do not x-post, people are sensitive here about keeping mail low. This is a change that affects only the CIMD2 driver. I see no problem with it, as long as the rest of the CIMD2 users agree with it. Personally I use only SMPP so I vote OK, but my vote shouldn't count :-) BR, Nikos - Original Message - From: Kyriacos Sakkas kyria...@netsmart.com.cy To: us...@kannel.org; Kannel Devel devel@kannel.org Sent: Monday, April 12, 2010 5:47 PM Subject: Re: CIMD DLRs, reading field 062 I have taken this live and it seems to be working ok. Kyriacos On 12/04/2010 16:36, Kyriacos Sakkas wrote: This should be a bit better :) Kyriacos On 12/04/2010 16:26, Kyriacos Sakkas wrote: What do you think of this? I will try it, but wondering if anyone things this will not work. I know this is not a proper solution, but it should be OK. Kyriacos On 12/04/2010 16:01, Kyriacos Sakkas wrote: Hi All, This question has been posted before, but I have not seen any solutions. I need to receive CIMD2 field 062 in my DLR urls. None of the %* options seems to return it, even embedded in other info. As far as I understand the meta-data TLV system is SMPP only, and will not provide a solution. From my system %A returns field 061 and %d the SMPP? mapping/equivalent of field 061. Could some small change alter this so that %A returns 062 which is to my understanding closer to the extra error info returned in SMPP DLRs. Thanks in advance, Kyriacos Sakkas -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at kyria...@netsmart.com.cy ** -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at kyria...@netsmart.com.cy ** -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at kyria...@netsmart.com.cy ** -- Kyriacos Sakkas Development Team Netsmart
CIMD meta-data [was: CIMD DLRs, reading field 062]
Hi All, I will start work on integrating meta-data to CIMD2. If anyone has already done some work on this, and has not yet commited to CVS, and would like to, please contact me in order to coordinate efforts. Thanks, Kyriacos Sakkas On 21/04/2010 17:12, Kyriacos Sakkas wrote: Hi, Is anyone working on meta-data for CIMD? I would prefer to avoid recoding something someone else already has, and my coding is not that good in general :). Kyriacos On 13/04/2010 19:53, Alexander Malysh wrote: Hi, CIMD2 doesn't have any meta-data code now. But you have to adapt you patch to use meta-data instead of hardcode values. Thanks, Alexander Malysh -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at kyria...@netsmart.com.cy **
Re: CIMD DLRs, reading field 062
Hi, That was part of my inital questions, I had not used meta-data with CIMD2 only SMPP and so was not sure if that was available on cimd and how to setup properly. Since that is available on meta-data, yes that is a much better global solution. Does someone have meta-data going on cimd? All is well and tested? I would rather use that rather than my own custom code. Kyriacos On 12/04/2010 23:03, Alexander Malysh wrote: HI, this will break backwards compatibility... Why do you change this and not just put it into meta-data? something like ?cimd2?errorcode=XXX ? meta-data was designed for such things... Thanks, Alexander Malysh Am 12.04.2010 um 17:57 schrieb Kyriacos Sakkas: Hi, Sorry for the cross-posting,, was looking at finding an existing solution, as well as comments on the diff. I should be able to comment better on stability and function on this patch tomorrow. Kyriacos On 12/04/2010 18:16, Nikos Balkanas wrote: Hi Kyriaco, Such issues are best addressed to devel group. Please do not x-post, people are sensitive here about keeping mail low. This is a change that affects only the CIMD2 driver. I see no problem with it, as long as the rest of the CIMD2 users agree with it. Personally I use only SMPP so I vote OK, but my vote shouldn't count :-) BR, Nikos - Original Message - From: Kyriacos Sakkas kyria...@netsmart.com.cy To: us...@kannel.org; Kannel Devel devel@kannel.org Sent: Monday, April 12, 2010 5:47 PM Subject: Re: CIMD DLRs, reading field 062 I have taken this live and it seems to be working ok. Kyriacos On 12/04/2010 16:36, Kyriacos Sakkas wrote: This should be a bit better :) Kyriacos On 12/04/2010 16:26, Kyriacos Sakkas wrote: What do you think of this? I will try it, but wondering if anyone things this will not work. I know this is not a proper solution, but it should be OK. Kyriacos On 12/04/2010 16:01, Kyriacos Sakkas wrote: Hi All, This question has been posted before, but I have not seen any solutions. I need to receive CIMD2 field 062 in my DLR urls. None of the %* options seems to return it, even embedded in other info. As far as I understand the meta-data TLV system is SMPP only, and will not provide a solution. From my system %A returns field 061 and %d the SMPP? mapping/equivalent of field 061. Could some small change alter this so that %A returns 062 which is to my understanding closer to the extra error info returned in SMPP DLRs. Thanks in advance, Kyriacos Sakkas -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at kyria...@netsmart.com.cy ** -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at kyria...@netsmart.com.cy ** -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at kyria...@netsmart.com.cy **
Re: CIMD DLRs, reading field 062
This should be a bit better :)
Kyriacos
On 12/04/2010 16:26, Kyriacos Sakkas wrote:
What do you think of this? I will try it, but wondering if anyone things
this will not work. I know this is not a proper solution, but it should
be OK.
Kyriacos
On 12/04/2010 16:01, Kyriacos Sakkas wrote:
Hi All,
This question has been posted before, but I have not seen any solutions.
I need to receive CIMD2 field 062 in my DLR urls. None of the %* options
seems to return it, even embedded in other info.
As far as I understand the meta-data TLV system is SMPP only, and will
not provide a solution.
From my system %A returns field 061 and %d the SMPP? mapping/equivalent
of field 061.
Could some small change alter this so that %A returns 062 which is to my
understanding closer to the extra error info returned in SMPP DLRs.
Thanks in advance,
Kyriacos Sakkas
--
Kyriacos Sakkas
Development Team
Netsmart
Tel: + 357 22 452565
Fax: + 357 22 452566
Email: kyria...@netsmart.com.cy
http://www.netsmart.com.cy
Taking Business to a New Level!
** Confidentiality Notice: The information contained in this email
message may be privileged, confidential and protected from disclosure.
If you are not the intended recipient, any dissemination, distribution,
or copying of this email message is strictly prohibited.
If you think that you have received this email message in error, please
email the sender at kyria...@netsmart.com.cy **
--- smsc_cimd2.c.original 2010-04-12 16:32:53.0 +0300
+++ smsc_cimd2.c2010-04-12 16:34:56.0 +0300
@@ -2088,12 +2088,14 @@
Octstr *destination = NULL;
Octstr *timestamp = NULL;
Octstr *statuscode = NULL;
+Octstr *statuserrorcode = NULL;
int st_code;
int code;
destination = packet_get_parm(request, P_DESTINATION_ADDRESS);
timestamp = packet_get_parm(request, P_MC_TIMESTAMP);
statuscode = packet_get_parm(request, P_STATUS_CODE);
+statuserrorcode = packet_get_parm(request, P_STATUS_ERROR_CODE);
st_code = atoi(octstr_get_cstr(statuscode));
@@ -2122,12 +2124,13 @@
if (msg) {
msg-sms.msgdata = packet_get_parm(request, P_USER_DATA);
if (!msg-sms.msgdata) {
-msg-sms.msgdata = statuscode;
-statuscode = NULL;
+msg-sms.msgdata = statuserrorcode;
+statuserrorcode = NULL;
}
}
octstr_destroy(statuscode);
+octstr_destroy(statuserrorcode);
octstr_destroy(destination);
octstr_destroy(timestamp);
Re: CIMD DLRs, reading field 062
I have taken this live and it seems to be working ok. Kyriacos On 12/04/2010 16:36, Kyriacos Sakkas wrote: This should be a bit better :) Kyriacos On 12/04/2010 16:26, Kyriacos Sakkas wrote: What do you think of this? I will try it, but wondering if anyone things this will not work. I know this is not a proper solution, but it should be OK. Kyriacos On 12/04/2010 16:01, Kyriacos Sakkas wrote: Hi All, This question has been posted before, but I have not seen any solutions. I need to receive CIMD2 field 062 in my DLR urls. None of the %* options seems to return it, even embedded in other info. As far as I understand the meta-data TLV system is SMPP only, and will not provide a solution. From my system %A returns field 061 and %d the SMPP? mapping/equivalent of field 061. Could some small change alter this so that %A returns 062 which is to my understanding closer to the extra error info returned in SMPP DLRs. Thanks in advance, Kyriacos Sakkas -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at kyria...@netsmart.com.cy **
Re: CIMD DLRs, reading field 062
Hi, Sorry for the cross-posting,, was looking at finding an existing solution, as well as comments on the diff. I should be able to comment better on stability and function on this patch tomorrow. Kyriacos On 12/04/2010 18:16, Nikos Balkanas wrote: Hi Kyriaco, Such issues are best addressed to devel group. Please do not x-post, people are sensitive here about keeping mail low. This is a change that affects only the CIMD2 driver. I see no problem with it, as long as the rest of the CIMD2 users agree with it. Personally I use only SMPP so I vote OK, but my vote shouldn't count :-) BR, Nikos - Original Message - From: Kyriacos Sakkas kyria...@netsmart.com.cy To: us...@kannel.org; Kannel Devel devel@kannel.org Sent: Monday, April 12, 2010 5:47 PM Subject: Re: CIMD DLRs, reading field 062 I have taken this live and it seems to be working ok. Kyriacos On 12/04/2010 16:36, Kyriacos Sakkas wrote: This should be a bit better :) Kyriacos On 12/04/2010 16:26, Kyriacos Sakkas wrote: What do you think of this? I will try it, but wondering if anyone things this will not work. I know this is not a proper solution, but it should be OK. Kyriacos On 12/04/2010 16:01, Kyriacos Sakkas wrote: Hi All, This question has been posted before, but I have not seen any solutions. I need to receive CIMD2 field 062 in my DLR urls. None of the %* options seems to return it, even embedded in other info. As far as I understand the meta-data TLV system is SMPP only, and will not provide a solution. From my system %A returns field 061 and %d the SMPP? mapping/equivalent of field 061. Could some small change alter this so that %A returns 062 which is to my understanding closer to the extra error info returned in SMPP DLRs. Thanks in advance, Kyriacos Sakkas -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at kyria...@netsmart.com.cy ** -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at kyria...@netsmart.com.cy **
Re: Kannel 1.4.2 out
Hi All, Nice to see a new stable coming out, especially with the meta-data included, probably have the longest running copy of that here, 180 days uptime (so even my meta-data is probably a bit out of date...). I have been considering doing a bit of a rewrite of the user docs, and this might be an opportunity for that. I will though need some feedback on a few changes made to the source code that are not represented in the current doc (on top of meta-data for which I know the details). I am aware of Stipe I believe doing some stilling changes to a few config parameters, switching from plural to singular and so on. Some of this I can probably track down, but anyone has a list of what their code changed with regards to what the users see, please post. Regards, Kyriacos Sakkas Nikos Balkanas wrote: That's the beauty of getting the release out. They might have doubts about the CVS, but they won't cancel a release because make check fails! :-) (Of course they might complain a lot!) BR, Nikos - Original Message - From: sangprabv sangpr...@gmail.com To: Nikos Balkanas nbalka...@gmail.com Cc: s...@tolj.org; Alejandro Guerrieri aguerri...@kannel.org; devel@kannel.org Sent: Friday, January 09, 2009 10:46 AM Subject: Re: Kannel 1.4.2 out Just a suggestion, make check script should be updated. Many users cancel to use CVS because they got errors when doing make check. TIA. Willy -Original Message- From: Nikos Balkanas nbalka...@gmail.com To: Nikos Balkanas nbalka...@gmail.com, s...@tolj.org, Alejandro Guerrieri aguerri...@kannel.org Cc: devel@kannel.org Subject: Re: Kannel 1.4.2 out Date: Fri, 9 Jan 2009 00:27:00 +0200 Mailer: Microsoft Outlook Express 6.00.2900.3138 Dear Stipe, I looked at 467 bugs with status New. Of those I filtered out alll refering to versions 1.4.1. (1.3.x - 1.4.0). And again I filtered out all bugs reported before 2006 - since a lot of entries lack product version, I assumed that anything submitted prior to 2006 cannot be 1.4.1 or cvs). I was left with 33 open bugs - of which 1 was commented as not reproducible. Therefore we are left with 32 Bugs. Of those 8 are minor, 19 major, 4 crashes and 1 block. I checked each one (crashes major) of those. I attach also csv. Aside from 418 that I have seen it many times, the others seem either not as important or easy to fix or Not blocking. What do you think? Crashes: 418: Seems general problem 3 people responded that any time SMSc connection is lost, Kannel doesn't send any more SMSs until bearerbox is restarted, at which point all messages in queue are lost (?). Latest submission 9/4/2008. 467: Make check fails. It is not the main application. Definitely not Crash status. Not Blocking 463: 1.4.1. User was able to solve by installing rpm instead of compiling from sources. Suspects incompatibility with Redhat EL 5 x86. Non blocking. 390: Bearerbox crashes when getting a lot os SMSs. Submitted 15/3/2007. If it was an issue we would have heard from a lot of others. Non blocking. 385:Memory leak in bearerbox when using sendsms script. Last submission on 22/2/2007. Many people use it with no such issues. Non blocking. Majors: 478: Same problem as 467. Make test fails on Redhat. Different user. Not blocking. 471: OMA problem with Nokia S60. wbxml compilation wrong. 14/10/2008 472: OMA problem. 17/10/2008. Same guy as before. Sends very large sms to smsc. Doesn't segment correctly. 462: WAP problem. Add support for application/vnd.wv.csp.wbxml MIME type. 13/6/2008 460: DLR problem. DLR msg_id gets munched up in 32bit Solaris. Even sends a 1-line patch. care to Look? 10/6/2008 359:Throttling doesn't work with SMPP. 24/7/2006. Somebody would have noticed. Not Blocking. 457: Same as 418. 13/5/2008 456: pdu decoding with udh and 7bit encoded sms has wrong length. Garbage in message. AT_smsc. Submits patch. 9/5/2008. I thought that Alex couldn't reproduce. Why still Open? Not Blocking 444: DLRs have wrong originator if SMS is buffered. 2/7/2008. Seems to me smsc issue. Not blocking. 437: Similar to 456. Corrupted pdu. AT_smsc. 23/1/2008 435: Init scripts have problems in Ubuntu. Offers easy solution. 22/1/2008 424: Incompatibility between kannel, PlaySMS and DLRs. Memory leak and crash. Someone would have noticed. 7/11/2007. Not blocking. 407: Umlaut problem. Answered by Alex. Please Close ticket. 403: Wapbox CPU 100%. Submitted on 7/6/2007. Someone would have noticed. Maybe race condition? Not blocking. 401: smsbox cannot fetch URL. Submitted 19/5/2007. Someone would have noticed if general. Not Blocking 388: sendsms problem. smsbox stalls after sending 2nd sms and waits forever. 24/2/2007. Someone would have noticed by now. Not Blocking. 384: Wrong charset when encoding DC_7BIT in smsbox. 25/3/2007. Someone would have noticed. Not Blocking. BR. Nikos - Original Message - From: Nikos Balkanas
Re: Segfault in Kannel meta-data (TLV) branch with certain DLR
Stipe Tolj wrote: Kyriacos Sakkas schrieb: This will happen, but I am holding off for a bit more, as meta-data was used to implement some new requirements, so I am waiting for a bit to make sure I am meeting those before making any further change. I will update when that happens. Hi, any change from our side? Or what is the waiting factor here? I didn't get the point I guess. :) Stipe 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. Kyriacos -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: [EMAIL PROTECTED] http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at [EMAIL PROTECTED] **
Re: Segfault in Kannel meta-data (TLV) branch with certain DLR
(gw_panic+0xdc) [0x808ae9c] 6455248:2008-01-22 12:56:25 [11220] [3] PANIC: /usr/local/sbin/smsbox [0x808b628] 6455322:2008-01-22 12:56:25 [11220] [3] PANIC: /usr/local/sbin/smsbox (octstr_destroy+0x26) [0x808dc46] 6455417:2008-01-22 12:56:25 [11220] [3] PANIC: /usr/local/sbin/smsbox [0x8059493] 6455491:2008-01-22 12:56:25 [11220] [3] PANIC: /usr/local/sbin/smsbox [0x8080b6e] 6455565:2008-01-22 12:56:25 [11220] [3] PANIC: /lib/tls/i686/cmov/ libpthread.so.0 [0xb7ed8240] 6455652:2008-01-22 12:56:25 [11220] [3] PANIC: /lib/tls/i686/cmov/ libc.so.6(__clone+0x5e) [0xb7d533de] Hope this is enough information to track down the bug! Unfortunately, I'm still not up to scratch with tracing execution in GDB, so I can't quite track down where those bad octstr_destroys are being called from :( Thanks, On 23/01/2008, at 9:42 PM, Kyriacos Sakkas wrote: Founf some PANIC lines is smsbox.log Kyriacos Sakkas wrote: My stability issues are in HTTP in both directions it would seem. I get no detailed error messages but it appears that smsbox dies after either forwarding more than 2-3 MOs to my app, or after it receives more than 2-3 MTs from my app. It then gets regenerated, but seems unable to talk properly to bearerbox. Unfortunately the logs show nearly nothing so I do not have something more detailed to share. Do you have another way of reading custom TLV values from DLR messages? The only thing I know that does it is the meta-data patches, and I need to have that functionality urgently, so for me there seems to be no other option, than to get it to work. Kyriacos -- Giulio Harding Systems Administrator m.Net Corporation Level 2, 8 Leigh Street Adelaide SA 5000, Australia Tel: +61 8 8210 2041 Fax: +61 8 8211 9620 Mobile: 0432 876 733 Yahoo: giulio.harding MSN: [EMAIL PROTECTED] http://www.mnetcorporation.com -- Thanks, Alexmdata-smsbox.diff -- Giulio Harding Systems Administrator m.Net Corporation Level 2, 8 Leigh Street Adelaide SA 5000, Australia Tel: +61 8 8210 2041 Fax: +61 8 8211 9620 Mobile: 0432 876 733 Yahoo: giulio.harding MSN: [EMAIL PROTECTED] http://www.mnetcorporation.com -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: [EMAIL PROTECTED] http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at [EMAIL PROTECTED] **
Re: Segfault in Kannel meta-data (TLV) branch with certain DLR
My stability issues are in HTTP in both directions it would seem. I get
no detailed error messages but it appears that smsbox dies after either
forwarding more than 2-3 MOs to my app, or after it receives more than
2-3 MTs from my app. It then gets regenerated, but seems unable to talk
properly to bearerbox. Unfortunately the logs show nearly nothing so I
do not have something more detailed to share.
Do you have another way of reading custom TLV values from DLR messages?
The only thing I know that does it is the meta-data patches, and I need
to have that functionality urgently, so for me there seems to be no
other option, than to get it to work.
Kyriacos
Giulio Harding wrote:
I've actually had to back out of using the meta-data Kannel, as we
spotted what looks to be a problem in the way Kannel handles carriage
return characters (ctrl-M) in synchronous responses to MO HTTP
requests - the carriage returns arrive at smsbox fine, but by the time
they leave the bearerbox in an SMPP PDU, they somehow end up actually
mangling the MT message body (text after the carriage returns is
missing, subsequent text segments overwrite the start of the message
body, etc.). Asynchronous MT HTTP requests aren't affected...
Not 100% sure whether it's a Kannel problem or something else
(site-specific) - I'll do a bit more investigation tomorrow morning
and get back to you ASAP.
What stability issues are you seeing? crashes/segfaults?
On 22/01/2008, at 11:20 PM, Kyriacos Sakkas wrote:
Hi Guys,
I got the meta-data branch and I am still getting a lot of stability
issues, although they all seem to have to do with the HTTP interface
rather than the patch. I am running on debian with stock amd64 kernels
but I understand that your production machine is 64bit anyway.
Gioulio are you using the meta-data branch, patched csv or something
else? If possible could we arrange for me to get the source files you
are using? (FTP access to one of my systems can be arranged of-list).
Kyriacos
PS. If you need some specific debugging info, please let me know what
(and if possible how) to get.
Giulio Harding wrote:
Just a followup on this, we've processed ~12000 MOs over SMPP this
morning, and there's been no further issues - thanks again Alex for
the prompt fix! :)
On 22/01/2008, at 2:21 AM, Giulio Harding wrote:
Thanks, looks good so far! I'll report back in a few hours after
traffic has picked up again, and let you know how the
patched-patched-Kannel is faring :)
Cheers,
On 22/01/2008, at 2:03 AM, Alexander Malysh wrote:
Hi,
you are right. Thanks!
Please try attached patch that combine fixes for both cases.
It's on top of clean smpp-tlv branch.
Giulio Harding wrote:
Also, it looks like there's 2 instances of the same typo, one at
1396, the other at 1460
the 2nd instance at line 1460, should it be something like this?
...
if (dlrmsg != NULL) {
if (dlrmsg-sms.meta_data == NULL)
dlrmsg-sms.meta_data = octstr_create();
meta_data_set_values(dlrmsg-sms.meta_data, pdu-
u.deliver_sm.tlv, smpp);
}
...
On 22/01/2008, at 1:32 AM, Kyriacos Sakkas wrote:
Hi,
There is some umbiquity in the patch. The new lines are inserted
lower from where the old lines are removed, and specificaly after
an IF
statement that would negate this code block:
if (dlrmsg != NULL) {
+if (dlrmsg-sms.meta_data == NULL)
This looks like an error in the diff output.
Kyriacos
Alexander Malysh wrote:
Hi,
thanks for very good bug report. Please try attached patch that
should fix:
1) typo ; 2) the case if dlr is not found in the storage.
Just apply it to smpp-tlv branch.
Giulio Harding wrote:
Ok, after a bit more perusing of the code, I think I found the
problem (line 1460 of gw/smsc/smsc_smpp.c):
...
/* got a deliver ack (DLR)?
* NOTE: following SMPP v3.4. spec. we are
interested
* only on bits 2-5 (some SMSC's send 0x44,
and it's
* spec. conforme)
*/
if (pdu-u.deliver_sm.esm_class (0x04|0x08)) {
debug(bb.sms.smpp,0,SMPP[%s] handle_pdu, got
DLR,
octstr_get_cstr(smpp-conn-id));
dlrmsg = handle_dlr(smpp, pdu-
u.deliver_sm.source_addr, pdu-u.deliver_sm.short_message, pdu-
u.deliver_sm.message_payload,
pdu-
u.deliver_sm.receipted_message_id, pdu-
u.deliver_sm.message_state);
if (dlrmsg-sms.meta_data == NULL)
dlrmsg-sms.meta_data = octstr_create();
meta_data_set_values(msg-sms.meta_data, pdu-
u.deliver_sm.tlv, smpp); /* --- should be
'dlrmsg-sms.meta_data' */
resp = smpp_pdu_create(deliver_sm_resp,
pdu
Re: Segfault in Kannel meta-data (TLV) branch with certain DLR
I re-compiled only difference was that is set with=debug, and now that
problem seems to have gone away. still I am at very low volumes.
Kyriacos
Also on submitting a message (MT) kannel no longer returns 0: Accepted
for delivery or anything else. I understand this may be unrelated
changes, but they are giving me some trouble.
Kyriacos Sakkas wrote:
Hi,
I compiled and I am running this and getting some very weird
behavior. After the first message is received the get-url is never
called for any subsequent messages, without any error messages. Outgoing
messages and DLRs look ok.
Kyriacos
Stipe Tolj wrote:
Alexander Malysh schrieb:
Hi,
you are right. Thanks!
Please try attached patch that combine fixes for both cases.
It's on top of clean smpp-tlv branch.
@Alex: Thanks! Instant resolving appritiated :)
+1, commited to CVS meta-data branch.
@Giulio, Kyriacos: please update your local CVS meta-data branch
checkouts and re-compile to verify it's stable in production.
From code review the segfault should be resolved now, since we ensure
we don't reference dlrmsg pointers without knowing we have anything to
reference.
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
---
--
Kyriacos Sakkas
Development Team
Netsmart
Tel: + 357 22 452565
Fax: + 357 22 452566
Email: [EMAIL PROTECTED]
http://www.netsmart.com.cy
Taking Business to a New Level!
** Confidentiality Notice: The information contained in this email
message may be privileged, confidential and protected from disclosure.
If you are not the intended recipient, any dissemination, distribution,
or copying of this email message is strictly prohibited.
If you think that you have received this email message in error, please
email the sender at [EMAIL PROTECTED] **
Re: Segfault in Kannel meta-data (TLV) branch with certain DLR
Hi Guys,
I got the meta-data branch and I am still getting a lot of stability
issues, although they all seem to have to do with the HTTP interface
rather than the patch. I am running on debian with stock amd64 kernels
but I understand that your production machine is 64bit anyway.
Gioulio are you using the meta-data branch, patched csv or something
else? If possible could we arrange for me to get the source files you
are using? (FTP access to one of my systems can be arranged of-list).
Kyriacos
PS. If you need some specific debugging info, please let me know what
(and if possible how) to get.
Giulio Harding wrote:
Just a followup on this, we've processed ~12000 MOs over SMPP this
morning, and there's been no further issues - thanks again Alex for
the prompt fix! :)
On 22/01/2008, at 2:21 AM, Giulio Harding wrote:
Thanks, looks good so far! I'll report back in a few hours after
traffic has picked up again, and let you know how the
patched-patched-Kannel is faring :)
Cheers,
On 22/01/2008, at 2:03 AM, Alexander Malysh wrote:
Hi,
you are right. Thanks!
Please try attached patch that combine fixes for both cases.
It's on top of clean smpp-tlv branch.
Giulio Harding wrote:
Also, it looks like there's 2 instances of the same typo, one at
1396, the other at 1460
the 2nd instance at line 1460, should it be something like this?
...
if (dlrmsg != NULL) {
if (dlrmsg-sms.meta_data == NULL)
dlrmsg-sms.meta_data = octstr_create();
meta_data_set_values(dlrmsg-sms.meta_data, pdu-
u.deliver_sm.tlv, smpp);
}
...
On 22/01/2008, at 1:32 AM, Kyriacos Sakkas wrote:
Hi,
There is some umbiquity in the patch. The new lines are inserted
lower from where the old lines are removed, and specificaly after
an IF
statement that would negate this code block:
if (dlrmsg != NULL) {
+if (dlrmsg-sms.meta_data == NULL)
This looks like an error in the diff output.
Kyriacos
Alexander Malysh wrote:
Hi,
thanks for very good bug report. Please try attached patch that
should fix:
1) typo ; 2) the case if dlr is not found in the storage.
Just apply it to smpp-tlv branch.
Giulio Harding wrote:
Ok, after a bit more perusing of the code, I think I found the
problem (line 1460 of gw/smsc/smsc_smpp.c):
...
/* got a deliver ack (DLR)?
* NOTE: following SMPP v3.4. spec. we are
interested
* only on bits 2-5 (some SMSC's send 0x44,
and it's
* spec. conforme)
*/
if (pdu-u.deliver_sm.esm_class (0x04|0x08)) {
debug(bb.sms.smpp,0,SMPP[%s] handle_pdu, got
DLR,
octstr_get_cstr(smpp-conn-id));
dlrmsg = handle_dlr(smpp, pdu-
u.deliver_sm.source_addr, pdu-u.deliver_sm.short_message, pdu-
u.deliver_sm.message_payload,
pdu-
u.deliver_sm.receipted_message_id, pdu-
u.deliver_sm.message_state);
if (dlrmsg-sms.meta_data == NULL)
dlrmsg-sms.meta_data = octstr_create();
meta_data_set_values(msg-sms.meta_data, pdu-
u.deliver_sm.tlv, smpp); /* --- should be
'dlrmsg-sms.meta_data' */
resp = smpp_pdu_create(deliver_sm_resp,
pdu-u.deliver_sm.sequence_number);
if (dlrmsg != NULL)
reason = bb_smscconn_receive(smpp-conn,
dlrmsg);
else
reason = SMSCCONN_SUCCESS;
resp-u.deliver_sm_resp.command_status =
smscconn_failure_reason_to_smpp_status(reason);
} else {/* MO-SMS */
...
I've changed that line (replaced 'msg' with 'dlrmsg') and rebuilt
Kannel - it seems to be working fine so far, but I'll need some
more
traffic to know for sure (it's late here, so traffic has dropped
off
a bit)
Can someone confirm this problem + fix?
Thanks,
On 21/01/2008, at 11:57 PM, Giulio Harding wrote:
I've been testing Alex's TLV patch with the meta-data branch, with
initial success (able to read and set mblox TLVs for US-specific
bind, as per Kyriacos's mblox TLV config - thanks for that!). It's
been performing perfectly on our test server, with a small number
of test binds, carrying test traffic.
However, when I decided to try deploying that build to production,
bearerbox would crash shortly after startup (after varying delay,
sometimes 1 second, sometimes 10 or so). It would segfault,
with no
indication in bearer.log (just a 'Connection closed by the
bearerbox' in smsbox.log) - the only indication was in /var/log/
messages, for example:
Jan 21 23:46:27 smsgw2 kernel: bearerbox[10180]: segfault at
0118 rip 0044c229 rsp 5ea30060 error 4
I initially thought it might be a 32
Re: Segfault in Kannel meta-data (TLV) branch with certain DLR
] DEBUG: validity_period: NULL 2008-01-21 23:59:28 [18588] [49] DEBUG: registered_delivery: 0 = 0x 2008-01-21 23:59:28 [18588] [49] DEBUG: replace_if_present_flag: 0 = 0x 2008-01-21 23:59:28 [18588] [49] DEBUG: data_coding: 0 = 0x 2008-01-21 23:59:28 [18588] [49] DEBUG: sm_default_msg_id: 0 = 0x 2008-01-21 23:59:28 [18588] [49] DEBUG: sm_length: 122 = 0x007a 2008-01-21 23:59:28 [18588] [49] DEBUG: short_message: 2008-01-21 23:59:28 [18588] [49] DEBUG:Octet string at 0x6be5f30: 2008-01-21 23:59:28 [18588] [49] DEBUG: len: 122 2008-01-21 23:59:28 [18588] [49] DEBUG: size: 123 2008-01-21 23:59:28 [18588] [49] DEBUG: immutable: 0 2008-01-21 23:59:28 [18588] [49] DEBUG: data: 69 64 3a 31 34 32 37 31 35 39 33 37 36 20 73 75 id:1427159376 su 2008-01-21 23:59:28 [18588] [49] DEBUG: data: 62 3a 30 30 31 20 64 6c 76 72 64 3a 30 30 31 20 b:001 dlvrd:001 2008-01-21 23:59:28 [18588] [49] DEBUG: data: 73 75 62 6d 69 74 20 64 61 74 65 3a 30 38 30 31 submit date:0801 2008-01-21 23:59:28 [18588] [49] DEBUG: data: 32 31 32 33 35 39 20 64 6f 6e 65 20 64 61 74 65 212359 done date 2008-01-21 23:59:28 [18588] [49] DEBUG: data: 3a 30 38 30 31 32 31 32 33 35 39 20 73 74 61 74 :0801212359 stat 2008-01-21 23:59:28 [18588] [49] DEBUG: data: 3a 44 45 4c 49 56 52 44 20 65 72 72 3a 30 30 30 :DELIVRD err:000 2008-01-21 23:59:28 [18588] [49] DEBUG: data: 20 74 65 78 74 3a 43 68 20 37 3a 20 54 68 6e 78text:Ch 7: Thnx 2008-01-21 23:59:28 [18588] [49] DEBUG: data: 20 34 20 65 6e 74 65 72 69 6e 4 enterin 2008-01-21 23:59:28 [18588] [49] DEBUG:Octet string dump ends. 2008-01-21 23:59:28 [18588] [49] DEBUG: SMPP PDU dump ends. 2008-01-21 23:59:28 [18588] [49] DEBUG: SMPP[optusfrmt] handle_pdu, got DLR 2008-01-21 23:59:28 [18588] [49] DEBUG: DLR[pgsql]: Looking for DLR smsc=optusfrmt, ts=1427159376, dst=, type=1 2008-01-21 23:59:28 [18588] [49] DEBUG: sql: SELECT mask, service, url, source, destination, boxc FROM dlr WHERE smsc='optusfrmt' AND ts='1427159376' LIMIT 1; 2008-01-21 23:59:28 [18588] [49] DEBUG: Found entry, col1=31, col2=apg, col3=http://apg:/dlr/kannel?i=44921898t=%Tc=%dm=% A, col4=19774777, col5= col6= 2008-01-21 23:59:28 [18588] [49] DEBUG: DLR[pgsql]: created DLR message for URL http://apg:/dlr/kannel?i=44921898t=%Tc=%dm=%A 2008-01-21 23:59:28 [18588] [49] DEBUG: removing DLR from database 2008-01-21 23:59:28 [18588] [49] DEBUG: sql: DELETE FROM dlr WHERE smsc='optusfrmt' AND ts='1427159376'; Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1577253216 (LWP 18639)] 0x0044ebc1 in handle_pdu (smpp=0x2a95c0e3d0, conn=0x6b4f8c0, pdu=0x6bcff60, pending_submits=0x5e02f0f0) at gw/smsc/ smsc_smpp.c:1460 1460meta_data_set_values(msg-sms.meta_data, pdu-u.deliver_sm.tlv, smpp); So, it seems the segfault is triggered by TLV handling for a certain kind of DLR? (We had DLRs coming in on our test binds, and that didn't cause a problem). I'm a complete GDB noob, so if there's anything else I can do to provide more information, please let me know. Any ideas why that meta_data_set_value function call would die with that DLR? Any assistance would be greatly appreciated! FYI, Kannel details are: Kannel bearerbox version `cvs-20071018'. Build `Jan 21 2008 23:52:11', compiler `3.4.6 20060404 (Red Hat 3.4.6-9)'. System Linux, release 2.6.9-55.0.2.ELsmp, version #1 SMP Tue Jun 26 14:14:47 EDT 2007, machine x86_64. Hostname smsgw2.appgw.mnetcorporation.com, IP 10.110.123.31. Libxml version 2.6.16. Using checking malloc. Thanks, -- Giulio Harding Systems Administrator m.Net Corporation Level 2, 8 Leigh Street Adelaide SA 5000, Australia Tel: +61 8 8210 2041 Fax: +61 8 8211 9620 Mobile: 0432 876 733 Yahoo: giulio.harding MSN: [EMAIL PROTECTED] http://www.mnetcorporation.com -- Giulio Harding Systems Administrator m.Net Corporation Level 2, 8 Leigh Street Adelaide SA 5000, Australia Tel: +61 8 8210 2041 Fax: +61 8 8211 9620 Mobile: 0432 876 733 Yahoo: giulio.harding MSN: [EMAIL PROTECTED] http://www.mnetcorporation.com -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: [EMAIL PROTECTED] http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at [EMAIL PROTECTED] **
Re: Segfault in Kannel meta-data (TLV) branch with certain DLR
:28 [18588] [49] DEBUG: validity_period: NULL 2008-01-21 23:59:28 [18588] [49] DEBUG: registered_delivery: 0 = 0x 2008-01-21 23:59:28 [18588] [49] DEBUG: replace_if_present_flag: 0 = 0x 2008-01-21 23:59:28 [18588] [49] DEBUG: data_coding: 0 = 0x 2008-01-21 23:59:28 [18588] [49] DEBUG: sm_default_msg_id: 0 = 0x 2008-01-21 23:59:28 [18588] [49] DEBUG: sm_length: 122 = 0x007a 2008-01-21 23:59:28 [18588] [49] DEBUG: short_message: 2008-01-21 23:59:28 [18588] [49] DEBUG:Octet string at 0x6be5f30: 2008-01-21 23:59:28 [18588] [49] DEBUG: len: 122 2008-01-21 23:59:28 [18588] [49] DEBUG: size: 123 2008-01-21 23:59:28 [18588] [49] DEBUG: immutable: 0 2008-01-21 23:59:28 [18588] [49] DEBUG: data: 69 64 3a 31 34 32 37 31 35 39 33 37 36 20 73 75 id:1427159376 su 2008-01-21 23:59:28 [18588] [49] DEBUG: data: 62 3a 30 30 31 20 64 6c 76 72 64 3a 30 30 31 20 b:001 dlvrd:001 2008-01-21 23:59:28 [18588] [49] DEBUG: data: 73 75 62 6d 69 74 20 64 61 74 65 3a 30 38 30 31 submit date:0801 2008-01-21 23:59:28 [18588] [49] DEBUG: data: 32 31 32 33 35 39 20 64 6f 6e 65 20 64 61 74 65 212359 done date 2008-01-21 23:59:28 [18588] [49] DEBUG: data: 3a 30 38 30 31 32 31 32 33 35 39 20 73 74 61 74 :0801212359 stat 2008-01-21 23:59:28 [18588] [49] DEBUG: data: 3a 44 45 4c 49 56 52 44 20 65 72 72 3a 30 30 30 :DELIVRD err:000 2008-01-21 23:59:28 [18588] [49] DEBUG: data: 20 74 65 78 74 3a 43 68 20 37 3a 20 54 68 6e 78text:Ch 7: Thnx 2008-01-21 23:59:28 [18588] [49] DEBUG: data: 20 34 20 65 6e 74 65 72 69 6e 4 enterin 2008-01-21 23:59:28 [18588] [49] DEBUG:Octet string dump ends. 2008-01-21 23:59:28 [18588] [49] DEBUG: SMPP PDU dump ends. 2008-01-21 23:59:28 [18588] [49] DEBUG: SMPP[optusfrmt] handle_pdu, got DLR 2008-01-21 23:59:28 [18588] [49] DEBUG: DLR[pgsql]: Looking for DLR smsc=optusfrmt, ts=1427159376, dst=, type=1 2008-01-21 23:59:28 [18588] [49] DEBUG: sql: SELECT mask, service, url, source, destination, boxc FROM dlr WHERE smsc='optusfrmt' AND ts='1427159376' LIMIT 1; 2008-01-21 23:59:28 [18588] [49] DEBUG: Found entry, col1=31, col2=apg, col3=http://apg:/dlr/kannel?i=44921898t=%Tc=%dm=% A, col4=19774777, col5= col6= 2008-01-21 23:59:28 [18588] [49] DEBUG: DLR[pgsql]: created DLR message for URL http://apg:/dlr/kannel?i=44921898t=%Tc=%dm=%A 2008-01-21 23:59:28 [18588] [49] DEBUG: removing DLR from database 2008-01-21 23:59:28 [18588] [49] DEBUG: sql: DELETE FROM dlr WHERE smsc='optusfrmt' AND ts='1427159376'; Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1577253216 (LWP 18639)] 0x0044ebc1 in handle_pdu (smpp=0x2a95c0e3d0, conn=0x6b4f8c0, pdu=0x6bcff60, pending_submits=0x5e02f0f0) at gw/smsc/ smsc_smpp.c:1460 1460meta_data_set_values(msg-sms.meta_data, pdu-u.deliver_sm.tlv, smpp); So, it seems the segfault is triggered by TLV handling for a certain kind of DLR? (We had DLRs coming in on our test binds, and that didn't cause a problem). I'm a complete GDB noob, so if there's anything else I can do to provide more information, please let me know. Any ideas why that meta_data_set_value function call would die with that DLR? Any assistance would be greatly appreciated! FYI, Kannel details are: Kannel bearerbox version `cvs-20071018'. Build `Jan 21 2008 23:52:11', compiler `3.4.6 20060404 (Red Hat 3.4.6-9)'. System Linux, release 2.6.9-55.0.2.ELsmp, version #1 SMP Tue Jun 26 14:14:47 EDT 2007, machine x86_64. Hostname smsgw2.appgw.mnetcorporation.com, IP 10.110.123.31. Libxml version 2.6.16. Using checking malloc. Thanks, -- Giulio Harding Systems Administrator m.Net Corporation Level 2, 8 Leigh Street Adelaide SA 5000, Australia Tel: +61 8 8210 2041 Fax: +61 8 8211 9620 Mobile: 0432 876 733 Yahoo: giulio.harding MSN: [EMAIL PROTECTED] http://www.mnetcorporation.com -- Giulio Harding Systems Administrator m.Net Corporation Level 2, 8 Leigh Street Adelaide SA 5000, Australia Tel: +61 8 8210 2041 Fax: +61 8 8211 9620 Mobile: 0432 876 733 Yahoo: giulio.harding MSN: [EMAIL PROTECTED] http://www.mnetcorporation.com -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: [EMAIL PROTECTED] http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at [EMAIL PROTECTED] **
Re: [PATCH] SMPP Optional Parameters
Hi Alexander, So us to be clear, me programing credential are not great, so I will give the backtrace a go, but if you thing some specials parameters to gdb would help, please let me know. Anyway the segfault is at run time, I will try and post a backtrace shortly. Kyriacos Sakkas Alexander Malysh wrote: Hi, the warnings while compile are OK. When kannel segfaults? when compile or starting kannel? If when starting kannel please provide backtrace. Kyriacos Sakkas wrote: Minus attachments. Kyriacos Sakkas wrote: Hi, Trying to compile against cvs, I segfault. Diring compile the only error is: gw/meta_data.c: In function âmeta_data_set_valueâ: gw/meta_data.c:338: warning: passing argument 2 of âdict_putâ discards qualifiers from pointer target type gw/meta_data.c:340: warning: passing argument 2 of âdict_putâ discards qualifiers from pointer target type gw/meta_data.c:341: warning: passing argument 2 of âdict_getâ discards qualifiers from pointer target type gw/meta_data.c:343: warning: passing argument 2 of âdict_putâ discards qualifiers from pointer target type gw/meta_data.c: In function âmeta_data_get_valueâ: gw/meta_data.c:368: warning: passing argument 2 of âdict_removeâ discards qualifiers from pointer target type -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: [EMAIL PROTECTED] http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at [EMAIL PROTECTED] **
Re: [PATCH] SMPP Optional Parameters
Hi, I just recompiled, and it looks stable, the difference was that up to now I had been using --with-mysql on the configure, which to be honest I did not need in this instance, just a force of habit. Anyway I will now test and if anything comes up I will let you know, but it does look like the problem lies there. As soon as I have some time I will try and dig a bit more into this. Kyriacos Alexander Malysh wrote: Hi, the warnings while compile are OK. When kannel segfaults? when compile or starting kannel? If when starting kannel please provide backtrace. Kyriacos Sakkas wrote: Minus attachments. Kyriacos Sakkas wrote: Hi, Trying to compile against cvs, I segfault. Diring compile the only error is: gw/meta_data.c: In function âmeta_data_set_valueâ: gw/meta_data.c:338: warning: passing argument 2 of âdict_putâ discards qualifiers from pointer target type gw/meta_data.c:340: warning: passing argument 2 of âdict_putâ discards qualifiers from pointer target type gw/meta_data.c:341: warning: passing argument 2 of âdict_getâ discards qualifiers from pointer target type gw/meta_data.c:343: warning: passing argument 2 of âdict_putâ discards qualifiers from pointer target type gw/meta_data.c: In function âmeta_data_get_valueâ: gw/meta_data.c:368: warning: passing argument 2 of âdict_removeâ discards qualifiers from pointer target type -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: [EMAIL PROTECTED] http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at [EMAIL PROTECTED] **
Re: [PATCH] SMPP Optional Parameters
-id=%istatus=%danswer=%Ato=%Pfrom=%pts=%to=%oI=%Its0=%Dts1=%vts2=%T 2007-11-26 15:58:14 [4930] [6] WARNING: smsbox_list empty! 2007-11-26 15:58:14 [4930] [4] WARNING: smsbox_list empty! 2007-11-26 15:58:14 [4930] [4] WARNING: smsbox_list empty! 2007-11-26 15:58:17 [4930] [6] DEBUG: SMPP[mblox28444]: Sending enquire link: 2007-11-26 15:58:17 [4930] [6] DEBUG: SMPP PDU 0x6804c0 dump: 2007-11-26 15:58:17 [4930] [6] DEBUG: type_name: enquire_link 2007-11-26 15:58:17 [4930] [6] DEBUG: command_id: 21 = 0x0015 2007-11-26 15:58:17 [4930] [6] DEBUG: command_status: 0 = 0x 2007-11-26 15:58:17 [4930] [6] DEBUG: sequence_number: 7 = 0x0007 2007-11-26 15:58:17 [4930] [6] DEBUG: SMPP PDU dump ends. 2007-11-26 15:58:17 [4930] [6] DEBUG: SMPP[mblox28444]: Got PDU: 2007-11-26 15:58:17 [4930] [6] DEBUG: SMPP PDU 0x6804c0 dump: 2007-11-26 15:58:17 [4930] [6] DEBUG: type_name: enquire_link_resp 2007-11-26 15:58:17 [4930] [6] DEBUG: command_id: 2147483669 = 0x8015 2007-11-26 15:58:17 [4930] [6] DEBUG: command_status: 0 = 0x 2007-11-26 15:58:17 [4930] [6] DEBUG: sequence_number: 7 = 0x0007 2007-11-26 15:58:17 [4930] [6] DEBUG: SMPP PDU dump ends. Kyriacos Sakkas wrote: Hi, I just recompiled, and it looks stable, the difference was that up to now I had been using --with-mysql on the configure, which to be honest I did not need in this instance, just a force of habit. Anyway I will now test and if anything comes up I will let you know, but it does look like the problem lies there. As soon as I have some time I will try and dig a bit more into this. Kyriacos Alexander Malysh wrote: Hi, the warnings while compile are OK. When kannel segfaults? when compile or starting kannel? If when starting kannel please provide backtrace. Kyriacos Sakkas wrote: Minus attachments. Kyriacos Sakkas wrote: Hi, Trying to compile against cvs, I segfault. Diring compile the only error is: gw/meta_data.c: In function âmeta_data_set_valueâ: gw/meta_data.c:338: warning: passing argument 2 of âdict_putâ discards qualifiers from pointer target type gw/meta_data.c:340: warning: passing argument 2 of âdict_putâ discards qualifiers from pointer target type gw/meta_data.c:341: warning: passing argument 2 of âdict_getâ discards qualifiers from pointer target type gw/meta_data.c:343: warning: passing argument 2 of âdict_putâ discards qualifiers from pointer target type gw/meta_data.c: In function âmeta_data_get_valueâ: gw/meta_data.c:368: warning: passing argument 2 of âdict_removeâ discards qualifiers from pointer target type -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: [EMAIL PROTECTED] http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at [EMAIL PROTECTED] ** 1.cap Description: Binary data
Re: [PATCH] SMPP Optional Parameters
Call: (Relevant values inserted of courser)
$post .= X-Kannel-Meta-Data:
?smpp-tlv?MBbilling=.$bill.MBoperator=.$operatorid.MBcontentType=100MBcommand=STARTMBsubDate=.date('U000').MBserviceId=XXX\r\n;
Definitions: (Had all as octstring, switched to nullterm for those with
no definite length)
group = smpp-tlv
name = MBoperator
tag = 0x1402
type = octetstring
length = 5
group = smpp-tlv
name = MBbilling
tag = 0x1403
type = octetstring
length = 5
group = smpp-tlv
name = MBsessionId
tag = 0x1404
type = nulterminated
length = 60
group = smpp-tlv
name = MBserviceDesc
tag = 0x1405
type = nulterminated
length = 10
group = smpp-tlv
name = MBcontentType
tag = 0x1406
type = nulterminated
length = 5
.
Alexander Malysh wrote:
Hi,
I suppose you didn't defined TLVs in the config and group in meta_data named
smpp instead of smpp-tlv. Example:
In the config
group = smpp-tlv
name = MBbilling
tag = 0x1601
type = integer|nulterminated|octetstring
length = 4
meta_data=?smpp?MBbilling=XXX...
Kyriacos Sakkas wrote:
If my packet capturing is correct, everything is parsed ok, but the TLVs
do not get added to the PDU.
Also my log file:
2007-11-26 15:58:08 [4930] [6] DEBUG: SMPP PDU 0x667eb0 dump:
2007-11-26 15:58:08 [4930] [6] DEBUG: type_name: enquire_link_resp
2007-11-26 15:58:08 [4930] [6] DEBUG: command_id: 2147483669 =
0x8015
2007-11-26 15:58:08 [4930] [6] DEBUG: command_status: 0 = 0x
2007-11-26 15:58:08 [4930] [6] DEBUG: sequence_number: 5 = 0x0005
2007-11-26 15:58:08 [4930] [6] DEBUG: SMPP PDU dump ends.
2007-11-26 15:58:13 [4930] [17] DEBUG: boxc_receiver: sms received
2007-11-26 15:58:13 [4930] [6] DEBUG: SMPP[mblox28444]: Manually forced
source addr ton = 3, source add npi = 9
2007-11-26 15:58:13 [4930] [6] DEBUG: SMPP[mblox28444]: Manually forced
dest addr ton = 1, dest add npi = 1
2007-11-26 15:58:13 [4930] [6] DEBUG: new group created `smpp-tlv'
2007-11-26 15:58:13 [4930] [6] DEBUG: group=`smpp-tlv' key=`MBbilling'
value=`sub'
2007-11-26 15:58:13 [4930] [6] DEBUG: group=`smpp-tlv' key=`MBoperator'
value=`31003'
2007-11-26 15:58:13 [4930] [6] DEBUG: group=`smpp-tlv'
key=`MBcontentType' value=`100'
2007-11-26 15:58:13 [4930] [6] DEBUG: group=`smpp-tlv' key=`MBcommand'
value=`START'
2007-11-26 15:58:13 [4930] [6] DEBUG: group=`smpp-tlv' key=`MBsubDate'
value=`1196085364000'
2007-11-26 15:58:13 [4930] [6] DEBUG: group=`smpp-tlv' key=`MBserviceId'
value=`'
2007-11-26 15:58:13 [4930] [6] DEBUG: SMPP[mblox28444]: Sending PDU:
2007-11-26 15:58:13 [4930] [6] DEBUG: SMPP PDU 0x6804c0 dump:
2007-11-26 15:58:13 [4930] [6] DEBUG: type_name: submit_sm
2007-11-26 15:58:13 [4930] [6] DEBUG: command_id: 4 = 0x0004
2007-11-26 15:58:13 [4930] [6] DEBUG: command_status: 0 = 0x
2007-11-26 15:58:13 [4930] [6] DEBUG: sequence_number: 6 = 0x0006
2007-11-26 15:58:13 [4930] [6] DEBUG: service_type: NULL
2007-11-26 15:58:13 [4930] [6] DEBUG: source_addr_ton: 3 = 0x0003
2007-11-26 15:58:13 [4930] [6] DEBUG: source_addr_npi: 9 = 0x0009
2007-11-26 15:58:13 [4930] [6] DEBUG: source_addr: 28444
2007-11-26 15:58:13 [4930] [6] DEBUG: dest_addr_ton: 1 = 0x0001
2007-11-26 15:58:13 [4930] [6] DEBUG: dest_addr_npi: 1 = 0x0001
2007-11-26 15:58:13 [4930] [6] DEBUG: destination_addr: 1X
2007-11-26 15:58:13 [4930] [6] DEBUG: esm_class: 3 = 0x0003
2007-11-26 15:58:13 [4930] [6] DEBUG: protocol_id: 0 = 0x
2007-11-26 15:58:13 [4930] [6] DEBUG: priority_flag: 0 = 0x
2007-11-26 15:58:13 [4930] [6] DEBUG: schedule_delivery_time: NULL
2007-11-26 15:58:13 [4930] [6] DEBUG: validity_period: NULL
2007-11-26 15:58:13 [4930] [6] DEBUG: registered_delivery: 1 =
0x0001
2007-11-26 15:58:13 [4930] [6] DEBUG: replace_if_present_flag: 0 =
0x
2007-11-26 15:58:13 [4930] [6] DEBUG: data_coding: 0 = 0x
2007-11-26 15:58:13 [4930] [6] DEBUG: sm_default_msg_id: 0 = 0x
2007-11-26 15:58:13 [4930] [6] DEBUG: sm_length: 8 = 0x0008
2007-11-26 15:58:13 [4930] [6] DEBUG: short_message: CONTENT0
2007-11-26 15:58:13 [4930] [6] DEBUG: SMPP PDU dump ends.
2007-11-26 15:58:13 [4930] [17] DEBUG: send_msg: sending msg to boxc:
smsc4
2007-11-26 15:58:13 [4930] [17] ERROR: Error reading from fd 46:
2007-11-26 15:58:13 [4930] [17] ERROR: System error 104: Connection
reset by peer
2007-11-26 15:58:13 [4930] [17] ERROR: Connection to box 127.0.0.1
broke. 2007-11-26 15:58:13 [4930] [18] DEBUG: send_msg: sending msg to
boxc: smsc4
2007-11-26 15:58:13 [4930] [18] ERROR: Error writing 16 octets to fd 46:
2007-11-26 15:58:13 [4930] [18] ERROR: System error 32: Broken pipe
2007-11-26 15:58:13 [4930] [18] ERROR: Couldn't write Msg to box
127.0.0.1, disconnecting
2007-11-26 15:58:13 [4930] [18] DEBUG: Thread 18
(gw/bb_boxc.c:boxc_sender) terminates.
2007-11-26 15:58:13 [4930] [17] ERROR: Error writing 16 octets to fd 46:
2007-11-26
Re: [PATCH] SMPP Optional Parameters
reset by peer
2007-11-26 16:47:37 [5137] [19] ERROR: Connection to box 127.0.0.1 broke.
2007-11-26 16:47:37 [5137] [20] DEBUG: send_msg: sending msg to boxc:
smsc4
2007-11-26 16:47:37 [5137] [20] ERROR: Error writing 16 octets to fd 46:
2007-11-26 16:47:37 [5137] [20] ERROR: System error 32: Broken pipe
2007-11-26 16:47:37 [5137] [20] ERROR: Couldn't write Msg to box
127.0.0.1, disconnecting
2007-11-26 16:47:37 [5137] [20] DEBUG: Thread 20
(gw/bb_boxc.c:boxc_sender) terminates.
2007-11-26 16:47:37 [5137] [19] ERROR: Error writing 16 octets to fd 46:
2007-11-26 16:47:37 [5137] [19] ERROR: System error 32: Broken pipe
2007-11-26 16:47:37 [5137] [19] DEBUG: Thread 19 (gw/bb_boxc.c:function)
terminates.
2007-11-26 16:47:37 [5137] [5] INFO: Client connected from 127.0.0.1
2007-11-26 16:47:37 [5137] [5] DEBUG: Started thread 21
(gw/bb_boxc.c:function)
2007-11-26 16:47:37 [5137] [21] DEBUG: Thread 21 (gw/bb_boxc.c:function)
maps to pid 5137.
2007-11-26 16:47:37 [5137] [21] DEBUG: Started thread 22
(gw/bb_boxc.c:boxc_sender)
2007-11-26 16:47:37 [5137] [22] DEBUG: Thread 22
(gw/bb_boxc.c:boxc_sender) maps to pid 5137.
2007-11-26 16:47:37 [5137] [21] DEBUG: boxc_receiver: got boxc_id
smsc4 from 127.0.0.1
2007-11-26 16:47:37 [5137] [6] WARNING: SMPP: PDU NULL terminated string
(message_id) has no NULL.
2007-11-26 16:47:37 [5137] [6] DEBUG: SMPP[mblox28444]: Got PDU:
2007-11-26 16:47:37 [5137] [6] DEBUG: SMPP PDU 0x668640 dump:
2007-11-26 16:47:37 [5137] [6] DEBUG: type_name: submit_sm_resp
2007-11-26 16:47:37 [5137] [6] DEBUG: command_id: 2147483652 = 0x8004
2007-11-26 16:47:37 [5137] [6] DEBUG: command_status: 1077 = 0x0435
2007-11-26 16:47:37 [5137] [6] DEBUG: sequence_number: 11 = 0x000b
2007-11-26 16:47:37 [5137] [6] DEBUG: message_id: NULL
2007-11-26 16:47:37 [5137] [6] DEBUG: SMPP PDU dump ends.
2007-11-26 16:47:37 [5137] [6] ERROR: SMPP[mblox28444]: SMSC returned
error code 0x0435 (Vendor-specific error, please refer to your SMPP
provider) in response to submit_sm.
2007-11-26 16:47:37 [5137] [6] DEBUG: SMSC[mblox28444]: creating DLR message
2007-11-26 16:47:37 [5137] [6] DEBUG: SMSC[mblox28444]: DLR =
http://10.10.3.23:8111/dlrT.php?smsc-id=%istatus=%danswer=%Ato=%Pfrom=%pts=%to=%oI=%Its0=%Dts1=%vts2=%T
2007-11-26 16:47:37 [5137] [22] DEBUG: send_msg: sending msg to boxc:
smsc4
2007-11-26 16:47:37 [5137] [22] DEBUG: boxc_sender: sent message to
127.0.0.1
2007-11-26 16:47:37 [5137] [21] DEBUG: boxc_receiver: got ack
2007-11-26 16:47:43 [5137] [6] DEBUG: SMPP[mblox28444]: Sending enquire
link:
2007-11-26 16:47:43 [5137] [6] DEBUG: SMPP PDU 0x668640 dump:
2007-11-26 16:47:43 [5137] [6] DEBUG: type_name: enquire_link
2007-11-26 16:47:43 [5137] [6] DEBUG: command_id: 21 = 0x0015
2007-11-26 16:47:43 [5137] [6] DEBUG: command_status: 0 = 0x
2007-11-26 16:47:43 [5137] [6] DEBUG: sequence_number: 12 = 0x000c
2007-11-26 16:47:43 [5137] [6] DEBUG: SMPP PDU dump ends.
2007-11-26 16:48:37 [5137] [5] INFO: Client connected from 127.0.0.1
2007-11-26 16:48:37 [5137] [5] DEBUG: Started thread 23
(gw/bb_boxc.c:function)
2007-11-26 16:48:37 [5137] [23] DEBUG: Thread 23 (gw/bb_boxc.c:function)
maps to pid 5137.
2007-11-26 16:48:37 [5137] [23] DEBUG: Started thread 24
(gw/bb_boxc.c:boxc_sender)
2007-11-26 16:48:37 [5137] [23] DEBUG: boxc_receiver: got boxc_id
smsc4 from 127.0.0.1
2007-11-26 16:48:37 [5137] [24] DEBUG: Thread 24
(gw/bb_boxc.c:boxc_sender) maps to pid 5137.
2007-11-26 16:48:37 [5137] [24] DEBUG: send_msg: sending msg to boxc:
smsc4
2007-11-26 16:48:37 [5137] [24] DEBUG: boxc_sender: sent message to
127.0.0.1
2007-11-26 16:48:37 [5137] [23] DEBUG: boxc_receiver: got ack
2007-11-26 16:48:43 [5137] [6] DEBUG: SMPP[mblox28444]: Sending enquire
link:
Alexander Malysh wrote:
Please read carefully :)
Kyriacos Sakkas wrote:
Call: (Relevant values inserted of courser)
$post .= X-Kannel-Meta-Data:
?smpp-tlv?MBbilling=.$bill.MBoperator=.
^^ group should be ?smpp? instead if ?smpp-tlv?
$operatorid.MBcontentType=100MBcommand=STARTMBsubDate=.date('U000').MBserviceId=XXX\r\n;
Definitions: (Had all as octstring, switched to nullterm for those with
no definite length)
group = smpp-tlv
name = MBoperator
tag = 0x1402
type = octetstring
length = 5
group = smpp-tlv
name = MBbilling
tag = 0x1403
type = octetstring
length = 5
group = smpp-tlv
name = MBsessionId
tag = 0x1404
type = nulterminated
length = 60
group = smpp-tlv
name = MBserviceDesc
tag = 0x1405
type = nulterminated
length = 10
group = smpp-tlv
name = MBcontentType
tag = 0x1406
type = nulterminated
length = 5
.
Alexander Malysh wrote:
Hi,
I suppose you didn't defined TLVs in the config and group in meta_data
named smpp instead of smpp-tlv. Example:
In the config
group = smpp-tlv
name = MBbilling
tag = 0x1601
type = integer|nulterminated|octetstring
length = 4
meta_data=?smpp?MBbilling=XXX...
Kyriacos Sakkas wrote
SMPP Optional Parameters + MBLOX TLVs
Hi All,
Here is what seems to be a working setup for Mblox using Alexanders
patch. Patch applied to current CVS, no extra options enabled (if I
enable mysql, I get a segfault, YMMV)
I am currently in a testing phase with Mblox and will post any changes
that might come from that, but the following seem to work. Adjust as you
see fit:
I know we are all being pushed to implement all their recent changes,
and this patch seems the best way of keeping up
kannel.conf:
group = smpp-tlv
name = MBoperator
tag = 0x1402
type = octetstring
length = 5
group = smpp-tlv
name = MBbilling
tag = 0x1403
type = octetstring
length = 5
group = smpp-tlv
name = MBsessionId
tag = 0x1404
type = octetstring
length = 60
group = smpp-tlv
name = MBserviceDesc
tag = 0x1405
type = octetstring
length = 10
group = smpp-tlv
name = MBcontentType
tag = 0x1406
type = octetstring
length = 5
group = smpp-tlv
name = MBserviceId
tag = 0x1407
type = octetstring
length = 60
group = smpp-tlv
name = MBimei
tag = 0x1501
type = octetstring
length = 5
group = smpp-tlv
name = MBimode
tag = 0x1502
type = octetstring
length = 5
group = smpp-tlv
name = MBsubId
tag = 0x1503
type = octetstring
length = 60
group = smpp-tlv
name = MBhostNet
tag = 0x1504
type = octetstring
length = 5
group = smpp-tlv
name = MBnewSub
tag = 0x1505
type = octetstring
length = 5
group = smpp-tlv
name = MBsubRef
tag = 0x1506
type = octetstring
length = 60
group = smpp-tlv
name = MBsubDateTag
tag = 0x1509
type = octetstring
length = 60
group = smpp-tlv
name = MBuaProfTag
tag = 0x1513
type = octetstring
length = 60
group = smpp-tlv
name = MBbillId
tag = 0x1519
type = octetstring
length = 60
group = smpp-tlv
name = MBsessionIdTag
tag = 0x1521
type = octetstring
length = 60
group = smpp-tlv
name = MBreasonCode
tag = 0x1522
type = octetstring
length = 60
group = smpp-tlv
name = MBreasonMsg
tag = 0x1523
type = octetstring
length = 60
group = smpp-tlv
name = MBcommand
tag = 0x1524
type = octetstring
length = 60
group = smpp-tlv
name = MBavStatus
tag = 0x1526
type = octetstring
length = 60
group = smpp-tlv
name = MBprodDesc
tag = 0x1527
type = octetstring
length = 60
Sending (PHP - X-Kannel-Headers,basic and slightly dirty):
$post = POST /cgi-bin/sendsms HTTP/1.1\r\n.
Host: X.X.X.X:\r\n.
X-Kannel-Username: test\r\n.
X-Kannel-Password: test\r\n.
X-Kannel-SMSC: .$smsc.\r\n.
X-Kannel-Smsbox-Id: .$box.\r\n.
X-Kannel-From: .$from.\r\n.
X-Kannel-To: .$MSISDN.\r\n;
$post .= X-Kannel-DLR-Mask: 31\r\n.
X-Kannel-DLR-Url:
http://X.X.X.X:/dlr.php?smsc-id=%istatus=%danswer=%Ato=%Pfrom=%pts=%to=%oI=%Its0=%D\r\n;;
$post .= X-Kannel-Meta-Data:
?smpp?MBbilling=.$bill.MBoperator=.$operatorid.MBx=x...\r\n;
$post .='Content-Type: text/plain'.\r\n.
Content-Length: .strlen($text).\r\n.
\r\n.
$text;
$h=fsockopen('X.X.X.X','');
stream_set_timeout($h, 1);
fwrite($h,$post);
for($a=0,$r='';!$a;){
$b=fread($h,1024);
$r.=$b;
$a=(($b=='')?1:0);
}
fclose($h);
$c=$c+1;
--
Kyriacos Sakkas
Development Team
Netsmart
Tel: + 357 22 452565
Fax: + 357 22 452566
Email: [EMAIL PROTECTED]
http://www.netsmart.com.cy
Taking Business to a New Level!
** Confidentiality Notice: The information contained in this email
message may be privileged, confidential and protected from disclosure.
If you are not the intended recipient, any dissemination, distribution,
or copying of this email message is strictly prohibited.
If you think that you have received this email message in error, please
email the sender at [EMAIL PROTECTED] **
Re: DLR TLVs
Hi Juan, Well aware of the patch, unfortunately I get a segfault when I compile with it... Kyriacos Sakkas Juan Nin wrote: Hi Kyriacos! Alexander Malysh created an SMPP Optional Parameters patch. You have already participated on that thread: http://www.nabble.com/-PATCH--SMPP-Optional-Parameters-t4223169.html The other day I tested it, and found that nothing came back with %D I sent e-mail to the devel list, and Alexander replied that he had missed something and sent a new patch very quick, which you'll find on that thread: meta_data.diff.gz With that new patch, you can receive your meta-data back on %D Now, it only gets vendor specific TLVs. In my case I also need to get info from some SMPP specs defined TLVs, which don't come with %D. Alexander said the patch could be expanded to do so, and that he would try to look at it on his spare time. Alexander, did you have any chance to look at this? Thanks again!!! :) Juan On Nov 13, 2007 8:00 AM, Kyriacos Sakkas [EMAIL PROTECTED] wrote: Hi All, I am looking for a way to extract a specific TLV from a DLR message. Where are the %escapes defined for the DLR URL? Kyriacos -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: [EMAIL PROTECTED] http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at [EMAIL PROTECTED] ** -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: [EMAIL PROTECTED] http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at [EMAIL PROTECTED] **
DLR TLVs
Hi All, I am looking for a way to extract a specific TLV from a DLR message. Where are the %escapes defined for the DLR URL? Kyriacos -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: [EMAIL PROTECTED] http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at [EMAIL PROTECTED] **
Re: [PATCH] SMPP Optional Parameters
Hi, Anybody has some extra info on how to us with post? (X-Kannel-Meta-Data). I am trying but not able it seems to get the proper format. Would this be considered ok? X-Kannel-Meta-Data: ?smpp?mytag=12 Definition is: group = smpp-tlv name = mytag tag = 0x1521 type = octetstring length = 32 Thanks, Kyriacos Alexander Malysh wrote: Hello all, as promised I rebased my SMPP TLV patch and post is here for review. Please anybody if possible, write a userguide because I don't have time to do it and without userguide this patch will not get into mainline. Short description... In the config group = smpp-tlv name = some-name tag = 0x1601 type = integer|nulterminated|octetstring length = 4 In the msg struct I added meta_data field that can contain any parameters not only for smpp. meta_data is formated as follows: meta_data = ?group?key=valuekey1=value1?smpp?some-name=ABC then SMPP module just set all TLVs that can be found in the smpp group of meta_data. With this approach it's possible to use this generic interface to put some extra functionality into any SMSC module. Example sendsms url: lynx -source -dump 'http://localhost:13013/cgi-bin/sendsms?username=testerpassword=foobarto=123from=456text=textmeta-data=%3Fsmpp%3Fsome-name%3D123' Example MO url: http://localhost:123/bla/...meta-data=%D;... or with Post: X-Kannel-Meta-Data or with xml: meta-datax/meta-data Please test it and let me know how it works. P.S. I don't like how smpp_pdu_init and smpp_pdu_shutdown functions called. They called from bb_smscconn.c but I have not found a better place to call these. This may change in future ;) -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: [EMAIL PROTECTED] http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at [EMAIL PROTECTED] **
kannel cvs (got it today) compiling but not running properly
Hi All, Got kannel of cvs today, trying to run it on a new machine but no go. I believe its most likely due to this box being set up as 64bit, but since I am not really a programmer, I would appreciate help in any parameters needed to force compilation/linking with the 32 bit libraries. (Debian etch) uname-a Linux smsdev 2.6.18-5-amd64 #1 SMP Thu Aug 30 01:14:54 UTC 2007 x86_64 GNU/Linux When I get kannel off the debian repositories that runs fine. When I compile and start I only get this: kannel 23099 1 0 10:41 ?00:00:00 /usr/local/sbin/run_kannel_box --pidfile /var/run/kannel/kannel_bearerbox.pid --no-extra-args /usr/local/sbin/ kannel 23104 1 0 10:41 ?00:00:00 /usr/local/sbin/run_kannel_box --pidfile /var/run/kannel/kannel_wapbox.pid --no-extra-args /usr/local/sbin/wap kannel 23109 1 0 10:41 ?00:00:00 /usr/local/sbin/run_kannel_box --pidfile /var/run/kannel/kannel_smsbox.pid --no-extra-args /usr/local/sbin/sms and after that silence. The actual boxes seem never to get called. if I exec the bearerbox directly I get: /usr/local/sbin/bearerbox -v 4 -- /etc/kannel/kannel.conf 2007-10-23 10:47:05 [23156] [0] PANIC: Couldn't read configuration from `/etc/kannel/kannel.conf'. 2007-10-23 10:47:05 [23156] [0] PANIC: /usr/local/sbin/bearerbox(gw_panic+0x15a) [0x4775da] 2007-10-23 10:47:05 [23156] [0] PANIC: /usr/local/sbin/bearerbox(main+0xa91) [0x40d611] 2007-10-23 10:47:05 [23156] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xda) [0x2ba34f7d34ca] 2007-10-23 10:47:05 [23156] [0] PANIC: /usr/local/sbin/bearerbox [0x40beba] Similar results for other boxes But kannel.conf is there, and to me at least looks OK: === group = core admin-port = 13010 admin-password = test status-password = test admin-deny-ip = *.*.*.* admin-allow-ip = 127.0.0.1;10.10.*.* wapbox-port = 13014 smsbox-port = 13013 wdp-interface-name = * log-file = /var/log/kannel/bearerbox.log log-level = 0 box-deny-ip = *.*.*.* box-allow-ip = 127.0.0.1;10.10.*.* group = wapbox bearerbox-host = localhost log-file = /var/log/kannel/wapbox.log log-level = 0 group = ppg ppg-url = /wappush ppg-port = 8383 concurrent-pushes = 100 users = 1024 trusted-pi= true service-name = ppg2 ppg-smsbox-id = smsc4 group = wap-push-user wap-push-user = wappush ppg-username= foo ppg-password= bar group = smsbox sendsms-port = 8181 smsbox-id = smsc4 mo-recode = true log-file = /var/log/kannel/smsbox.log log-level = 0 group = smsbox-route smsbox-id = smsc4 smsc-ids = mblox28444 group = smsc smsc= smpp smsc-id = TEST throughput = 3 host= smpp.host port= transceiver-mode= true smsc-username = user smsc-password = pass system-type = type unified-prefix = +1,001;+1,1 interface-version = 34 address-range = source-addr-ton = 3 source-addr-npi = 9 source-addr-autodetect = false dest-addr-ton = 1 dest-addr-npi = 1 enquire-link-interval = 10 reconnect-delay = 10 msg-id-type = 0x01 alt-charset = ISO_8859-1 group = sms-service keyword = default get-url = http://10.10.3.23:8111/MOT.php?body=%aopid=%mtime=%tMSISDN=%precipient=%Pcing=%Fzz=%D; accept-x-kannel-headers = true max-messages= 0 concatenation = false accepted-smsc = TEST omit-empty = true group = sendsms-user name = Test Vroup username = test2 password = test2 concatenation = true group = sendsms-user name = Test Froup username = test password = test max-messages = 3 concatenation = true -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: [EMAIL PROTECTED] http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at [EMAIL PROTECTED] **
Re: [PATCH] SMPP Optional Parameters
Hi, If this is known to somebody, please tell: Will this patch work for capturing optional parameters presend in DLR messages ? That is can I use meta-data=%D in my DLR-URL? Thanks, Kyriacos Sakkas Alexander Malysh wrote: Hi, any progress on testing and userguide :)? Alejandro Guerrieri wrote: So far I've tested the sendsms - SMSC portion using Logica SMSC simulator and it works like a charm! Great job Alex! I've also made a patch for Sqlbox-standalone (already sent to dev list). I'll test the SMSC - Kannel portion as soon as I can get a hand on a SMSC and/or Simulator capable of sending TLV's (Logica cannot AFAIK, just displays the raw bytes when TLV's are received). We're just missing the userguide docs (coming after completing the tests). Regards, Alejandro On 8/6/07, Alexander Malysh [EMAIL PROTECTED] wrote: Hello all, as promised I rebased my SMPP TLV patch and post is here for review. Please anybody if possible, write a userguide because I don't have time to do it and without userguide this patch will not get into mainline. Short description... In the config group = smpp-tlv name = some-name tag = 0x1601 type = integer|nulterminated|octetstring length = 4 In the msg struct I added meta_data field that can contain any parameters not only for smpp. meta_data is formated as follows: meta_data = ?group?key=valuekey1=value1?smpp?some-name=ABC then SMPP module just set all TLVs that can be found in the smpp group of meta_data. With this approach it's possible to use this generic interface to put some extra functionality into any SMSC module. Example sendsms url: lynx -source -dump 'http://localhost:13013/cgi-bin/sendsms?username=testerpassword=foobarto=123from=456text=textmeta-data=%3Fsmpp%3Fsome-name%3D123' Example MO url: http://localhost:123/bla/...meta-data=%D;... or with Post: X-Kannel-Meta-Data or with xml: meta-datax/meta-data Please test it and let me know how it works. P.S. I don't like how smpp_pdu_init and smpp_pdu_shutdown functions called. They called from bb_smscconn.c but I have not found a better place to call these. This may change in future ;) -- Thanks, Alex -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: [EMAIL PROTECTED] http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at [EMAIL PROTECTED] **
Mblox and SRM
Anyone have a version that incorporates all the latest mblox additional parameters ? I have tried patching locally, but getting some funny errors. Kyriacos Sakkas -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: [EMAIL PROTECTED] http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at [EMAIL PROTECTED] **
Re: CIMD 2.0 Greek
On 07/07/2006 15:04, Stipe Tolj wrote: Thanos Chatziathanassiou wrote: Stipe Tolj wrote: Thanos Chatziathanassiou wrote: patch sniped this patch is works if you punch in the greek values of GSM 03.38 alphabet in there. But remember(!), they are not part of ISO-8859-1 (latin1), they are part of latin7. So this patch is a kludge. Yes, it is...but then again so is GSM 03.38 :) We obviously loose characters (those marked with '?') when mapping from GSM default alphabet to latin1. We should use UTF-8 (unicode) instead?! We could, but we'd be giving up on 160-chars-long SMS. Besides, some (admittedly old) devices don't handle utf8 all too well... If I understand correctly, your problem is that this isn't ``gsm_to_latin1'' any more. Maybe we could translate to/from iso-8859-7 for these chars. i.e. 0x10 would become 0xC4 which is greek capital delta on iso-8859-7. Thing is, my end application (and probably Kyriakos' too) was already prepared to handle this, so I simply didn't bother. If we're talking about integrating it properly to kannel, I think that's the best way to go. Maybe even have it as a configuration option. That would only leave a problem with the Euro sign (double-byte 0x1B 0x65). Thoughts ? [I'll move this thread to devel@ list, since it's more appropriate there] yep, correct. This should be configurable. Actually we do may gsm_to_latin1() already _inside_ the smsc modules. Which seems wrong to me. We should exit the smsc-specific layer with GSM default charset, and allow the user to change the exit charset encoding in the abstaction layer. Which would mean this has to be done only in one global place for all smsc modules. Alex, your thoughts on this? Others? Stipe This was my expected behavior, that is I expected kannel to pass me the characters as they came (GSM ascii / UTF-8 etc) and then my application to convert to whatever it requires and in essence that is what Thanos patch does. My application had the code to do this already in place, and confused the hell out of me when I only got question marks. This seems the most sensible approach and the only other one I can see as working globally, is default converting to UTF-8 of all incoming (from smsc to kannel) messages before handing them to an external application/module. For me it would seem simpler to leave the recoding of GSM ascii to each users external application rather than in kannel, but I guess having a configurable kannel module to do it would be handy for those folks that do their keyword matching entirely inside kannel and would like to match non latin1 characters as well. -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: [EMAIL PROTECTED] http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at [EMAIL PROTECTED] **
