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:[email protected]] Sent: maandag 12 juli 2010 11:45 To: Rene Kluwen; 'Victor Luchitz'; [email protected] 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" <[email protected]> To: "'Nikos Balkanas'" <[email protected]>; "'Victor Luchitz'" <[email protected]>; <[email protected]> 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:[email protected]] > Sent: zondag 11 juli 2010 17:33 > To: Rene Kluwen; 'Victor Luchitz'; [email protected] > 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" <[email protected]> > To: "'Nikos Balkanas'" <[email protected]>; "'Victor Luchitz'" > <[email protected]>; <[email protected]> > 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:[email protected]] >> Sent: zondag 11 juli 2010 9:46 >> To: Rene Kluwen; 'Victor Luchitz'; [email protected] >> 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" <[email protected]> >> To: "'Victor Luchitz'" <[email protected]>; <[email protected]> >> 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:[email protected]] >> Sent: zaterdag 10 juli 2010 22:17 >> To: [email protected]; 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 <[email protected]>: >>> 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:[email protected]] >>> 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 <[email protected]>: >>>> 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:[email protected]] >>>> Sent: zaterdag 10 juli 2010 15:53 >>>> To: [email protected]; 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 <[email protected]>: >>>>> Right away I also checked in your ton/npi patch. >>>>> >>>>> == Rene >>>>> >>>>> -----Original Message----- >>>>> From: Victor Luchitz [mailto:[email protected]] >>>>> 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 <[email protected]>: >>>>>> 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:[email protected]] >>>>>> 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 <[email protected]>: >>>>>>> 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:[email protected]] >>>>>>> Sent: vrijdag 9 juli 2010 15:35 >>>>>>> To: [email protected]; 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 <[email protected]>: >>>>>>>> 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:[email protected]] >>>>>>>> Sent: vrijdag 9 juli 2010 14:24 >>>>>>>> To: [email protected]; 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 <[email protected]>: >>>>>>>>> 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:[email protected]] >>>>>>>>> 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 <[email protected]>: >>>>>>>>>> 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:[email protected]] >>>>>>>>>> Sent: vrijdag 9 juli 2010 11:12 >>>>>>>>>> To: [email protected]; 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 <[email protected]>: >>>>>>>>>>> Done. >>>>>>>>>>> Current revision is 17. >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: [email protected] [mailto:[email protected]] >>>>>>>>>>> On Behalf Of Victor Luchitz >>>>>>>>>>> Sent: donderdag 8 juli 2010 15:06 >>>>>>>>>>> To: [email protected] >>>>>>>>>>> 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 <[email protected]>: >>>>>>>>>>>> It's already in the code. >>>>>>>>>>>> Current revision is 16. >>>>>>>>>>>> >>>>>>>>>>>> == Rene >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: [email protected] >>>>>>>>>>>> [mailto:[email protected]] On Behalf Of Victor Luchitz >>>>>>>>>>>> Sent: donderdag 8 juli 2010 7:52 >>>>>>>>>>>> To: [email protected] >>>>>>>>>>>> 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 <[email protected]>: >>>>>>>>>>>>> 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 <[email protected]>: >>>>>>>>>>>>>> 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: [email protected] >>>>>>>>>>>>>> [mailto:[email protected]] On Behalf Of Victor Luchitz >>>>>>>>>>>>>> Sent: dinsdag 6 juli 2010 14:53 >>>>>>>>>>>>>> To: [email protected] >>>>>>>>>>>>>> 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 <[email protected]>: >>>>>>>>>>>>>>> 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: [email protected] >>>>>>>>>>>>>>> [mailto:[email protected]] On Behalf Of Victor >>>>>>>>>>>>>>> Luchitz >>>>>>>>>>>>>>> Sent: maandag 5 juli 2010 20:36 >>>>>>>>>>>>>>> To: [email protected] >>>>>>>>>>>>>>> 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 >> >> >> >> >> >> >> > > >
