smppbox code questions

Nikos Balkanas nbalkanas at gmail.com
Tue Jul 13 01:33:46 CEST 2010


Hi,

Could you change it to:

version = octstr_format("smppbox version %s, kannel", GW_VERSION);

until it is patched?

BR,
Nikos

----- Original Message ----- 
From: "Nikos Balkanas" <nbalkanas at gmail.com>
To: "Rene Kluwen" <rene.kluwen at chimit.nl>; "'Victor Luchitz'" 
<vluchits at gmail.com>; <devel at kannel.org>
Sent: Tuesday, July 13, 2010 1:40 AM
Subject: Re: smppbox code questions


> As anticipated this is wrong and can be confusing to users.
>
> BR,
> Nikos
> ----- Original Message ----- 
> From: "Rene Kluwen" <rene.kluwen at chimit.nl>
> To: "'Rene Kluwen'" <rene.kluwen at chimit.nl>; "'Nikos Balkanas'" 
> <nbalkanas at gmail.com>; "'Victor Luchitz'" <vluchits at gmail.com>; 
> <devel at kannel.org>
> Sent: Monday, July 12, 2010 6:48 PM
> Subject: RE: smppbox code questions
>
>
>>I added the file VERSION.
>> Also I changed the gw/smppbox.c and I think I have a workaround.
>>
>> Now report_versions() says:
>>
>> 2010-07-12 17:47:35 [25289] [0] INFO: Debug_lvl = -1, log_file = <none>,
>> log_lvl = 0
>> 2010-07-12 17:47:35 [25289] [0] DEBUG: Kannel smppbox version svn-r20:21M
>> version `svn-r4833'.
>>
>> It is not ideal. But it works. Maybe I should send a patch for gwlib.
>>
>> Alex: Let me know if I should do the same for sqlbox.
>>
>> == Rene
>>
>>
>> Index: gw/smppbox.c
>> ===================================================================
>> --- gw/smppbox.c        (revision 21)
>> +++ gw/smppbox.c        (working copy)
>> @@ -79,6 +79,10 @@
>> #include "gw/heartbeat.h"
>> #include "gw/meta_data.h"
>>
>> +#undef GW_NAME
>> +#undef GW_VERSION
>> +#include "../sb-config.h"
>> +
>> /* our config */
>> static Cfg *cfg;
>> /* have we received restart cmd from bearerbox? */
>> @@ -1943,6 +1947,10 @@
>>     return 0;
>> }
>>
>> +#undef OCTSTR
>> +#undef SINGLE_GROUP
>> +#undef MULTI_GROUP
>> +
>> static int smppbox_is_single_group(Octstr *query)
>> {
>>     #define OCTSTR(name)
>> @@ -1959,7 +1967,7 @@
>> int main(int argc, char **argv)
>> {
>>        int cf_index;
>> -       Octstr *filename;
>> +       Octstr *filename, *version;
>>
>>        gwlib_init();
>>        all_boxes = gwlist_create();
>> @@ -1984,7 +1992,9 @@
>>
>>        octstr_destroy(filename);
>>
>> -       report_versions("smppbox");
>> +       version = octstr_format("smppbox version %s", GW_VERSION);
>> +       report_versions(octstr_get_cstr(version));
>> +       octstr_destroy(version);
>>
>>        init_smppbox(cfg);
>>
>>
>>
>> -----Original Message-----
>> From: devel-bounces at kannel.org [mailto:devel-bounces at kannel.org] On 
>> Behalf
>> Of Rene Kluwen
>> Sent: maandag 12 juli 2010 17:27
>> To: 'Nikos Balkanas'; 'Victor Luchitz'; devel at kannel.org
>> Subject: RE: smppbox code questions
>>
>> To be honest: I didn't try it.
>> But report_versions() is a gwlib library functions and outputs the values
>> that it was compiled with.
>>
>> == Rene
>>
>> -----Original Message-----
>> From: Nikos Balkanas [mailto:nbalkanas at gmail.com]
>> Sent: maandag 12 juli 2010 11:45
>> To: Rene Kluwen; 'Victor Luchitz'; devel at kannel.org
>> Subject: Re: smppbox code questions
>>
>> Hey, I didn't say it would work, just asked if you had tried it. You 
>> can't
>> expect me to remember by heart where each #define is set. Unfortunately 
>> it
>> needs patching.
>>
>> BR,
>> Nikos
>>
>> ----- Original Message ----- 
>> From: "Rene Kluwen" <rene.kluwen at chimit.nl>
>> To: "'Nikos Balkanas'" <nbalkanas at gmail.com>; "'Victor Luchitz'"
>> <vluchits at gmail.com>; <devel at kannel.org>
>> Sent: Monday, July 12, 2010 1:30 AM
>> Subject: RE: smppbox code questions
>>
>>
>>> Nikos, you disappoint me.
>>>
>>> report_versions() is linked in from the gwlib libraries with the values
>>> that
>>> it was compiled with. Try it, and you will see.
>>>
>>> == Rene
>>>
>>> -----Original Message-----
>>> From: Nikos Balkanas [mailto:nbalkanas at gmail.com]
>>> Sent: zondag 11 juli 2010 17:33
>>> To: Rene Kluwen; 'Victor Luchitz'; devel at kannel.org
>>> Subject: Re: smppbox code questions
>>>
>>> Nope, that would defeat the whole puprose. Add it to your code, just
>>> before
>>> calling report_versions()
>>>
>>> BR,
>>> Nikos
>>> ----- Original Message ----- 
>>> From: "Rene Kluwen" <rene.kluwen at chimit.nl>
>>> To: "'Nikos Balkanas'" <nbalkanas at gmail.com>; "'Victor Luchitz'"
>>> <vluchits at gmail.com>; <devel at kannel.org>
>>> Sent: Sunday, July 11, 2010 4:50 PM
>>> Subject: RE: smppbox code questions
>>>
>>>
>>>>I haven't tried.
>>>> But it will only work if I recompile gwlib after the new #define's.
>>>>
>>>> == Rene
>>>>
>>>> -----Original Message-----
>>>> From: Nikos Balkanas [mailto:nbalkanas at gmail.com]
>>>> Sent: zondag 11 juli 2010 9:46
>>>> To: Rene Kluwen; 'Victor Luchitz'; devel at kannel.org
>>>> Subject: Re: smppbox code questions
>>>>
>>>> Hi,
>>>>
>>>> Have you tried:
>>>>
>>>> #undef GW_NAME
>>>> #undef GW_VERSION
>>>>
>>>> #define GW_VERSION ...
>>>> #define GW_NAME ...
>>>>
>>>> and then call report_versions?
>>>>
>>>> BR,
>>>> Nikos
>>>> ----- Original Message ----- 
>>>> From: "Rene Kluwen" <rene.kluwen at chimit.nl>
>>>> To: "'Victor Luchitz'" <vluchits at gmail.com>; <devel at kannel.org>
>>>> Sent: Saturday, July 10, 2010 11:48 PM
>>>> Subject: RE: smppbox code questions
>>>>
>>>>
>>>> That is a gwlib quirk. The function report_versions() has the Kannel
>>>> version
>>>>
>>>> hard coded in it.
>>>> Sqlbox has the same problem.
>>>>
>>>> Maybe we need to send in a patch for gwlib/utils.c.
>>>>
>>>> == Rene
>>>>
>>>> -----Original Message-----
>>>> From: Victor Luchitz [mailto:vluchits at gmail.com]
>>>> Sent: zaterdag 10 juli 2010 22:17
>>>> To: devel at kannel.org; Rene Kluwen
>>>> Subject: Re: smppbox code questions
>>>>
>>>> Yeah, I made similar changes locally with the same result: at startup,
>>>> smppbox prints the following message:
>>>> [91108] [0] DEBUG: Kannel smppbox version `svn-r4833M'.
>>>> which is kannel's svn revision number, not that of smppbox.
>>>>
>>>> 2010/7/10 Rene Kluwen <rene.kluwen at chimit.nl>:
>>>>> I did an attempt to include the svn version numbers.
>>>>> But so far no luck. I did check things in, in case you want to have a
>>>>> look
>>>>
>>>>> at it.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Victor Luchitz [mailto:vluchits at gmail.com]
>>>>> Sent: zaterdag 10 juli 2010 18:27
>>>>> To: Rene Kluwen
>>>>> Subject: Re: smppbox code questions
>>>>>
>>>>> Ok, then. On a side note, the configure.in file needs to be updated to
>>>>> reflect the cvs -> svn change, currently the configure script still
>>>>> tries to fetch the version number from CVS/Entries file and fails at
>>>>> doing so. I am by no means an M4/autotools expert, guess some
>>>>> copy&paste job could be done using the main kannel configure.in..
>>>>>
>>>>> 2010/7/10 Rene Kluwen <rene.kluwen at chimit.nl>:
>>>>>> I decided to change the sources with longer variables, so things are
>>>>>> consistent with smsbox.
>>>>>> cfg.diff has also been committed.
>>>>>>
>>>>>> == Rene
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Victor Luchitz [mailto:vluchits at gmail.com]
>>>>>> Sent: zaterdag 10 juli 2010 15:53
>>>>>> To: devel at kannel.org; Rene Kluwen
>>>>>> Subject: Re: smppbox code questions
>>>>>>
>>>>>> Oh, my original patch was missing the smppbox-cfg.def part (in
>>>>>> attachment) so currently you can't specify any of the new vars,
>>>>>> otherwise
>>>>
>>>>>> smppbox doesn't start.
>>>>>> One thing I noticed is that you committed my patch with vars using
>>>>>> shorter names: src-addr-npi, etc, while the svn doc uses longer names
>>>>>> for
>>>>
>>>>>> them: source-addr-npi, dest-addr-npi and so on. Either the source 
>>>>>> code
>>>>>> needs correction to match the documentation or later is messed up
>>>>>> :)
>>>>>>
>>>>>> 2010/7/10 Rene Kluwen <rene.kluwen at chimit.nl>:
>>>>>>> Right away I also checked in your ton/npi patch.
>>>>>>>
>>>>>>> == Rene
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Victor Luchitz [mailto:vluchits at gmail.com]
>>>>>>> Sent: vrijdag 9 juli 2010 23:19
>>>>>>> To: Rene Kluwen
>>>>>>> Subject: Re: smppbox code questions
>>>>>>>
>>>>>>> Yeah, I was thinking about this "hack" as well, but it's going to
>>>>>>> create more problems than it solves. Btw, why does smppbox use
>>>>>>> system-type as boxc_id instead of ESME's login name? That forces
>>>>>>> EMSE's to have distinct system-type values, while almost all SMSC'es
>>>>>>> I've seen so far allow connections with empty system-type string, 
>>>>>>> for
>>>>>>> example.
>>>>>>>
>>>>>>> 2010/7/10 Rene Kluwen <rene.kluwen at chimit.nl>:
>>>>>>>> Heh... I think the way it works now is best for the average user.
>>>>>>>> But I am sure you are competent enough to change it to your own
>>>>>>>> needs.
>>>>>>>> One "hack" that you can make is make the system-type of the client
>>>>>>>> the
>>>>>>>> same as your smsc-id in your kannel.conf.
>>>>>>>> This is of course not recommended for most persons, but it might 
>>>>>>>> work
>>>>>>>> for you.
>>>>>>>>
>>>>>>>> == Rene
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Victor Luchitz [mailto:vluchits at gmail.com]
>>>>>>>> Sent: vrijdag 9 juli 2010 22:39
>>>>>>>> To: Rene Kluwen
>>>>>>>> Subject: Re: smppbox code questions
>>>>>>>>
>>>>>>>> I have a pretty good idea how it works, it's just that the way it
>>>>>>>> works doesn't suit my needs ;)
>>>>>>>>
>>>>>>>> 2010/7/9 Rene Kluwen <rene.kluwen at chimit.nl>:
>>>>>>>>> Surely this is relevant.
>>>>>>>>>
>>>>>>>>> Smppbox is not interested in bearerbox generated dlr's. It just
>>>>>>>>> needs
>>>>>>>>> to "dlr_find" the dlr's that it added itself via dlr_add.
>>>>>>>>> Bearerbox takes care of its own dlr's. Smppbox also takes care of
>>>>>>>>> its
>>>>>>>>> own dlr's.
>>>>>>>>>
>>>>>>>>> I think you should re-read the code again to see how it works.
>>>>>>>>>
>>>>>>>>> == Rene
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Victor Luchitz [mailto:vluchits at gmail.com]
>>>>>>>>> Sent: vrijdag 9 juli 2010 15:35
>>>>>>>>> To: devel at kannel.org; Rene Kluwen
>>>>>>>>> Subject: Re: smppbox code questions
>>>>>>>>>
>>>>>>>>> Yes, but how is this relevant? I mean, there are two possibilities
>>>>>>>>> to make smppbox be aware of bearerbox-generated DLRs:
>>>>>>>>>
>>>>>>>>> 1) use boxc_id as smsc-id in dlr_add in bearerbox and then pass 
>>>>>>>>> the
>>>>>>>>> report_mo message to smppbox without issuing dlr_find in bearerbox
>>>>>>>>> 2) use "proper"/parent smsc-id in smppbox
>>>>>>>>>
>>>>>>>>> The whole issue arises from the need to pass SMSC-related DLR's to
>>>>>>>>> smppbox without the later issuing any DLR's itself. For example, a
>>>>>>>>> MT message may fail to be delivered due to insufficient funds on
>>>>>>>>> user's account.
>>>>>>>>>
>>>>>>>>> 2010/7/9 Rene Kluwen <rene.kluwen at chimit.nl>:
>>>>>>>>>> If bearerbox sends a report_mo, then it should include a status
>>>>>>>>>> (dlr
>>>>>>>>>> type) as well.
>>>>>>>>>> Or am I wrong?
>>>>>>>>>>
>>>>>>>>>> == Rene
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Victor Luchitz [mailto:vluchits at gmail.com]
>>>>>>>>>> Sent: vrijdag 9 juli 2010 14:24
>>>>>>>>>> To: devel at kannel.org; Rene Kluwen
>>>>>>>>>> Subject: Re: smppbox code questions
>>>>>>>>>>
>>>>>>>>>> Unfortunately there's currently no way to add a SMSC_SUCCESS or
>>>>>>>>>> SMSC_FAIL DLR in smppbox so I have/need to do that in bearerbox.
>>>>>>>>>> But oh, well, I'll just go with boxc_id as smsc-id and live with
>>>>>>>>>> this fact.
>>>>>>>>>>
>>>>>>>>>> 2010/7/9 Rene Kluwen <rene.kluwen at chimit.nl>:
>>>>>>>>>>> But bearerbox inserts it's own dlr's. As does smppbox.
>>>>>>>>>>> So bearerbox will find their dlr's. And smppbox will do also.
>>>>>>>>>>>
>>>>>>>>>>> == Rene
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Victor Luchitz [mailto:vluchits at gmail.com]
>>>>>>>>>>> Sent: vrijdag 9 juli 2010 13:55
>>>>>>>>>>> To: Rene Kluwen
>>>>>>>>>>> Subject: Re: smppbox code questions
>>>>>>>>>>>
>>>>>>>>>>> Well, this is going against the logic in bearerbox. For example,
>>>>>>>>>>> if you pass a DLR via standard Kannel HTTP protocol, bearerbox
>>>>>>>>>>> will try to find a matching DLR using its own smsc-id, upon
>>>>>>>>>>> failing to do, it won't pass the DLR to smppbox either.
>>>>>>>>>>>
>>>>>>>>>>> 2010/7/9 Rene Kluwen <rene.kluwen at chimit.nl>:
>>>>>>>>>>>> The first parameter (smsc_id) is to determine "who's" dlr it is
>>>>>>>>>>>> to
>>>>>>>>>>>> begin with. So in short: To which smsc it belongs.
>>>>>>>>>>>> Because smppbox does things the other way around, it passes the
>>>>>>>>>>>> boxc_id variable. So if two boxes happen to have the same "ts"
>>>>>>>>>>>> (which can in theory happen) the value is used to distinguish 
>>>>>>>>>>>> to
>>>>>>>>>>>> which box_id it belongs.
>>>>>>>>>>>>
>>>>>>>>>>>> == Rene
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Victor Luchitz [mailto:vluchits at gmail.com]
>>>>>>>>>>>> Sent: vrijdag 9 juli 2010 11:12
>>>>>>>>>>>> To: devel at kannel.org; Rene Kluwen
>>>>>>>>>>>> Subject: Re: smppbox code questions
>>>>>>>>>>>>
>>>>>>>>>>>> On a side note, why does smppbox use boxc_id as the first
>>>>>>>>>>>> parameter passed to dlr_add and dlr_find? Both functions take
>>>>>>>>>>>> smsc_id as the first argument and boxc_id value is obtained 
>>>>>>>>>>>> from
>>>>>>>>>>>> the sms struct.
>>>>>>>>>>>>
>>>>>>>>>>>> 2010/7/8 Rene Kluwen <rene.kluwen at chimit.nl>:
>>>>>>>>>>>>> Done.
>>>>>>>>>>>>> Current revision is 17.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: devel-bounces at kannel.org 
>>>>>>>>>>>>> [mailto:devel-bounces at kannel.org]
>>>>>>>>>>>>> On Behalf Of Victor Luchitz
>>>>>>>>>>>>> Sent: donderdag 8 juli 2010 15:06
>>>>>>>>>>>>> To: devel at kannel.org
>>>>>>>>>>>>> Subject: Re: smppbox code questions
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yeah, you committed the proposed change to boxc->boxc_id in
>>>>>>>>>>>>> revision 15. What I'm asking about is the suggestion and patch 
>>>>>>>>>>>>> I
>>>>>>>>>>>>> posted here:
>>>>>>>>>>>>> http://www.kannel.org/pipermail/devel/2010-July/003653.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2010/7/8 Rene Kluwen <rene.kluwen at chimit.nl>:
>>>>>>>>>>>>>> It's already in the code.
>>>>>>>>>>>>>> Current revision is 16.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> == Rene
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: devel-bounces at kannel.org
>>>>>>>>>>>>>> [mailto:devel-bounces at kannel.org] On Behalf Of Victor Luchitz
>>>>>>>>>>>>>> Sent: donderdag 8 juli 2010 7:52
>>>>>>>>>>>>>> To: devel at kannel.org
>>>>>>>>>>>>>> Subject: Re: smppbox code questions
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Any hope this will be reviewed and committed?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm also working on a patch that adds TLV support to smppbox
>>>>>>>>>>>>>> but I'd like to get this one included first.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2010/7/6 Victor Luchitz <vluchits at gmail.com>:
>>>>>>>>>>>>>>> Yup, it's working fine now. Noticed there's another memleak
>>>>>>>>>>>>>>> though:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> another octstr_destroy(msgid); call is needed right after 
>>>>>>>>>>>>>>> the:
>>>>>>>>>>>>>>> /* we could not find a corresponding dlr; nothing to send */
>>>>>>>>>>>>>>> line.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm also attaching another patch which allows transmission 
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> custom error codes in DLR's in the same manner as the 
>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>> text bit.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2010/7/6 Rene Kluwen <rene.kluwen at chimit.nl>:
>>>>>>>>>>>>>>>> I have no way of testing this here. But since either way
>>>>>>>>>>>>>>>> cannot
>>>>
>>>>>>>>>>>>>>>> harm I changed it.
>>>>>>>>>>>>>>>> Current smppbox revision is now 15.
>>>>>>>>>>>>>>>> Could you please check out and see if this fixes your
>>>>>>>>>>>>>>>> problem?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> == Rene
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>> From: devel-bounces at kannel.org
>>>>>>>>>>>>>>>> [mailto:devel-bounces at kannel.org] On Behalf Of Victor 
>>>>>>>>>>>>>>>> Luchitz
>>>>>>>>>>>>>>>> Sent: dinsdag 6 juli 2010 14:53
>>>>>>>>>>>>>>>> To: devel at kannel.org
>>>>>>>>>>>>>>>> Subject: Re: smppbox code questions
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1) I think this assumption is incorrect. I have the routing
>>>>>>>>>>>>>>>> set up this way in bearerbox:
>>>>>>>>>>>>>>>> group = smsbox-route
>>>>>>>>>>>>>>>> smsbox-id = vma
>>>>>>>>>>>>>>>> smsc-id = HTTP
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So all messages on the 'HTTP' smsc get routed to smppbox.
>>>>>>>>>>>>>>>> However, the custom HTTP protocol in the above layer does 
>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>> use dlr_find to route messages to a specific box for two
>>>>>>>>>>>>>>>> reasons:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> a) wrong smsc-id is used in the query (bearerbox doesn't 
>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>> that smppbox overrides the smsc id with system-type) so
>>>>>>>>>>>>>>>> dlr_find always fails
>>>>>>>>>>>>>>>> b) dlr_find removes DLR from the table and then 
>>>>>>>>>>>>>>>> subsequently
>>>>>>>>>>>>>>>> readds it, which is rather stressful on the DB for no sane
>>>>>>>>>>>>>>>> reason
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What it does instead is simply setting the sms_type to
>>>>>>>>>>>>>>>> report_mo, leaving box_id empty as in regular MO messages.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2010/7/6 Rene Kluwen <rene.kluwen at chimit.nl>:
>>>>>>>>>>>>>>>>> To start with the last thing:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2) You are right. It should use the msgid's in the dlr_url
>>>>>>>>>>>>>>>>> from the dlr instance. I changed it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> About 1): We assume msg->boxc_id and box->boxc_id are the
>>>>>>>>>>>>>>>>> same
>>>>
>>>>>>>>>>>>>>>>> in this case. Otherwise the message wouldn't have ended up
>>>>>>>>>>>>>>>>> there.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> == Rene
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>> From: devel-bounces at kannel.org
>>>>>>>>>>>>>>>>> [mailto:devel-bounces at kannel.org] On Behalf Of Victor
>>>>>>>>>>>>>>>>> Luchitz
>>>>>>>>>>>>>>>>> Sent: maandag 5 juli 2010 20:36
>>>>>>>>>>>>>>>>> To: devel at kannel.org
>>>>>>>>>>>>>>>>> Subject: smppbox code questions
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I have a few questions for you regarding the handling of
>>>>>>>>>>>>>>>>> DLR's by smppbox, which might also turn out to be bugs.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1)
>>>>>>>>>>>>>>>>> In msg_to_pdu function there's a line which reads:
>>>>>>>>>>>>>>>>> dlr = dlr_find(msg->sms.boxc_id, msgid, msg->sms.receiver,
>>>>>>>>>>>>>>>>> dlrtype);
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think it's incorrect because when a DLR is stored by
>>>>>>>>>>>>>>>>> smppbox in handle_pdu, the boxc_id it uses is that from
>>>>>>>>>>>>>>>>> smpp_logins file (system_type). That in turn may cause
>>>>>>>>>>>>>>>>> dlr_find to always fail. So in my opinion the correct
>>>>>>>>>>>>>>>>> dlr_find
>>>>
>>>>>>>>>>>>>>>>> call is this:
>>>>>>>>>>>>>>>>> dlr = dlr_find(box->boxc_id, msgid, msg->sms.receiver,
>>>>>>>>>>>>>>>>> dlrtype);
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2) another thing I find not quite correct is the way 
>>>>>>>>>>>>>>>>> smppbox
>>>>>>>>>>>>>>>>> splits message ids for concatenated DLR's. Basically, what
>>>>>>>>>>>>>>>>> smppbox does is
>>>>>>>>>>>>>>>>> this:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> parts = octstr_split(msg->sms.dlr_url, octstr_imm(";"));
>>>>>>>>>>>>>>>>> msgid = gwlist_extract_first(parts); ...
>>>>>>>>>>>>>>>>> Then it loops through all elements of the 'parts' list and
>>>>>>>>>>>>>>>>> here is where the potential problem lies. smppbox assumes
>>>>>>>>>>>>>>>>> that msgid for the concatenated DLR is always equal to
>>>>>>>>>>>>>>>>> dlr_url
>>>>
>>>>>>>>>>>>>>>>> which is not always true.
>>>>>>>>>>>>>>>>> In fact, I think it's never true for concatenated DLR's
>>>>>>>>>>>>>>>>> stored by the dlr_add call in handle_pdu. Also, for 
>>>>>>>>>>>>>>>>> example,
>>>>>>>>>>>>>>>>> the 'msgid' and 'dlrurls' columns in the storage table can
>>>>>>>>>>>>>>>>> have different maxiumum lengths, allowing truncation of 
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> msgid. Here's my proposed fix - add the following bit of
>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>> to msg_to_pdu:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> gwlist_destroy(parts, octstr_destroy_item); parts =
>>>>>>>>>>>>>>>>> octstr_split(dlr->sms.dlr_url, octstr_imm(";"));
>>>>>>>>>>>>>>>>> gwlist_extract_first(parts);
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> right above the following bit:
>>>>>>>>>>>>>>>>> if (gwlist_len(parts) > 0) {
>>>>>>>>>>>>>>>>>    while ((msgid2 = gwlist_extract_first(parts)) != NULL) 
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>  Victor Luchitz
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>  Victor Luchitz
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>  Victor Luchitz
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>  Victor Luchitz
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>  Victor Luchitz
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>  Victor Luchitz
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Best regards,
>>>>>>>>>>>  Victor Luchitz
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Best regards,
>>>>>>>>>>  Victor Luchitz
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Best regards,
>>>>>>>>>  Victor Luchitz
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best regards,
>>>>>>>>  Victor Luchitz
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best regards,
>>>>>>>  Victor Luchitz
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>>  Victor Luchitz
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>>  Victor Luchitz
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Best regards,
>>>> Victor Luchitz
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
> 




More information about the devel mailing list