smppbox code questions

Rene Kluwen rene.kluwen at chimit.nl
Sat Jul 10 22:48:21 CEST 2010


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