Re: [PATCH] Use pkg-config to find libxml2

[Alexander Malysh]

Hi Hugh,

it’s better to keep .in for now because we also support old versions, warnings 
are not errors ;-)

Regards,
Alexander Malysh
Am 20. Sept. 2022, 08:04 +0200 schrieb Hugh McMaster 
:
> > On Wed, 14 Sept 2022 at 01:36, Alexander Malysh wrote:
> > > Hi Hugh,
> > >
> > > commited to SVN, Thanks!
> > >
> > > Regards,
> > > Alexander Malysh
> >
> > Fantastic. Thanks so much!
> >
> > You might also consider renaming configure.in as configure.ac to silence 
> > some autoconf warnings. Using configure.in as a filename has been 
> > deprecated for some years now.
> >
> > I'd attach a patch, but SVN literally removes every line in the old file. 
> > So, it's quicker for you to run the command and commit the change:
> >
> >     svn rename configure.in configure.ac
> >
> > > Am 29. Aug. 2022, 06:39 +0200 schrieb Hugh McMaster:
> > > > Debian is taking steps towards removing xml2-config in favour of using 
> > > > pkg-config to find libxml2.
> > > >
> > > > This means Kannel will fail to build from source on Debian and related 
> > > > distributions that track Debian packages (such as Ubuntu).
> > > >
> > > > Following a brief discussion in #830 [1], I have patched configure.in 
> > > > to check for libxml2 using xml2-config, then check for libxml2 using 
> > > > pkg-config if xml2-config is not found or libxml2 is too old.
> > > >
> > > > Hugh
> > > >
> > > > [1] https://redmine.kannel.org/issues/830
> >
> > Hugh

Re: [PATCH] Use pkg-config to find libxml2

[Alexander Malysh]

Hi Hugh,

commited to SVN, Thanks!

Regards,
Alexander Malysh
Am 29. Aug. 2022, 06:39 +0200 schrieb Hugh McMaster :
> Debian is taking steps towards removing xml2-config in favour of using 
> pkg-config to find libxml2.
>
> This means Kannel will fail to build from source on Debian and related 
> distributions that track Debian packages (such as Ubuntu).
>
> Following a brief discussion in #830 [1], I have patched configure.in to 
> check for libxml2 using xml2-config, then check for libxml2 using pkg-config 
> if xml2-config is not found or libxml2 is too old.
>
> Hugh
>
> [1] https://redmine.kannel.org/issues/830
>

Re: Multipart long message delivery receipt problem

[Alexander Malysh]

Hi,

this is bug on carrier side. Kannel splits long message and asks for DLR for 
_only_ first part. If carrier sends DLR not only for the part that kennel asked 
about, it’s a bug and has to be fixed on carrier side.

For a workaround for this unknown big carrier, you can modify kannel 
(gw/sms.c:split_sms) to ask for DLR for the last instead of the first part of 
long message.

Regards,
Alexander Malysh
Am 5. Juli 2022, 22:31 +0200 schrieb lbrezs...@gmx.co.uk :
> Hi,
> Yes, we are using bearerbox's internal functionality for splitting long 
> messages. And we are aware that kannel stores only 1st segment message_id 
> (receipted_message_id) to match from deliver_sm.
> The problem arises from the fact that carriers/providers send either 1 
> deliver_sm or all deliver_sm(s), one for each part.
> Let's take as an example a long message that requires kannel to split it into 
> 2 parts.
> Kannel sends 2 submit_sm, receives 2 submit_sm_resp, stores only one 
> message_id from the 1st submit_sm_resp to dlr storage.
> Now there are three basic cases:
> 1) Happy path: we receive one deliver_sm and the message_id matches 1st 
> submit_sm_resp message_id. All good.
> 2) Acceptable path: we receive two deliver_sm(s) and one of the the 
> message_id matches 1st submit_sm_resp message_id. Kannel still cannot match 
> one of them and an error is logged. Something like: "got DLR but could not 
> find message or was not interested in it". But the 2nd is matched. They not 
> always come in the same order they were submitted. Small inconvenience 
> unmatched deliver_sm is marked as the error. If you are monitoring logs for 
> errors ( (and you shoudl), it will be a false/positive.
> 3) Problem: Only one deliver_sm and it's a 2nd part. Kannel cannot match it 
> and error is logged : "got DLR but could not find message or was not 
> interested in it.
> Delivery receipt is lost.
>
> Unfortunately, at least one very big carrier consistently sends only "last 
> part" deliver_sm.
> Regards,
> Lelik.
>
> On 7/5/2022 02:26, Alexander Malysh wrote:
> > Hi,
> >
> > it looks like you submitting parts to channel instead of the whole message? 
> > If kannel, I’m speaking of bearerbox, splitting message then kannel asks 
> > for DLR only for a first part. If for any reason you splitting messages by 
> > yourself, then kannel sends each part independent and has no clue about the 
> > whole message. In last case you and SMSC has to handle it on yourown.
> >
> > Regards,
> > Alexander Malysh
> > Am 21. Juni 2022, 23:25 +0200 schrieb lbrezs...@gmx.co.uk 
> > :
> > > Alexander,
> > > We observed totally different behaviour of Kannel:
> > > 1) Kannel requested all segments for delivery, not just 1, i.e. 3 segment 
> > > message will result in 3 submit_sm (s) all marked with 
> > > registered_delivery: 1 = 0x0001
> > > 2) dlr_mask is altered with dlr8/16 flipped back to 0 as kannel converts 
> > > ACKs and NACKs to dlr8/16 instead
> > > 3) Kannel receives all corresponding submit_sm_resp(s). Only 1st segment 
> > > message_id is written to dlr storage. And only one ACK/NACK is converted 
> > > to dlr8/16.
> > > 4) Depending on the end user mobile provider, we get either all segments 
> > > deliver_sm(s) or just 1. In fact, majority of the carriers return 
> > > multiple. In fact, only one carrier returns 1 part and it's the last 
> > > segment message_id :(
> > > 5) The order of the corresponding deliver_sm is arbitrary. If the 1st 
> > > segment deliver_sm comes 1st, then you are in luck, as it will be matched 
> > > to the message_id in dlr_storage and delivered to smsbox. Any other part 
> > > would result in error "got DLR but could not fi nd message or was not 
> > > interested in it" and dlr would be lost.
> > > In my honest opinion, there is an easy fix, but it involves altering 
> > > Kannel source code and re-compiling it.
> > > Write both id(s) to the dlr storage. id of the 1 segment + id of the 
> > > current segment. We use redis for example. 3 segment message would result 
> > > in something like this:
> > > Now:
> > > 123) "dlr:provider_smsc:11"
> > > Altered:
> > > 100) "dlr:provider_smsc:11:11"
> > > 101) "dlr:provider_smsc:11:12"
> > > 102) "dlr:provider_smsc:11:13"
> > > When 1st deliver_sm received, let say for message_id 100003 (last), match 
> > > dlr by message id 13, but delete by all dlr(s) marked 11, and 
> > > give the dlr to smsbox.
> &g

Re: Multipart long message delivery receipt problem

[Alexander Malysh]

Hi,

it looks like you submitting parts to channel instead of the whole message? If 
kannel, I’m speaking of bearerbox, splitting message then kannel asks for DLR 
only for a first part. If for any reason you splitting messages by yourself, 
then kannel sends each part independent and has no clue about the whole 
message. In last case you and SMSC has to handle it on yourown.

Regards,
Alexander Malysh
Am 21. Juni 2022, 23:25 +0200 schrieb lbrezs...@gmx.co.uk :
> Alexander,
> We observed totally different behaviour of Kannel:
> 1) Kannel requested all segments for delivery, not just 1, i.e. 3 segment 
> message will result in 3 submit_sm (s) all marked with registered_delivery: 1 
> = 0x0001
> 2) dlr_mask is altered with dlr8/16 flipped back to 0 as kannel converts ACKs 
> and NACKs to dlr8/16 instead
> 3) Kannel receives all corresponding submit_sm_resp(s). Only 1st segment 
> message_id is written to dlr storage. And only one ACK/NACK is converted to 
> dlr8/16.
> 4) Depending on the end user mobile provider, we get either all segments 
> deliver_sm(s) or just 1. In fact, majority of the carriers return multiple. 
> In fact, only one carrier returns 1 part and it's the last segment message_id 
> :(
> 5) The order of the corresponding deliver_sm is arbitrary. If the 1st segment 
> deliver_sm comes 1st, then you are in luck, as it will be matched to the 
> message_id in dlr_storage and delivered to smsbox. Any other part would 
> result in error "got DLR but could not fi nd message or was not interested in 
> it" and dlr would be lost.
> In my honest opinion, there is an easy fix, but it involves altering Kannel 
> source code and re-compiling it.
> Write both id(s) to the dlr storage. id of the 1 segment + id of the current 
> segment. We use redis for example. 3 segment message would result in 
> something like this:
> Now:
> 123) "dlr:provider_smsc:11"
> Altered:
> 100) "dlr:provider_smsc:11:11"
> 101) "dlr:provider_smsc:11:12"
> 102) "dlr:provider_smsc:11:13"
> When 1st deliver_sm received, let say for message_id 13 (last), match dlr 
> by message id 13, but delete by all dlr(s) marked 11, and give the 
> dlr to smsbox.
> When next dlr let say for id 12 comes in, it will result in "got DLR but 
> could not find message or was not interested in it" error (flip to warning) 
> and no dlr would be given to smsbox.
> This way you always get only one dlr, and you do not depend on which order 
> they are sent back by the provider.
> Regards,
> Lelik.
>
> On 6/21/2022 04:27, Alexander Malysh wrote:
> > Hi,
> >
> > Kännel per default split long message and request DLR for only first part 
> > of long message. If carrier sends more DLRs as requested, it’s a bug on 
> > carrier side. To get all DLRs requested for long message, more work on 
> > patching channel is needed, because a mid layer expect only one DLR from 
> > kannel to be delivered, because mid layer made only one request to kannel.
> >
> > Regards,
> > Alexander Malysh
> > Am 16. Juni 2022, 17:54 +0200 schrieb lbrezs...@gmx.co.uk 
> > :
> > > Hi all,
> > >
> > > When sending long messages using native Kannel concatenation
> > > functionality based on UDH, we are experiencing problems with matching
> > > delivery receipts of the submitted messages.
> > >
> > > The problem arises from the fact that not all carries send back all
> > > delivery receipts. Some send only one receipt and it's not not
> > > necessarily #1.
> > >
> > > Basically there are 3 scenarios:
> > >
> > > 1) Carrier/Provider #1 sends back 1 delivery receipt and message_id
> > > correspondents to segment #1. Bearer_box matches by message_id, and
> > > forwards 1 delivery receipt to sms_box. This is the most desirable path.
> > >
> > > 2) Carrier/Provider #2 sends back 1 delivery receipt and message_id
> > > correspondents to last segment. Bearer_box cannot match by message_id,
> > > and does NOT forward a delivery receipt to sms_box at all.
> > >
> > > Delivery receipt is lost.
> > >
> > > 3) Carrier/Provider #3 sends back all delivery receipts for each
> > > segment. The order is random, lat say 5-segment message migh come back
> > > as 3,5,1,4,2. Bearer_box cannot match 3,5, matches 1 , cannot match 4,2
> > > . It forwards only a delivery receipt for segment # 1 to sms_box. The
> > > other 2,3,4,5 would stay in dlr-storage and eventually expire. This
> > > scenario is not prefect, but acceptable.
> > >
> > > Question: Can we tell Kannel to save all submit_sm_resp message_id to
> > > dlr-storage? Is there any kind of kannel config switch to accommodate 
> > > this?
> > > Do we have to patch and recompile bearer_box ourselves?
> > >
> > > Thanks and best Regards,
> > > Lelik.
> > >
> > >

Re: Multipart long message delivery receipt problem

[Alexander Malysh]

Hi,

Kännel per default split long message and request DLR for only first part of 
long message. If carrier sends more DLRs as requested, it’s a bug on carrier 
side. To get all DLRs requested for long message, more work on patching channel 
is needed, because a mid layer expect only one DLR from kannel to be delivered, 
because mid layer made only one request to kannel.

Regards,
Alexander Malysh
Am 16. Juni 2022, 17:54 +0200 schrieb lbrezs...@gmx.co.uk :
> Hi all,
>
> When sending long messages using native Kannel concatenation
> functionality based on UDH, we are experiencing problems with matching
> delivery receipts of the submitted messages.
>
> The problem arises from the fact that not all carries send back all
> delivery receipts. Some send only one receipt and it's not not
> necessarily #1.
>
> Basically there are 3 scenarios:
>
> 1) Carrier/Provider #1 sends back 1 delivery receipt and message_id
> correspondents to segment #1. Bearer_box matches by message_id, and
> forwards 1 delivery receipt to sms_box. This is the most desirable path.
>
> 2) Carrier/Provider #2 sends back 1 delivery receipt and message_id
> correspondents to last segment. Bearer_box cannot match by message_id,
> and does NOT forward a delivery receipt to sms_box at all.
>
> Delivery receipt is lost.
>
> 3) Carrier/Provider #3 sends back all delivery receipts for each
> segment. The order is random, lat say 5-segment message migh come back
> as 3,5,1,4,2. Bearer_box cannot match 3,5, matches 1 , cannot match 4,2
> . It forwards only a delivery receipt for segment # 1 to sms_box. The
> other 2,3,4,5 would stay in dlr-storage and eventually expire. This
> scenario is not prefect, but acceptable.
>
> Question: Can we tell Kannel to save all submit_sm_resp message_id to
> dlr-storage? Is there any kind of kannel config switch to accommodate this?
> Do we have to patch and recompile bearer_box ourselves?
>
> Thanks and best Regards,
> Lelik.
>
>

Re: [PATCH] MO throughput control

[Alexander Malysh]

Hi Stipe,

thanks for this patch. Quick review shows at least following:

+ resp->u.data_sm_resp.command_status = SMPP_ESME_RX_T_APPN;

this should be ESME_RTHROTTLED. The same apply to deliver_sm.

Please give some more time to review before commit.

Regards,
Alexander Malysh
Am 3. Juni 2022, 17:08 +0200 schrieb Stipe Tolj :
> Hi all,
>
> in certain conditions it may be feasible also to have MO throughput
> control in terms of regulating how many messages we want to handle on
> the MO side (including DLRs).
>
> For this purpose I have prepared the attached patchset, that introduces
> the optional splitting of the config directives:
>
> group = smsc
> throughput = X
>
> would means X as MT and MO throughput constraint, and
>
> group = smsc
> throughput-mt = X
> throughput-mo = Y
>
> where MT wise we have a X TPS constraint and MO wise a Y TPS.
>
> So far only the SMSC HTTP and SMSC SMPP modules have been implementing
> in the patchset the MO throughput control. Other modules may follow if
> required.
>
> Please review, comments as always welcome. If no objections, will commit
> next week.
>
> (ONE argument that may be a decline reason is that the behavior WOULD
> change with current setups, i.e. for SMPP connections this would imply
> that we would also have MO throughput control for DLRs if the
> 'throughput = x' value is configured. A way to solve this is to keep
> 'throughput' for MT wise only, and introduce 'throughput-mo' as the new
> one for MO control. Comments?)
>
> Thanks,
> Stipe
>
> --
> Best Regards,
> Stipe
>
> ---
> Koelner Landstrasse 419
> 40589 Düsseldorf, NRW, Germany
>
> tolj.org system architecture Kannel Software Foundation (KSF)
> http://www.tolj.org/ http://www.kannel.org/
>
> mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
> ---

Re: Issue in GWLIB SSL data reading

[Alexander Malysh]

Hi Paul,

sorry for delay. Thanks for this patch, committed to svn.

Regards,
Alexander Malysh
Am 8. März 2021, 06:03 +0100 schrieb Paul Bagyenda :
> Hi,
>
> GWLIB's Connection module has a bug relating to how it handles large
> data reads over SSLed connections.
>
> The issue lies in the function unlocked_read() in conn.c, which is
> called in several places to read from the underlying socket/file
> descriptor. Typical usage in HTTPS transactions is as follows:
> 1. http module polls the socket for inbound data. The callback then
> issues a conn_read_* call on the underlying connection object.
> conn_read_fixed() is used to read HTTPS POST bodies.
> 2. unlocked_read() is called if there isn't sufficient data in the
> Connection object buffer. However this only reads up to 4k bytes, and
> then returns, leaving it up the upper level poller to detect if there
> is more data to be read (and in turn call conn_read_* again).
> This is where the problem arises: For SSLed connections, openssl may
> buffer some data internally, and so reading only 4k bytes and then
> waiting for the next poller call can result in a timeout on the sender
> side while we still have data in the openssl read buffer. We tripped
> over this issue with Mbuni.
>
> The patch below is a suggested fix.
>
> Thanks
>
> Paul.

Re: Possible bug? Cannot send Unicode message using TLV 0x424

[Alexander Malysh]

Hi,

Kannel doesn’t re-encode metadata fields like text field in request. Therefore 
you have to
prepare TLV data by yourself and encode to SMSC charset GSM03.38/UCS2 whatever.

Regards,
Alex
Am 26. Mai 2020, 03:00 +0200 schrieb lbrezs...@gmx.co.uk :
> When submitting Unicode message using smpp protocol via regular "text"
> field by specifying coding=2 and char-set=utf-8, message is delivered
> correctly.
>
> =2=utf8=Unicode+Greek+Όλα Καλά
>
>     2020-05-25 20:37:03 [24722] [6] DEBUG:   short_message:
>     2020-05-25 20:37:03 [24722] [6] DEBUG:    Octet string at
> 0x7fe9e8006c80:
>     2020-05-25 20:37:03 [24722] [6] DEBUG:  len:  44
>     2020-05-25 20:37:03 [24722] [6] DEBUG:  size: 45
>     2020-05-25 20:37:03 [24722] [6] DEBUG:  immutable: 0
>     2020-05-25 20:37:03 [24722] [6] DEBUG:  data: 00 55 00 6e 00 69
> 00 63 00 6f 00 64 00 65 00 20   .U.n.i.c.o.d.e.
>     2020-05-25 20:37:03 [24722] [6] DEBUG:  data: 00 47 00 72 00 65
> 00 65 00 6b 00 20 03 8c 03 bb   .G.r.e.e.k. 
>     2020-05-25 20:37:03 [24722] [6] DEBUG:  data: 03 b1 00 20 03 9a
> 03 b1 03 bb 03 ac   ... 
>     2020-05-25 20:37:03 [24722] [6] DEBUG:    Octet string dump ends.
>     2020-05-25 20:37:03 [24722] [6] DEBUG: SMPP PDU dump ends.
>
> But when submitting Unicode message in TLV 0x424 field and coding=2 and
> char-set=utf-8, message is not converted to ucs2 and delivered as
> something that looks like Chinese.
>
> kannel.conf configured with
>
> group = smpp-tlv
> name = message-payload
> smsc-id = 123
> tag = 0x0424
> type = nulterminated
> length = 65535
>
> =2=utf8==%3Fsmpp%3Fmessage-payload%3D%=Unicode+Greek+Όλα
> Καλά
>
> [6] DEBUG:    Octet string at 0x7fe9e8006e10:
> 2020-05-25 21:05:11 [24722] [6] DEBUG:  len:  29
> 2020-05-25 21:05:11 [24722] [6] DEBUG:  size: 30
> 2020-05-25 21:05:11 [24722] [6] DEBUG:  immutable: 0
> 2020-05-25 21:05:11 [24722] [6] DEBUG:  data: 55 6e 69 63 6f 64 65
> 20 47 72 65 65 6b 20 ce 8c   Unicode Greek ..
> 2020-05-25 21:05:11 [24722] [6] DEBUG:  data: ce bb ce b1 20 ce 9a
> ce b1 ce bb ce ac     
> 2020-05-25 21:05:11 [24722] [6] DEBUG:    Octet string dump ends.
> 2020-05-25 21:05:11 [24722] [6] DEBUG: SMPP PDU dump ends.
>
> When using GSM-7 encoded message in in TLV 0x424 field, message
> delivered correctly.
>
> Is it a bug?  Or I am doing encoding meta-data wrong?
>
>

Re: [RFC] smsbox dead-lock on shutdown

[Alexander Malysh]

Hi,

agree that 240 sec timeout is too high. I think max 30 sec , should be enough.

Alex
Am 5. Nov. 2020, 11:58 +0100 schrieb Stipe Tolj :
> Am 05.11.20, 10:41, schrieb Stipe Tolj:
> > Hi all,
> >
> > I got across and issue on the shutdown sequence of Kannel smsbox, that
> > seems to me like a potential dead-lock situation while shutdown phase.
> >
> > On a loaded system bearerbox was SIGHUP'ed and hence instructed it's
> > connected smsbox to go down too.
> >
> > Bearerbox didn't shutdown cleanly, so forced a 'kill -9' to get it down.
> > Through the smsbox still maintained running, and I looked into the gdb
> > backtrace of the process a bit more.
> >
> > What I see is this: (BTW, the line numbers don't match with the svn trunk).
> >
> > #1 0x0044596b in gwthread_join_every (func=0x41ba40
> > ) at gwlib/gwthread-pthread.c:744
> > #2 0x004142c8 in main (argc=,
> > argv=0x7fff05d24428) at gw/smsbox.c:3872
> >
> > so main() was blocking in the gwthread_join_every for the
> > obey_request_thread()s.
> >
> > They itself blocked in:
> >
> > #0 0x7f809e117bd1 in sem_wait () from /lib/libpthread.so.0
> > #1 0x0041bdcb in obey_request_thread (arg=)
> > at gw/smsbox.c:1346
> >
> > in the semaphore_down(max_pending_requests); all before a
> > http_start_request().
> >
> > Since we know that the semaphore_up() is performed in the
> > url_result_thread() when we got the response via
> > http_receive_result_real(), but that itself blocked in:
> >
> > #0 0x7f809e115d29 in pthread_cond_wait@@GLIBC_2.3.2 () from
> > /lib/libpthread.so.0
> > #1 0x0044e098 in gwlist_consume (list=0x1498e50) at
> > gwlib/list.c:478
> > #2 0x0044840c in http_receive_result_real (caller=0x1498e84,
> > status=0x44485054, final_url=0x44485018, headers=0x44484ff8,
> > body=0x44484fc8, blocking=1577) at gwlib/http.c:1764
> > #3 0x0041a98e in url_result_thread (arg=)
> > at gw/smsbox.c:1105
> >
> > so in the gwlist_consume() on the HTTPCaller *caller.
> >
> > Now, checking the the shutdown sequence in main() we see that we do:
> >
> > ...
> > gwthread_join_every(obey_request_thread);
> > http_caller_signal_shutdown(caller);
> > gwthread_join_every(url_result_thread);
> > ...
> >
> > so we remove the producer on HTTPCaller *caller AFTER we join the
> > obey_request_thread()s, which are performing the semaphore_down.
> >
> > This ends up in a dead-lock situation IMO.
> >
> > Resolution should be simply to move the http_caller_signal_shutdown()
> > before gwthread_join_every(obey_request_thread) in the shutdown sequence.
> >
> > Any comments, reviews are highly welcome.
>
> ok, this is NOT blocking fully. It does block for any HTTP requests that
> are performed against "bogus IP ranges", i.e. unrouted C-class 10.x.x.x
> ranges, and blocks while we have out client timeout running, which is
> 240 seconds by default.
>
> If we set
>
> group = smsbox
> ...
> http-timeout = 10
>
> then we get it unblocked and shutdown cleanly.
>
> So, forget about the dead-lock claim I made. The only thing that we MAY
> want here is to have a more realistic TCP connection timeout?
>
> Stipe
>
> --
> Best Regards,
> Stipe Tolj
>
> ---
> Düsseldorf, NRW, Germany
>
> Kannel Foundation tolj.org system architecture
> http://www.kannel.org/ http://www.tolj.org/
>
> st...@kannel.org s...@tolj.org
> ---
>

RE: Patch for opensmppbox

[Alexander Malysh]

Hi,

pushed to upstream.

Thanks,
Alex
Am 23. Sept. 2020, 23:35 +0200 schrieb Rene Kluwen :
> +1 for me. Please commit.
>
> Van: devel  Namens Alexander Malysh
> Verzonden: woensdag 23 september 2020 20:56
> Aan: Akis Stamatiou 
> CC: devel@kannel.org
> Onderwerp: Re: Patch for opensmppbox
>
> Hi,
>
> looks ok, +1 from me.
>
> Any objections or should I commit it ?
>
> Thanks,
> Alex
>
>
>
> > Am 16.09.2020 um 11:00 schrieb Akis Stamatiou 
> > :
> >
> > Dear Kannel,
> >
> > We are submitting for your consideration a patch for opensmppbox.
> >
> > As per https://www.kannel.org/download.shtml#svn, you may find in the 
> > email, as plain text, the output of svn diff.
> >
> > Thank you,
> >
> > Akis Stamatiou
> > Technical Product Manager
> > T +302106618500 (ext.279)
> > M +306986973922
> > Skype: live:stamprok_1
> >
> >
> > PRIVILEGED AND CONFIDENTIAL COMMUNICATION
> >
> > This e-mail transmission, and any documents, files or previous e-mail 
> > messages attached to it, may contain confidential information that is 
> > legally privileged. If you are not the intended recipient or a person 
> > responsible for delivering it to the intended recipient, you are hereby 
> > notified that any disclosure, copying, distribution or use of any of the 
> > information contained in or attached to this transmission is STRICTLY 
> > PROHIBITED. If you have received this transmission in error, please: (1) 
> > immediately notify me by reply e-mail, or by collect telephone call; and 
> > (2) destroy the original transmission and its attachments without reading 
> > or saving in any manner.
> > 
>

Re: Patch for opensmppbox

[Alexander Malysh]

Hi,

looks ok, +1 from me.

Any objections or should I commit it ?

Thanks,
Alex


> Am 16.09.2020 um 11:00 schrieb Akis Stamatiou 
> :
> 
> Dear Kannel,
> 
> We are submitting for your consideration a patch for opensmppbox.
> 
> As per https://www.kannel.org/download.shtml#svn 
> , you may find in the email, as 
> plain text, the output of svn diff.
> 
> Thank you,
> 
>  
>   
> Akis Stamatiou
> 
> Technical Product Manager
> 
> 
> 
>    
>   
>  
>   
>   
>   
>  
>   
> T +302106618500 (ext.279) 
> M +306986973922 
> Skype: live:stamprok_1 <>
>  
> 
> PRIVILEGED AND CONFIDENTIAL COMMUNICATION
> 
> This e-mail transmission, and any documents, files or previous e-mail 
> messages attached to it, may contain confidential information that is legally 
> privileged. If you are not the intended recipient or a person responsible for 
> delivering it to the intended recipient, you are hereby notified that any 
> disclosure, copying, distribution or use of any of the information contained 
> in or attached to this transmission is STRICTLY PROHIBITED. If you have 
> received this transmission in error, please: (1) immediately notify me by 
> reply e-mail, or by collect telephone call; and (2) destroy the original 
> transmission and its attachments without reading or saving in any manner.
> 

Re: Question about bearerbox throttling

[Alexander Malysh]

Hello Akis,

please don’t crosspost users and devel ML. 

Can you share the whole bearerbox config? 

Thanks,
Alex


> Am 26.05.2020 um 12:21 schrieb Akis Stamatiou 
> :
> 
> Hello,
> We have created a configuration with opensmppbox, smsbox and bearerbox.
> We send sms through the smsbox endpoint, we use loopback to route it as mo 
> and finally route it to the opensmppbox to be sent as deliver_sm to the 
> client.
> We are running some tests in our setup and we noticed that while the smsbox 
> accepts the messages at the rate we are sending them, 
> the bearerbox throttled to 100 tps for some reason.
> We cannot find anything to change this throttling in the configuration.
> Could you please advise?
> 
> 
> Relevant configuration:
> 
> kannel.conf
> #-
> # REDIRECT MT AS MO
> #-
> group = smsc
> smsc = loopback
> smsc-id = mobouncer
> denied-smsc-id = PERF
> #-
> # SEND-SMS USERS
> #-
> group = sendsms-user
> username = tester
> password = t3st3r
> max-messages = 3
> concatenation = true
> #-
> # SERVICES
> # curl -vvv 
> 'http://localhost:13004/cgi-bin/sendsms?username=tester=t3st3r=1234=1234567890=test=mobouncer
>  
> '
> #-
> group = smsbox
> bearerbox-host = localhost
> sendsms-port = 13004
> log-file = "/applogs/kannel/smsbox.log"
> access-log = "/applogs/kannel/smsbox-access.log"
> log-level = 1
> # SERVICES
> group = sms-service
> keyword-regex = ".*"
> max-messages = 0
> text = "WRONG SMSBOX"
> #-
> # USE OPNSMPPBOX FOR DELIVER_SM & DLRs
> #-
> group = smsbox-route
> smsbox-id = "system-id-in-clients-txt"
> smsc-id = "mobouncer"
> ```
> opensmppbox.conf
> ```
> # opensmppbox.conf
> #
> # Core configuration
> #
> group = core
> dlr-storage = internal
> group = opensmppbox
> bearerbox-host = 127.0.0.1
> bearerbox-port = 13001
> opensmppbox-id = perf
> opensmppbox-port = 13003
> log-file = "/applogs/kannel/opensmppbox.log"
> log-level = 1
> our-system-id = system-id
> route-to-smsc = PERF 
> smpp-logins = /opt/kannel/config/clients
> use-systemid-as-smsboxid = true
> 
> Thank you,
> Akis
> 
> 
>  
> 
> PRIVILEGED AND CONFIDENTIAL COMMUNICATION
> 
> This e-mail transmission, and any documents, files or previous e-mail 
> messages attached to it, may contain confidential information that is legally 
> privileged. If you are not the intended recipient or a person responsible for 
> delivering it to the intended recipient, you are hereby notified that any 
> disclosure, copying, distribution or use of any of the information contained 
> in or attached to this transmission is STRICTLY PROHIBITED. If you have 
> received this transmission in error, please: (1) immediately notify me by 
> reply e-mail, or by collect telephone call; and (2) destroy the original 
> transmission and its attachments without reading or saving in any manner.

Re: [PATCH] Support for 'reroute-receiver-regex' in 'group = smsc' context

[Alexander Malysh]

Hi Stipe,

not tested, but looks ok. +1

Alex

P.S. Let’s do a new stable release.

> Am 03.06.2020 um 15:33 schrieb Stipe Tolj  >:
> 
> Hi all,
> 
> at the moment we can define an explicit list of receiver numbers that we want 
> to be re-routed to a connected smsc-id B when receiving an MO on a smsc-id A, 
> but we can't define any number ranges or other patterns of the receiver 
> number.
> 
> Adding now the support for 'reroute-receiver-regex' which allows to define 
> regular expressions instead of explicit receiver numbers only.
> 
> The patchset is pretty straight forward. Please find it attached and feel 
> free to review. I'll commit it to svn trunk in the coming days if there are 
> no objections.
> 
> The diffstat is:
> doc/userguide/userguide.xml |   15 ++
> gw/bb_smscconn.c|   64 +++--
> gw/smscconn.c   |   96 
> +++-
> gw/smscconn_p.h |8 +++
> gwlib/cfg.def   |1
> 5 files changed, 145 insertions(+), 39 deletions(-)
> 
> BTW, I would like to enroll some more changes into the svn trunk soon, which 
> includes mainly the way how "pattern matching" and "message constraint 
> matching" is performed. We have some sweet constructs for this here that we 
> want to get public.
> 
> So this would be a good time to have another round of stable release declared 
> and then go on with the changes/commits to result in a new devel release.
> 
> -- 
> Best Regards,
> Stipe Tolj
> 
> ---
> Düsseldorf, NRW, Germany
> 
> Kannel Foundation tolj.org  system 
> architecture
> http://www.kannel.org/ 
> http://www.tolj.org/ 
> 
> st...@kannel.org   s...@tolj.org 
> 
> ---
> 

Re: Bug in the init_smsbox_routes of gw/bb_box.c

[Alexander Malysh]

Hi,

commited to svn , thx!

Alex


> Am 06.08.2019 um 14:52 schrieb Денис Давыдов :
> 
> Hello, 
> 
> I found that the smsc_ids octet string is not destroyed in the 
> init_smsbox_routes function where smsc-id and shortcode are defined. See 
> attached patch. This is for 5282 revision and older.
> 
> --
> Regards,
> Denis S.Davydov
> 

Re: Patch to avoid panic of opensmppbox and add EXPIRE status

[Alexander Malysh]

Hi,

committed to SVN, thanks!

Alex


> Am 24.11.2017 um 12:03 schrieb Денис Давыдов :
> 
> Hi,
> 
> I had crashed the opensmppbox when I've used smsc-route group to route MT 
> messages out of the box. For example, if you add such block to route MT from 
> esme test1 to the smsc jasper you'll get panic:
> 
> group = smsc-route
> smsbox-id = test1
> smsc-id = jasper
> 
> 2017-11-16 10:36:32 [1578] [0] INFO: Starting to log to file 
> /var/log/kannel/opensmppbox.log level 0
> 2017-11-16 10:36:32 [1578] [0] INFO: Added logfile 
> `/var/log/kannel/opensmppbox.log' with level `0'.
> 2017-11-16 10:36:32 [1578] [0] DEBUG: Adding smsc routing to id  for 
> box id 
> 2017-11-16 10:36:32 [1578] [0] PANIC: gwlib/octstr.c:2564: seems_valid_real: 
> Assertion `ostr->data != NULL' failed. (Called from 
> gwlib/octstr.c:325:octstr_destroy.)
> 2017-11-16 10:36:32 [1578] [0] PANIC: 
> /usr/local/kannel/sbin/opensmppbox(gw_backtrace+0xae) [0x45654e]
> 2017-11-16 10:36:32 [1578] [0] PANIC: 
> /usr/local/kannel/sbin/opensmppbox(gw_panic+0x15f) [0x4566bf]
> 2017-11-16 10:36:32 [1578] [0] PANIC: /usr/local/kannel/sbin/opensmppbox() 
> [0x45dac0]
> 2017-11-16 10:36:32 [1578] [0] PANIC: 
> /usr/local/kannel/sbin/opensmppbox(octstr_destroy+0x1d) [0x45dfbd]
> 2017-11-16 10:36:32 [1578] [0] PANIC: 
> /usr/local/kannel/sbin/opensmppbox(main+0x8bc) [0x40bf6c]
> 2017-11-16 10:36:32 [1578] [0] PANIC: 
> /lib64/libc.so.6(__libc_start_main+0xf5) [0x75e7cc05]
> 2017-11-16 10:36:32 [1578] [0] PANIC: /usr/local/kannel/sbin/opensmppbox() 
> [0x40c82a]
> 
> There's an issue of freeing of unallocated pointers. This has been fixed.
> 
> Another issue found in delivery receipt with EXPIRE status that coming from 
> smsc to esme with "stat:(null)" status instead of EXPIRED. I have added the 
> EXPIRE status in msg_to_pdu of opensmppbox. In some cases it's very important 
> to get this status instead of "(null)" value in delivery receipt. 
> 
> See attached patch. Please share any feedback.
> 
> Thank you.
> 
> --
> Regards,
> Denis S.Davydov
> 

Re: [PATCH] http PUT requests

[Alexander Malysh]

Hi,

committed to SVN, Thanks for this patch!

Alex


> Am 19.07.2019 um 17:52 schrieb Lamasuta, Franck, Vodafone Automotive 
> :
> 
> Hi,
>  
> The new patch tries to parse the vars in the URL then checks the content-type 
> value before trying to parse the request body (the RFC doesn’t prevent to 
> have vars in the URL andin the body).
> Also, I have optimized parse_cgivars() by using an index to avoid a copy of 
> the string, some deletes and a destroy.
>  
> Regards,
> Franck
>  
>  
> From: devel  On Behalf Of Lamasuta, Franck, 
> Vodafone Automotive
> Sent: mercredi 17 juillet 2019 12:16
> To: Alexander Malysh 
> Cc: devel@kannel.org
> Subject: RE: [PATCH] http PUT requests
>  
> I’m working on it…
>  
>  
> From: Alexander Malysh mailto:malys...@gmail.com>> On 
> Behalf Of Alexander Malysh
> Sent: vendredi 12 juillet 2019 15:01
> To: Lamasuta, Franck, Vodafone Automotive  <mailto:franck.lamas...@vodafone.com>>
> Cc: devel@kannel.org <mailto:devel@kannel.org>
> Subject: Re: [PATCH] http PUT requests
>  
> Hi,
>  
> 
> Am 11.07.2019 um 14:24 schrieb Lamasuta, Franck, Vodafone Automotive 
> mailto:franck.lamas...@vodafone.com>>:
>  
> I thought again about it…
> I guess you are concerned because the body of all POST or PUT requests would 
> be parsed.
> Of course this is bad!   J
>  
> exactly...
>  
> 
> I think we have to check the value of the Content-Type header.
>  
> This is what we get from Micro Ocean:
> Content-Type: application/x-www-form-urlencoded
> 
> Would it be ok to test this header before calling parse_cgivars() to parse 
> the body?
> Do you have another idea?
>  
> This should work.
>  
> Thanks,
> Alex
>  
> 
>  
> Regards,
> Franck
>  
>  
> From: devel mailto:devel-boun...@kannel.org>> On 
> Behalf Of Lamasuta, Franck, Vodafone Automotive
> Sent: jeudi 11 juillet 2019 12:06
> To: Alexander Malysh mailto:amal...@kannel.org>>
> Cc: devel@kannel.org <mailto:devel@kannel.org>
> Subject: RE: [PATCH] http PUT requests
>  
> Hi Alexander,
>  
> This is what http_accept_request() logs (with my patch) when Micro Ocean 
> submits a DLR:
>  
> 2019-07-10 13:21:05 [5746] [7] DEBUG: HTTP: Got PUT request with 
> url='/MOcean-Kannel/DLR' and 
> body='mocean-from=33123456789=Mocean=1=0710212043806340=0'
>  
> As you can see, the query variables are in the body of the request. I think 
> this is usual for a PUT (and for a POST).
> To avoid code duplication, it seemed logical to slightly modify 
> parse_cgivars() to parse the body.
> How would you manage this?
>  
> Regards,
> Franck
>  
>  
> From: Alexander Malysh mailto:malys...@gmail.com>> On 
> Behalf Of Alexander Malysh
> Sent: mardi 9 juillet 2019 08:42
> To: Lamasuta, Franck, Vodafone Automotive  <mailto:franck.lamas...@vodafone.com>>
> Cc: devel@kannel.org <mailto:devel@kannel.org>
> Subject: Re: [PATCH] http PUT requests
>  
> Hi,
>  
> sorry for delay. Patch would be ok if not this part where you parse body for 
> post and put request
> as cgi vars. this is wrong. Please fix it and resubmit.
>  
> Thanks,
> Alexander Malysh
>  
>  
> 
> Am 28.06.2019 um 10:58 schrieb Lamasuta, Franck, Vodafone Automotive 
> mailto:franck.lamas...@vodafone.com>>:
>  
> Hi list,
>  
> Here is a patch to allow inbound http PUT requests in generic http connector.
> It is required to implement Micro Ocean’s API for Delivery Reports: 
> https://www.moceanapi.com/docs/#delivery-report 
> <https://www.moceanapi.com/docs/#delivery-report>
>  
> Regards,
> Franck
> 
>  
>  
> 

Re: Mysql 8.x will not compile with latest Kannel

[Alexander Malysh]

Hi,

yes, I already saw it. Fixed in SVN.

Alex


> Am 02.08.2019 um 17:18 schrieb Werner Coetzee :
> 
> Compare pre-8 documentation (e.g. 5.5 
> https://dev.mysql.com/doc/refman/5.5/en/c-api-data-structures.html 
> <https://dev.mysql.com/doc/refman/5.5/en/c-api-data-structures.html> ) to 
> mysql 8.0 
> documentationhttps://dev.mysql.com/doc/refman/8.0/en/c-api-data-structures.html
>  <https://dev.mysql.com/doc/refman/8.0/en/c-api-data-structures.html>
>  
> For 8 it says:
> my_bool: A boolean type, for values that are true (nonzero) or false (zero). 
> The my_bool type was used before MySQL 8.0. As of MySQL 8.0, use the bool or 
> int C type instead.
> NOTE: The change from my_bool to bool means that the mysql.h header file 
> requires a C++ or C99 compiler to compile.
>  
> So maybe dbpool_mysql.c can do with a #if MYSQL_VERSION_ID check? e.g.
>  
> #if MYSQL_VERSION_ID >= 8
> typedef int my_bool;
> #endif
>  
> Werner
>  
>  
> Werner Coetzee​
> C Developer
>  
> werner.coet...@clickatell.com <mailto:werner.coet...@clickatell.com>
>  
> +27 (21) 910 7700
> 
> From: devel  On Behalf Of Hillel Bilman
> Sent: 02 August 2019 16:30
> To: Alexander Malysh 
> Cc: Kannel Devel 
> Subject: Mysql 8.x will not compile with latest Kannel
> 
>  
> Hi Alex,
>  
> The server I'm using has:
> Mysql 8.0.17
> Centos 7.x
> Kannel  svn-r5278M (latest version from svn)
>  
> Latest Kannel SVN will not compile with Mysql 8.0.17.
> This error with Mysql 8.x was reported in redmine 08/18/2018  
> https://redmine.kannel.org/issues/782 
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fredmine.kannel.org%2Fissues%2F782=02%7C01%7C%7C0d7a493199de4c4ae61408d717560036%7Cf05b82000f184302889e9f6703297586%7C0%7C0%7C637003530455590653=S%2FjJrklB%2BM%2FtVaIQ9bU51KrWit7baFk7LzyrnyLf5bA%3D=0>
> But there does not seem to be any reported solution.
>  
> Any help is appreciated to be able to compile Kannel.
>  
> Steps using to compile Kannel:
> svn co https://svn.kannel.org/gateway/trunk/ 
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsvn.kannel.org%2Fgateway%2Ftrunk%2F=02%7C01%7C%7C0d7a493199de4c4ae61408d717560036%7Cf05b82000f184302889e9f6703297586%7C0%7C0%7C637003530455600647=jXRnV%2Blvm8ThzHynnpyo1PFsSzUcr8OdCCDphFmoOFc%3D=0>
>   gateway
> cd gateway
> ./bootstrap.sh
> ./configure --with-defaults=speed --with-mysql  --enable-start-stop-daemon 
> --enable-ssl  --disable-localtime  --enable-cookies 
> make;make install
>  
> Configuring for Kannel gateway version svn-r5278M ... 
>  ..
> Showing the database section with the two WARNINGs:
> Configuring DB support ...
> checking whether to compile with MySQL support... searching
> checking for mysql_config... /bin/mysql_config
> checking mysql version... 8.0.17
> checking mysql reentrant libs... -L/usr/lib64/mysql -lmysqlclient -lpthread 
> -lm -lrt -lssl -lcrypto -ldl
> checking for mysql_init in -lmysqlclient_r... no
> checking mysql libs... -L/usr/lib64/mysql -lmysqlclient -lpthread -lm -lrt 
> -lssl -lcrypto -ldl
> checking for mysql_init in -lmysqlclient... yes
> checking mysql includes... -I/usr/include/mysql
> checking mysql/mysql.h usability... yes
> checking mysql/mysql.h presence... no
> configure: WARNING: mysql/mysql.h: accepted by the compiler, rejected by the 
> preprocessor!
> configure: WARNING: mysql/mysql.h: proceeding with the compiler's result
> checking for mysql/mysql.h... yes
> checking mysql/mysql_version.h usability... yes
> checking mysql/mysql_version.h presence... yes
> checking for mysql/mysql_version.h... yes
> checking for mysql_stmt_init in -lmysqlclient_r... no
> checking for mysql_stmt_init in -lmysqlclient... yes
> checking whether to compile with MySQL support... yes
> checking whether to compile with LibSDB support... disabled
> checking whether to compile with SQLite2 support... disabled
> checking whether to compile with SQLite3 support... disabled
> checking whether to compile with Oracle support... disabled
> checking whether to compile with PostgresSQL support... disabled
> checking whether to compile with Redis support... disabled
> checking whether to compile with FreeTDS Ct-Lib support... disabled
> checking whether to compile with Cassandra support... disabled
>  
> root@eco007-truservcomm-jhb1-001 /home/kannel/gateway $ make
> make  all-recursive
> make[1]: Entering directory `/home/kannel/gateway'
> Making all in gwlib
> make[2]: Entering directory `/home/kannel/gateway/gwlib'
> /bin/sh ../libtool  --tag=CC   --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H 
> -I. -I.. -g -O2 -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE 
> -D_LARGE_FI

Re: [PATCH] http PUT requests

[Alexander Malysh]

Hi,

> Am 11.07.2019 um 14:24 schrieb Lamasuta, Franck, Vodafone Automotive 
> :
> 
> I thought again about it…
> I guess you are concerned because the body of all POST or PUT requests would 
> be parsed.
> Of course this is bad!   J

exactly...

> I think we have to check the value of the Content-Type header.
>  
> This is what we get from Micro Ocean:
> Content-Type: application/x-www-form-urlencoded
> 
> Would it be ok to test this header before calling parse_cgivars() to parse 
> the body?
> Do you have another idea?

This should work.

Thanks,
Alex

>  
> Regards,
> Franck
>  
>  
> From: devel  On Behalf Of Lamasuta, Franck, 
> Vodafone Automotive
> Sent: jeudi 11 juillet 2019 12:06
> To: Alexander Malysh 
> Cc: devel@kannel.org
> Subject: RE: [PATCH] http PUT requests
>  
> Hi Alexander,
>  
> This is what http_accept_request() logs (with my patch) when Micro Ocean 
> submits a DLR:
>  
> 2019-07-10 13:21:05 [5746] [7] DEBUG: HTTP: Got PUT request with 
> url='/MOcean-Kannel/DLR' and 
> body='mocean-from=33123456789=Mocean=1=0710212043806340=0'
>  
> As you can see, the query variables are in the body of the request. I think 
> this is usual for a PUT (and for a POST).
> To avoid code duplication, it seemed logical to slightly modify 
> parse_cgivars() to parse the body.
> How would you manage this?
>  
> Regards,
> Franck
>  
>  
> From: Alexander Malysh mailto:malys...@gmail.com>> On 
> Behalf Of Alexander Malysh
> Sent: mardi 9 juillet 2019 08:42
> To: Lamasuta, Franck, Vodafone Automotive  <mailto:franck.lamas...@vodafone.com>>
> Cc: devel@kannel.org <mailto:devel@kannel.org>
> Subject: Re: [PATCH] http PUT requests
>  
> Hi,
>  
> sorry for delay. Patch would be ok if not this part where you parse body for 
> post and put request
> as cgi vars. this is wrong. Please fix it and resubmit.
>  
> Thanks,
> Alexander Malysh
>  
>  
> 
> Am 28.06.2019 um 10:58 schrieb Lamasuta, Franck, Vodafone Automotive 
> mailto:franck.lamas...@vodafone.com>>:
>  
> Hi list,
>  
> Here is a patch to allow inbound http PUT requests in generic http connector.
> It is required to implement Micro Ocean’s API for Delivery Reports: 
> https://www.moceanapi.com/docs/#delivery-report 
> <https://www.moceanapi.com/docs/#delivery-report>
>  
> Regards,
> Franck
> 
>  

Re: [PATCH] SMSC cluster

[Alexander Malysh]

Hi,

just fixed CIMD2 DLR handling to use smsc-id instead of name.

Thanks,
Alex

> Am 28.06.2019 um 10:18 schrieb Lamasuta, Franck, Vodafone Automotive 
> :
> 
> Hi,
>  
> I think it is not flexible enough to rely on smsc-id to manage the pending 
> DLRs.
> We use already the status endpoint provided by Kannel to monitor the binds 
> and trigger alerts.
> But we want to know which path (bind) a MO-SMS took and store this in our 
> database. Then we can use this info to draw charts with the throughput of 
> each bind on different time periods and to detect issues.
>  
> Another solution to keep this flexibility would be to add an optional config 
> parameter (something like pending-dlr-id). If it is not defined then smsc-id 
> would be used as a fallback (to be compatible with current behavior).
> What do you think?
>  
> Regards,
> Franck
>  
>  
> From: Alexander Malysh  On Behalf Of Alexander Malysh
> Sent: vendredi 28 juin 2019 09:43
> To: Alejandro Guerrieri 
> Cc: Lamasuta, Franck, Vodafone Automotive ; 
> devel@kannel.org
> Subject: Re: [PATCH] SMSC cluster
>  
> Hi,
>  
> I’m agree with Alejandro. For SMPP we don’t need such patch but for the CIMD2 
> we have to fix it to conn->id if it’s not used
> there.
>  
> Thanks,
> Alex
>  
> 
> 
> Am 26.06.2019 um 15:13 schrieb Alejandro Guerrieri 
> mailto:alejandro.guerri...@gmail.com>>:
>  
> Franck,
>  
> Thank you for clarifying.
>  
> Regarding SMPP, you are using your application to indirectly diagnose problem 
> with your binds. Kannel has a status endpoint that you can use to monitor the 
> bind status directly instead of "bubbling-up" the problem to your application 
> layer.
> 
> You have a point on CIMD2, though iMHO that is a "bug" in Kannel: all 
> connectors should use the same naming strategy. I don't know how likely is 
> the scenario of having multi-protocol binds sharing SMS traffic, but in 
> Kannel's current state it is the only case where this patch would make a 
> difference. In my opinion, the right answer is to make the naming convention 
> consistent so DLR's can be resolved across different protocols.
>  
> Regards,
>  
> Alejandro
>  
> On Wed, Jun 26, 2019 at 4:11 AM Lamasuta, Franck, Vodafone Automotive 
> mailto:franck.lamas...@vodafone.com>> wrote:
> Hi Alejandro,
>  
> I know we could use identical smsc-ids but…
>  
> 1) It does not work for CIMD2 because dlr_add() and dlr_find() are called 
> with conn->name which is built with the IP and port.
>  
> 2) It could work with SMPP (because dlr_add() and dlr_find() are called with 
> conn->id) but…
> When a MO-SMS is received, the smsc-id is assigned to the message and 
> forwarded to our back-end by smsbox.
> We use this id to monitor the incoming traffic on each bind and detect issues 
> (e.g. when the MO-SMS rate is below a threshold).
> With identical smsc-ids, we could have an issue on one of the binds (with the 
> bind still up) and not be able to detect it. Therefore we do prefer to have 
> different smsc-ids.
> 
> The patch only uses smsc-username which is (AFAIK) always the same with 
> multiple binds.
> It is more flexible in my opinion.
>  
> Regards,
> Franck
>  
>  
> From: Alejandro Guerrieri  <mailto:alejandro.guerri...@gmail.com>> 
> Sent: mercredi 26 juin 2019 00:27
> To: Lamasuta, Franck, Vodafone Automotive  <mailto:franck.lamas...@vodafone.com>>
> Cc: devel@kannel.org <mailto:devel@kannel.org>
> Subject: Re: [PATCH] SMSC cluster
>  
> I'm curious why do you even need this patch? You could use the same smsc-id 
> on both and assign different smsc-admin-id values to manage each bind 
> separately (e.g. start/stop). If by any reason you'd want to send over a 
> specific bind, you could use different allowed-smsc-id's as well.
>  
> Regards,
>  
> Alejandro
>  
> On Tue, Jun 25, 2019 at 12:20 PM Lamasuta, Franck, Vodafone Automotive 
> mailto:franck.lamas...@vodafone.com>> wrote:
> Hi list,
>  
> We have implemented many patches along the way and I can finally take some 
> time to submit them.
> They are running on our staging and production platforms since years for the 
> oldest ones.
> I will submit them one by one in the next days/weeks.
> Let’s start with the first one…   J
>  
> This patch allows Kannel to retrieve a pending DLRs in its database when 2 
> (or more) SMSC binds are established (with different IPs and/or ports).
> It is required when a MT-SMS is submitted to SMSC A and its DLR is sent back 
> by SMSC B.
> Done for CIMD2 and SMPP.
>  
> Example of configuration where the patch is required:
>  
> #
> # Primary server
> #
> group = smsc
> smsc = cimd2
> smsc-id = SMSC-A
> host = 123.1.2.3
> port = 6001
> smsc-username = user
> smsc-password = 
> allowed-smsc-id = id1
> preferred-smsc-id = id1
>  
> #
> # Secondary server
> #
> group = smsc
> smsc = cimd2
> smsc-id = SMSC-B
> host = 123.1.2.3
> port = 6002
> smsc-username = user
> smsc-password = 
> allowed-smsc-id = id1
>  
>  
> Regards,
> Franck
>  

Re: [PATCH] Clickatell

[Alexander Malysh]

Hi,

commited to SVN. Thanks!

Alex

> Am 01.07.2019 um 19:10 schrieb Lamasuta, Franck, Vodafone Automotive 
> :
> 
> Hi list,
>  
> Here is a patch to improve Clickatell HTTP API support: 
> https://archive.clickatell.com/developers/api-docs/http-overview/ 
> 
> The patch was required to send MT-SMS to US customers (two-way number).
>  
> Main changes:
> - Better support of Clickatell HTTP API (Developer’s Central): from, mo, 
> validity and callback parameters
> - Better DLR and error management
>  
> Minor changes:
> - Removed useless struct field (conndata->proxy)
> - Fixed code indentation
> - Removed tabs in cfg.def
> - User guide: Fixed invalid character entities ( and ) + Fixed 
> literals (& and >)
>  
> Regards,
> Franck
> 

Re: [PATCH] http PUT requests

[Alexander Malysh]

Hi,

sorry for delay. Patch would be ok if not this part where you parse body for 
post and put request
as cgi vars. this is wrong. Please fix it and resubmit.

Thanks,
Alexander Malysh


> Am 28.06.2019 um 10:58 schrieb Lamasuta, Franck, Vodafone Automotive 
> :
> 
> Hi list,
>  
> Here is a patch to allow inbound http PUT requests in generic http connector.
> It is required to implement Micro Ocean’s API for Delivery Reports: 
> https://www.moceanapi.com/docs/#delivery-report 
> <https://www.moceanapi.com/docs/#delivery-report>
>  
> Regards,
> Franck
> 

Re: [PATCH] SMSC cluster

[Alexander Malysh]

Hi,

I’m agree with Alejandro. For SMPP we don’t need such patch but for the CIMD2 
we have to fix it to conn->id if it’s not used
there.

Thanks,
Alex


> Am 26.06.2019 um 15:13 schrieb Alejandro Guerrieri 
> :
> 
> Franck,
> 
> Thank you for clarifying.
> 
> Regarding SMPP, you are using your application to indirectly diagnose problem 
> with your binds. Kannel has a status endpoint that you can use to monitor the 
> bind status directly instead of "bubbling-up" the problem to your application 
> layer.
> 
> You have a point on CIMD2, though iMHO that is a "bug" in Kannel: all 
> connectors should use the same naming strategy. I don't know how likely is 
> the scenario of having multi-protocol binds sharing SMS traffic, but in 
> Kannel's current state it is the only case where this patch would make a 
> difference. In my opinion, the right answer is to make the naming convention 
> consistent so DLR's can be resolved across different protocols.
> 
> Regards,
> 
> Alejandro
> 
> On Wed, Jun 26, 2019 at 4:11 AM Lamasuta, Franck, Vodafone Automotive 
> mailto:franck.lamas...@vodafone.com>> wrote:
> Hi Alejandro,
> 
>  
> 
> I know we could use identical smsc-ids but…
> 
>  
> 
> 1) It does not work for CIMD2 because dlr_add() and dlr_find() are called 
> with conn->name which is built with the IP and port.
> 
>  
> 
> 2) It could work with SMPP (because dlr_add() and dlr_find() are called with 
> conn->id) but…
> When a MO-SMS is received, the smsc-id is assigned to the message and 
> forwarded to our back-end by smsbox.
> We use this id to monitor the incoming traffic on each bind and detect issues 
> (e.g. when the MO-SMS rate is below a threshold).
> 
> With identical smsc-ids, we could have an issue on one of the binds (with the 
> bind still up) and not be able to detect it. Therefore we do prefer to have 
> different smsc-ids.
> 
> 
> The patch only uses smsc-username which is (AFAIK) always the same with 
> multiple binds.
> 
> It is more flexible in my opinion.
> 
>  
> 
> Regards,
> 
> Franck
> 
>  
> 
>  
> 
> From: Alejandro Guerrieri  > 
> Sent: mercredi 26 juin 2019 00:27
> To: Lamasuta, Franck, Vodafone Automotive  >
> Cc: devel@kannel.org 
> Subject: Re: [PATCH] SMSC cluster
> 
>  
> 
> I'm curious why do you even need this patch? You could use the same smsc-id 
> on both and assign different smsc-admin-id values to manage each bind 
> separately (e.g. start/stop). If by any reason you'd want to send over a 
> specific bind, you could use different allowed-smsc-id's as well.
> 
>  
> 
> Regards,
> 
>  
> 
> Alejandro
> 
>  
> 
> On Tue, Jun 25, 2019 at 12:20 PM Lamasuta, Franck, Vodafone Automotive 
> mailto:franck.lamas...@vodafone.com>> wrote:
> 
> Hi list,
> 
>  
> 
> We have implemented many patches along the way and I can finally take some 
> time to submit them.
> They are running on our staging and production platforms since years for the 
> oldest ones.
> 
> I will submit them one by one in the next days/weeks.
> 
> Let’s start with the first one…   J
> 
>  
> 
> This patch allows Kannel to retrieve a pending DLRs in its database when 2 
> (or more) SMSC binds are established (with different IPs and/or ports).
> 
> It is required when a MT-SMS is submitted to SMSC A and its DLR is sent back 
> by SMSC B.
> 
> Done for CIMD2 and SMPP.
> 
>  
> 
> Example of configuration where the patch is required:
> 
>  
> 
> #
> 
> # Primary server
> 
> #
> 
> group = smsc
> 
> smsc = cimd2
> 
> smsc-id = SMSC-A
> 
> host = 123.1.2.3
> 
> port = 6001
> 
> smsc-username = user
> 
> smsc-password = 
> 
> allowed-smsc-id = id1
> 
> preferred-smsc-id = id1
> 
>  
> 
> #
> 
> # Secondary server
> 
> #
> 
> group = smsc
> 
> smsc = cimd2
> 
> smsc-id = SMSC-B
> 
> host = 123.1.2.3
> 
> port = 6002
> 
> smsc-username = user
> 
> smsc-password = 
> 
> allowed-smsc-id = id1
> 
>  
> 
>  
> 
> Regards,
> 
> Franck
> 

Re: [PATCH] fixing possible PANIC condition

[Alexander Malysh]

Thanks a lot.

Alex


Stipe Tolj  schrieb am Di., 25. Sep. 2018, 09:46:

> Am 19.09.2018 15:31, schrieb amal...@kannel.org:
> > Hi Stipe,
> >
> > is it not easier just check for conn != NULL at the place it passed to
> conn_unregister ?
> > assertion is very interesting at this place IMHO because it can show
> that someone try to unregister connection which is null but should not be
> null.
> > This prevents from resources leak.
>
> Hi Alex,
>
> hope you're doing fine.
>
> I agree, committed a fix for the possible PANIC condition by
> pre-checking before calling conn_unregister() in the handle_transaction().
>
> Stipe
>
> --
> Best Regards,
> Stipe Tolj
>
> ---
> Düsseldorf, NRW, Germany
>
> Kannel Foundation tolj.org system architecture
> http://www.kannel.org/http://www.tolj.org/
>
> stolj at kannel.org   st at tolj.org
> ---
>

RE: Sending TLV Parameters

[Alexander Malysh]

Hi,

you have to add metadata. Please check userguide, how to add it.
 

Thanks,
Alexander Malysh     From: AhmedNegm <ahmedn...@windowslive.com>
Sent: 12/06/2017 21:10
To: devel@kannel.org
Subject: Sending TLV Parameters
I have been requested from my SP to send TLV parameters while sending SMS,
so, I have configured Kannel.conf to have:

group = smpp-tlv
name = PRICEPOINT
tag = 0x1400
type = integer
length = 4
smsc-id = Ooredoo

group = smpp-tlv
name = PRODUCT
tag = 0x1401
type = integer
length = 4
smsc-id = Ooredoo

group = smpp-tlv
name = PARTNER_ROLE_ID
tag = 0x1402
type = integer
length = 4
smsc-id = Ooredoo

But also, I was not able to send the message as the SP got an exception on
SMSC which is related to PRICEPOINT, so, should I add something to this
callback??

http://localhost:13013/cgi-bin/sendsms?username==x==Test%20from%20Negm%20by%20Kannel=91823=Ooredoo



--
View this message in context: 
http://kannel.6189.n7.nabble.com/Sending-TLV-Parameters-tp32896.html
Sent from the Kannel - Dev mailing list archive at Nabble.com.

Re: smpp, cimd2 support for expired DLR

[Alexander Malysh]

Hi,

thanks, commited to SVN.

Thanks,
Alex


Iwan Iwanowicz  schrieb am So., 30. Okt. 2016 um
17:36 Uhr:

> Hi,
> Thanks for review.
> Fixed version in attachment.
>
> Best regards
> Marcin 'Iwan' K-k
>
> 2016-10-26 16:43 GMT+02:00 :
>
> Hi,
>
> patch looks mostly ok except this part:
>
> +if ( dlr_mask < -1 || dlr_mask > 255 ) { /*  */
>
> Why 255 ?
>
> Max dlr-msk what we have:
> #define DLR_UNKNOWN 0x40|DLR_FAIL
>
> => 66
>
> Please fix and if no objections I will commit it.
>
> Thanks,
> Alex
>
>
> Am 02.10.2016 um 21:07 schrieb Iwan Iwanowicz :
>
> Hi,
>
> Please take a look on smpp and cimd2 patch so now those protocols can
> support DLR_EXPIRED.
>
> Best regards
> Marcin 'Iwan' K-k.
> 
>
>
>
>

RE: [PATCH] Reduce logging in dbpool_mysql.c

[Alexander Malysh]

Hi,

definitely -1 for #ifdef. 
And I agree with Rene here, debug is debug and if you don't like it => don't 
enable it.
Kannel has enough infos what's going on even without debug enabled and if users
enable debug they don't have to complain about too much information.

Thanks,
Alexander Malysh   From: Stipe Tolj <st...@kannel.org>
Sent: Monday, September 26, 2016 07:35 PM
To:
Cc: kannel_dev_mailinglist <devel@kannel.org>
Subject: Re: [PATCH] Reduce logging in dbpool_mysql.c
Am 24.09.2016 13:57, schrieb Rene Kluwen:
> I don’t agree completely with your reasoning.
>
> Either you want debug information or you don’t.
>
> Enabling debug information yields a lot of information.
>
> What about if you want to debug the mysql pool usage?
>
> Still +0 from me in case it’s redundant info.

both points are viable. I know what Donald means here. He wants DEBUG
level, but not cluttered with "too much deep" info.

I would suggest wrapping the debug() line into a #ifdef DO_DEBUG which
CAN be defined in the header section of the source file itself. So
people CAN easily add it as extra DEBUG level information, but we
wouldn't see it in the "normal" DEBUG way.

--
Best Regards,
Stipe Tolj

---
Düsseldorf, NRW, Germany

Kannel Foundation tolj.org system architecture
http://www.kannel.org/ http://www.tolj.org/

stolj at kannel.org st at tolj.org
---

RE: [PATCH] Memory leak in smpp_pdu.c

[Alexander Malysh]

Hi,

good catch! But there is a question: should we really accept such wrong PDUs or 
reject them?
IMHO rejecting those would be the correct behavior but I don't see in SMPP spec 
that case described.

Thanks,
Alexander Malysh   From: Stipe Tolj <st...@kannel.org>
Sent: Monday, September 26, 2016 07:24 PM
To:
Cc: kannel_dev_mailinglist <devel@kannel.org>
Subject: Re: [PATCH] Memory leak in smpp_pdu.c
Am 24.09.2016 13:55, schrieb Rene Kluwen:
> +1 from me.

yep, good catch Donald.

+1 for it.

If no objections, will commit.

--
Best Regards,
Stipe Tolj

---
Düsseldorf, NRW, Germany

Kannel Foundation tolj.org system architecture
http://www.kannel.org/ http://www.tolj.org/

stolj at kannel.org st at tolj.org
---

Re: patch to allow data_coding to be set to 3

[Alexander Malysh]

Hi Hillel,

I have to agree to Andreas. You don’t need any special data coding because 
Kannel will do the whole
convert magic to GSM for you.

Alex

> Am 07.10.2015 um 15:24 schrieb Andreas Fink :
> 
> theres no need for having the SMSC do the latin1 to GSM transcoding as kannel 
> already does this.
> you feed kannel with latin1 or utf8 and kannel will make GSM out of it 
> automatically.
> 
> What matters at the end is what the handset receives and the GSM character 
> set is hardcoded in billions of phones. You can not send latin1 to phones but 
> you can send the GSM character set to phones which has a few more chars than 
> IA5 by now (by the use of some escape sequence they added things like | { } 
> if I remember correctly). And in GSM things are slightly differnet as @ for 
> example is encoded as 0x00.
> 
> Kannel does the conversion from whatever you feed it with to the GSM 
> character set. There is no need to set coding value for this. This is only 
> needed if you want to send raw bytes to kannel (and thus disable the internal 
> conversion) for example when you send binary data.
> 
> So the key is to have your character set properly set in your http request 
> header. Kannel defaults to UTF8. So when you feed latin1 characters to 
> kannel, they should be translated already correctly to GSM and have the DCS 
> values set correctly.
> 
> Its nice that Vodacom's SMSC has a _proprietary_ extension to do the  
> conversion in the SMSC but Kannel doesn't need it to operate correctly.
> 
>> On 07 Oct 2015, at 15:12, hbil...@ecommunicate.biz 
>>  wrote:
>> 
>> Hi Alex,
>> 
>> From this thread that you responded to see
>> http://www.kannel.org/pipermail/users/2012-April/017611.html 
>>  and the 
>> current
>> user guide, it seems Kannel has never allowed data_coding to be set to 3.
>> See  the coding parameter in the current spec
>> http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html#AEN5 
>> 
>> 058
>> Coding Accepts values 0 to 2, for 7bit, 8bit or UCS-2.
>> 0 causes data_coding 0 (for 7bit), 1 causes data_coding 4 (for 8bit) and 2
>> causes data_coding 8 (for UCS-2).
>> 
>> Vodacom SA which has the largest mobile network in SA, has said to send the
>> Extended GSM characters, we need to use Latin-1 characters and set our
>> data_coding field to 3 to tell the SMSC to translate the characters from
>> Latin-1 to GSM. (Note that standard ASCII and IA5 is a sub set of Latin-1.)
>> However, need to be able to send the extended GSM characters using 7 bits
>> without using Unicode as otherwise each SMS would then only be 70 characters
>> and our clients would require many more SMSs to send the same message.
>> 
>> Do you have a patch, that will allow Kannel users to set the coding
>> parameter to 3?
>> If not, would you be open to someone committing a patch for this?
>> 
>> Thanks for all the amazing work you do for Kannel.
>> 
>> Kind Regards
>> 
>> Hillel Bilman
>> Manager eCommunicate
>> mailto: hbil...@ecommunicate.co.za
>> Cell: 083-232
>> Landline: 011-443-6164
>> Fax: 088-011-443-6164
>> 
>> Mobile Wallets  - .mobi Sites – Mobile Apps(Android, iPhone, Blackberry,
>> Nokia) -  Premium Rated SMSs and short codes - SMS competitions and
>> campaigns – Lead Generation - opt-in subscription Billing – MMS campaigns -
>> USSD campaigns - WAP - Outlook SMS – Bulk SMS and Bulk Email – Email 2 SMS 2
>> Email - Developer Kit for Mobile Services integration - Voice Over IP
>> services
>> 
>> 
>> 
> 

Re: question about postgresql dlr storage

[Alexander Malysh]

Hi,

it should be converted to use prepared statements instead of plain sql string.

Patches are welcome…

Alex

 Am 04.08.2015 um 09:19 schrieb Marcin Matyaszczyk m.matyaszc...@ogicom.pl:
 
 Hello
 
 The sms is submited like this:
 
 http://localhost:13013/cgi-bin/sendsms?username=usernamepassword=passto=%2B485text=SMS+test+40from=Victoria%27ssmsc=smpp1tmobiledlr-mask=31priority=0dlr-url=http%3A%2F%2Fsmsc.host.pl%2Fdlr2.php%3Fid%3D145092731%26source%3Dred%26t%3D%25t%26i%3D%25i%26d%3D%25d%26D%3D%25D%26A%3D%25A%26F%3D%25F
 
 All fields are urlencoded,  problem is with insert query for dlr result
 (we think that the string €žsource is not escaped properly before insert
 to db).
 
 Pozdrawiam,
  Marcin Matyaszczyk
  Administrator
 
 Ogicom “Spider” Sp. z o.o. S.K.A., (61-131) Poznan, ul. Abpa Baraniaka
 88, REGON 634407251, NIP 781-17-20-476, Sad Rejonowy Poznan Nowe Miasto
 i Wilda w Poznaniu, VIII Wydzial Gospodarczy Krajowego Rejestru
 Sadowego, KRS 410900,  kapital zakladowy: 429 000 PLN.
 
 W dniu 04.08.2015 o 09:13, Jacek Raczkiewicz pisze:
 I think in postgres you need to escape single quote by doubling it:
 Victoria's - Victoria''s
 
 2015-08-04 9:08 GMT+02:00 spameden spame...@gmail.com
 mailto:spame...@gmail.com:
 
 
 
2015-08-03 18:24 GMT+03:00 Alvaro Cornejo cornejo.alv...@gmail.com
mailto:cornejo.alv...@gmail.com:
 
Hi Marcin
 
Seems you are getting the problem due to the ' on text
Victoria's. Even though you are urlencoding it, it seems it is
being taken as a field delimiter and not part of the text. I'm
thinking on two options:
 
-) Try to escape it with \' or \\' 
 
-) You might want to replace any ' within any field with ´ or  `
(right/left sided apostrophe)  before urlencoding the fields.
 
 
I think Marcin spot a bug when you're receiving returning DLR data
with ' (apostroph) it won't be escaped / urlencoded properly that's
why there is an error.
Would be nice to reproduce this bug somehow. 
 
 
Regards
 
Alvaro
 

 |-|
Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde
cualquier celular y Nextel
en el Perú, México y en mas de 180 paises. Use aplicaciones 2
vias via SMS y GPRS online
  Visitenos en www.perusms.com http://www.perusms.com
 
On Mon, Aug 3, 2015 at 9:15 AM, Marcin Matyaszczyk
m.matyaszc...@ogicom.pl mailto:m.matyaszc...@ogicom.pl wrote:
 
Hello
 
we have a problem with Postgresql DLR storage which looks
like a bug:
when we try to send sms with source field containing '
character we've
got an error:
 
2015-04-02 10:18:51 CEST STATEMENT:  INSERT INTO dlr
(smsc, ts,
source, destination, service, url, mask, boxc,
status)
VALUES ('smpp3', '', 'Victoria's', '+488
tel:%2B488', 'xx',

 'http://.domain.pl/dlr2.php?id=110725920source=XXXt=%ti=%id=%dD=%DA=%AF=%F',
'31', '', '0');
 
2015-04-02 10:21:51 CEST ERROR:  syntax error at or near s at
character 147
 
We urlencode all fields and sms is submitted ok to kannel,
problem
appears in dlr's insert query only. We use kannel 1.5.
 
regards
Marcin Matyaszczyk
 
 
 
 
 
 

Re: [PATCH] orig DLR bitmask passing back via DLR msg

[Alexander Malysh]

Hi Stipe,

 Am 16.07.2015 um 12:09 schrieb Stipe Tolj st...@kannel.org:
 
 Am 13.07.2015 17:50, schrieb Alexander Malysh:
 Hi Stipe,
 
 first of all I don’t get the intension for this feature? Please explain.
 
 Hi Alex,
 
 the intention was actually explained, let me enroll here. When the DLR gets 
 back to an smsbox application, we get only the DLR event itself, i.e. 
 DLR_SMSC_SUCCESS. Now the smsbox application needs to compare this to the 
 original msg DLR bitmask to decide if there is any action to be taken, i.e. 
 proxy this DLR to the downstream application or not. For this, the smsbox 
 application needs to locally store the orig msg DLR mask. IF we would provide 
 that orgi msg DLR mask in the DLR event msg itself, the smsbox application 
 doesn't need any temporary storage and retrieval, since this is performed 
 already logically from the DLR storage in bearebox.
 
 I hope this shades some light on the intention ;)

ok, got it...

 
 Even if we should forward back original dlr_mask of message, we should not 
 do it in dlr group
 because original dlr_mask has nothing todo with dlr. Maybe create a new 
 group ‚orig_msg‘ and
 put it inside but not in dlr group.
 
 hm, I disagree here. The DLR is literally correlated to the DLR bitmask. If 
 the bitmask wouldn't have been set, there would be no DLR event itself.
 
 To go into your direction, I would suggest keeping it in the 'dlr' group, but 
 renaming the field to 'msg_dlr_mask' to indicate this was the mask of the 
 original message.

I disagree to put it in dlr group because it has nothing with dlr todo. To dlr 
group belongs submittime/donetime/errorcode etc. (means any metadata that are 
DLR specific)
but original message is not related to DLR. If we think further about your idea 
to put it in DLR group then if we want to keep e.g. message body (don’t know 
the reason now
but just as example) then we will have message in DLR group? Sorry it makes not 
sense for me.

 
 Stipe
 
 ---
 Kölner Landstrasse 419
 40589 Düsseldorf, NRW, Germany
 
 Kannel Foundation tolj.org system architecture
 http://www.kannel.org/http://www.tolj.org/
 
 mailto:stolj_{at}_kannel.org  mailto:st_{at}_tolj.org
 ---
 

Re: [PATCH] Fix store file race

[Alexander Malysh]

Hi all,

no objections = commited to SVN.

Alex

 Am 08.07.2015 um 11:02 schrieb Alexander Malysh amal...@kannel.org:
 
 Hi all,
 
 please find attached patch that fixes store file race condition by status 
 request. Additionally this patch removes
 status from each of store and add it to bb_store to abstract and simplified 
 status handling in store.
 
 Comment and objections please.
 
 Thanks,
 Alex
 
 bb_store.patch

Re: [PATCH] orig DLR bitmask passing back via DLR msg

[Alexander Malysh]

Hi Stipe,

first of all I don’t get the intension for this feature? Please explain.

Even if we should forward back original dlr_mask of message, we should not do 
it in dlr group
because original dlr_mask has nothing todo with dlr. Maybe create a new group 
‚orig_msg‘ and
put it inside but not in dlr group.

Alex

 Am 10.07.2015 um 14:44 schrieb Stipe Tolj st...@kannel.org:
 
 Hi list,
 
 at the moment we don't pass back the original set bitmask when a DLR msg-sms 
 is send back to an smsbox connection, we just set the actual DLR even bit 
 in msg-sms.dlr_mask.
 
 I would like to add the original DLR bitmask that was set when MT was 
 processed in the msg-sms.meta_data part, group 'dlr', name 'dlr_mask', to 
 allow smsbox applications to retrieve this information without the need to 
 locally store temporary data.
 
 Please review and vote for committing.
 
 -- 
 Best Regards,
 Stipe
 
 ---
 Kölner Landstrasse 419
 40589 Düsseldorf, NRW, Germany
 
 Kannel Foundation tolj.org system architecture
 http://www.kannel.org/http://www.tolj.org/
 
 mailto:stolj_{at}_kannel.org  mailto:st_{at}_tolj.org
 ---
 dlr-orig-bitmask.diff

[PATCH] Fix store file race

[Alexander Malysh]

Hi all,

please find attached patch that fixes store file race condition by status 
request. Additionally this patch removes
status from each of store and add it to bb_store to abstract and simplified 
status handling in store.

Comment and objections please.

Thanks,
Alex



bb_store.patch
Description: Binary data

Re: BB crash svn revision 5141

[Alexander Malysh]

Hi,

I wonder how it should work without any locking? It’s simple race condition as 
far as I see…
We trying to format store message but it was just freed by another thread…

Alex

 Am 07.07.2015 um 17:39 schrieb Stipe Tolj st...@kannel.org:
 
 Am 01.07.2015 11:50, schrieb Ahmed Shabana:
 Dear Stipe ,
 
  Sorry for delay , find the ouput of the command as below
 
 $ addr2line -e bearerbox  0x41a338 0x414884 0x498c56
 /kannel/src/production/trunk/gw/bb_store_file.c:329
 /kannel/src/production/trunk/gw/bb_http.c:452
 /kannel/src/production/trunk/gwlib/gwthread-pthread.c:387 (discriminator 2)
 
 Hi Ahmed,
 
 thanks a lot for the addr2line resolution of the address blocks.
 
 Your PANIC happens while calling the HTTP admin URI /store-status, correct? 
 Can you reproduce the behavior constantly, or is this an very occasional 
 issue you see?
 
 Stipe
 
 ---
 Kölner Landstrasse 419
 40589 Düsseldorf, NRW, Germany
 
 Kannel Foundation tolj.org system architecture
 http://www.kannel.org/http://www.tolj.org/
 
 mailto:stolj_{at}_kannel.org  mailto:st_{at}_tolj.org
 ---
 

Re: [patch] add UUID to HTTP headers

[Alexander Malysh]

Hi,

maybe you are right, but for your scenario we already have some other routing 
things in place.
If one provider is slow, then just define preferred smsc and low queue size, 
then kannel will send
automatically via second provider without a need to delete and re-inject 
message again.

What is disturbing in this implementation that we copy headers for each message 
and this is costly…
Any chance to provide copy free implementation?

Alex

 Am 16.06.2015 um 22:01 schrieb hbil...@ecommunicate.biz:
 
 Hi Alex,
 
 One good reason to add a UUID to HTTP headers is to then have a method to be
 able to easily delete an SMS in Kannel's store before it's sent. 
 
 Currently Kannel internally creates a UUID for each SMS before sending it.
 This can be seen using lynx -dump
 http://127.0.0.1:xxx/store-status.xml?password= 
 http://127.0.0.1:xxx/store-status.xml?password=.  But how can we know
 which SMS message has which allocated UUID, without having to analyse all
 the SMSs in the store.
 
 If we can send an SMS to Kannel and also create the UUID that Kannel will
 use internally, then we can simply know which UUID to delete when we run the
 command http://127.0.0.1:13000/remove-message?id=UUIDpassword= 
 http://127.0.0.1:13000/remove-message?id=UUIDpassword=
 
 If SMSs are going out slowly via one provider, it would be useful to be able
 delete those SMSs still in the queue and send them via another provider. By
 being able to set the internal Kannel UUID when sending the SMS this will be
 easy to implement.
 
 thanks
 
 Date: Tue, 9 Jun 2015 10:32:01 +0200
 From: Alexander Malysh amal...@kannel.org mailto:amal...@kannel.org
 To: Vladimir Laskov samflan...@gmail.com mailto:samflan...@gmail.com
 Cc: devel@kannel.org mailto:devel@kannel.org
 Subject: Re: [patch] add UUID to HTTP headers
 Message-ID: bb7ac4ff-b351-4272-b98c-81bf7d400...@kannel.org 
 mailto:bb7ac4ff-b351-4272-b98c-81bf7d400...@kannel.org
 Content-Type: text/plain; charset=windows-1252
 
 Hi Vladimir,
 
 thanks for the patch! But  first thing would be to know, why it?s needed?
 For messages tracking purposes you can always use dlr-url with your
 params/id.
 
 Second thing: List *local_? is not a C-style and duplication of headers
 costs performance...
 
 Alex
 
 Am 04.06.2015 um 10:36 schrieb Vladimir Laskov samflan...@gmail.com:
 
 
 
 Hello, guys
 
 please see and confirm patch
 patch description: add UUID HTTP herader like here
 
 ==
 Server: Kannel/1.4.4
 Date: Thu, 04 Jun 2015 08:15:28 GMT
 Content-Length: 24
 Content-type: text/html
 Pragma: no-cache
 Cache-Control: no-cache
 X-Kannel-UUID: 4d069003-e43f-426e-8a95-ba21cb71dca5
 ==
 
 
 
 diff --git a/gw/smsbox.c b/gw/smsbox.c index b62e62e..2e0faf4 100644
 --- a/gw/smsbox.c
 +++ b/gw/smsbox.c
 @@ -213,8 +213,12 @@ static void delayed_http_reply(Msg *msg)
 break;
 }
 
 -http_send_reply(client, status, sendsms_reply_hdrs, answer);
 +List *local_sendsms_reply_hdrs =
 http_header_duplicate(sendsms_reply_hdrs);
 +http_header_add(local_sendsms_reply_hdrs, X-Kannel-UUID, 
 + octstr_get_cstr(os));
 +
 +http_send_reply(client, status, local_sendsms_reply_hdrs, 
 + answer);
 
 +http_destroy_headers(local_sendsms_reply_hdrs);
 octstr_destroy(answer);
 octstr_destroy(os);
 }
 
 
 
 THX
 --
 Vladimir Laskov
 samflan...@gmail.com mailto:samflan...@gmail.com 
 mailto:samflan...@gmail.com mailto:samflan...@gmail.com
 +79266285176

Re: [patch] add UUID to HTTP headers

[Alexander Malysh]

Hi Vladimir,

thanks for the patch! But  first thing would be to know, why it’s needed? For 
messages tracking purposes you can always
use dlr-url with your params/id.

Second thing: List *local_… is not a C-style and duplication of headers costs 
performance...

Alex

 Am 04.06.2015 um 10:36 schrieb Vladimir Laskov samflan...@gmail.com:
 
 
 
 Hello, guys
 
 please see and confirm patch
 patch description: add UUID HTTP herader like here
 
 ==
 Server: Kannel/1.4.4
 Date: Thu, 04 Jun 2015 08:15:28 GMT
 Content-Length: 24
 Content-type: text/html
 Pragma: no-cache
 Cache-Control: no-cache
 X-Kannel-UUID: 4d069003-e43f-426e-8a95-ba21cb71dca5
 ==
 
 
 
 diff --git a/gw/smsbox.c b/gw/smsbox.c
 index b62e62e..2e0faf4 100644
 --- a/gw/smsbox.c
 +++ b/gw/smsbox.c
 @@ -213,8 +213,12 @@ static void delayed_http_reply(Msg *msg)
  break;
  }
  
 -http_send_reply(client, status, sendsms_reply_hdrs, answer);
 +List *local_sendsms_reply_hdrs = 
 http_header_duplicate(sendsms_reply_hdrs);
 +http_header_add(local_sendsms_reply_hdrs, X-Kannel-UUID, 
 octstr_get_cstr(os));
 +
 +http_send_reply(client, status, local_sendsms_reply_hdrs, answer);
  
 +http_destroy_headers(local_sendsms_reply_hdrs);
  octstr_destroy(answer);
  octstr_destroy(os);
  }
 
 
 
 THX
 --
 Vladimir Laskov
 samflan...@gmail.com mailto:samflan...@gmail.com
 +79266285176
 

Re: Bug in admin interface for parameter remove-message

[Alexander Malysh]

Hi,

see comment in redmine and try to fix your URL.

Alex

 Am 28.05.2015 um 11:26 schrieb Kirti Mandwade kirti.mandw...@gmail.com:
 
 Hello,
 From the latest user guide 
 http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html#AEN926
  
 http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html#AEN926
 remove-message Removes the message with the give id (an UUID) from the local 
 storage
 subsystem.
 But this is not working.
 I need to remove specific message from kannel queue and i am testing it by 
 using fakesmsc.
 
 Here is my redmine link:
 https://redmine.kannel.org/issues/718 https://redmine.kannel.org/issues/718
 
 Thanks
 Kirti

Re: concurrency issue with http_close_all_ports

[Alexander Malysh]

Hi David,

thanks for pointing to this race condition!

I can easy reproduce it but I don’t think that your fix is the right one 
because it may
hung if client don’t read response or read it but very slow.

I have to think a little bit more how to fix it.

Alex

 Am 31.03.2015 um 11:49 schrieb David Schneider david.schnei...@dimoco.eu:
 
 Hello
 
 I found a concurrency issue with the latest http server implementation.
 
 I'm running test_http_server with multiple threads (-t 5). If I send a 
 request which is delayed by a sleep and in the mean time I'm calling 
 http://localhost:8080/quit; then the server crashes during http_send_reply 
 call due to already freed client-conn.
 
 Index: test/test_http_server.c
 ===
 --- test/test_http_server.c(Revision 5141)
 +++ test/test_http_server.c(working copy)
 @@ -237,6 +237,9 @@
 if (extra_headers != NULL)
 http_header_combine(resph, extra_headers);
 
 +if (run)
 +gwthread_sleep(5);
 +
 /* return response to client */
 http_send_reply(client, status, resph, reply_body);
 
 
 testing with:
 test/test_http_server -t 5 
 curl http://localhost:8080; 
 sleep 1
 curl http://localhost:8080/quit;
 
 I found a possible solution in http.c: port_remove
 
 Index: gwlib/http.c
 ===
 --- gwlib/http.c(Revision 5141)
 +++ gwlib/http.c(working copy)
 @@ -2097,8 +2097,14 @@
  */
 gwlist_lock(active_connections);
 l = gwlist_search_all(active_connections, port, port_match);
 -while(l != NULL  (client = gwlist_extract_first(l)) != NULL)
 +while(l != NULL  (client = gwlist_extract_first(l)) != NULL) {
 conn_unregister(client-conn);
 +while (client-state == request_is_being_handled) {
 +gwthread_sleep(0.1);
 +}
 +}
 gwlist_unlock(active_connections);
 gwlist_destroy(l, NULL);
 while((client = gwlist_search(active_connections, port, port_match)) != 
 NULL)
 
 
 What do you think about that solution?
 
 David
 
 PS: There is a typo in test_http_server help:
 Index: test/test_http_server.c
 ===
 --- test/test_http_server.c(Revision 5141)
 +++ test/test_http_server.c(working copy)
 @@ -288,7 +291,7 @@
 info(0, read HTTP headers from file 'filename' and add them to);
 info(0, the request for url 'url');
 info(0, specific URIs with special functions are:);
 -info(0,   /quite - shutdown the HTTP server);
 +info(0,   /quit - shutdown the HTTP server);
 info(0,   /whitelist - provides the -w whitelist as response);
 info(0,   /blacklist - provides the -b blacklist as response);
 info(0,   /save - save a HTTP POST request body to a file 
 /tmp/body.pid.n);
 
 

Re: How to remove messages from Kannel local subsystem using

[Alexander Malysh]

Hi,

sorry for delay, but I don;t see bug here because wrong url used:

 2) Does the remove-message option actually work for the admin interface as
 mentioned in the Kannel documentation
 http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html#AEN9
 26
 I've followed the steps of Kirti and I also get
 http://127.0.0.1:13000/remove-message?id=UUID?password=
 Denied error.

? twice? replace second ? with  and try again

Alex


 Am 21.05.2015 um 23:24 schrieb hbil...@ecommunicate.biz:
 
 Hi Alex,
 
 1) Was code for this feature accepted and committed
 https://redmine.kannel.org/issues/567 ?
 
 Add a new command to the kannel admin interface to delete the queued
 messages for certain criteria, like for SMSC connection XX or for short code
  or move these messages to certain directory:
 
 kannel_admin/delete-queue?smsc=XX
 kannel_admin/delete-queue?short-code=YYY
 kannel_admin/move-queue?smsc=XXdestination=URL_ENCODE('/some_directory/move
 d/')
 
 2) Does the remove-message option actually work for the admin interface as
 mentioned in the Kannel documentation
 http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html#AEN9
 26
 I've followed the steps of Kirti and I also get
 http://127.0.0.1:13000/remove-message?id=UUID?password=
 Denied error.
 
 But lynx -dump http://127.0.0.1:13000/store-status.xml?password=; works
 and gives me the UUIDs. Which means the password and admin interface is
 working. (I've used 13000 as the admin port.)
 
 Either the Kannel documentation is wrong or there is a bug in the code
 regarding remove-message.
 Removes the message with the give id (an UUID) from the local storage
 subsystem.
 
 thanks
 
 --
 
 Message: 
 Date: Mon, 18 May 2015 18:59:11 +0530
 From: Kirti Mandwade kirti.mandw...@gmail.com
 To: devel@kannel.org
 Subject: Fwd: How to remove messages from Kannel local subsystem using
   UUID
 Message-ID:
   CACz0=AgQDxMbYHOA0t+w5tYbVLNRP=p+p6m4pcq6p8zuxnz...@mail.gmail.com
 Content-Type: text/plain; charset=utf-8
 
 Hello,
 
 I need to remove specific message from kannel queue and i am testing it by
 using fakesmsc.
 
 So far what i did is:
 1) I used this command to check the status of various smsc.This works fine
 
 lynx -dump http://127.0.0.1:xxx/status?password=;
 
 2) I took down fakesmsc and sent 10 sms.
 
 3) I used the following command to check the queue.
 lynx -dump http://127.0.0.1:xxx/store-status.xml?password=;
 
 And got the following output
91fc3583-761a-4e1f-8493-3f47a01e628a MT-PUSH 2015-05-18 12:33:35
   1950 1876052832 fake1 dlrbox hello
   f8c68792-7d95-4d14-9a84-276a25aba8e4 MT-PUSH 2015-05-18 12:33:35
   1950 1126022293 fake1 dlrbox hello
   c9f5d10e-861d-48b4-a5ae-c6a743dcff21 MT-PUSH 2015-05-18 12:33:35
   1950 1638362136 fake1 dlrbox hello
   202f331a-6c5a-4120-a0de-f20bf71f1da9 MT-PUSH 2015-05-18 12:33:35
   1950 1903556200 fake1 dlrbox hello
   0924eb0d-7a98-4e58-9fbe-e549227f93f5 MT-PUSH 2015-05-18 12:33:35
   1950 1156234781 fake1 dlrbox hello
   a91495f9-f48f-4b2d-8c6b-3b3872bde40b MT-PUSH 2015-05-18 12:33:35
   1950 1039133110 fake1 dlrbox hello
   d5b14df4-2025-4176-97a6-d8f034d2c024 MT-PUSH 2015-05-18 12:33:35
   1950 1295345287 fake1 dlrbox hello
 
 
 
 4) I wanted to remove these messages from the queue using the UUID's. So i
 tried doing
 
 lynx -dump 
 http://127.0.0.1:13000/remove-message?id=91fc3583-761a-4e1f-8493-3f47a01e628
 a
 
 
 This gave me Denied error
 
 
 5) Then i tried removing using password
 http://127.0.0.1:13000/remove-message?id=91fc3583-761a-4e1f-8493-3f47a01e628
 a?password=
 
 
 Still it gave me error Denied.
 
 It should work as its given in Kannel svn-r5114 doc that we can use
 remove-message command for removing messages.
 
 remove-message - Removes the message with the give id (an UUID) from the
 local storage subsystem.
 Can someone explain me about how to make this to work.
 
 
 Also please check the following link.
 https://redmine.kannel.org/issues/567
 
 I want to know is this working i cant find any related documents. Its
 posted a long time ago so it should be implemented till now.
 
 Thanks
 Kirti
 
 

Re: xmlrpc in 1.5.0

[Alexander Malysh]

Hi Artem,

sorry, but I can’t share code because it's company’s private property. I just 
answered to you
that this is possible and is really easy.

Alex

 Am 16.02.2015 um 11:00 schrieb Artem Pylypchuk artic...@ua.fm:
 
 Hi Alex,
 
 oh I see, you already did such a server. Can you share? It can be a complete 
 test server example into code tree, or some raw code if project license 
 allows.
 
 At first glance, the code in xmlrpc.h was enough to make a parser for the 
 client. To make a server it has to be a separate module with some glue code 
 connecting it to http.h and others. Is that what you did?
 
 You're right, xmlrpc-c has a lot of redundant code and makes another 
 dependency.
 
 
 06.02.2015 18:04, Alexander Malysh amal...@kannel.org
 Hi Artem,
 
 kannel has it’s own xmlrpc implementation and it’s possible to implement 
 with it server as well (I did it for another project).
 xmlrpc-c library is not welcome because we are trying to avoid unnecessary 
 dependencies.
 
 Alex
 
 Am 06.02.2015 um 13:43 schrieb Artem Pylypchuk artic...@ua.fm:
 
 
 Hi!
 
 I've noticed there's an xmlrpc.h in the latest version, and there's a unit 
 test for it as well.
 Is it possible to implement a XMLRPC server using this code? Does it need 
 more work?
 
 On the roadmap, have you considered using the xmlrpc-c library?
 I'm going to implement an XMLRPC server for Kannel, and would like to 
 contribute it. Do you want it from scratch or linked to xmlrpc-c?
 
 Cheers,
 Artem.
 
 -- реклама ---
 Поторопись зарегистрировать самый короткий почтовый адрес @i.ua
 http://mail.i.ua/reg - и получи 1Gb для хранения писем
 
 
 
 -- реклама ---
 Hostpro 14 лет! Скидка 50% на хостинг, VPS, серверы!
 http://hostpro.ua/ru/hosting-linux.html?from=i.ua-14

Re: xmlrpc in 1.5.0

[Alexander Malysh]

Hi Artem,

kannel has it’s own xmlrpc implementation and it’s possible to implement with 
it server as well (I did it for another project).
xmlrpc-c library is not welcome because we are trying to avoid unnecessary 
dependencies.

Alex

 Am 06.02.2015 um 13:43 schrieb Artem Pylypchuk artic...@ua.fm:
 
 
 Hi!
 
 I've noticed there's an xmlrpc.h in the latest version, and there's a unit 
 test for it as well.
 Is it possible to implement a XMLRPC server using this code? Does it need 
 more work?
 
 On the roadmap, have you considered using the xmlrpc-c library?
 I'm going to implement an XMLRPC server for Kannel, and would like to 
 contribute it. Do you want it from scratch or linked to xmlrpc-c?
 
 Cheers,
 Artem.
 
 -- реклама ---
 Поторопись зарегистрировать самый короткий почтовый адрес @i.ua
 http://mail.i.ua/reg - и получи 1Gb для хранения писем
 

Re: Proposal: a more powerful SQL DLR storage

[Alexander Malysh]

Hi,

maybe before you reinvent the wheel look into sqlbox?

And yes, Kannel support HTTP 1.1 just configure your apache for this.

Alex

 Am 07.11.2014 um 17:32 schrieb Vincenzo Romano vincenzo.rom...@notorand.it:
 
 Hi,
 it looks like I've done it the wrong way to solve my problem.
 
 If I'll find enough time I'll investigate Andreas' suggestion and will
 submit the changes to him...
 But I need to first finish my project. :-)
 
 2014-11-07 17:28 GMT+01:00 Spina Eduardo eduardo.sp...@gemalto.com:
 Hi All,
 
 This implementation would be important for me too. I tried sometime ago to 
 setup the web server for similar purposes, but, running 1500+ SMS/s, the 
 performance dropped significantly with the opening/closing of sockets (at 
 least as it was configured, kannel was using HTTP 1.0 and creating a lot of 
 connections with the web server, maybe there is a way to setup HTTP 1.1 
 here?).
 
 Best Regards,
 ---
 Eduardo Martins Spina
 
 -Original Message-
 From: devel [mailto:devel-boun...@kannel.org] On Behalf Of Vincenzo Romano
 Sent: Friday, November 07, 2014 8:49 AM
 To: Andreas Fink
 Cc: devel Devel
 Subject: Re: Proposal: a more powerful SQL DLR storage
 
 Hi.
 It's that temporaryness that's not a mandatory feature for kannel to work.
 As long as your queries are fast and effective, the application can provide 
 a(nother) powerful integration tool.
 
 The SMS status information is already there, within system data structures.
 My proposal is to keep it structured and stored into the DB.
 That'd be more usefulness from the DB store.
 What you suggest is to undo later the work done to flatten all the details 
 into one or more log lines.
 That'd be more usefulness from the log store.
 
 My proposal leads to a more effective use of the DB, as there wouldn't be 
 any UPDATE and DELETE (thus fewer locks, no tablespace fragmentation, more 
 compact indices). And, reasonably, higher application throughput.
 
 
 2014-11-07 10:49 GMT+01:00 Andreas Fink af...@list.fink.org:
 the purpose of the persistent storage is for temporary usage as DLR's
 can refer to SMS which have been sent a couple of days ago.
 the DLR storage you want is what delivery reports are meant for and
 those are transmitted to the user requesting it In addition to that
 the access logs already contains this data.
 It would probably make more sense to offer a access log into SQL
 driver than to abuse the internal state cache mechanism.
 
 Am 07.11.2014 um 10:34 schrieb Vincenzo Romano
 vincenzo.rom...@notorand.it:
 
 Introduction
 Kannel has the ability to store the SMS DLRs also in SQL tables.
 The main aim for this is to provide for storage persistence against
 system crashes.
 For this reason a DB table is configured where kannel will insert
 details for submitted SMSs.
 Later, upon reaching the final status, those data will be searched and
 deleted.
 
 Motivation
 This feature can be made more powerful with little changes to the system.
 Basically it's all about replacing the deletion with insertion at
 every single status change.
 This would create a SMS status history from which the user can
 extract an amount of useful information that's otherwise lost.
 
 Implementation
 On the software side of the feature, the code in gw/dlr.c needs to be
 changed in order to replace the calls to method dlr_remove with
 dlr_insert (or even dlr_update ).
 The underlying table needs to be supplemented at least with a real
 timestamp column (automatically calculated at every insertion) in
 order to retrieve either the latest status update or the initial
 details thanks to the ORDER BY predicate in either ASCending or
 DESCending direction.
 The actual queries used in dlr_*.c should also be reviewed in order to
 reflect thes changes, even if that can be avoided with intervention in
 the SQL with VIEWs and TRIGGERs.
 
 Note
 I recently started a thread on this topic in the users mailing list.
 It can be viewed here:
 http://www.kannel.org/pipermail/users/2014-November/021632.html
 And I have no idea on how the development organisation is done in Kannel.
 
 
 Thanks for the patience. Any feedback will be welcomed.
 
 
 
 
 
 Andreas Fink
 
 CEO DataCell ehf
 CEO Backbone ehf
 
 ---
 Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
 Address: Clarastrasse 3, 4058 Basel, Switzerland
 E-Mail:  andr...@fink.org
 www.datacell.com, www.backbone.is, www.finkconsulting.com www.fink.org
 ---
 Jabber/XMPP: andr...@fink.org
 ICQ: 8239353 Skype: andreasfink
 
 
 
 
 
 
 This message and any attachments are intended solely for the addressees and 
 may contain confidential information. Any unauthorized use or disclosure, 
 either whole or partial, is prohibited.
 E-mails are susceptible to alteration. Our company shall not be liable for 
 the message if altered, changed or falsified. If you are 

Re: [PATCH] 'group = smsc' directive 'instances = x' to multiply the runtime instances

[Alexander Malysh]

Hi Stipe,

don’t know why we need this? If you need some amount of equal smsc connections 
then:

1) create file with smsc config: e.g. smsc.conf
2) in the global config:
include smsc.conf
include smsc.conf
include smsc.conf
include smsc.conf
include smsc.conf
...

I know this is a workaround, but we have just t much config variable and I 
just trying to avoid to produce more of them.

Alex


 Am 30.10.2014 um 18:46 schrieb Stipe Tolj st...@kannel.org:
 
 Hi list,
 
 typically we have one config group towards an SMSC that we copy-and-paste to 
 create a number of same connection to it. The attached patch allows to define 
 this multiplication via the config directive
 
  group = smsc
  ...
  instances = number
  ...
 
 The patchset is a feature add and a NLC.
 
 BTW, it does NOT work for 'smsc = http' since the MO/DLR side HTTP port will 
 be bound already by the previous incarnation of the group, but I think this 
 is anyway not the type of SMSC group you would use the multiplier for.
 
 Please review and vote.
 Stipe
 
 -- 
 ---
 Kölner Landstrasse 419
 40589 Düsseldorf, NRW, Germany
 
 Kannel Foundation tolj.org system architecture
 http://www.kannel.org/http://www.tolj.org/
 
 mailto:stolj_{at}_kannel.org  mailto:st_{at}_tolj.org
 ---
 gateway-smsc-instances.diff

Re: [PATCH] [white|black]list for receiver addresses

[Alexander Malysh]

Hi,

+1 for the feature but not for the patch itself.

I would propose to make it clear in the code and userguide which list ist for 
which field. Please rename black-list… to black-list-sender etc.
For the migration phase you can accept in the config both, black-list-sender 
and black-list and warn about deprecated config values.

We have to keep code clean…

Alex

 Am 30.10.2014 um 16:51 schrieb Stipe Tolj st...@kannel.org:
 
 Hi list,
 
 this is a very intuitive addition to the way we allow handling 
 '[white|black]-list[-regex]' config directives in the 'group = core' context.
 
 Unfortunately the existing logic only patterns against the msg-sms.sender 
 (source address) of the message, but not against the receiver side.
 
 While you may argue that this SHOULD be done by the upper application layer 
 instead, some may find it useful to be added as feature add into the baseline 
 svn trunk.
 
 Please review and vote for committing.
 
 Stipe
 
 -- 
 ---
 Kölner Landstrasse 419
 40589 Düsseldorf, NRW, Germany
 
 Kannel Foundation tolj.org system architecture
 http://www.kannel.org/http://www.tolj.org/
 
 mailto:stolj_{at}_kannel.org  mailto:st_{at}_tolj.org
 ---
 gateway-white-black-list.diff

[PATCH] Drop intermediate dlr mask

[Alexander Malysh]

Hi all,

this patch drops intermediate dlr mask from Kannel because it make no sense to 
extract SMPP specific
mask to abstracted Kannel DLR layer. Even more, intermediate dlr mask only used 
for the sending of
message but maps incoming intermediate DLR to buffered.

Attached patch drops intermediate dlr mask and request intermediate DLRs if 
buffered dlr mask set. The
same is on the receiver side: if we receive intermediate DLR, we map it to 
buffered. That means that both
side sending and receiving behave the same.

Alex



intermediate.patch
Description: Binary data

Re: extended logging for OpenSSL library errors

[Alexander Malysh]

Hi Artem,

thanks for your patch. I commited the first part of your patch but not sure if 
we need the second
part, therefore not commited yet.

Alex

Am 14.09.2014 um 13:06 schrieb Artem Pylypchuk artic...@ua.fm:

 
 Hi! I have a new patch to gwlib, it adds two different features related to 
 openssl.
 
 1)
 
 When sending to a proprietary SSL server which has trouble with SSL method 
 chosen, one may receive errors like:
 
 ERROR: SSL write failed: OpenSSL error 1: 
 error:0001:lib(0):func(0):reason(1)
 
 which aren't very verbose :(
 
 While connection and negotiation errors can be traced by the user outside 
 gwlib, there is the unlocked_write() function inside conn.c that produces 
 these write errors. The following patch has allowed me to trace it into this 
 openssl bug http://cvs.openssl.org/chngview?cn=22565 (bad renegotiation):
 
 ERROR: SSL write failed: OpenSSL error 1: 
 error:0001:lib(0):func(0):reason(1)
 ERROR: SSL error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
 
 2)
 The other part of the patch allows the user to manually set the SSL for 
 Connection, in a workflow like this:
 
 (it uses a config option use_ssl, that switches either from strictly TLSv1 to 
 a negotiation that disallows SSLv2 and TLSv1_1, usually ending up in SSLv3 
 for my server )
 
 
 my_ssl_context = SSL_CTX_new(use_ssl ? SSLv23_client_method() : 
 TLSv1_client_method());
SSL_CTX_set_mode(my_ssl_context, 
SSL_MODE_ENABLE_PARTIAL_WRITE | SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER);
 if (use_ssl) {
SSL_CTX_set_options(my_ssl_context, SSL_OP_NO_SSLv2 | SSL_OP_NO_TLSv1_1); 
 //tweak SSLv23_client_method()
 }
 
 con = conn_open_tcp_nb(server_addr, server_port, NULL);
 SSL *ssl = SSL_new(my_ssl_context);
 conn_set_ssl(pc-con, ssl, NULL); //needs patch to Kannel
 
 
 Otherwise, without this second part of the patch, using a SSL method other 
 than the gwlib-hardcoded default SSLv23_client_method() would require a 
 workaround like this, creating the SSL inside gwlib and then resetting it:
 
 con = conn_open_ssl_nb(server_addr, server_port, NULL, NULL);
 SSL *conn_ssl = conn_get_ssl(pc-con);
 SSL_clear(conn_ssl);
 SSL_set_ssl_method(conn_ssl, use_ssl ? SSLv23_client_method() : 
 TLSv1_client_method());
 if (use_ssl) SSL_set_options(conn_ssl, SSL_OP_NO_SSLv2 | SSL_OP_NO_TLSv1_1);
 
 
 Note, the conn_set_ssl() public function introduced into conn.h, sets the SSL 
 only to a Connection created with conn_open_tcp*, and does not override the 
 existing SSL inside a Connection created by conn_open_ssl*. It also needs the 
 certkeyfile argument. Some essential reorganization of where SSL_new from the 
 global context is called inside conn.c was needed to implement this.
 
 
 The first part is very useful to trace openssl library errors on write, and I 
 think it should be definitely added to Kannel source. The second reorganizes 
 code inside conn.c and is not quite essential to the user, so you may or may 
 not accept it.
 
 
 Cheers!
 Artem
 
 -- реклама ---
 Быстрый виртуальный хостинг с SSD. Домен в подарок!
 http://freehost.com.ua/unix/ssl_set.patch

Re: Double hostname in DLR URL

[Alexander Malysh]

Hi Andreas,

did you find anything? I never saw this on our side.

Alex

Am 27.07.2014 um 23:02 schrieb Andreas Fink af...@list.fink.org:

 Hi folks,
 
 I run into a very puzzling issue with the delivery of DLRs from Kannel.
 
 I have a script which submits SMS to kannel. This script constructs a DLR URL 
 like this:
 
 callback_url = 
 octstr_format(http://%s:%d/sms/response.php?priority=%d;,
  
 octstr_get_cstr(callback_host),
  (int)callback_port,ilm_prio);
   further parameters added...
 
 callback_host and callback_port are Octstr read from the config file and are 
 always constant. They do not contain spaces or any trailing tabs or the like
 Then this URL is urlencoded and passed on to the URL which is sent to kannel.
 Kannel is processing the request and comes back with a delivery report.
 The hostname passed is a straight IP address not a DNS name.
 
 
 This is the SMSBox Log on a DLR being sent back
 
 2014-07-27 20:27:06 [16079] [10] DEBUG:   Scheme: http://
 2014-07-27 20:27:06 [16079] [10] DEBUG:   Host: 10.195.198.70
 2014-07-27 20:27:06 [16079] [10] DEBUG:   Port: 80
 2014-07-27 20:27:06 [16079] [10] DEBUG:   Username: (null)
 2014-07-27 20:27:06 [16079] [10] DEBUG:   Password: (null)
 2014-07-27 20:27:06 [16079] [10] DEBUG:   Path: /sms/response.php
 2014-07-27 20:27:06 [16079] [10] DEBUG:   Query: {some parameters...}
 2014-07-27 20:27:06 [16079] [10] DEBUG:   Fragment: (null)
 2014-07-27 20:27:06 [16079] [10] DEBUG: HTTP: Reusing connection to 
 `10.195.198.70:80' (fd=31).
 2014-07-27 20:27:06 [16079] [10] DEBUG: Socket connected at once
 2014-07-27 20:27:06 [16079] [10] DEBUG: HTTP: Sending request:
 2014-07-27 20:27:06 [16079] [10] DEBUG: Octet string at 0x7f9dd3b00050:
 2014-07-27 20:27:06 [16079] [10] DEBUG:   len:  563
 2014-07-27 20:27:06 [16079] [10] DEBUG:   size: 1024
 2014-07-27 20:27:06 [16079] [10] DEBUG:   immutable: 0
 
 
 this is all correct so far and my script answers with a OK and everything's 
 fine.
 
 
 but then further down in the log I suddenly see this:
 
 
 2014-07-27 20:32:30 [16079] [10] DEBUG: Parsing URL `http://10.195.198.70, 
 10.195.198.70/sms/response.php?
 2014-07-27 20:31:03 [16079] [10] DEBUG:   Scheme: http://
 2014-07-27 20:31:03 [16079] [10] DEBUG:   Host: 85.195.198.70, 85.195.198.70
 2014-07-27 20:31:03 [16079] [10] DEBUG:   Port: 80
 2014-07-27 20:31:03 [16079] [10] DEBUG:   Username: (null)
 2014-07-27 20:31:03 [16079] [10] DEBUG:   Password: (null)
 2014-07-27 20:31:03 [16079] [10] DEBUG:   Path: /sms/response.php
 2014-07-27 20:31:03 [16079] [10] DEBUG:   Query: ...
 2014-07-27 20:31:03 [16079] [10] DEBUG:   Fragment: (null)
 2014-07-27 20:31:03 [16079] [10] ERROR: gethostbyname failed
 
 As you can see here, the IP address of the host is now twice in the hostname 
 and of course this is not resolvable.
 I verified and I am 100% sure that I pass it only once, not twice.
 And nothing changed between the first request and the second one.
 Its still the same running instance of my code calling kannel. Its still 
 passing the same DLR URL being passed.
 Its still the same smsbox running.
 
 Has anyone seen such issues before?
 Has there been any change in gwlib in regards to handling URL's?
 
 The version used is a SVN checkout from 24th of June.
 
 
 
 

Re: [PATCH] Generic TLV module functions - Re: UCP/EMI to support E50_HPLMN and E50_AC

[Alexander Malysh]

Hi Andreas,

yes you are right, I like your idea.

Alex

Am 16.07.2014 um 17:47 schrieb Andreas Fink af...@list.fink.org:

 While we think about changing tlv, we should also think about having a set 
 of tlv which you can apply to a smsc.
 In my case I have like 40 instances of the same SMSC and having 20 TLV 
 configs for every smsc (as you specify smsc-id in it) is creating very long 
 config files.
 
 What about 
 
 group = tlv
 name = xxx
 tag = xxx
 length = xxx
 type = INTEGER/OCTSTR/NULLTERMINATED
 vendor-id = XXX
 
 
 and then under SMSC
 
 group = smpp
 vendor-tlv = xxx...
 
 this would automatically link a certain set of tlv's to a specific smpp.
 not sure if protocol is really needed in the tlv in that case.
 
 
 On 16 Jul 2014, at 17:35, Alexander Malysh amal...@kannel.org wrote:
 
 Hi,
 
 idea is good but TLV is SMPP specific IMHO. Therefore I would not expect 
 this as generic :-)
 
 Patch is hardcoded on many places. If you do it generic then please do it 
 instead of just to name it so.
 I would expect generic config groups that have proto inside of group and 
 SMPP PDU just
 fetch with constant they part instead of oct_imm(smpp-tlv).
 
 so the group would be:
 
 group = tlv  (Hier we have to think about better name, TLV is confusing)
 protocol = smpp/ucp/cimd2
 name = xxx
 tag = xxx
 length = xxx
 type = INTEGER/OCTSTR/NULTERMINATED
 smsc-id = xxx;xxx1
 
 Then SMPP PDU will just fetch by proto:
 
 generic_tlv_get_by_tag(TLV_PROTO_SMPP, smsc_id, tag);
 
 
 And please avoid using typedefs it's really bad style: 
 http://discuss.fogcreek.com/joelonsoftware1/default.asp?cmd=showixPost=10506
 
 Alex
 
 Am 16.07.2014 um 16:40 schrieb Stipe Tolj st...@kannel.org:
 
 Am 10.07.2014 19:59, schrieb marc-andre.gat...@gameloft.com:
 Hi,
 
 I'm using the meta-data to get the E50_HPLMN and set the E50_AC.
 
 here's the patch to support that for the EMI protocol. If you guys have
 a better way of doing so please feel free to give me a hint.
 
 I'd like to apply the patch in the main repo asap.
 
 Hi Mark,
 
 thanks a lot for the patch, we appreciate your willingness to contribute.
 
 In fact I had this being tackled in a more generic way, pulling the SMPP 
 TLV code out of the SMPP specific modules into a generic 
 gw/generic_tlv.[ch] module that can be used by any SMSC module.
 
 Please find it attached to this mail for review and voting for commiting to 
 svn trunk. (Though, this WILL go into svn post 1.4.4-stable release).
 
 The SMPP module is modified accordingly, along with additions for CIMD2. 
 I'm sure you will be able to add EMI/UCP too using the same function set.
 
 Stipe
 
 -- 
 ---
 Kölner Landstrasse 419
 40589 Düsseldorf, NRW, Germany
 
 Kannel Foundation tolj.org system architecture
 http://www.kannel.org/http://www.tolj.org/
 
 mailto:stolj_{at}_kannel.org  mailto:st_{at}_tolj.org
 ---
 gateway-generic-tlv.diff
 
 

Re: UCP/EMI to support E50_HPLMN and E50_AC

[Alexander Malysh]

Hi,

thanks for your contribution but this is not acceptable patch, see below...

+   
+//Insert the E50_HPLMN into meta_data

we are in C and this is not C comment style ;)

+msg-sms.meta_data = octstr_duplicate(emimsg-fields[E50_HPLMN]);

potential mem leak, best to destroy meta_data first

+   if (msg-sms.meta_data != NULL) {
+meta_data_set_value(msg-sms.meta_data, smpp , 
octstr_imm(E50_HPLMN), octstr_duplicate(emimsg-fields[E50_HPLMN]),1);
+   }

why do you use smpp meta data group in UCP ? Please change to use ?emi? or 
?ucp? group.

Alex


Am 10.07.2014 um 19:59 schrieb marc-andre.gat...@gameloft.com:

 Hi,
 
 I'm using the meta-data to get the E50_HPLMN and set the E50_AC.
 
 here's the patch to support that for the EMI protocol. If you guys have a 
 better way of doing so please feel free to give me a hint.
 
 I'd like to apply the patch in the main repo asap.
 
 thanks
 
  
 emi.patch

Re: [PATCH] Generic TLV module functions - Re: UCP/EMI to support E50_HPLMN and E50_AC

[Alexander Malysh]

Hi,

idea is good but TLV is SMPP specific IMHO. Therefore I would not expect this 
as generic :-)

Patch is hardcoded on many places. If you do it generic then please do it 
instead of just to name it so.
I would expect generic config groups that have proto inside of group and SMPP 
PDU just
fetch with constant they part instead of oct_imm(smpp-tlv).

so the group would be:

group = tlv  (Hier we have to think about better name, TLV is confusing)
protocol = smpp/ucp/cimd2
name = xxx
tag = xxx
length = xxx
type = INTEGER/OCTSTR/NULTERMINATED
smsc-id = xxx;xxx1

Then SMPP PDU will just fetch by proto:

generic_tlv_get_by_tag(TLV_PROTO_SMPP, smsc_id, tag);


And please avoid using typedefs it's really bad style: 
http://discuss.fogcreek.com/joelonsoftware1/default.asp?cmd=showixPost=10506

Alex

Am 16.07.2014 um 16:40 schrieb Stipe Tolj st...@kannel.org:

 Am 10.07.2014 19:59, schrieb marc-andre.gat...@gameloft.com:
 Hi,
 
 I'm using the meta-data to get the E50_HPLMN and set the E50_AC.
 
 here's the patch to support that for the EMI protocol. If you guys have
 a better way of doing so please feel free to give me a hint.
 
 I'd like to apply the patch in the main repo asap.
 
 Hi Mark,
 
 thanks a lot for the patch, we appreciate your willingness to contribute.
 
 In fact I had this being tackled in a more generic way, pulling the SMPP TLV 
 code out of the SMPP specific modules into a generic gw/generic_tlv.[ch] 
 module that can be used by any SMSC module.
 
 Please find it attached to this mail for review and voting for commiting to 
 svn trunk. (Though, this WILL go into svn post 1.4.4-stable release).
 
 The SMPP module is modified accordingly, along with additions for CIMD2. I'm 
 sure you will be able to add EMI/UCP too using the same function set.
 
 Stipe
 
 -- 
 ---
 Kölner Landstrasse 419
 40589 Düsseldorf, NRW, Germany
 
 Kannel Foundation tolj.org system architecture
 http://www.kannel.org/http://www.tolj.org/
 
 mailto:stolj_{at}_kannel.org  mailto:st_{at}_tolj.org
 ---
 gateway-generic-tlv.diff

Re: Kannel Multiple DB connection

[Alexander Malysh]

Hi,

you can try to configure CNAME in DNS and put two IPs in round robin manner.
Then configure mysql connection with at least 2 connections and you should have
2 connections to different nodes.

Alex


Am 03.06.2014 um 11:23 schrieb Abdul Basit basit.e...@gmail.com:

 Hi, smii
 
 Thank you for prompt reply. 
 
 This is one way. right!
 
 But my architecture is using two Mysql master nodes in parallel so i don't 
 have one virtual IP or floating IP.
 Instead i have two DB IPs. 
 
 Is there any way to open two DB connections on different IPs?
 
 
 --
 regards,
 
 abdul basit | p: +92 32 1416 4196 | o: +92 30 0841 1445
 
 
 On Tue, Jun 3, 2014 at 4:02 PM, smii saber saber.s...@gmail.com wrote:
 Hi Abdul basit
 Normally in the mysql-connection group you have to configure the  host ip 
 adresse of your mysql db, so:
 1- you install you db cluser system 
 2- configure the virtual ip on the  host ip adresse of your mysql in kannel 
 configuration file
 
 group = mysql-connection
 id = mydlr
 host = virtual ip adress of your db nodes
 username = foo
 password = bar
 database = dlr
 max-connections = 1
 
 
 2014-06-03 9:37 GMT+01:00 Abdul Basit basit.e...@gmail.com:
 
 Dear Team,
 
 I am using kannel for SMPP connectivity and storing DLR in mysql DB.
 
 Now working on a scalable solution using Mysql multi-master setup. 
 Currently Kannel connect to only 1 DB server for DLR storage.
 
 Is there any way that i can configure kannel for multiple master DB servers 
 (either in load balance mode or in failover manner)?
 
 Looking forward for suggestions.
 
 --
 regards,
 
 abdul basit | p: +92 32 1416 4196 | o: +92 30 0841 1445
 
 

Re: [PATCH] Optional usage of submit_sm.message_payload for large MTs

[Alexander Malysh]

Hi Stipe,

why this limit of 254? It's hard to explain for users what this mean, IMHO. I 
think, the beast would be to have config switch to use
either short_message or message_payload. Another argument for simple switch 
that some SMSCs expect message_payload even
for short message body.

Alex

Am 20.05.2014 um 17:44 schrieb Stipe Tolj st...@kannel.org:

 Hi list,
 
 at the moment there is no configurable way to have the SMPP client side 
 module rather use the submit_sm.message_payload field for SMPP v3.4+ sessions 
 and large MTs.
 
 We'll always chop to the GSM 140 octet segment size and always use 
 submit_sm.short_message.
 
 Since SMPP is in general independent from the underlying network layer (i.e. 
 GSM), we want to allow for PDUs that can transport larger messages in one PDU.
 
 Please find attached a patchset that allows this, by using the existing 
 config directive 'max-sms-octets' in the 'group = smsc' scope. We can use it 
 for SMPP configuration to indicate what the maximum size of the message for 
 ONE PDU should be.
 
 I.e. a config:
 
  group = smsc
  smsc = smpp
  ...
  max-sms-octets = 32000
 
 would use submit_sm.short_message for any content size = 254, and 
 submit_sm.message_payload for any content size  254. The message is 
 segmented to multiple PDUs of size 'max-sms-octets'.
 
 Comments and votes for committing to SVN trunk are as always welcome.
 
 Stipe
 
 -- 
 ---
 Kölner Landstrasse 419
 40589 Düsseldorf, NRW, Germany
 
 tolj.org system architecture  Kannel Software Foundation (KSF)
 http://www.tolj.org/  http://www.kannel.org/
 
 mailto:st_{at}_tolj.org   mailto:stolj_{at}_kannel.org
 ---
 smpp-message-payload.diff

Re: Does opensmppbox and smsbox have serious memory issues?

[Alexander Malysh]

Hi,

unfortunately this file is not there anymore. Could you please new file please?

Alex

Am 07.05.2014 um 13:15 schrieb hbil...@ecommunicate.biz:

 HI Hanh and Kannel developers,
  
 The memory leaks in the latest svn for smsbox, as mentioned in your post 
 Date: Sat, 3 May 2014 10:06:54 +0700 and  shown 
 inhttps://www.dropbox.com/s/yjrc6wmdm0rwonz/smsbox_memleakcheck_20140503.txt
 are also contributing to the increase in the total memory leak.  Each SMSs 
 needs to also go through smsbox.  There are memory leaks both smsbox and also 
 in opensmppbox.
  
 Thanks for bringing this to the attention of the Kannel devel group and 
 producing these Valgrinds. It’s useful to see what happens to Kannel with a 
 high throughput.
 This is currently not my area of expertise.
  
 We need the help of the top Kannel developers to fix this, so the latest svn 
 will be free of memory leaks.
  
 You mention in the post on Sat, 3 May 2014 10:06:54 +0700: “Hello again, Here 
 is valgrind report for the smsbox memory leaking. This is also the latest 
 kannel revision 5089.
 For me, it still happen, i submit (broadcast) million SMS(s) per day within 
 few hours at 1000 TPS of throughput. Thus each day, smsbox swallow ~ 400MB 
 RAM and not release until server memory exhaust after few days. At this time, 
 the box is auto restarted and i have my memory back, so on, again and again.
  
 I not sure, but in very low throughput system, i am not aware this issue.
  
 ==5730== LEAK SUMMARY:
 ==5730==definitely lost: 231,680 bytes in 14,480 blocks
 ==5730==indirectly lost: 144,790 bytes in 14,479 blocks
 ==5730==  possibly lost: 0 bytes in 0 blocks
 ==5730==still reachable: 1,250 bytes in 40 blocks
 ==5730== suppressed: 0 bytes in 0 blocks
 ==5730== Reachable blocks (those to which a pointer was found) are not shown.
 ==5730== To see them, rerun with: --leak-check=full --show-leak-kinds=all 
 ==5730== ==5730== For counts of detected and suppressed errors, rerun with:
 -v ==5730== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 45 from 10)”
  
 rgds
  
 From: Hanh Le Bich [mailto:hanhmi...@gmail.com] 
 Sent: Wednesday, May 7, 2014 10:32 AM
 To: Rene Kluwen
 Cc: hbil...@ecommunicate.biz; af...@list.fink.org; devel@kannel.org
 Subject: Re: Does opensmppbox and smsbox have serious memory issues?
  
 No Rene, i just monitor by some mem check tool. For example, htop tell me in 
 the fist day, opensmppbox occupied 0.1% of RAM, the next 2 day is was 0.2%, 
 and the 5th day, it is 0.3% now. Slowly increase.
  
 Regards, Hanh.
  
 On Wed, May 7, 2014 at 3:09 PM, Rene Kluwen rene.klu...@chimit.nl wrote:
 Would you happen to have a valgrind output for this?
  
 == Rene
  
 From: Hanh Le Bich [mailto:hanhmi...@gmail.com] 
 Sent: woensdag 7 mei 2014 9:20
 To: hbil...@ecommunicate.biz
 Cc: Rene Kluwen; af...@list.fink.org; devel@kannel.org
 
 Subject: Re: Does opensmppbox and smsbox have serious memory issues?
  
 Hello again,
 Hope you are doing great. 
 After close monitoring opensmppbox after  4 days continuous running, I just 
 want to inform the mem leak still happen, the box is eating few tens (or 
 nearly hundred) byte per day at throughput 100TPS (at max) and keep 
 increasing.
 
 Regards, Hanh.

Re: Does opensmppbox and smsbox have serious memory issues?

[Alexander Malysh]

Hi,

just checked daily snapshot, yes you can use it, this is uptodate.

Alex

Am 29.04.2014 um 04:44 schrieb Hanh Le Bich hanhmi...@gmail.com:

 Dear hbilman  development team,
 I'm willing to help to provide more evident but i have no background to work 
 in IT fields.
 Cause my server has no internet connection thus i cannot get the lastest SVN 
 trunk. Normally i download source files via the daily snapshot, is it ok?
 
 Regards, Hanh.
 
 
 On Mon, Apr 28, 2014 at 12:25 AM, hbil...@ecommunicate.biz wrote:
 Hi Kannel developers,
 
 Hanh posted his Valgrind research to the user group for smsbox and
 opensmppbox.  His results seem interesting and so I'm copying them to this
 thread so the Kannel developers can view them.
 These results can be viewed by following the thread on Wed, Apr 23, 2014 at
 3:41 AM, by Hanh Le Bich hanhmi...@gmail.com with the Subject: Re: 2
 Questions re Redis/Debian. (The email subject is not related to this issue.)
 
 His research shows that opensmppbox and smsbox may have serious memory
 issues.
 I use the word may as until others have confirmed his results, there could
 be a mistake somewhere.
 Is there anyone who has a test environment that can follow his approach and
 confirm for the Kannel community if opensmppbox and smsbox have serious
 memory issues or if his testing approach has flaws?
 
 His approach is:
  Let me describe a little bit for my application back end. It's  pretty
  simple: i make a loop that for each second, it push an sms via kannel
  CGI for 1K mobile numbers, that mean throughput is 1000 msg/sec.
  My kannel configuration is simple too, it's only smsbox - bearerbox
  - SMSC (via smpp), no file storage, no SQL, no dlr (actually
 dlr-mask=8).
   I even don't expect the sms can deliver  to all end users and the app
 run some hours per day only. That why i
  can play with the lasted SVN which don't care so much for the reliability.
 
 For smsbox:
 In the pass when using ver 1.4.3, it was fine for years. After
  upgrade to 1.5.0, after each few days, i realized smsbox is reset,
  then i found it exhaust my memory. It's funny that smsbox consume the
  mem and doesn't release. Example, if it occupies 50% your mem and you
  stop sms pushing, it will 50% forever except the box restarting.
  That's all, same server with no other tasks, same back end, just
  different kannel version.
 
  Just paste the valgrind sum in here:
 
  ==27581== LEAK SUMMARY:
  ==27581==definitely lost: 1,077,904 bytes in 67,369 blocks
  ==27581==indirectly lost: 673,660 bytes in 67,366 blocks
  ==27581==  possibly lost: 160 bytes in 13 blocks
  ==27581==still reachable: 1,240 bytes in 39 blocks
  ==27581== suppressed: 0 bytes in 0 blocks
  ==27581== Reachable blocks (those to which a pointer was found) are
  not shown.
  ==27581== To see them, rerun with: --leak-check=full
  --show-leak-kinds=all ==27581== ==27581== For counts of detected and
  suppressed errors, rerun with: -v ==27581== ERROR SUMMARY: 3 errors
  from 3 contexts (suppressed: 45 from 10)
 
 For opensmppbox
 opensmppbox  drains your memory 10 times faster than smsbox
 ==31087== Memcheck, a memory error detector ==31087== Copyright (C)
 2002-2013, and GNU GPL'd, by Julian Seward et al.
 ==31087== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
 ==31087== Command: /usr/local/sbin/opensmppbox -v -d --
 /etc/kannel/opensmppbox.conf ==31087== Parent PID: 31085 ==31087== ==31087==
 ==31087== HEAP SUMMARY:
 ==31087== in use at exit: 8,163,073 bytes in 36,550 blocks
 ==31087==   total heap usage: 893,827 allocs, 857,277 frees, 295,662,079
 bytes allocated
 ==31087==
 ==31087== 49 (32 direct, 17 indirect) bytes in 2 blocks are definitely lost
 in loss record 485 of 813
 ==31087==at 0x4027434: malloc (vg_replace_malloc.c:291)
 ==31087==by 0x80970B3: gw_native_malloc (gwmem-native.c:87)
 ==31087==by 0x80A37A1: octstr_create_from_data_real (octstr.c:263)
 ==31087==by 0x80A3D81: octstr_duplicate_real (octstr.c:377)
 ==31087==by 0x808B106: cfg_get_real (cfg.c:670)
 ==31087==by 0x8052769: main (opensmppbox.c:2291)
 ==31087==
 ==31087== 79 (64 direct, 15 indirect) bytes in 4 blocks are definitely lost
 in loss record 529 of 813
 ==31087==at 0x4027434: malloc (vg_replace_malloc.c:291)
 ==31087==by 0x80970B3: gw_native_malloc (gwmem-native.c:87)
 ==31087==by 0x80A37A1: octstr_create_from_data_real (octstr.c:263)
 ==31087==by 0x80A3D81: octstr_duplicate_real (octstr.c:377)
 ==31087==by 0x805D52F: msg_duplicate (msg-decl.h:80)
 ==31087==by 0x805651D: catenate_msg (opensmppbox.c:525)
 ==31087==by 0x805686B: check_multipart (opensmppbox.c:1481)
 ==31087==by 0x8057AD8: smpp_to_bearerbox (opensmppbox.c:1639)
 ==31087==by 0x80983AE: new_thread (gwthread-pthread.c:385)
 ==31087==by 0x46F9C38: start_thread (pthread_create.c:304)
 ==31087==by 0x482F78D: clone (clone.S:130)
 ==31087==
 ==31087== 100 (80 direct, 20 indirect) bytes in 5 

Re: Does opensmppbox and smsbox have serious memory issues?

[Alexander Malysh]

Hi,

there was memory issue with smsbox but should be fixed already. Please try to 
run SVN trunk version
because 1.5.0 is really tooo old.

Alex

Am 27.04.2014 um 08:27 schrieb Andreas Fink af...@list.fink.org:

 If there's a memory leak (which it looks like) it should be relatively easy 
 to spot and fix.
 valgrind should be able to tell you where the blocks are allocated which are 
 not freed.
 
 On 26.04.2014, at 22:31, hbil...@ecommunicate.biz wrote:
 
 Hi Rene and other Kannel developers,
 
 Hanh posted his Valgrind research to the user group for smsbox and
 opensmppbox.  His results seem interesting and so I'm copying them to this
 thread so the Kannel developers can view them.
 These results can be viewed by following the thread on Wed, Apr 23, 2014 at
 3:41 AM, by Hanh Le Bich hanhmi...@gmail.com with the Subject: Re: 2
 Questions re Redis/Debian.
 (The email subject is not related to this issue.)
 
 His research shows that opensmppbox and smsbox may have serious memory
 issues.
 I use the word may as until others have confirmed his results, there could
 be a mistake somewhere.
 Is there anyone who has a test environment that can follow his approach and
 confirm for the Kannel community if opensmppbox and smsbox have serious
 memory issues?
 
 His approach is:
 Let me describe a little bit for my application back end. It's  pretty
 simple: i make a loop that for each second, it push an sms via kannel 
 CGI for 1K mobile numbers, that mean throughput is 1000 msg/sec.
 My kannel configuration is simple too, it's only smsbox - bearerbox
 - SMSC (via smpp), no file storage, no SQL, no dlr (actually
 dlr-mask=8).
 
 For smsbox:
 In the pass when using ver 1.4.3, it was fine for years. After 
 upgrade to 1.5.0, after each few days, i realized smsbox is reset, 
 then i found it exhaust my memory. It's funny that smsbox consume the 
 mem and doesn't release. Example, if it occupies 50% your mem and you 
 stop sms pushing, it will 50% forever except the box restarting.
 That's all, same server with no other tasks, same back end, just 
 different kannel version.
 
 Just paste the valgrind sum in here:
 
 ==27581== LEAK SUMMARY:
 ==27581==definitely lost: 1,077,904 bytes in 67,369 blocks
 ==27581==indirectly lost: 673,660 bytes in 67,366 blocks
 ==27581==  possibly lost: 160 bytes in 13 blocks
 ==27581==still reachable: 1,240 bytes in 39 blocks
 ==27581== suppressed: 0 bytes in 0 blocks
 ==27581== Reachable blocks (those to which a pointer was found) are 
 not shown.
 ==27581== To see them, rerun with: --leak-check=full 
 --show-leak-kinds=all ==27581== ==27581== For counts of detected and 
 suppressed errors, rerun with: -v ==27581== ERROR SUMMARY: 3 errors 
 from 3 contexts (suppressed: 45 from 10)
 
 For opensmppbox 
 opensmppbox  drains your memory 10 times faster than smsbox
 ==31087== LEAK SUMMARY:
 ==31087==definitely lost: 78,944 bytes in 4,882 blocks
 ==31087==indirectly lost: 4,911,232 bytes in 4,859 blocks
 ==31087==  possibly lost: 48,496 bytes in 74 blocks
 ==31087==still reachable: 3,124,401 bytes in 26,735 blocks
 ==31087== suppressed: 0 bytes in 0 blocks
 ==31087== Reachable blocks (those to which a pointer was found) are 
 not shown.
 ==31087== To see them, rerun with: --leak-check=full 
 --show-leak-kinds=all ==31087== ==31087== For counts of detected and 
 suppressed errors, rerun with: -v ==31087== ERROR SUMMARY: 10 errors 
 from 10 contexts (suppressed: 45 from 10)
 
 Regards
 
 
 
 
 
 
 
 
 
 Andreas Fink
 
 CEO DataCell ehf
 CEO Backbone ehf
 
 ---
 Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
 Address: Clarastrasse 3, 4058 Basel, Switzerland
 E-Mail:  andr...@fink.org
 www.datacell.com, www.backbone.is, www.finkconsulting.com www.fink.org
 ---
 Jabber/XMPP: andr...@fink.org
 ICQ: 8239353 Skype: andreasfink 
 
 
 
 

Re: Redis delivery report DLR backend

[Alexander Malysh]

Hi,

Lorenzo your account on redmine activated now and email configuration error in 
redmine fixed.

Alex

Am 13.03.2014 um 17:15 schrieb spameden spame...@gmail.com:

 Forwarding to devel-list, hopefully someone would check and copying Alexander.
 
 
 2014-03-13 17:10 GMT+04:00 Lorenzo Bagni ba...@networkweb.net:
 Hi,
 I've found the problem under redis backend crash.
 My dlr-url ( 
 http://my.fqdn.name/DlrManager.aspx31oa=%pda=%Psmsc=%idlrtype=%ddetail=%atempo=%Tid=%idelr=%Auser=%nforeign=%Fidgen=0|1|2|3|4|5|6
  ) contais many parameters with values as %[char], some of this broke 
 /usr/bin/bearerbox, some not but store on Redis backend different values:
 %p %P %T %n = PANIC
 %a is soted as 0x0.07f1160003b48p-1022
 %A is soted as 0x0.07f1160003b48p-1022
 %F is soted as 0.00
 %i is soted as 378
 %d is soted as 378
 
 The dlr-url is passed is urlencoded, so I guess the issue is when the bearer 
 decode and evaluate per params sent to http://kannel-ip:13013/cgi-bin/sendsms.
 
 Last thing, I've tried to register under Kannel Redmine, but after 
 successully registration I cannot login because I've nevere recevied the 
 confirmation mail.
 For admins: could you kinldy check my account and unlock my account?
 
 Thanks in advance
 Bagni
 
 
 2014-03-12 16:06 GMT+01:00 Lorenzo Bagni ba...@networkweb.net:
 
 Hi,
 I've activated the REDIS_DEBUG but the HMSET command works on redis-cli, but 
 not with Kannel:
 bearerbox.log:
 2014-03-12 15:54:14 [30938] [8] DEBUG: DLR[redis]: Adding DLR 
 smsc=kannelfake, ts=8f3d43b4-f93c-4d8f-b681-35b658f74d90, src=51303, 
 dst=39328000, mask=31, boxc=
 2014-03-12 15:54:14 [30938] [8] DEBUG: Adding DLR into keystore
 2014-03-12 15:54:14 [30938] [8] DEBUG: redis cmd: HMSET 
 dlr:kannelfake:8f3d43b4-f93c-4d8f-b681-35b658f74d90:4677782 smsc kannelfake 
 ts 8f3d43b4-f93c-4d8f-b681-35b658f74d90 source 51303 destination 
 39328 service user_mobyt_fake url 
 http://my.fqdn.name/DlrManager.aspx31oa=%pda=%Psmsc=%idlrtype=%ddetail=%atempo=%Tid=%idelr=%Auser=%nforeign=%Fidgen=0|1|2|3|4|5|6
  mask _NULL_ boxc ? status 0
 2014-03-12 15:54:14 [30938] [8] PANIC: /usr/sbin/bearerbox() [0x4a810c]
 2014-03-12 15:54:14 [30938] [8] PANIC: /lib64/libpthread.so.0(+0xf710) 
 [0x7f3d26ec0710]
 2014-03-12 15:54:14 [30938] [8] PANIC: /usr/sbin/bearerbox() [0x48d431]
 2014-03-12 15:54:14 [30938] [8] PANIC: /usr/sbin/bearerbox() [0x41fa63]
 2014-03-12 15:54:14 [30938] [8] PANIC: 
 /usr/sbin/bearerbox(dlr_add_real+0x3a3) [0x41cf63]
 2014-03-12 15:54:14 [30938] [8] PANIC: /usr/sbin/bearerbox() [0x457b7f]
 2014-03-12 15:54:14 [30938] [8] PANIC: 
 /usr/sbin/bearerbox(smscconn_send+0x5f) [0x42406f]
 2014-03-12 15:54:14 [30938] [8] PANIC: /usr/sbin/bearerbox(smsc2_rout+0x428) 
 [0x417f68]
 2014-03-12 15:54:14 [30938] [8] PANIC: /usr/sbin/bearerbox() [0x418e1d]
 2014-03-12 15:54:14 [30938] [8] PANIC: /usr/sbin/bearerbox() [0x491da9]
 2014-03-12 15:54:14 [30938] [8] PANIC: /lib64/libpthread.so.0(+0x79d1) 
 [0x7f3d26eb89d1]
 2014-03-12 15:54:14 [30938] [8] PANIC: /lib64/libc.so.6(clone+0x6d) 
 [0x7f3d25c50b6d]
 
 Any clue for this?
 Thanks in advance
 Bagni
 
 
 2014-03-06 12:37 GMT+01:00 Lorenzo Bagni ba...@networkweb.net:
 
 Hi all,
 I'm facing a blocking problem on redis backend for delivery report.
 I'm sendig correctly (and receive on my MT) but the bearerbox hangs when try 
 to write on redis:
 
 smsc log:
 2014-03-06 11:44:54 [25724] [7] DEBUG: SMPP[mobytusaprod]: Got PDU:
 2014-03-06 11:44:54 [25724] [7] DEBUG: SMPP PDU 0x7f6c08000a10 dump:
 2014-03-06 11:44:54 [25724] [7] DEBUG:   type_name: submit_sm_resp
 2014-03-06 11:44:54 [25724] [7] DEBUG:   command_id: 2147483652 = 0x8004
 2014-03-06 11:44:54 [25724] [7] DEBUG:   command_status: 0 = 0x
 2014-03-06 11:44:54 [25724] [7] DEBUG:   sequence_number: 2 = 0x0002
 2014-03-06 11:44:54 [25724] [7] DEBUG:   message_id:
 2014-03-06 11:44:54 [25724] [7] DEBUG:Octet string at 0x7f6c080011a0:
 2014-03-06 11:44:54 [25724] [7] DEBUG:  len:  36
 2014-03-06 11:44:54 [25724] [7] DEBUG:  size: 37
 2014-03-06 11:44:54 [25724] [7] DEBUG:  immutable: 0
 2014-03-06 11:44:54 [25724] [7] DEBUG:  data: 37 35 33 31 62 34 32 61 2d 
 66 34 34 66 2d 34 33   7531b42a-f44f-43
 2014-03-06 11:44:54 [25724] [7] DEBUG:  data: 38 31 2d 39 63 35 61 2d 36 
 31 37 65 32 32 33 31   81-9c5a-617e2231
 2014-03-06 11:44:54 [25724] [7] DEBUG:  data: 36 30 35 63 
   605c
 2014-03-06 11:44:54 [25724] [7] DEBUG:Octet string dump ends.
 2014-03-06 11:44:54 [25724] [7] DEBUG: SMPP PDU dump ends.
 2014-03-06 11:44:54 [25724] [7] DEBUG: new group created `smpp'
 2014-03-06 11:44:54 [25724] [7] DEBUG: group=`smpp' key=`mobyt_campaignid' 
 value=`1245'
 2014-03-06 11:44:54 [25724] [7] DEBUG: DLR[redis]: Adding DLR 
 smsc=mobytusaprod, ts=7531b42a-f44f-4381-9c5a-617e2231605c, src=51303, 
 dst=393284677782, mask=31, boxc=
 2014-03-06 11:44:54 [25724] [7] DEBUG: Adding DLR into keystore
 
 bearerbox log:
 

Re: [PATCH] Meta-data support for SMPP resp PDUs

[Alexander Malysh]

Hi all,

any objections or should I commit this patch?

Alex

Am 27.01.2014 um 16:22 schrieb Alexander Malysh amal...@kannel.org:

 Hi,
 
 attached is the announced patch for this functionality.
 
 Alex
 smpp_resp_meta.patch
 
 Am 24.01.2014 um 09:54 schrieb Alexander Malysh a...@malysh.de:
 
 Hi Stipe,
 
 as usual I'm writing some critic for this patch. I do like this 
 functionality BUT I don't like how this
 patch implemented, I don't like this _real don't _real functions because we 
 have already to much of them
 and have to start to cleanup it. The second issue is with va_args where it's 
 not needed and at this place it's
 not needed.
 
 We have such patch at GTX and I will try to extract this from our sources 
 this weekend but in a nutshell it works as follows:
 
 * sent sms with dlr_mask SMSC_CONN_SUCCESS
 * submit_sm
 * submit_sm_resp - pack TLVs into meta to the sent sms
 * bb_smscconn_(sent|failed) - generate DLR  SMSC_SUCCESS and put meta_data 
 from sent sms into resulting DLR
 * smsbox forward it to application
 
 - no complex va_args , no _real functions needed. This is then really clean.
 
 Btw. The same technic we use for the HTTP , e.g. to pack all CGI params into 
 meta_data for the later processing in the application.
 
 Alex
 
 
 Am 21.01.2014 um 19:52 schrieb Stipe Tolj st...@kannel.org:
 
 Hi list,
 
 this is a patchset in reference to a request that Paulo Correia made in the 
 users@ mailing list, [Msg-Id: 52dda269.30...@pdmfc.com].
 
 The basic idea is: in SMPP (and other protocols too), we may have meta-data 
 parts (optional TLVs in SMPP) that we get on the Sent SMS event, hence in 
 the submit_sm_resp PDU for SMPP. At the moment we don't have a construct to 
 pass this meta-data in the corresponding intermediate DLR SMSC SUCCESS 
 event that we pass to smsbox.
 
 The attached patchset allows this at least for optional TLVs coming inside 
 submit_sm_resp. I don't see a clean way to do this for the bind resp PDUs 
 though.
 
 The patchset SHOULD be not intrusive, adding only the feature and not 
 changing any standard behavior. Please review and vote for commit.
 
 Stipe
 
 -- 
 ---
 Kölner Landstrasse 419
 40589 Düsseldorf, NRW, Germany
 
 tolj.org system architecture  Kannel Software Foundation (KSF)
 http://www.tolj.org/  http://www.kannel.org/
 
 mailto:st_{at}_tolj.org   mailto:stolj_{at}_kannel.org
 ---
 smpp-resp-pdu-optional-tvls.diff
 
 

Fwd: [PATCH] Meta-data support for SMPP resp PDUs

[Alexander Malysh]

Forgot to add devel to CC...

Alex

Anfang der weitergeleiteten Nachricht:

 Von: Alexander Malysh a...@malysh.de
 Betreff: Aw: [PATCH] Meta-data support for SMPP resp PDUs
 Datum: 24. Januar 2014 09:54:21 MEZ
 An: Stipe Tolj st...@kannel.org
 Kopie: devel@kannel.org devel@kannel.org
 
 Hi Stipe,
 
 as usual I'm writing some critic for this patch. I do like this functionality 
 BUT I don't like how this
 patch implemented, I don't like this _real don't _real functions because we 
 have already to much of them
 and have to start to cleanup it. The second issue is with va_args where it's 
 not needed and at this place it's
 not needed.
 
 We have such patch at GTX and I will try to extract this from our sources 
 this weekend but in a nutshell it works as follows:
 
 * sent sms with dlr_mask SMSC_CONN_SUCCESS
 * submit_sm
 * submit_sm_resp - pack TLVs into meta to the sent sms
 * bb_smscconn_(sent|failed) - generate DLR  SMSC_SUCCESS and put meta_data 
 from sent sms into resulting DLR
 * smsbox forward it to application
 
 - no complex va_args , no _real functions needed. This is then really clean.
 
 Btw. The same technic we use for the HTTP , e.g. to pack all CGI params into 
 meta_data for the later processing in the application.
 
 Alex
 
 
 Am 21.01.2014 um 19:52 schrieb Stipe Tolj st...@kannel.org:
 
 Hi list,
 
 this is a patchset in reference to a request that Paulo Correia made in the 
 users@ mailing list, [Msg-Id: 52dda269.30...@pdmfc.com].
 
 The basic idea is: in SMPP (and other protocols too), we may have meta-data 
 parts (optional TLVs in SMPP) that we get on the Sent SMS event, hence in 
 the submit_sm_resp PDU for SMPP. At the moment we don't have a construct to 
 pass this meta-data in the corresponding intermediate DLR SMSC SUCCESS event 
 that we pass to smsbox.
 
 The attached patchset allows this at least for optional TLVs coming inside 
 submit_sm_resp. I don't see a clean way to do this for the bind resp PDUs 
 though.
 
 The patchset SHOULD be not intrusive, adding only the feature and not 
 changing any standard behavior. Please review and vote for commit.
 
 Stipe
 
 -- 
 ---
 Kölner Landstrasse 419
 40589 Düsseldorf, NRW, Germany
 
 tolj.org system architecture  Kannel Software Foundation (KSF)
 http://www.tolj.org/  http://www.kannel.org/
 
 mailto:st_{at}_tolj.org   mailto:stolj_{at}_kannel.org
 ---
 smpp-resp-pdu-optional-tvls.diff
 

Re: bug reporting about the retry of message when smpp gateway receive error code from smsc

[Alexander Malysh]

Hi Marc,

the issue is due to fact that SMSC returns wrong error code to kannel. 0x58 is 
throttling error and not queue full (which would be 0x14).
Therefore kannel will retry any temporarily errors. I know that there was/is 
bug in the retry handling and I'm going to fix it in the near
future but if you want that also the old kannel clients don't have any problem, 
please use appropriate errorcode in the SMSC.

Thanks,
Alex

Am 24.01.2014 um 14:17 schrieb marc.bazi...@orange.com 
marc.bazi...@orange.com:

 Hi
 We faced to some trouble with application that use kannel.
 A subscriber has got a limited number of message on the smsc queue when he is 
 unreachable. By example if a subscriber turned off his mobile and someone or 
 something send him message , the sms will be placed on the inetrnal db from 
 SMSC in order to send him when he will be reachable again on the network. 
 This db is called SFE store and forward engine  but the number of messages 
 stored are limited . on ournetwork the maximum message that is kept is 10. I 
 f a susbcriber has got his queue full and a application try to send him a new 
 message , the smsc will respond with a 0x0058 error code message to the 
 smpp gateway. this error is in fact a mapping of the error 0x0014 messag 
 equeue full.
  
 The trouble we faced to is that kannel will try to send the message  back 
 until the subscriber will receive it (  until he will turned on the mobile 
 ).Some of VAS service we used has got an huge traffic and in some affiliate ( 
 often in Africa country ) as one message generate 6 retry per sec , it filled 
 the capacity of the smsc and often it make crash the smsc. Some workaround 
 has been found in order to avoid this crash but all the sms are loosed. This 
 could be problematic when we talk about sms that dealt with money exchange 
 service.
  
 is there any way to manage the message that has not being taking by the smsc 
 due to some error , to keep the message into the smpp gateway DB  and do some 
 retry rule to not loose the message. As far as i can understand from the 
 behaviour of kannel , there's a db used for dlr , but is it foressen to do 
 this kind of thing?
  
 I can send you any pcap trace , log  , etc you want. 
 tell me if it is clear or not
  
 Thx by advance for your help and advice ,
 Br
 Marc
  
 
 
 Marc Bazimon
 Expert skill center SMSC Comverse
 Orange/OF/DO/DORM/DSI/DSM
 tél. (+262) 02 62 23 16 14
 mob. (+262) 06 92 08 03 92
 marc.bazi...@orange.com
  
 _
 
 Ce message et ses pieces jointes peuvent contenir des informations 
 confidentielles ou privilegiees et ne doivent donc
 pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
 ce message par erreur, veuillez le signaler
 a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
 electroniques etant susceptibles d'alteration,
 Orange decline toute responsabilite si ce message a ete altere, deforme ou 
 falsifie. Merci.
 
 This message and its attachments may contain confidential or privileged 
 information that may be protected by law;
 they should not be distributed, used or copied without authorisation.
 If you have received this email in error, please notify the sender and delete 
 this message and its attachments.
 As emails may be altered, Orange is not liable for messages that have been 
 modified, changed or falsified.
 Thank you.
 orange_logo.gif

Re: [PATCH] No PANIC on failing store_load()

[Alexander Malysh]

Hi Rene,

+1 if you will use sms_type enum instead of hardcoded values.

Alex

Am 17.09.2013 um 18:56 schrieb Rene Kluwen rene.klu...@chimit.nl:

 Agreed with Stipe here.
 If the users enters a different value for sms_type, it is their
 responsibility.
 
 What is covered here, is an accidental wrong value for sms_type, because
 nowhere is documented that sms_type should be set to MT (value '2') because
 otherwise Kannel will panic.
 
 Attached is a simple solution that will benefit everyone. Which is ready to
 be committed.
 
 == Rene
 
 -Original Message-
 From: devel [mailto:devel-boun...@kannel.org] On Behalf Of Stipe Tolj
 Sent: dinsdag 17 september 2013 17:55
 Cc: kannel_dev_mailinglist devel@kannel. org
 Subject: Re: [PATCH] No PANIC on failing store_load()
 
 Am 17.09.2013 17:22, schrieb Willy Mularto:
 Sorry,  it doesn't mean setting default value during table creation 
 right? Because this approach will still might be interupted by user's 
 value. Thanks.
 
 The default value is defined during table creation, yes. The point is: 
 IF the user doesn't insert a specific value for the field THEN the default
 is applied. If the user specifically inserts -1 then he will get -1. But
 that makes no logical sense.
 
 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
 ---
 
 default.diff

Re: Proposed changes in gwlib/http.c to fix a meta_data issue

[Alexander Malysh]

Hi,

how did you send your request, example URL please.

Make sure you send meta_data as follow:

sendsms?meta_data=URLENCODED(?group?key=URLENCODED(value))...

Alex

Am 31.08.2013 um 02:40 schrieb Germán Bobr - Redmond Software 
german.b...@redmondsoftware.com:

 Hello!
  
 Using send-sms cgi to send messages with message_payload tlv i found out I 
 couldn’t send characters like ‘?’ and ‘’ even when I was encoding them as 
 %26 and %3F
  
 I’d never messed with kannel sources before, but looking at it I found that 
 the problem was because of parse_cgivars function in gwlib/http.c doing an 
 octstr_url_decode for all values in the request.
  
 I know it’s not a pretty solution but I changed this to make it work:
  
 On gwlib/http.c lines 2553 where code reads:
 octstr_url_decode(v-name);
 octstr_url_decode(v-value);
  
 I changed it for:
 octstr_url_decode(v-name);  
 if(octstr_str_compare(v-name,meta-data))
octstr_url_decode(v-value);
  
  
 Does anyone have a better idea on how to fix the issue?
 Should I make a patch for this?
  
 Thank you
  
 Germán Bobr
 german.b...@redmondsoftware.com
 image001.png
  

Re: [Patch] smsc connection status url

[Alexander Malysh]

Hi,

idea is OK but implementation is wrong.

1) +http_start_request(caller, HTTP_METHOD_GET, url, request_headers,
+  NULL, 1, NULL, NULL);

I'm missing consumer who reads completed requests otherwise you will leak 
memory.

2) why do you add it to smpp module instead of to add it to bb_smscconn? Here 
it will work for all
smsc types.

Alex

Am 13.08.2013 um 11:32 schrieb Semion Spivak sem...@smscoin.com:

 Hi all,
 
 I'm trying to modify the bearerbox so the bb would make a HTTP GET request to 
 a specific url every time a SMPP SMSC client loses the connection or comes 
 back online.
 
 All this to ensure that our routing app reacts as quickly as possible when 
 the connection fails and routes the traffic away to another SMSC. Currently 
 we are polling the Kannel's status page once a minute, which is not adaptive 
 enough.
 
 We considered designing our routing app to state several smsc-ids (like 
 smsc-id=primary;secondary) when submitting the message to Kannel, so Kannel 
 would choose the secondary smsc in case the primary is not available, but we 
 saw an overhead of updating an actual price, user's balance and smsc-id of 
 the message after it has been submitted to the upstream SMSC.
 
 The patch is made against rev 5043 with `svn diff --patch-compatible` 
 command. Not being much confident with C++ myself, I'm asking for your advice 
 - are there any critical flaws I'm not aware of?
 
 This is a basic version, and there is a room for improvement, like adding 
 templates to the url for passing smsc host, port, username, service-type 
 etc., and adding this notifications to other smsc types.
 
 And as allways, if anyone finds it usefull, I would be honored if you add it 
 to the Kannel codebase.
 
 Thanks a lot in advance,
 -- 
 Regards,
 Semion Spivak,
 SmsCoin.com
 smsc_status_url.patch

Re: [PATCH] Default 'dlr-[url|mask]' for 'group = sms-service' context

[Alexander Malysh]

Hi,

looks good, got for it...

Alex

Am 16.08.2013 um 18:04 schrieb Stipe Tolj st...@kannel.org:

 Hi list,
 
 here is a simple patch that adds the capability to define an default DLR 
 URL and bit mask for the 'group = sms-service', when we use the HTTP response 
 (or a defined fixed reply string) directly as MT back to the user.
 
 At the moment we can parse the X-Kannel HTTP headers for a [get|post]-url'ed 
 sms-service, but, i.e. have no mechanism to do this for exec'ed or fixed 
 replies. This config directive allows it to define a default DLR URL with the 
 corresponding escape codes defined, that are called on the DLR event getting 
 back to the smsbox scope.
 
 The patch is considerable easy and adds just a couple of checks. We'll still 
 use the X-Kannel HTTP header values in favor, before falling back to the 
 default config values from these directives.
 
 Please review and comment.
 
 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
 ---
 sms-service-dlr.diff

Re: Another sms-resend-retry thread...

[Alexander Malysh]

Hi,

sms-resend-retry is still ignored in 1.5 but 1.5 SMPP has better throughout 
handling so that this issue may be considered as fixed
if you configure right throughput for SMPP connection.

Tip: Better to use SVN trunk version because we did a lot of changes since 1.5 
and it may be considered as stable.

Alex

Am 29.07.2013 um 20:25 schrieb Brian McCavour bmccav...@yahoo.com:

 
 Hi guys,
 
 I'm having the same old problem of sms-resend-retry being ignored for 
 concatenated msg with coding=2, when the smsc return a Queue full error. 
 Kannel just spams the SMSC and all kind of nasty happens.
 Looking around the threads I've seen a LOTS of people with the same issue but 
 never a proper resolution other then code changes or to disable concatenation 
 (ew).
 
 Ex: 
 http://kannel.6189.n7.nabble.com/Kannel-ignoring-sms-resend-retry-td13400.html
 http://kannel.6189.n7.nabble.com/sms-resend-retry-ignored-td4759.html
 
 There is also this bug that is many years old, but never set to fixed:
 https://redmine.kannel.org/issues/352
 
 I am using Kannel 1.4.3
 Is there any news on this? Is it fixed in 1.5.0 ?
 
 Thanks,
 Brian

Re: Another sms-resend-retry thread...

[Alexander Malysh]

Hi,

seems you are right, forgot that I fixed it already :-)

Alex

Am 30.07.2013 um 14:47 schrieb Brian McCavour bmccav...@yahoo.com:

 Hi Alex,
 
 Thanks for your response. I wish I had known 1.5.0 was stable before I 
 started modifying 1.4.3 about 8 months ago :(
 Now it will be a big task to rebase it with my changes, since I modified it 
 quick and dirty with the thought of never rebasing (beginner mistakes...)
 
 Right before seeing your response though, I noticed this bug fixed by you: 
 https://redmine.kannel.org/issues/529
 Looking briefly through the patch it seems to add the retry count to the 
 SMSCCONN_FAILED_TEMPORARILY case for split messages.
 Isn't this a fix for that issue?
 
 
 Brian
 
 From: Alexander Malysh amal...@kannel.org
 To: Brian McCavour bmccav...@yahoo.com 
 Cc: devel@kannel.org devel@kannel.org 
 Sent: Tuesday, July 30, 2013 3:59:36 AM
 Subject: Re: Another sms-resend-retry thread...
 
 Hi,
 
 sms-resend-retry is still ignored in 1.5 but 1.5 SMPP has better throughout 
 handling so that this issue may be considered as fixed
 if you configure right throughput for SMPP connection.
 
 Tip: Better to use SVN trunk version because we did a lot of changes since 
 1.5 and it may be considered as stable.
 
 Alex
 
 Am 29.07.2013 um 20:25 schrieb Brian McCavour bmccav...@yahoo.com:
 
 
 Hi guys,
 
 I'm having the same old problem of sms-resend-retry being ignored for 
 concatenated msg with coding=2, when the smsc return a Queue full error. 
 Kannel just spams the SMSC and all kind of nasty happens.
 Looking around the threads I've seen a LOTS of people with the same issue 
 but never a proper resolution other then code changes or to disable 
 concatenation (ew).
 
 Ex: 
 http://kannel.6189.n7.nabble.com/Kannel-ignoring-sms-resend-retry-td13400.html
 http://kannel.6189.n7.nabble.com/sms-resend-retry-ignored-td4759.html
 
 There is also this bug that is many years old, but never set to fixed:
 https://redmine.kannel.org/issues/352
 
 I am using Kannel 1.4.3
 Is there any news on this? Is it fixed in 1.5.0 ?
 
 Thanks,
 Brian
 
 
 

test pls ignore

[Alexander Malysh]

Re: 500 error in redmine

[Alexander Malysh]

fixed

Am 12.05.2013 um 18:19 schrieb spameden spame...@gmail.com:

 https://redmine.kannel.org/issues/686

Re: [PATCH] Abstraction for config resources, allowing file, URL, pipe, etc.

[Alexander Malysh]

Hi Rene,

we need http support in the config because you can pipe it with lynx BUT if you 
will use
include directive you want http support as well.

Alex

Am 02.05.2013 um 23:05 schrieb Rene Kluwen rene.klu...@chimit.nl:

 For http:
 
 lynx -dump  | bearerbox /dev/stdin
 
 -Original Message-
 From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf
 Of Alexander Malysh
 Sent: maandag 29 april 2013 18:44
 To: Stipe Tolj
 Cc: devel@kannel.org
 Subject: Re: [PATCH] Abstraction for config resources, allowing file, URL,
 pipe, etc.
 
 Hi,
 
 just came across this patch again and find it unnecessary complicated. Why
 we have to differentiate pipe and file and why we have to tell config_read
 which type of config to read?
 
 For pipe:
 $ cat config | bearerbox /dev/stdin
 
 The same as above foe the file. And for HTTP just define filename as HTTP
 URI. That's it. No modifications in the boxes needed because config module
 will handle this transparently.
 
 Alex
 
 Am 19.10.2012 um 05:34 schrieb Stipe Tolj st...@kannel.org:
 
 Hi list,
 
 I have abstracted the gwlib/cfg.[ch] module in order not to handle simply
 a 'config file', but a 'config resource', which then can be either of:
 
 - a config file
 - a config URL, retrieving the config via the HTTP body
 - the stdin pipe, allowing to pipe in a config
 - a data block itself, interpreted as config
 
 Now, to demonstrate the effect, here are some sample ways on how Kannel's
 daemon can be then started:
 
 $ bearerbox
 
 will look for 'kannel.conf', as it does today.
 
 $ bearerbox smskannel.conf
 
 will open the local 'smskannel.conf' file, parse and expand it, as it does
 today.
 
 $ bearebox http://host/smskannel.conf
 
 will HTTP GET to the URL and pull the config from the HTTP response body.
 
 $ cat smskannel.conf | bearerbox pipe
 
 will instruct bearerbox to read in the config from the stdin pipe.
 
 Ok, sounds sweet, right? But is there more? Yes, there is. Due that the
 gwlib/cfg.[ch] module is abstracted on these types of resources for the
 config, we can mix them using the 'include = resource' statement.
 
 I.e. I can have a local smskannel.conf that includes a remote URL config
 part, or I can fetch a remote URL config block, but refer again to local
 config files, etc.
 
 Now you may ask what's this used for, you have been living quite fine with
 the normal local config style, or even have sync'ed configs via rsync to
 achieve HA setups?
 
 Yes, sync'ing the filesystem is a way to make remote changes for a
 Kannel worker node. But I wanted something that is even more simple, like
 the HTTP URL call fetching of the config.
 
 This allows a controler node to instruct how the Kannel worker nodes
 will operate. Meaning, to which SMSCs they connect, which sms-services they
 need to obey, etc.
 
 It makes things simply more flexible, especially when you start to look at
 large scalability, HA and LB issues.
 
 The patchset can be found at URL:
 http://www.kannel.org/~tolj/patchsets/cfg/gateway-cfg.diff
 
 NOTE: The user's guide part is still missing, I'll make sure this gets
 into the patchset before committing.
 
 Reviews, comments, votes welcome.
 
 Stipe
 
 -- 
 ---
 Kölner Landstrasse 419
 40589 Düsseldorf, NRW, Germany
 
 tolj.org system architecture  Kannel Software Foundation (KSF)
 http://www.tolj.org/  http://www.kannel.org/
 
 mailto:st_{at}_tolj.org   mailto:stolj_{at}_kannel.org
 ---
 
 
 
 
 

Re: [PATCH] Abstraction for config resources, allowing file, URL, pipe, etc.

[Alexander Malysh]

Hi,

just came across this patch again and find it unnecessary complicated. Why we 
have to differentiate pipe and file and why we have to tell config_read which 
type of config to read?

For pipe:
$ cat config | bearerbox /dev/stdin

The same as above foe the file. And for HTTP just define filename as HTTP URI. 
That's it. No modifications in the boxes needed because config module will 
handle this transparently.

Alex

Am 19.10.2012 um 05:34 schrieb Stipe Tolj st...@kannel.org:

 Hi list,
 
 I have abstracted the gwlib/cfg.[ch] module in order not to handle simply a 
 'config file', but a 'config resource', which then can be either of:
 
 - a config file
 - a config URL, retrieving the config via the HTTP body
 - the stdin pipe, allowing to pipe in a config
 - a data block itself, interpreted as config
 
 Now, to demonstrate the effect, here are some sample ways on how Kannel's 
 daemon can be then started:
 
  $ bearerbox
 
 will look for 'kannel.conf', as it does today.
 
  $ bearerbox smskannel.conf
 
 will open the local 'smskannel.conf' file, parse and expand it, as it does 
 today.
 
  $ bearebox http://host/smskannel.conf
 
 will HTTP GET to the URL and pull the config from the HTTP response body.
 
  $ cat smskannel.conf | bearerbox pipe
 
 will instruct bearerbox to read in the config from the stdin pipe.
 
 Ok, sounds sweet, right? But is there more? Yes, there is. Due that the 
 gwlib/cfg.[ch] module is abstracted on these types of resources for the 
 config, we can mix them using the 'include = resource' statement.
 
 I.e. I can have a local smskannel.conf that includes a remote URL config 
 part, or I can fetch a remote URL config block, but refer again to local 
 config files, etc.
 
 Now you may ask what's this used for, you have been living quite fine with 
 the normal local config style, or even have sync'ed configs via rsync to 
 achieve HA setups?
 
 Yes, sync'ing the filesystem is a way to make remote changes for a Kannel 
 worker node. But I wanted something that is even more simple, like the HTTP 
 URL call fetching of the config.
 
 This allows a controler node to instruct how the Kannel worker nodes will 
 operate. Meaning, to which SMSCs they connect, which sms-services they need 
 to obey, etc.
 
 It makes things simply more flexible, especially when you start to look at 
 large scalability, HA and LB issues.
 
 The patchset can be found at URL:
 http://www.kannel.org/~tolj/patchsets/cfg/gateway-cfg.diff
 
 NOTE: The user's guide part is still missing, I'll make sure this gets into 
 the patchset before committing.
 
 Reviews, comments, votes welcome.
 
 Stipe
 
 -- 
 ---
 Kölner Landstrasse 419
 40589 Düsseldorf, NRW, Germany
 
 tolj.org system architecture  Kannel Software Foundation (KSF)
 http://www.tolj.org/  http://www.kannel.org/
 
 mailto:st_{at}_tolj.org   mailto:stolj_{at}_kannel.org
 ---
 

Re: wap client with SAR

[Alexander Malysh]

Hi,

any objections from WAP Experts?

Alex

Am 20.03.2013 um 23:45 schrieb Piotr Galecki 
piotr_gale...@affirmednetworks.com:

 Hi Stipe,
 
 Attached is the latest patch for fakewap with additional functionality:
 - parse WSP message and save only the received payload to the output file
 - support for connectionless get/post
 - robustness fixes for Post (resend group segments if no ack), packet loss 
 simulation
 
 Usage:
 [root@contentsim11-UE kannel]# ./fakewap 
 2013-03-20 18:30:43 [11297] [0] PANIC: fakewap version 1.6
 Usage: fakewap [options] url ...
 
 where options are:
 
 -hhelp
 -g hostname   hostname or IP number of gateway (default: localhost)
 -p port   port number of gateway (default: 9201)
 -m maxmaximum number of requests fakewap will make (default: 
 1)
 -i interval   interval between requests (default: 1.0 seconds)
 -c threadsnumber of concurrent clients simulated (default: 1)
 -V protoversion   protocol version field, as an integer (default: 0)
 -T pdu-type   PDU type, as an integer (default: 1)
 -t tcltransaction class, as an integer (default: 2)
 -nset tid_new flag in packets, forces gateway to flush cache
(default: off)
 -s  test separation, by concatenating ack and disconnect pdus
(default: off)
 -d difference difference between successive tid numbers (default: 1)
 -FAccept failure and continue rather than exiting
 -A agentuser agent
 -C content-type Specify content type: text, mms
 -D level  debug level (0=none(default), 1=brief, 2=verbose
 -I addr[:port]  Specify source address
 -M mode Transaction mode: 0=connectionless, 1=connection-oriented
 -P in-filePost data from file
 -w out-file   Write received data to file
 -l loss-precent Simulate packet loss
 
 The urls are fetched in random order.
 
 I have verified the following:
 
 #1 Connectionless GET
 ./fakewap -g 10.32.35.61 -D 1 -M 0 http://10.48.1.231/sqa/file_1k.txt
 2013-03-20 18:24:49 [11290] [0] ERROR: Error while gw_gethostbyname occurs.
 2013-03-20 18:24:49 [11290] [0] ERROR: System error 2: No such file or 
 directory
 2013-03-20 18:24:49 [11290] [0] ERROR: Can't find out official hostname for 
 this host, using `contentsim11-UE' instead.
 2013-03-20 18:24:49 [11290] [0] INFO: fakewap: starting
 2013-03-20 18:24:49 [11290] [0] DEBUG: Sent WSP_GET packet
 2013-03-20 18:24:50 [11290] [0] INFO: fakewap: Received WSP Reply with status 
 code 200OK
 2013-03-20 18:24:50 [11290] [0] INFO: fakewap: finished session # 1
 2013-03-20 18:24:50 [11290] [0] INFO: fakewap: complete.
 2013-03-20 18:24:50 [11290] [0] INFO: fakewap: 1 client threads made total 1 
 transactions.
 2013-03-20 18:24:50 [11290] [0] INFO: fakewap: total running time 1.0 seconds
 2013-03-20 18:24:50 [11290] [0] INFO: fakewap: 1.0 messages/seconds on average
 2013-03-20 18:24:50 [11290] [0] INFO: fakewap: time of best, worst and 
 average transaction: 0.6 s, 0.6 s, 0.6 s
 [root@contentsim11-UE kannel]#
 
 #2 Connection-oriented GET
 [root@contentsim11-UE kannel]# ./fakewap -g 10.32.35.61 -D 1 -M 1 
 http://10.48.1.231/sqa/file_2k.txt
 2013-03-20 18:28:20 [11293] [0] ERROR: Error while gw_gethostbyname occurs.
 2013-03-20 18:28:20 [11293] [0] ERROR: System error 2: No such file or 
 directory
 2013-03-20 18:28:20 [11293] [0] ERROR: Can't find out official hostname for 
 this host, using `contentsim11-UE' instead.
 2013-03-20 18:28:20 [11293] [0] INFO: fakewap: starting
 2013-03-20 18:28:20 [11293] [0] DEBUG: Sent WSP_CONNECT packet
 2013-03-20 18:28:21 [11293] [0] DEBUG: Received WSP_ConnectReply, SessID 14
 2013-03-20 18:28:21 [11293] [0] DEBUG: Sent WTP_ACK packet
 2013-03-20 18:28:21 [11293] [0] DEBUG: Sent WSP_GET packet
 2013-03-20 18:28:21 [11293] [0] DEBUG: Received WTP_RESULT pdu, gtr 0, ttr 0, 
 payload len 1380
 2013-03-20 18:28:21 [11293] [0] DEBUG: Received WTP_SEGM_RESULT pdu, psn 1, 
 gtr 0, ttr 1, payload len 703
 2013-03-20 18:28:21 [11293] [0] DEBUG: Sending WTP_ACK pdu, gtr_psn 1
 2013-03-20 18:28:21 [11293] [0] DEBUG: Sent WTP_ACK packet
 2013-03-20 18:28:21 [11293] [0] INFO: fakewap: Received WSP Reply with status 
 code 200OK
 2013-03-20 18:28:21 [11293] [0] DEBUG: Sent WSP_DISCONNECT packet
 2013-03-20 18:28:21 [11293] [0] INFO: fakewap: finished session # 1
 2013-03-20 18:28:21 [11293] [0] INFO: fakewap: complete.
 2013-03-20 18:28:21 [11293] [0] INFO: fakewap: 1 client threads made total 1 
 transactions.
 2013-03-20 18:28:21 [11293] [0] INFO: fakewap: total running time 1.0 seconds
 2013-03-20 18:28:21 [11293] [0] INFO: fakewap: 1.0 messages/seconds on average
 2013-03-20 18:28:21 [11293] [0] INFO: fakewap: time of best, worst and 
 average transaction: 0.2 s, 0.2 s, 0.2 s
 [root@contentsim11-UE kannel]#
 
 #3 Connection-oriented POST of MMS message via WAPGW to MMSC
 
 [root@contentsim11-UE kannel]# ./fakewap -g 10.32.35.61 -P 
 /root/mms/Picture1.mms -C mms -w /tmp/mms-confirm.txt 

Re: wap client with SAR

[Alexander Malysh]

Hi,

commited to SVN.

Alex

Am 09.04.2013 um 09:24 schrieb Alexander Malysh amal...@kannel.org:

 Hi,
 
 any objections from WAP Experts?
 
 Alex
 
 Am 20.03.2013 um 23:45 schrieb Piotr Galecki 
 piotr_gale...@affirmednetworks.com:
 
 Hi Stipe,
 
 Attached is the latest patch for fakewap with additional functionality:
 - parse WSP message and save only the received payload to the output file
 - support for connectionless get/post
 - robustness fixes for Post (resend group segments if no ack), packet loss 
 simulation
 
 Usage:
 [root@contentsim11-UE kannel]# ./fakewap 
 2013-03-20 18:30:43 [11297] [0] PANIC: fakewap version 1.6
 Usage: fakewap [options] url ...
 
 where options are:
 
 -h   help
 -g hostname  hostname or IP number of gateway (default: localhost)
 -p port  port number of gateway (default: 9201)
 -m max   maximum number of requests fakewap will make (default: 
 1)
 -i interval  interval between requests (default: 1.0 seconds)
 -c threads   number of concurrent clients simulated (default: 1)
 -V protoversion  protocol version field, as an integer (default: 0)
 -T pdu-type  PDU type, as an integer (default: 1)
 -t tcl   transaction class, as an integer (default: 2)
 -n   set tid_new flag in packets, forces gateway to flush cache
   (default: off)
 -s  test separation, by concatenating ack and disconnect pdus
   (default: off)
 -d differencedifference between successive tid numbers (default: 1)
 -F   Accept failure and continue rather than exiting
 -A agentuser agent
 -C content-type Specify content type: text, mms
 -D level debug level (0=none(default), 1=brief, 2=verbose
 -I addr[:port]  Specify source address
 -M mode Transaction mode: 0=connectionless, 1=connection-oriented
 -P in-file   Post data from file
 -w out-file  Write received data to file
 -l loss-precent Simulate packet loss
 
 The urls are fetched in random order.
 
 I have verified the following:
 
 #1 Connectionless GET
 ./fakewap -g 10.32.35.61 -D 1 -M 0 http://10.48.1.231/sqa/file_1k.txt
 2013-03-20 18:24:49 [11290] [0] ERROR: Error while gw_gethostbyname occurs.
 2013-03-20 18:24:49 [11290] [0] ERROR: System error 2: No such file or 
 directory
 2013-03-20 18:24:49 [11290] [0] ERROR: Can't find out official hostname for 
 this host, using `contentsim11-UE' instead.
 2013-03-20 18:24:49 [11290] [0] INFO: fakewap: starting
 2013-03-20 18:24:49 [11290] [0] DEBUG: Sent WSP_GET packet
 2013-03-20 18:24:50 [11290] [0] INFO: fakewap: Received WSP Reply with 
 status code 200OK
 2013-03-20 18:24:50 [11290] [0] INFO: fakewap: finished session # 1
 2013-03-20 18:24:50 [11290] [0] INFO: fakewap: complete.
 2013-03-20 18:24:50 [11290] [0] INFO: fakewap: 1 client threads made total 1 
 transactions.
 2013-03-20 18:24:50 [11290] [0] INFO: fakewap: total running time 1.0 seconds
 2013-03-20 18:24:50 [11290] [0] INFO: fakewap: 1.0 messages/seconds on 
 average
 2013-03-20 18:24:50 [11290] [0] INFO: fakewap: time of best, worst and 
 average transaction: 0.6 s, 0.6 s, 0.6 s
 [root@contentsim11-UE kannel]#
 
 #2 Connection-oriented GET
 [root@contentsim11-UE kannel]# ./fakewap -g 10.32.35.61 -D 1 -M 1 
 http://10.48.1.231/sqa/file_2k.txt
 2013-03-20 18:28:20 [11293] [0] ERROR: Error while gw_gethostbyname occurs.
 2013-03-20 18:28:20 [11293] [0] ERROR: System error 2: No such file or 
 directory
 2013-03-20 18:28:20 [11293] [0] ERROR: Can't find out official hostname for 
 this host, using `contentsim11-UE' instead.
 2013-03-20 18:28:20 [11293] [0] INFO: fakewap: starting
 2013-03-20 18:28:20 [11293] [0] DEBUG: Sent WSP_CONNECT packet
 2013-03-20 18:28:21 [11293] [0] DEBUG: Received WSP_ConnectReply, SessID 14
 2013-03-20 18:28:21 [11293] [0] DEBUG: Sent WTP_ACK packet
 2013-03-20 18:28:21 [11293] [0] DEBUG: Sent WSP_GET packet
 2013-03-20 18:28:21 [11293] [0] DEBUG: Received WTP_RESULT pdu, gtr 0, ttr 
 0, payload len 1380
 2013-03-20 18:28:21 [11293] [0] DEBUG: Received WTP_SEGM_RESULT pdu, psn 1, 
 gtr 0, ttr 1, payload len 703
 2013-03-20 18:28:21 [11293] [0] DEBUG: Sending WTP_ACK pdu, gtr_psn 1
 2013-03-20 18:28:21 [11293] [0] DEBUG: Sent WTP_ACK packet
 2013-03-20 18:28:21 [11293] [0] INFO: fakewap: Received WSP Reply with 
 status code 200OK
 2013-03-20 18:28:21 [11293] [0] DEBUG: Sent WSP_DISCONNECT packet
 2013-03-20 18:28:21 [11293] [0] INFO: fakewap: finished session # 1
 2013-03-20 18:28:21 [11293] [0] INFO: fakewap: complete.
 2013-03-20 18:28:21 [11293] [0] INFO: fakewap: 1 client threads made total 1 
 transactions.
 2013-03-20 18:28:21 [11293] [0] INFO: fakewap: total running time 1.0 seconds
 2013-03-20 18:28:21 [11293] [0] INFO: fakewap: 1.0 messages/seconds on 
 average
 2013-03-20 18:28:21 [11293] [0] INFO: fakewap: time of best, worst and 
 average transaction: 0.2 s, 0.2 s, 0.2 s
 [root@contentsim11-UE kannel]#
 
 #3 Connection-oriented POST of MMS message via WAPGW to MMSC
 
 [root

Re: Status page not responding, among other things.

[Alexander Malysh]

Hi,

I would suggest to use SVN version because there were made some fixes in this 
area.

Alex

Am 21.03.2013 um 08:14 schrieb Brenton Murray brenton.mur...@gmail.com:

 Hi all,
 
 I've been playing with kannel for the last couple of weeks and i'm having a 
 really hard time to get it to stay fully functional and running. Using Kannel 
 1.5 snapshot.
 
 My main problem is that after some time (4days to 20minutes) the status page 
 becomes unresponsive. When this occurs i can still send SMSs to the 
 smsbox-bearerbox-SMSC, but the DLRs no longer are returned. (There have 
 been a few occasions when everything stops)
 
 I detected the problem because DLRs weren't being sent to our webserver. At 
 this time the status was unavailable. After setting up some server monitors i 
 have seen it go:
 
 5:19am Monitor is down
 7:15am Monitor is up
 7:40am monitor is down
 9:08am monitor is up
 
 There were times when the system was not being used to send but was just 
 running.
 
 After having it run on my server with other daemons i've now put it on it's 
 own instance (Using AWS) and still getting the same problem.
 
 2013-03-21 05:43:01 [17504] [2] DEBUG: HTTP: Creating HTTPClient for 
 `46.165.195.139'.
 2013-03-21 05:43:01 [17504] [2] DEBUG: HTTP: Created HTTPClient area 
 0x7fbbd8000a60.
 2013-03-21 05:43:01 [17504] [2] DEBUG: HTTP: Creating HTTPClient for 
 `174.34.224.167'.
 2013-03-21 05:43:01 [17504] [2] DEBUG: HTTP: Created HTTPClient area 
 0x7fbbd8001520.
 2013-03-21 05:43:06 [17504] [6] DEBUG: SMPP[clx_1]: Sending enquire link:
 2013-03-21 05:43:06 [17504] [6] DEBUG: SMPP PDU 0x7fbbe00058f0 dump:
 
 The above is what is happening, clients get created but no data is sent.
 
 Even when attempting to view the status from localhost/127.0.0.1, it still 
 idles and receives no data.
 
 2013-03-21 05:59:58 [17504] [2] DEBUG: HTTP: Creating HTTPClient for 
 `127.0.0.1'.
 2013-03-21 05:59:58 [17504] [2] DEBUG: HTTP: Created HTTPClient area 
 0x7fbbd8002fd0.
 2013-03-21 06:00:21 [17504] [2] DEBUG: HTTP: Creating HTTPClient for 
 `127.0.0.1'.
 2013-03-21 06:00:21 [17504] [2] DEBUG: HTTP: Created HTTPClient area 
 0x7fbbd8002e10.
 2013-03-21 06:01:50 [17504] [2] DEBUG: HTTP: Creating HTTPClient for 
 `174.34.224.167'.
 2013-03-21 06:01:50 [17504] [2] DEBUG: HTTP: Created HTTPClient area 
 0x7fbbd8004210.
 
 I'm hoping someone else may have experienced something similar and could 
 point me in the right direction to debug it?
 
 Another thing I've noticed is that during these times the mySQL connections 
 start to slowly disconnect and do not attempt to reconnect. I have upped the 
 mySQL wait timeout to 48hrs. Should I have try lowering instead to force 
 reconnections earlier?
 
 I can supply more logs and configs etc if you need more info, I'm hoping 
 someone out there may have some ideas as i'm not finding any existing issues 
 being discussed similar to this.
 
 Best Regards,
Brenton
 

Re: [PATCH] Add start- stop- box/smsc, store-status functionality to debian init script

[Alexander Malysh]

Hi,

patch not tested but the idea is good and I'm +1 to commit it.

Any objections?

Alex

Am 12.03.2013 um 00:09 schrieb Konstantin Vayner pon...@gmx.net:

 This adds some new features to debian init script:
 
 1. Allow start/stop separate boxes via /etc/init.d/kannel {start|stop}-box 
 boxname
 2. Allow start/stop smsc by /etc/init.d/kannel {start|stop}-smsc smsc-id
 3. Allow querying store status via /etc/init.d/kannel store-status
 4. Actually, it also allows arbitrary http admin commands via 
 /etc/init.d/kannel http-admin command params , where params should be a 
 single-argument string, prepared to be passed via url (in form 
 param1=valueparam2=value)
 
 NB: startup/shutdown output format changed to multiple lines of output here 
 (because it uses start-box / stop-box internally, and each call like that 
 outputs a line)
 
 Attached.
 
 Regards,
Konstantin
 debian_kannel_init.patch

Re: [PATCH] Add start- stop- box/smsc, store-status functionality to debian init script

[Alexander Malysh]

I would suggest to wait for 2 minutes, because I saw some buggy SMSCs that 
didn't accept unbind pdu.

If then bearerbox still running you can send SIGABRT to the process, this 
ensure that Kannel cleanups pid files.

Alex

Am 12.03.2013 um 10:33 schrieb Konstantin Vayner pon...@gmx.net:

 Looking at your init script;
 I can merge these together
 
 Question is - what if bearerbox is stuck and does not shut down?
 I've ran across this before with ucp smscs that were not letting go ;)
 
 Regards,
Konstantin
 
 
 On Tue, Mar 12, 2013 at 11:25 AM, spameden spame...@gmail.com wrote:
 2013/3/12 Alexander Malysh amal...@kannel.org:
  Hi,
 
  patch not tested but the idea is good and I'm +1 to commit it.
 
  Any objections?
 
  Alex
 
  Am 12.03.2013 um 00:09 schrieb Konstantin Vayner pon...@gmx.net:
 
  This adds some new features to debian init script:
 
  1. Allow start/stop separate boxes via /etc/init.d/kannel {start|stop}-box 
  boxname
 
 Nice idea, but needs better handling, I've looked into the patch it
 seems does not support multiple configuration files (for example for
 starting multiple smsbox'es or sqlbox'es, e.g.
 /etc/kannel/sqlbox1.conf /etc/kannel/sqlbox2.conf, etc)
 
  2. Allow start/stop smsc by /etc/init.d/kannel {start|stop}-smsc smsc-id
  3. Allow querying store status via /etc/init.d/kannel store-status
  4. Actually, it also allows arbitrary http admin commands via 
  /etc/init.d/kannel http-admin command params , where params should be a 
  single-argument string, prepared to be passed via url (in form 
  param1=valueparam2=value)
 
 Would be nice to require/chacking of lynx installation before giving
 any of the opportunity to execute those commands.
 
 
  NB: startup/shutdown output format changed to multiple lines of output 
  here (because it uses start-box / stop-box internally, and each call like 
  that outputs a line)
 
 The main problem with current init.d script it's not always working.
 
 If there was a big queue on the restart bearerbox takes some time to
 populate the memory with it, thus
 
 sleep 1 is not enough anymore.
 
 I'm using this solution on the start:
 
 PORTCONF=$(grep '^smsbox-port' ${CONF}|awk {'print $3'})
 while [ -z $(netstat -nl|grep :${PORTCONF}.*LISTEN) ]; do sleep 1; done
 
 and on stop:
 
 while [ ! -z $(netstat -nl|grep :${PORTCONF}.*LISTEN) ]; do sleep 1; done
 
 
 My version also handles multiple sqlbox.conf files depending on the
 values in the /etc/default/kannel file for debian.
 
 So if you don't want to start specific service (e.g. OpenSMPPBox, you
 just change value from 1 to 0 for START_SMPPBOX in the
 /etc/default/kannel).
 
 I've attached my init.d script and default file for understanding.
 
  Attached.
 
  Regards,
 Konstantin
  debian_kannel_init.patch
 
 
 

Re: Validity patch

[Alexander Malysh]

Hi Rene,

issue fixed in SVN.

Alex

Am 05.03.2013 um 10:16 schrieb Alexander Malysh amal...@kannel.org:

 Hi Rene,
 
 do you have any update regarding this bug? Can I somehow help you to 
 reproduce/fix it?
 
 Alex
 
 Am 01.03.2013 um 13:03 schrieb Alexander Malysh amal...@kannel.org:
 
 Hi Rene,
 
 I don't think that should be the issue because message fields are not int 
 they are long.
 
 Does anybody has the same issue with the latest SVN version?
 
 Alex
 
 Am 28.02.2013 um 14:15 schrieb Rene Kluwen rene.klu...@chimit.nl:
 
 Could the difference between your situation where it works and (for 
 example) my situation be the following:
  
 I am using a 32 bits processor. If you are using a 64 bits processor maybe 
 the int size is different?
  
 Just a wild guess. Trying to solve this problem.
  
 == Rene
 
 

Re: Validity patch

[Alexander Malysh]

Hi Rene,

do you have any update regarding this bug? Can I somehow help you to 
reproduce/fix it?

Alex

Am 01.03.2013 um 13:03 schrieb Alexander Malysh amal...@kannel.org:

 Hi Rene,
 
 I don't think that should be the issue because message fields are not int 
 they are long.
 
 Does anybody has the same issue with the latest SVN version?
 
 Alex
 
 Am 28.02.2013 um 14:15 schrieb Rene Kluwen rene.klu...@chimit.nl:
 
 Could the difference between your situation where it works and (for example) 
 my situation be the following:
  
 I am using a 32 bits processor. If you are using a 64 bits processor maybe 
 the int size is different?
  
 Just a wild guess. Trying to solve this problem.
  
 == Rene
 

Re: Validity patch

[Alexander Malysh]

Hi Rene,

I don't think that should be the issue because message fields are not int they 
are long.

Does anybody has the same issue with the latest SVN version?

Alex

Am 28.02.2013 um 14:15 schrieb Rene Kluwen rene.klu...@chimit.nl:

 Could the difference between your situation where it works and (for example) 
 my situation be the following:
  
 I am using a 32 bits processor. If you are using a 64 bits processor maybe 
 the int size is different?
  
 Just a wild guess. Trying to solve this problem.
  
 == Rene

Re: Send non-GSM alphabet chars

[Alexander Malysh]

Hi,

could you please start with a description of your issue? Kannel supports and 
use GSM7Bit as default.
Just call smsbox HTTP interface with UTF-8 coded message and Kannel will do the 
whole magic for you.

If you would like to send non GSM chars then you have to know which charset you 
need and configure it
in SMSC group, look at alt-charset in the manual.

Alex

Am 28.02.2013 um 12:27 schrieb Александр Николаев na...@mail.ru:

 Hello! 
 
 Kannel 1.5.0 
 SMPP 
   
 I need to send and receive binary chars (0x00..0x7F) using 7-bit (coding=0) 
 I have patched source code in places: 
 
 gwlib/charset.h
 
 void charset_gsm_to_utf8(Octstr *ostr) 
 { /*empty body */ 
 } 
 void charset_utf8_to_gsm(Octstr *ostr) 
 {/*empty body */ 
 } 
 void charset_gsm_to_latin1(Octstr *ostr) 
 {/*empty body */ 
 } 
 void charset_latin1_to_gsm(Octstr *ostr) 
 {/*empty body */ 
 } 
 int charset_gsm_truncate(Octstr *gsm, long max) 
 { 
 if (octstr_len(gsm)  max) { 
 /* If the last GSM character was an escaped character, 
  * then chop off the escape as well as the character. */ 
 octstr_truncate(gsm, max); 
 return 1; 
 } 
 return 0; 
 } 
   
 My purpose is exclude mapping chars to GSM-alphabet and vice versa. 
 
 It workes, but 3 chars mapped as before: 
 0x40 as 0x00 ('@') 
 0x24 as 0x02 ('$') 
 0x5f as 0x11 ('_') 
 
 Please help me. 
 Where I have to patch else? 
 
 
 

Re: Send non-GSM alphabet chars

[Alexander Malysh]

Hi,

just tested and it works as expected:

2013-03-01 14:28:14 [39437] [8] DEBUG: SMPP PDU 0x7fc811e03a10 dump:
2013-03-01 14:28:14 [39437] [8] DEBUG:   type_name: submit_sm
2013-03-01 14:28:14 [39437] [8] DEBUG:   command_id: 4 = 0x0004
2013-03-01 14:28:14 [39437] [8] DEBUG:   command_status: 0 = 0x
2013-03-01 14:28:14 [39437] [8] DEBUG:   sequence_number: 4 = 0x0004
2013-03-01 14:28:14 [39437] [8] DEBUG:   service_type: NULL
2013-03-01 14:28:14 [39437] [8] DEBUG:   source_addr_ton: 2 = 0x0002
2013-03-01 14:28:14 [39437] [8] DEBUG:   source_addr_npi: 1 = 0x0001
2013-03-01 14:28:14 [39437] [8] DEBUG:   source_addr: 123
2013-03-01 14:28:14 [39437] [8] DEBUG:   dest_addr_ton: 2 = 0x0002
2013-03-01 14:28:14 [39437] [8] DEBUG:   dest_addr_npi: 1 = 0x0001
2013-03-01 14:28:14 [39437] [8] DEBUG:   destination_addr: 456
2013-03-01 14:28:14 [39437] [8] DEBUG:   esm_class: 3 = 0x0003
2013-03-01 14:28:14 [39437] [8] DEBUG:   protocol_id: 0 = 0x
2013-03-01 14:28:14 [39437] [8] DEBUG:   priority_flag: 0 = 0x
2013-03-01 14:28:14 [39437] [8] DEBUG:   schedule_delivery_time: NULL
2013-03-01 14:28:14 [39437] [8] DEBUG:   validity_period: NULL
2013-03-01 14:28:14 [39437] [8] DEBUG:   registered_delivery: 0 = 0x
2013-03-01 14:28:14 [39437] [8] DEBUG:   replace_if_present_flag: 0 = 0x
2013-03-01 14:28:14 [39437] [8] DEBUG:   data_coding: 0 = 0x
2013-03-01 14:28:14 [39437] [8] DEBUG:   sm_default_msg_id: 0 = 0x
2013-03-01 14:28:14 [39437] [8] DEBUG:   sm_length: 3 = 0x0003
2013-03-01 14:28:14 [39437] [8] DEBUG:   short_message: @$_
2013-03-01 14:28:14 [39437] [8] DEBUG: SMPP PDU dump ends.

http://localhost:13003/cgi-bin/sendsms?username=testerpassword=foobarfrom=123to=456text=%40%24_

And the config:

group = smsc
smsc = smpp
smsc-id = XXX
allowed-smsc-id = XXX
host = XXX
port = 13345
smsc-username = bla
smsc-password = blu
system-type = WMA
transceiver-mode = true
alt-charset = ASCII


Alex

Am 01.03.2013 um 14:18 schrieb Alexander Nikolaev na...@mail.ru:

 Alexander, thank you for reply.
 
 I do:
 
 group = smsc
 smsc = smpp
 smsc-id = Glosav-SPB
 host = 193.201.231.44
 port = 2775
 smsc-username = xxx
 smsc-password = xxx
 source-addr-ton = 1
 source-addr-npi = 1
 dest-addr-ton = 1
 dest-addr-npi = 1
 system-type = 
 throughput = 1000
 reconnect-delay = 5
 connection-timeout = 120
 transceiver-mode = true
 connect-allow-ip = *
 allowed-smsc-id = Glosav-SPB
 preferred-smsc-id = Glosav-SPB
 *alt-charset = ASCII*
 alt-addr-charset = GSM
 interface-version = 34
 #alt-dcs = true
 
 My send URL is
 http://10.0.5.37:13003/cgi-bin/sendsms?text=%40%24%5Fusername=xxxpassword=xxxcoding=0to=79254247283charset=ASCII
 
 Unfortunately, it doesn't  take expected result.
 I still got %00%02%11
 
 
 
 
 --
 View this message in context: 
 http://kannel.6189.n7.nabble.com/Send-non-GSM-alphabet-chars-tp28057p28062.html
 Sent from the Kannel - Dev mailing list archive at Nabble.com.
 

Re: 159 chars with symbols results in a msg:41:NACK/0x00000001/Message Length is invalid

[Alexander Malysh]

Hi,

I'm unable to reproduce it with the latest SVN version.

In your SMPP dump, it seems Kannel sends in UTF-8 without any converting. 
Please check your
SMPP config whether you have alt-charset set to utf-8?

smsbox URL called:
http://localhost:13003/cgi-bin/sendsms?username=testerpassword=foobarfrom=123to=456text=aaa%C2%A35.00%2F%C2%A34.00acharset=utf8

SMPP PDU:

2013-02-25 23:07:37 [21166] [8] DEBUG: SMPP PDU 0x7ff560d0c8c0 dump:
2013-02-25 23:07:37 [21166] [8] DEBUG:   type_name: submit_sm
2013-02-25 23:07:37 [21166] [8] DEBUG:   command_id: 4 = 0x0004
2013-02-25 23:07:37 [21166] [8] DEBUG:   command_status: 0 = 0x
2013-02-25 23:07:37 [21166] [8] DEBUG:   sequence_number: 2 = 0x0002
2013-02-25 23:07:37 [21166] [8] DEBUG:   service_type: NULL
2013-02-25 23:07:37 [21166] [8] DEBUG:   source_addr_ton: 2 = 0x0002
2013-02-25 23:07:37 [21166] [8] DEBUG:   source_addr_npi: 1 = 0x0001
2013-02-25 23:07:37 [21166] [8] DEBUG:   source_addr: 123
2013-02-25 23:07:37 [21166] [8] DEBUG:   dest_addr_ton: 2 = 0x0002
2013-02-25 23:07:37 [21166] [8] DEBUG:   dest_addr_npi: 1 = 0x0001
2013-02-25 23:07:37 [21166] [8] DEBUG:   destination_addr: 456
2013-02-25 23:07:37 [21166] [8] DEBUG:   esm_class: 3 = 0x0003
2013-02-25 23:07:37 [21166] [8] DEBUG:   protocol_id: 0 = 0x
2013-02-25 23:07:37 [21166] [8] DEBUG:   priority_flag: 0 = 0x
2013-02-25 23:07:37 [21166] [8] DEBUG:   schedule_delivery_time: NULL
2013-02-25 23:07:37 [21166] [8] DEBUG:   validity_period: NULL
2013-02-25 23:07:37 [21166] [8] DEBUG:   registered_delivery: 0 = 0x
2013-02-25 23:07:37 [21166] [8] DEBUG:   replace_if_present_flag: 0 = 0x
2013-02-25 23:07:37 [21166] [8] DEBUG:   data_coding: 0 = 0x
2013-02-25 23:07:37 [21166] [8] DEBUG:   sm_default_msg_id: 0 = 0x
2013-02-25 23:07:37 [21166] [8] DEBUG:   sm_length: 159 = 0x009f
2013-02-25 23:07:37 [21166] [8] DEBUG:   short_message:
2013-02-25 23:07:37 [21166] [8] DEBUG:Octet string at 0x7ff560d0cca0:
2013-02-25 23:07:37 [21166] [8] DEBUG:  len:  159
2013-02-25 23:07:37 [21166] [8] DEBUG:  size: 162
2013-02-25 23:07:37 [21166] [8] DEBUG:  immutable: 0
2013-02-25 23:07:37 [21166] [8] DEBUG:  data: 61 61 61 61 61 61 61 61 61 61 
61 61 61 61 61 61   
2013-02-25 23:07:37 [21166] [8] DEBUG:  data: 61 61 61 61 61 61 61 61 61 61 
61 61 61 61 61 61   
2013-02-25 23:07:37 [21166] [8] DEBUG:  data: 61 61 61 61 61 61 61 61 61 61 
61 61 61 61 61 61   
2013-02-25 23:07:37 [21166] [8] DEBUG:  data: 61 61 61 61 61 61 61 61 61 61 
61 61 61 61 61 61   
2013-02-25 23:07:37 [21166] [8] DEBUG:  data: 61 61 61 61 61 61 61 61 61 61 
61 01 35 2e 30 30   aaa.5.00
2013-02-25 23:07:37 [21166] [8] DEBUG:  data: 2f 01 34 2e 30 30 61 61 61 61 
61 61 61 61 61 61   /.4.00aa
2013-02-25 23:07:37 [21166] [8] DEBUG:  data: 61 61 61 61 61 61 61 61 61 61 
61 61 61 61 61 61   
2013-02-25 23:07:37 [21166] [8] DEBUG:  data: 61 61 61 61 61 61 61 61 61 61 
61 61 61 61 61 61   
2013-02-25 23:07:37 [21166] [8] DEBUG:  data: 61 61 61 61 61 61 61 61 61 61 
61 61 61 61 61 61   
2013-02-25 23:07:37 [21166] [8] DEBUG:  data: 61 61 61 61 61 61 61 61 61 61 
61 61 61 61 61  aaa
2013-02-25 23:07:37 [21166] [8] DEBUG:Octet string dump ends.
2013-02-25 23:07:37 [21166] [8] DEBUG: SMPP PDU dump ends.


Am 25.02.2013 um 21:24 schrieb Nathan Kelly nat...@callparents.com:

 PDU dump:
  
 2013-02-25 20:13:02 [32385] [37] DEBUG: SMPP[default]: Sending PDU:
 2013-02-25 20:13:02 [32385] [37] DEBUG: SMPP PDU 0xb44b9c50 dump:
 2013-02-25 20:13:02 [32385] [37] DEBUG:   type_name: submit_sm
 2013-02-25 20:13:02 [32385] [37] DEBUG:   command_id: 4 = 0x0004
 2013-02-25 20:13:02 [32385] [37] DEBUG:   command_status: 0 = 0x
 2013-02-25 20:13:02 [32385] [37] DEBUG:   sequence_number: 1230 = 0x04ce
 2013-02-25 20:13:02 [32385] [37] DEBUG:   service_type: NULL
 2013-02-25 20:13:02 [32385] [37] DEBUG:   source_addr_ton: 5 = 0x0005
 2013-02-25 20:13:02 [32385] [37] DEBUG:   source_addr_npi: 0 = 0x
 2013-02-25 20:13:02 [32385] [37] DEBUG:   source_addr:  default 
 2013-02-25 20:13:02 [32385] [37] DEBUG:   dest_addr_ton: 1 = 0x0001
 2013-02-25 20:13:02 [32385] [37] DEBUG:   dest_addr_npi: 1 = 0x0001
 2013-02-25 20:13:02 [32385] [37] DEBUG:   destination_addr: 447123456789
 2013-02-25 20:13:02 [32385] [37] DEBUG:   esm_class: 0 = 0x
 2013-02-25 20:13:02 [32385] [37] DEBUG:   protocol_id: 0 = 0x
 2013-02-25 20:13:02 [32385] [37] DEBUG:   priority_flag: 0 = 0x
 2013-02-25 20:13:02 [32385] [37] DEBUG:   schedule_delivery_time: NULL
 2013-02-25 20:13:02 [32385] [37] DEBUG:   validity_period: 

Re: Validity perdiod

[Alexander Malysh]

Hi Rene,

I converted validity  deferred to be unix timestamp internally, they were in 
minutes before.
Due to the fact that I didn't know how sqlbox works, I assumed that validity  
deferred in the
sqlbox tables also stored in minutes therefore this conversion:
if validity set then (now - unix timestamp) / 60 - minutes

the counter part is when selecting values from DB and sending to bearerbox:

/* convert validity and deferred to unix timestamp */
if (msg-sms.validity != SMS_PARAM_UNDEFINED)
msg-sms.validity = time(NULL) + msg-sms.validity * 60;
if (msg-sms.deferred != SMS_PARAM_UNDEFINED)
msg-sms.deferred = time(NULL) + msg-sms.deferred * 60;

Alex

Am 16.02.2013 um 15:36 schrieb Rene Kluwen rene.klu...@chimit.nl:

 Also: in sqlbox.c (function smsbox_to_bearerbox()):
  
/* convert validity  deferred to minutes */
 if (msg-sms.validity != SMS_PARAM_UNDEFINED)
 msg-sms.validity = (msg-sms.validity - time(NULL))/60;
 if (msg-sms.deferred != SMS_PARAM_UNDEFINED)
 msg-sms.deferred = (msg-sms.deferred - time(NULL))/60;
  
 Isn’t this field encoded twice now? Once in smsbox and another time in sqlbox?
  
 Alexander, you made this change. Please shed some light.
  
 From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of 
 Rene Kluwen
 Sent: vrijdag 15 februari 2013 15:16
 To: devel@kannel.org
 Subject: Validity perdiod
  
 I came across an issue since svn version 4956 of smsbox.c, using smpp.
  
 The logs show the following:
  
 2013-02-15 14:52:45 [3144] [7] DEBUG:   validity_period: 70215159000+
  
 This was this afternoon at 14:52. The validity field of the sendsms interface 
 was not set.
  
 How do I interpret this as “YYMMDDhhmmsstnnp”?
  
 One of my clients needed to downgrade because of this issue.
  
 == Rene

Re: Validity perdiod

[Alexander Malysh]

Hi,

just found a typo in my patch and changed it to:

msg_escaped = msg_duplicate(msg);
/* convert validity  deferred to minutes */
if (msg_escaped-sms.validity != SMS_PARAM_UNDEFINED)
msg_escaped-sms.validity = (msg_escaped-sms.validity - 
time(NULL))/60;
if (msg_escaped-sms.deferred != SMS_PARAM_UNDEFINED)
msg_escaped-sms.deferred = (msg_escaped-sms.deferred - 
time(NULL))/60;
gw_sql_save_msg(msg_escaped, octstr_imm(MT));

This should fix this issue.

Alex

Am 18.02.2013 um 09:57 schrieb Rene Kluwen rene.klu...@chimit.nl:

 In sqlbox, two different things happen.
  
 1.   Select rows from send_sms and send them to bearerbox (with validity 
 in minutes)
 2.   Relay rows from smsbox to bearerbox and store them in sent_sms on 
 the fly. These messages have been processed by smsbox already and should not 
 be reprocessed.
  
 I am not sure what exactly you did because I don’t have time to look at the 
 code now. But something is going very wrong here. Even without using sqlbox 
 we are getting invalid validity_period fields in smsc_smpp.
  
 On a side note, I see now that opensmppbox never sends a validity field to 
 its connected entity, now I look at it. But that’s a different story.
  
 == Rene
  
 From: Alexander Malysh [mailto:malys...@gmail.com] On Behalf Of Alexander 
 Malysh
 Sent: maandag 18 februari 2013 9:29
 To: Rene Kluwen
 Cc: devel@kannel.org
 Subject: Re: Validity perdiod
  
 Hi Rene,
  
 I converted validity  deferred to be unix timestamp internally, they were in 
 minutes before.
 Due to the fact that I didn't know how sqlbox works, I assumed that validity 
  deferred in the
 sqlbox tables also stored in minutes therefore this conversion:
 if validity set then (now - unix timestamp) / 60 - minutes
  
 the counter part is when selecting values from DB and sending to bearerbox:
  
 /* convert validity and deferred to unix timestamp */
 if (msg-sms.validity != SMS_PARAM_UNDEFINED)
 msg-sms.validity = time(NULL) + msg-sms.validity * 60;
 if (msg-sms.deferred != SMS_PARAM_UNDEFINED)
 msg-sms.deferred = time(NULL) + msg-sms.deferred * 60;
  
 Alex
  
 Am 16.02.2013 um 15:36 schrieb Rene Kluwen rene.klu...@chimit.nl:
 
 
 Also: in sqlbox.c (function smsbox_to_bearerbox()):
  
/* convert validity  deferred to minutes */
 if (msg-sms.validity != SMS_PARAM_UNDEFINED)
 msg-sms.validity = (msg-sms.validity - time(NULL))/60;
 if (msg-sms.deferred != SMS_PARAM_UNDEFINED)
 msg-sms.deferred = (msg-sms.deferred - time(NULL))/60;
  
 Isn’t this field encoded twice now? Once in smsbox and another time in sqlbox?
  
 Alexander, you made this change. Please shed some light.
  
 From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of 
 Rene Kluwen
 Sent: vrijdag 15 februari 2013 15:16
 To: devel@kannel.org
 Subject: Validity perdiod
  
 I came across an issue since svn version 4956 of smsbox.c, using smpp.
  
 The logs show the following:
  
 2013-02-15 14:52:45 [3144] [7] DEBUG:   validity_period: 70215159000+
  
 This was this afternoon at 14:52. The validity field of the sendsms interface 
 was not set.
  
 How do I interpret this as “YYMMDDhhmmsstnnp”?
  
 One of my clients needed to downgrade because of this issue.
  
 == Rene

Re: Validity perdiod

[Alexander Malysh]

I just want that validity  deferred is the absolute timestamp and not 
dependent from
any message value.

As to the mentioned code. I just don't understand why sqlbox first fetch 
message from db, sends it
ro bearerbox and then insert it back to DB??

while (sqlbox_status == SQL_RUNNING  boxc-alive) {
if ((msg = gw_sql_fetch_msg()) != NULL) {
if (charset_processing(msg) == -1) {
error(0, Could not charset process message, dropping it!);
msg_destroy(msg);
continue;
}
if (global_sender != NULL  (msg-sms.sender == NULL || 
octstr_len(msg-sms.sender) == 0)) {
msg-sms.sender = octstr_duplicate(global_sender);
}
/* convert validity and deferred to unix timestamp */
if (msg-sms.validity != SMS_PARAM_UNDEFINED)
msg-sms.validity = time(NULL) + msg-sms.validity * 60;
if (msg-sms.deferred != SMS_PARAM_UNDEFINED)
msg-sms.deferred = time(NULL) + msg-sms.deferred * 60;
send_msg(boxc-bearerbox_connection, boxc, msg);

^ here is correct that we send unix timestamp to bearerbox, because 
bearerbox expects seconds now

gw_sql_save_msg(msg, octstr_imm(MT));

^ why do we save message again, that we just fetched from DB?

}
else {
gwthread_sleep(SLEEP_BETWEEN_SELECTS);
}


Alex

Am 18.02.2013 um 10:54 schrieb Rene Kluwen rene.klu...@chimit.nl:

 Not sure why you want to go through all this trouble.
 But the function sql_to_bearerbox does not do still what you want.
  
 Here goes:
  
 /* convert validity and deferred to unix timestamp */
 if (msg-sms.validity != SMS_PARAM_UNDEFINED)
 msg-sms.validity = time(NULL) + msg-sms.validity * 60;
 if (msg-sms.deferred != SMS_PARAM_UNDEFINED)
 msg-sms.deferred = time(NULL) + msg-sms.deferred * 60;
 send_msg(boxc-bearerbox_connection, boxc, msg);  
  /* message is sent with validity in absolute seconds */
 gw_sql_save_msg(msg, octstr_imm(MT));   
/* message is saved in sent_sms in absolute seconds */
  
 From: Alexander Malysh [mailto:malys...@gmail.com] On Behalf Of Alexander 
 Malysh
 Sent: maandag 18 februari 2013 10:02
 To: Rene Kluwen
 Cc: devel@kannel.org
 Subject: Re: Validity perdiod
  
 Hi,
  
 just found a typo in my patch and changed it to:
  
 msg_escaped = msg_duplicate(msg);
 /* convert validity  deferred to minutes */
 if (msg_escaped-sms.validity != SMS_PARAM_UNDEFINED)
 msg_escaped-sms.validity = (msg_escaped-sms.validity - 
 time(NULL))/60;
 if (msg_escaped-sms.deferred != SMS_PARAM_UNDEFINED)
 msg_escaped-sms.deferred = (msg_escaped-sms.deferred - 
 time(NULL))/60;
 gw_sql_save_msg(msg_escaped, octstr_imm(MT));
  
 This should fix this issue.
  
 Alex
  
 Am 18.02.2013 um 09:57 schrieb Rene Kluwen rene.klu...@chimit.nl:
 
 
 In sqlbox, two different things happen.
  
 1.   Select rows from send_sms and send them to bearerbox (with validity 
 in minutes)
 2.   Relay rows from smsbox to bearerbox and store them in sent_sms on 
 the fly. These messages have been processed by smsbox already and should not 
 be reprocessed.
  
 I am not sure what exactly you did because I don’t have time to look at the 
 code now. But something is going very wrong here. Even without using sqlbox 
 we are getting invalid validity_period fields in smsc_smpp.
  
 On a side note, I see now that opensmppbox never sends a validity field to 
 its connected entity, now I look at it. But that’s a different story.
  
 == Rene
  
 From: Alexander Malysh [mailto:malys...@gmail.com] On Behalf Of Alexander 
 Malysh
 Sent: maandag 18 februari 2013 9:29
 To: Rene Kluwen
 Cc: devel@kannel.org
 Subject: Re: Validity perdiod
  
 Hi Rene,
  
 I converted validity  deferred to be unix timestamp internally, they were in 
 minutes before.
 Due to the fact that I didn't know how sqlbox works, I assumed that validity 
  deferred in the
 sqlbox tables also stored in minutes therefore this conversion:
 if validity set then (now - unix timestamp) / 60 - minutes
  
 the counter part is when selecting values from DB and sending to bearerbox:
  
 /* convert validity and deferred to unix timestamp */
 if (msg-sms.validity != SMS_PARAM_UNDEFINED)
 msg-sms.validity = time(NULL) + msg-sms.validity * 60;
 if (msg-sms.deferred != SMS_PARAM_UNDEFINED)
 msg-sms.deferred = time(NULL) + msg-sms.deferred * 60;
  
 Alex
  
 Am 16.02.2013 um 15:36 schrieb Rene Kluwen rene.klu...@chimit.nl:
 
 
 
 Also: in sqlbox.c (function smsbox_to_bearerbox()):
  
/* convert validity  deferred to minutes

Re: Validity perdiod

[Alexander Malysh]

independent of question bellow, I fixed this in the SVN.

Alex

Am 18.02.2013 um 11:32 schrieb Alexander Malysh amal...@kannel.org:

 I just want that validity  deferred is the absolute timestamp and not 
 dependent from
 any message value.
 
 As to the mentioned code. I just don't understand why sqlbox first fetch 
 message from db, sends it
 ro bearerbox and then insert it back to DB??
 
 while (sqlbox_status == SQL_RUNNING  boxc-alive) {
 if ((msg = gw_sql_fetch_msg()) != NULL) {
 if (charset_processing(msg) == -1) {
 error(0, Could not charset process message, dropping it!);
 msg_destroy(msg);
 continue;
 }
 if (global_sender != NULL  (msg-sms.sender == NULL || 
 octstr_len(msg-sms.sender) == 0)) {
 msg-sms.sender = octstr_duplicate(global_sender);
 }
 /* convert validity and deferred to unix timestamp */
 if (msg-sms.validity != SMS_PARAM_UNDEFINED)
 msg-sms.validity = time(NULL) + msg-sms.validity * 60;
 if (msg-sms.deferred != SMS_PARAM_UNDEFINED)
 msg-sms.deferred = time(NULL) + msg-sms.deferred * 60;
 send_msg(boxc-bearerbox_connection, boxc, msg);
 
   ^ here is correct that we send unix timestamp to bearerbox, because 
 bearerbox expects seconds now
 
 gw_sql_save_msg(msg, octstr_imm(MT));
 
   ^ why do we save message again, that we just fetched from DB?
 
 }
 else {
 gwthread_sleep(SLEEP_BETWEEN_SELECTS);
 }
 
 
 Alex
 
 Am 18.02.2013 um 10:54 schrieb Rene Kluwen rene.klu...@chimit.nl:
 
 Not sure why you want to go through all this trouble.
 But the function sql_to_bearerbox does not do still what you want.
  
 Here goes:
  
 /* convert validity and deferred to unix timestamp */
 if (msg-sms.validity != SMS_PARAM_UNDEFINED)
 msg-sms.validity = time(NULL) + msg-sms.validity * 60;
 if (msg-sms.deferred != SMS_PARAM_UNDEFINED)
 msg-sms.deferred = time(NULL) + msg-sms.deferred * 60;
 send_msg(boxc-bearerbox_connection, boxc, msg); 
   /* message is sent with validity in absolute seconds */
 gw_sql_save_msg(msg, octstr_imm(MT));  
 /* message is saved in sent_sms in absolute seconds */
  
 From: Alexander Malysh [mailto:malys...@gmail.com] On Behalf Of Alexander 
 Malysh
 Sent: maandag 18 februari 2013 10:02
 To: Rene Kluwen
 Cc: devel@kannel.org
 Subject: Re: Validity perdiod
  
 Hi,
  
 just found a typo in my patch and changed it to:
  
 msg_escaped = msg_duplicate(msg);
 /* convert validity  deferred to minutes */
 if (msg_escaped-sms.validity != SMS_PARAM_UNDEFINED)
 msg_escaped-sms.validity = (msg_escaped-sms.validity - 
 time(NULL))/60;
 if (msg_escaped-sms.deferred != SMS_PARAM_UNDEFINED)
 msg_escaped-sms.deferred = (msg_escaped-sms.deferred - 
 time(NULL))/60;
 gw_sql_save_msg(msg_escaped, octstr_imm(MT));
  
 This should fix this issue.
  
 Alex
  
 Am 18.02.2013 um 09:57 schrieb Rene Kluwen rene.klu...@chimit.nl:
 
 
 In sqlbox, two different things happen.
  
 1.   Select rows from send_sms and send them to bearerbox (with validity 
 in minutes)
 2.   Relay rows from smsbox to bearerbox and store them in sent_sms on 
 the fly. These messages have been processed by smsbox already and should not 
 be reprocessed.
  
 I am not sure what exactly you did because I don’t have time to look at the 
 code now. But something is going very wrong here. Even without using sqlbox 
 we are getting invalid validity_period fields in smsc_smpp.
  
 On a side note, I see now that opensmppbox never sends a validity field to 
 its connected entity, now I look at it. But that’s a different story.
  
 == Rene
  
 From: Alexander Malysh [mailto:malys...@gmail.com] On Behalf Of Alexander 
 Malysh
 Sent: maandag 18 februari 2013 9:29
 To: Rene Kluwen
 Cc: devel@kannel.org
 Subject: Re: Validity perdiod
  
 Hi Rene,
  
 I converted validity  deferred to be unix timestamp internally, they were 
 in minutes before.
 Due to the fact that I didn't know how sqlbox works, I assumed that validity 
  deferred in the
 sqlbox tables also stored in minutes therefore this conversion:
 if validity set then (now - unix timestamp) / 60 - minutes
  
 the counter part is when selecting values from DB and sending to bearerbox:
  
 /* convert validity and deferred to unix timestamp */
 if (msg-sms.validity != SMS_PARAM_UNDEFINED)
 msg-sms.validity = time(NULL) + msg-sms.validity * 60;
 if (msg-sms.deferred != SMS_PARAM_UNDEFINED)
 msg-sms.deferred = time(NULL) + msg-sms.deferred * 60;
  
 Alex
  
 Am 16.02.2013 um 15:36 schrieb

Re: Validity perdiod

[Alexander Malysh]

ok, understand...

Can you confirm that the issue fixed now?

Alex

Am 18.02.2013 um 12:01 schrieb Rene Kluwen rene.klu...@chimit.nl:

 Because we save it into a different table we fetched it from.
  
 From: Alexander Malysh [mailto:malys...@gmail.com] On Behalf Of Alexander 
 Malysh
 Sent: maandag 18 februari 2013 11:32
 To: Rene Kluwen
 Cc: devel@kannel.org
 Subject: Re: Validity perdiod
  
 I just want that validity  deferred is the absolute timestamp and not 
 dependent from
 any message value.
  
 As to the mentioned code. I just don't understand why sqlbox first fetch 
 message from db, sends it
 ro bearerbox and then insert it back to DB??
  
 while (sqlbox_status == SQL_RUNNING  boxc-alive) {
 if ((msg = gw_sql_fetch_msg()) != NULL) {
 if (charset_processing(msg) == -1) {
 error(0, Could not charset process message, dropping it!);
 msg_destroy(msg);
 continue;
 }
 if (global_sender != NULL  (msg-sms.sender == NULL || 
 octstr_len(msg-sms.sender) == 0)) {
 msg-sms.sender = octstr_duplicate(global_sender);
 }
 /* convert validity and deferred to unix timestamp */
 if (msg-sms.validity != SMS_PARAM_UNDEFINED)
 msg-sms.validity = time(NULL) + msg-sms.validity * 60;
 if (msg-sms.deferred != SMS_PARAM_UNDEFINED)
 msg-sms.deferred = time(NULL) + msg-sms.deferred * 60;
 send_msg(boxc-bearerbox_connection, boxc, msg);
  
 ^ here is correct that we send unix timestamp to bearerbox, 
 because bearerbox expects seconds now
  
 gw_sql_save_msg(msg, octstr_imm(MT));
  
 ^ why do we save message again, that we just fetched from 
 DB?
  
 }
 else {
 gwthread_sleep(SLEEP_BETWEEN_SELECTS);
 }
  
  
 Alex
  
 Am 18.02.2013 um 10:54 schrieb Rene Kluwen rene.klu...@chimit.nl:
 
 
 Not sure why you want to go through all this trouble.
 But the function sql_to_bearerbox does not do still what you want.
  
 Here goes:
  
 /* convert validity and deferred to unix timestamp */
 if (msg-sms.validity != SMS_PARAM_UNDEFINED)
 msg-sms.validity = time(NULL) + msg-sms.validity * 60;
 if (msg-sms.deferred != SMS_PARAM_UNDEFINED)
 msg-sms.deferred = time(NULL) + msg-sms.deferred * 60;
 send_msg(boxc-bearerbox_connection, boxc, msg);  
  /* message is sent with validity in absolute seconds */
 gw_sql_save_msg(msg, octstr_imm(MT));   
/* message is saved in sent_sms in absolute seconds */
  
 From: Alexander Malysh [mailto:malys...@gmail.com] On Behalf Of Alexander 
 Malysh
 Sent: maandag 18 februari 2013 10:02
 To: Rene Kluwen
 Cc: devel@kannel.org
 Subject: Re: Validity perdiod
  
 Hi,
  
 just found a typo in my patch and changed it to:
  
 msg_escaped = msg_duplicate(msg);
 /* convert validity  deferred to minutes */
 if (msg_escaped-sms.validity != SMS_PARAM_UNDEFINED)
 msg_escaped-sms.validity = (msg_escaped-sms.validity - 
 time(NULL))/60;
 if (msg_escaped-sms.deferred != SMS_PARAM_UNDEFINED)
 msg_escaped-sms.deferred = (msg_escaped-sms.deferred - 
 time(NULL))/60;
 gw_sql_save_msg(msg_escaped, octstr_imm(MT));
  
 This should fix this issue.
  
 Alex
  
 Am 18.02.2013 um 09:57 schrieb Rene Kluwen rene.klu...@chimit.nl:
 
 
 
 In sqlbox, two different things happen.
  
 1.   Select rows from send_sms and send them to bearerbox (with validity 
 in minutes)
 2.   Relay rows from smsbox to bearerbox and store them in sent_sms on 
 the fly. These messages have been processed by smsbox already and should not 
 be reprocessed.
  
 I am not sure what exactly you did because I don’t have time to look at the 
 code now. But something is going very wrong here. Even without using sqlbox 
 we are getting invalid validity_period fields in smsc_smpp.
  
 On a side note, I see now that opensmppbox never sends a validity field to 
 its connected entity, now I look at it. But that’s a different story.
  
 == Rene
  
 From: Alexander Malysh [mailto:malys...@gmail.com] On Behalf Of Alexander 
 Malysh
 Sent: maandag 18 februari 2013 9:29
 To: Rene Kluwen
 Cc: devel@kannel.org
 Subject: Re: Validity perdiod
  
 Hi Rene,
  
 I converted validity  deferred to be unix timestamp internally, they were in 
 minutes before.
 Due to the fact that I didn't know how sqlbox works, I assumed that validity 
  deferred in the
 sqlbox tables also stored in minutes therefore this conversion:
 if validity set then (now - unix timestamp) / 60 - minutes
  
 the counter part is when selecting values from DB and sending to bearerbox:
  
 /* convert validity and deferred to unix timestamp

Re: USSD: Mallformed destination_addr `(null)', may not be empty. Discarding MO message

[Alexander Malysh]

Hi,

I think it will crash on other places because Kannel expects destination 
address to be set.

But try it, if you want...

Alex

Am 14.01.2013 um 13:16 schrieb Andreas Fink af...@list.fink.org:

 I'm sure this can be patched to make it work. but its not really intentional 
 to have a field destination address.
 the data is what the user types. As this is a session, this makes sense.
 
 
 You can temporary comment out this section in gw/smsc/smsc_smpp.c (line 
 442-464 ) to see if that works around the problem.
 
 
 /*
  * Follows SMPP spec. v3.4. issue 1.2
  * it's not allowed to have destination_addr NULL
  */
 if (pdu-u.deliver_sm.destination_addr == NULL) {
 error(0, SMPP[%s]: Malformed destination_addr `%s', may not be 
 empty. 
   Discarding MO message., octstr_get_cstr(smpp-conn-id),
   octstr_get_cstr(pdu-u.deliver_sm.destination_addr));
 *reason = SMPP_ESME_RINVDSTADR;
 goto error;
 }
 
 
 
 
 On 14.01.2013, at 13:04, kayode tobi kay4bl...@yahoo.co.uk wrote:
 
 Hi Andreas,
 
 I am so grateful for your response.
 
 However, I have been to this supplier with this question, but they claim 
 this is how they push requests to all connected clients via SMPP.
 
 Please look at this again:
 
 2012-11-27 11:38:35 [6369] [6] DEBUG: SMPP[USSD]: throughput (0.00,0.00)
 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter tag (0x001e)
 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter length read as 33
 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter tag (0x0202)
 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter length read as 15
 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter tag (0x0203)
 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter length read as 13
 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter tag (0x0501)
 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter length read as 1
 2012-11-27 11:38:35 [6369] [6] DEBUG: Found configured optional parameter 
 `mydata'
 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter tag (0x0424)
 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter length read as 5
 2012-11-27 11:38:35 [6369] [6] DEBUG: SMPP[USSD]: Got PDU:
 2012-11-27 11:38:35 [6369] [6] DEBUG: SMPP PDU 0x7ff7c8001550 dump:
 2012-11-27 11:38:35 [6369] [6] DEBUG:   type_name: data_sm
 2012-11-27 11:38:35 [6369] [6] DEBUG:   command_id: 259 = 0x0103
 2012-11-27 11:38:35 [6369] [6] DEBUG:   command_status: 0 = 0x
 2012-11-27 11:38:35 [6369] [6] DEBUG:   sequence_number: 1 = 0x0001
 2012-11-27 11:38:35 [6369] [6] DEBUG:   service_type: USSD
 2012-11-27 11:38:35 [6369] [6] DEBUG:   source_addr_ton: 1 = 0x0001
 2012-11-27 11:38:35 [6369] [6] DEBUG:   source_addr_npi: 1 = 0x0001
 2012-11-27 11:38:35 [6369] [6] DEBUG:   source_addr: 2347055932235
 2012-11-27 11:38:35 [6369] [6] DEBUG:   dest_addr_ton: 0 = 0x
 2012-11-27 11:38:35 [6369] [6] DEBUG:   dest_addr_npi: 0 = 0x
 2012-11-27 11:38:35 [6369] [6] DEBUG:   destination_addr: NULL
 2012-11-27 11:38:35 [6369] [6] DEBUG:   esm_class: 1 = 0x0001
 2012-11-27 11:38:35 [6369] [6] DEBUG:   registered_delivery: 0 = 0x
 2012-11-27 11:38:35 [6369] [6] DEBUG:   data_coding: 0 = 0x
 2012-11-27 11:38:35 [6369] [6] DEBUG:   message_payload:
 2012-11-27 11:38:35 [6369] [6] DEBUG:Octet string at 0x7ff7c80018c0:
 2012-11-27 11:38:35 [6369] [6] DEBUG:  len:  5
 2012-11-27 11:38:35 [6369] [6] DEBUG:  size: 6
 2012-11-27 11:38:35 [6369] [6] DEBUG:  immutable: 0
 2012-11-27 11:38:35 [6369] [6] DEBUG:  data: aa 19 0c 36 02  
   ...6.
 2012-11-27 11:38:35 [6369] [6] DEBUG:Octet string dump ends.
 2012-11-27 11:38:35 [6369] [6] DEBUG:   receipted_message_id:
  
  When the highlighted data: aa 19 0c 36 02 was decripted, it revealed the 
 code *300# which I presume should be the destination address.
 
 1. Kindly enlighten me what this should be, because they claim my app 
 (kannel) is what is not accepting the destination address.
 
 2. Do you think I am missing anything in the kannel config? If yes, can u 
 let me see a sample kannel USSD config?
 
 3. Can I set configure kannel to accept NULL destination address?
 
 Thank you so much for your time.
 
 
 Best Regards,
 Kayode
 
 
 
 
 
 
 
 
 
 From: Andreas Fink af...@list.fink.org
 To: kayode tobi kay4bl...@yahoo.co.uk 
 Cc: devel@kannel.org devel@kannel.org 
 Sent: Monday, 14 January 2013, 9:20
 Subject: Re: USSD: Mallformed destination_addr `(null)', may not be empty. 
 Discarding MO message
 
 there is your error in the log:
 
 2012-11-27 11:38:35 [6369] [6] DEBUG:   dest_addr_ton: 0 = 0x
 2012-11-27 11:38:35 [6369] [6] DEBUG:   dest_addr_npi: 0 = 0x
 2012-11-27 11:38:35 [6369] [6] DEBUG:   destination_addr: NULL
 2012-11-27 11:38:35 [6369] [6] ERROR: SMPP[USSD]: Mallformed 
 destination_addr `(null)', may not be empty. Discarding MO message.
 
 talk to 

Re: *** MERRY CHRISTMAS and a HAPPY NEW YEAR! *** from the Kannel Group!

[Alexander Malysh]

I would like to join the Stipe wishes!

Happy New Year to all supporters of Kannel Group!

Alexander Maöysh

Am 24.12.2012 um 15:19 schrieb Stipe Tolj st...@kannel.org:

 Dear developers,
 Dear users,
 
 in the name of the whole Kannel Group, and to all the great individual 
 supporters and contributor that have shown again tremendous participation and 
 encouragement in this year we wish you:
 
  *** Merry Christmas, Happy Holidays and a Happy New Year! ***
 
 Enjoy the holiday season and make yourself a great time, either with family, 
 friends or both. :)
 
 Stipe
 
 -- 
 ---
 Kölner Landstrasse 419
 40589 Düsseldorf, NRW, Germany
 
 tolj.org system architecture  Kannel Software Foundation (KSF)
 http://www.tolj.org/  http://www.kannel.org/
 
 mailto:st_{at}_tolj.org   mailto:stolj_{at}_kannel.org
 ---
 

Re: Kannel certificate

[Alexander Malysh]

Hi,

yes, I'm the person who requested certs in the past but unable to do so by 
StartSSL now because unable to verify our domain.
Seems they are unable to deliver emails to our domain. I'm in contact with 
support.

If anyone else know free CA where the most browser nowadays accept their cert, 
I'm open for alternatives.

Alex

Am 18.12.2012 um 18:37 schrieb Rene Kluwen rene.klu...@chimit.nl:

 When I try to update from svn https, I get:
  
 $ svn update
 Error validating server certificate for 'https://svn.kannel.org:443':
 - The certificate hostname does not match.
 - The certificate has expired.
 Certificate information:
 - Hostname: redmine.kannel.org
 - Valid: from Dec 18 03:47:17 2011 GMT until Dec 18 15:40:34 2012 GMT
 - Issuer: Secure Digital Certificate Signing, StartCom Ltd., IL
 - Fingerprint: ee:f7:38:a9:89:ce:12:cf:3a:4f:ba:8a:ee:47:85:88:f8:1a:be:c5
 (R)eject, accept (t)emporarily or accept (p)ermanently? T
  
  
 Who is in charge of the Kannel server?

Re: Kannel certificate

[Alexander Malysh]

Hi,

cheap != free

startcom == StartSSL

godaddy take too much time and only one year free.

Alex

Am 19.12.2012 um 15:02 schrieb spameden spame...@gmail.com:

 as an alternative you can buy rapidssl cert they are really cheap!
 
 2012/12/19 spameden spame...@gmail.com
 http://www.godaddy.com/ssl/ssl-open-source.aspx
 
 https://cert.startcom.org/
 
 others seems to be limited for 90 days..
 
 
 2012/12/19 Alexander Malysh amal...@kannel.org
 Hi,
 
 yes, I'm the person who requested certs in the past but unable to do so by 
 StartSSL now because unable to verify our domain.
 Seems they are unable to deliver emails to our domain. I'm in contact with 
 support.
 
 If anyone else know free CA where the most browser nowadays accept their 
 cert, I'm open for alternatives.
 
 Alex
 
 Am 18.12.2012 um 18:37 schrieb Rene Kluwen rene.klu...@chimit.nl:
 
 When I try to update from svn https, I get:
  
 $ svn update
 Error validating server certificate for 'https://svn.kannel.org:443':
 - The certificate hostname does not match.
 - The certificate has expired.
 Certificate information:
 - Hostname: redmine.kannel.org
 - Valid: from Dec 18 03:47:17 2011 GMT until Dec 18 15:40:34 2012 GMT
 - Issuer: Secure Digital Certificate Signing, StartCom Ltd., IL
 - Fingerprint: ee:f7:38:a9:89:ce:12:cf:3a:4f:ba:8a:ee:47:85:88:f8:1a:be:c5
 (R)eject, accept (t)emporarily or accept (p)ermanently? T
  
  
 Who is in charge of the Kannel server?
 
 
 

Re: Kannel certificate

[Alexander Malysh]

fixed, cert is OK now

Am 19.12.2012 um 15:37 schrieb Alexander Malysh amal...@kannel.org:

 Hi,
 
 cheap != free
 
 startcom == StartSSL
 
 godaddy take too much time and only one year free.
 
 Alex
 
 Am 19.12.2012 um 15:02 schrieb spameden spame...@gmail.com:
 
 as an alternative you can buy rapidssl cert they are really cheap!
 
 2012/12/19 spameden spame...@gmail.com
 http://www.godaddy.com/ssl/ssl-open-source.aspx
 
 https://cert.startcom.org/
 
 others seems to be limited for 90 days..
 
 
 2012/12/19 Alexander Malysh amal...@kannel.org
 Hi,
 
 yes, I'm the person who requested certs in the past but unable to do so by 
 StartSSL now because unable to verify our domain.
 Seems they are unable to deliver emails to our domain. I'm in contact with 
 support.
 
 If anyone else know free CA where the most browser nowadays accept their 
 cert, I'm open for alternatives.
 
 Alex
 
 Am 18.12.2012 um 18:37 schrieb Rene Kluwen rene.klu...@chimit.nl:
 
 When I try to update from svn https, I get:
  
 $ svn update
 Error validating server certificate for 'https://svn.kannel.org:443':
 - The certificate hostname does not match.
 - The certificate has expired.
 Certificate information:
 - Hostname: redmine.kannel.org
 - Valid: from Dec 18 03:47:17 2011 GMT until Dec 18 15:40:34 2012 GMT
 - Issuer: Secure Digital Certificate Signing, StartCom Ltd., IL
 - Fingerprint: ee:f7:38:a9:89:ce:12:cf:3a:4f:ba:8a:ee:47:85:88:f8:1a:be:c5
 (R)eject, accept (t)emporarily or accept (p)ermanently? T
  
  
 Who is in charge of the Kannel server?
 
 
 
 

Re: wrong source code link on main page

[Alexander Malysh]

fixed, thanks!

Am 15.11.2012 um 12:26 schrieb spameden spame...@gmail.com:

 Goto http://kannel.org
 
 click Source code
 
 link is http://redmine.kannel.org/repositories/show/kannel
 
 instead of https://redmine.kannel.org/projects/kannel/repository
 
 please fix

Re: [PATCH] SMPP command_status as meta-data

[Alexander Malysh]

Hi Alex,

I'm relieved to hear that :-)

Ok what we could do is the following:

ACK/PROTO///
NACK/PROTO/ERRCODE/ERR DESCR/

With this format we easy split DLR message on / and we have all the infos.
Meta-data hack would be too fragile for me...

I'm not sure that we need error code for ACK but will not veto it.

Alex  

Am 25.10.2012 um 21:00 schrieb Alejandro Guerrieri 
alejandro.guerri...@gmail.com:

 Alex,
 
 I didn't expect the patch to be accepted, it was more of a conversation 
 starter. Anyway, perhaps it could prove useful for some people or at least 
 as a guide (even about how NOT to do things) ;)
 
 Passing the error code on ACK was more about consistency than anything else. 
 The protocol, as Juan mentioned, is intended to allow multi-protocol load 
 balancing. It's not really needed if you stay on a single protocol, otherwise 
 you'd get different error codes for the same error depending on the protocol 
 you're into.
 
 Regards,
 
 Alex
 
 On Thu, Oct 25, 2012 at 12:01 PM, Alexander Malysh amal...@kannel.org wrote:
 Hi Alex,
 
 this patch is no go, because you put SMPP specific handling into abstract 
 bb_smscconn.
 
 As to the discussion itself. We use error codes in our apps as well and we 
 were never in the
 situation that we have to know protocol from the meta-data or message itself. 
 We have mapping
 of SMSC name and which protocol it uses BUT we this only as exception.
 
 We can put protocol into NACK with error code but it make no sense for me to 
 put protocol into ACK as well as put
 error code into ACK. ACK means accepted and I don't see any sense to forward 
 protocol specific ack error code
 to the application layer. Am I missing something then please clarify why do 
 you need numeric value for ACK?
 
 If we decide to put protocol into NACK message then we should implement 
 additional callback function (get_protocol) or
 something like this and then write it out to application layer but not as you 
 did it with mixing SMSC abstract layer and implementation
 specific things.
 
 Alex
 
 Am 25.10.2012 um 00:56 schrieb Alejandro Guerrieri 
 alejandro.guerri...@gmail.com:
 
 Hi,
 
 Attached is a patch that allows passing the command_status on SMPP as 
 meta-data, on the smpp_error_code parameter, so on the logs (and dlr-url) 
 you'd get something like:
 
 [META:?smpp?smpp_error_code=72]
 
 This would be command status value (which is 0 for accepted messages and a 
 positive integer for any other outcome).
 
 This is based on some code Donald Jackson wrote for us time ago, and while 
 this might prove useful for some people, after speaking with Stipe he 
 mentioned that we can achieve similar results by parsing the %A parameter on 
 the dlr-url. In that case, the possible outcomes right now are:
 
 ACK/
 NACK/0x/Error text
 
 In this case, for an accepted message, no numeric code is given.
 For a rejected message, 0x contains the hex value of the 
 command_status
 
 After discussing for a little bit, Stipe pretty much talked us out of the 
 idea of our patch because it's non-generic (only works for SMPP).
 
 However, %A is far from perfect as well:
 
 1. It's inconsistent. No numeric value is provided on ACK's.
 2. You cannot tell the protocol, so if you're load-balancing binds with 
 different protocols you'd get different error codes with no way to correlate 
 them by protocol.
 3. It's not documented either.
 
 After a very healthy debate, we thought of the following approach, keeping 
 the %A method:
 
 ACK/SMPP:0x/OK
 NACK/SMPP:0x0048/Invalid Source address TON
 
 This slightly breaks compatibility if you were already parsing the error 
 code on the NACK's or doing an exact match on ACK/ but imho is not a big 
 deal.
 
 Thoughts? Ideas? Is it something other people would be interested into?
 
 Regards,
 
 Alex
 kannel-command-status.patch
 
 

Re: [PATCH] SMPP command_status as meta-data

[Alexander Malysh]

Hi Alex,

this patch is no go, because you put SMPP specific handling into abstract 
bb_smscconn.

As to the discussion itself. We use error codes in our apps as well and we were 
never in the
situation that we have to know protocol from the meta-data or message itself. 
We have mapping
of SMSC name and which protocol it uses BUT we this only as exception.

We can put protocol into NACK with error code but it make no sense for me to 
put protocol into ACK as well as put
error code into ACK. ACK means accepted and I don't see any sense to forward 
protocol specific ack error code
to the application layer. Am I missing something then please clarify why do you 
need numeric value for ACK?

If we decide to put protocol into NACK message then we should implement 
additional callback function (get_protocol) or
something like this and then write it out to application layer but not as you 
did it with mixing SMSC abstract layer and implementation
specific things.

Alex

Am 25.10.2012 um 00:56 schrieb Alejandro Guerrieri 
alejandro.guerri...@gmail.com:

 Hi,
 
 Attached is a patch that allows passing the command_status on SMPP as 
 meta-data, on the smpp_error_code parameter, so on the logs (and dlr-url) 
 you'd get something like:
 
 [META:?smpp?smpp_error_code=72]
 
 This would be command status value (which is 0 for accepted messages and a 
 positive integer for any other outcome).
 
 This is based on some code Donald Jackson wrote for us time ago, and while 
 this might prove useful for some people, after speaking with Stipe he 
 mentioned that we can achieve similar results by parsing the %A parameter on 
 the dlr-url. In that case, the possible outcomes right now are:
 
 ACK/
 NACK/0x/Error text
 
 In this case, for an accepted message, no numeric code is given.
 For a rejected message, 0x contains the hex value of the 
 command_status
 
 After discussing for a little bit, Stipe pretty much talked us out of the 
 idea of our patch because it's non-generic (only works for SMPP).
 
 However, %A is far from perfect as well:
 
 1. It's inconsistent. No numeric value is provided on ACK's.
 2. You cannot tell the protocol, so if you're load-balancing binds with 
 different protocols you'd get different error codes with no way to correlate 
 them by protocol.
 3. It's not documented either.
 
 After a very healthy debate, we thought of the following approach, keeping 
 the %A method:
 
 ACK/SMPP:0x/OK
 NACK/SMPP:0x0048/Invalid Source address TON
 
 This slightly breaks compatibility if you were already parsing the error code 
 on the NACK's or doing an exact match on ACK/ but imho is not a big deal.
 
 Thoughts? Ideas? Is it something other people would be interested into?
 
 Regards,
 
 Alex
 kannel-command-status.patch

Re: [PATCH] this patch allows to specify our port to SMPP smsc.

[Alexander Malysh]

Hi Vincent,

patch looks OK but missing userguide part.

Alex

Am 10.10.2012 um 11:41 schrieb Vincent CHAVANIS v.chava...@telemaque.fr:

 Hi all,
 
 As some SMPP Servers requires this feature,
 here is the patch.
 
 Comments please ?
 
 regards
 
 patch_smpp_receiverport.txt

Re: [PATCH] this patch allows to specify our port to SMPP smsc.

[Alexander Malysh]

very often :-)

Am 25.10.2012 um 18:08 schrieb Stipe Tolj st...@kannel.org:

 Am 25.10.2012 18:04, schrieb Alexander Malysh:
 
 patch looks OK but missing userguide part.
 
 isn't it always the missing userguide part? :p
 
 Stipe
 
 -- 
 ---
 Kölner Landstrasse 419
 40589 Düsseldorf, NRW, Germany
 
 tolj.org system architecture  Kannel Software Foundation (KSF)
 http://www.tolj.org/  http://www.kannel.org/
 
 mailto:st_{at}_tolj.org   mailto:stolj_{at}_kannel.org
 ---
 

Re: [patch] fakesmsc no longer segmentation faults after reaching EOF

[Alexander Malysh]

Hi,

patch comitted to SVN.

Thanks!

On 11.09.2012, at 19:06, Rudy Matela r...@matela.com.br wrote:

 Hello,
 
 There is a bug on fakesmsc. It gives segmentation fault when the
 program reaches EOF. The simplest way to simulate the bug is:
 
 $ ./test/fakesmsc  /dev/null
 2012-09-11 13:56:02 [5946] [0] INFO: Debug_lvl = -1, log_file =
 none, log_lvl = 0
 2012-09-11 13:56:02 [5946] [0] INFO: Entering interactive mode. Type
 your message on the command line
 2012-09-11 13:56:02 [5946] [0] INFO: fakesmsc starting
 2012-09-11 13:56:02 [5946] [0] DEBUG: Connecting to 127.0.0.1
 2012-09-11 13:56:02 [5946] [0] PANIC: ./test/fakesmsc() [0x805d5ad]
 2012-09-11 13:56:02 [5946] [0] PANIC:
 linux-gate.so.1(__kernel_rt_sigreturn+0) [0xb772140c]
 2012-09-11 13:56:02 [5946] [0] PANIC: ./test/fakesmsc(main+0x8a8) [0x804fc48]
 2012-09-11 13:56:02 [5946] [0] PANIC:
 /usr/lib/libc.so.6(__libc_start_main+0xf5) [0xb7149605]
 2012-09-11 13:56:02 [5946] [0] PANIC: ./test/fakesmsc() [0x804fdd9]
 Segmentation fault
 
 Real situations for it to happen include reading several messages from a file
 $ ./test/fakesmsc  file.txt (after reaching the end of file the
 program will crash)
 
 Or even reading from keyboard by simulating EOF when typing control+d.
 
 
 Attached is a patch that solves the issue. The program now quits when
 reaches end of file on stdin. This provides a great way to quit when
 in interactive mode: type your messages, then ctrl+d to quit (as it is
 on bash / python / perl / ruby and other interpreters).
 
 I've successfully applied it against revision 4995 using patch -p0 
 fakesmsc-gracefully-quits-when-eof.patch on project root.
 
 Regards,
 Rudy
 
 
 Index: test/fakesmsc.c
 ===
 --- test/fakesmsc.c (revision 4995)
 +++ test/fakesmsc.c (working copy)
 @@ -307,6 +307,8 @@
 /* something went off, let's see if it's stdin */
 if (FD_ISSET(fileno(fp), rset)) { /* stdin is readable */
 cptr = fgets(buffer, IN_BUFSIZE, stdin);
 +if (!cptr)
 +goto over;
 if( strlen( cptr )  2 )
 goto rcv;
 } else { /* timer kicked in */
 fakesmsc-gracefully-quits-when-eof.patch

Re: [patch] SIGUSR1 increments max_send on fakesmsc

[Alexander Malysh]

Hi,

why not use interactive mode instead?

Alex

On 11.09.2012, at 18:28, Rudy Matela r...@matela.com.br wrote:

 Hello,
 
 Don't know if this patch is elegible for the trunk of kannel. But it
 was useful for me. I wanted a way to keep sending random messages
 using fakesmsc even when the limit was hit:
 
 I've patched it to treat the SIGUSR1 signal as a increment command to
 the max_send variable.
 
 This way you can do:
 
 $ ./test/fakesmsc -m 0 100 200 text blah
 2012-09-11 13:22:17 [21787] [0] INFO: Debug_lvl = -1, log_file =
 none, log_lvl = 0
 2012-09-11 13:22:17 [21787] [0] INFO: Host localhost Port 1
 interval 1.000 max-messages 0
 2012-09-11 13:22:17 [21787] [0] INFO: fakesmsc starting
 2012-09-11 13:22:17 [21787] [0] DEBUG: Connecting to 127.0.0.1
 
 An on other terminal:
 
 $ kill -s SIGUSR1 21787
 
 Then on the terminal with fakesmsc appears:
 
 2012-09-11 13:22:26 [21787] [0] INFO: fakesmsc: sent message 1
 
 
 
 And you can tell fakesmsc to send random messages when you want and
 not on a fixed interval.
 
 
 In other words,
 
 This patch makes fakesmsc interpret the SIGUSR1 signal as a command to
 send another message after the cap is hit.
 
 
 Regards,
 Rudy
 fakesmsc-sigusr1-increments-max_send.patch

Re: [PATCH] Lightning speed Dict hash table

[Alexander Malysh]

Hi,

I just commited hash from Robert Sedgewick as replacement for the old one. I 
think that would be default for now?

Alex

Am 09.08.2012 um 13:42 schrieb Stipe Tolj st...@kannel.org:

 Am 07.08.2012 22:40, schrieb Rene Kluwen:
 Well... Considering the figures it is clear that either of your patches can
 make a big difference to Kannel's performance.
 MHO is that we go for the least complex patch, if test results appear more
 or less the same between the two.
 
 right, we'll consider the Bob Jenkins code as optional here, because of the 
 code complexity and the way the parallelization of the hash computation is 
 performed.
 
 The idea is to have one that is fast as default, and make others modular 
 as an option. I.e. extracting the implementations into own gwlib/hash.[ch] 
 files.
 
 Stipe
 
 -- 
 ---
 Kölner Landstrasse 419
 40589 Düsseldorf, NRW, Germany
 
 tolj.org system architecture  Kannel Software Foundation (KSF)
 http://www.tolj.org/  http://www.kannel.org/
 
 mailto:st_{at}_tolj.org   mailto:stolj_{at}_kannel.org
 ---
 

Re: [PATCH] Lightning speed Dict hash table

[Alexander Malysh]

Hi Stipe,

this is really complex patch for the hash issue, but it could be made easier 
and almost the same speed.
I'm not really convenient that we need to apply this complex patch...

Here are my simple tests and patch attached:

Command used:

time ./test/test_dict 

-- old
2012-08-07 14:47:49 [57291] [0] DEBUG: Dict populate phase.
2012-08-07 14:48:16 [57291] [0] INFO: ok, got 20 entries in dict1.
2012-08-07 14:48:16 [57291] [0] INFO: ok, got 20 entries in dict2.
2012-08-07 14:48:16 [57291] [0] DEBUG: Dict lookup phase.

real0m41.842s
user0m40.680s
sys 0m1.078s

-- sedgewick (my patch)
2012-08-07 14:47:01 [57016] [0] DEBUG: Dict populate phase.
2012-08-07 14:47:03 [57016] [0] INFO: ok, got 20 entries in dict1.
2012-08-07 14:47:03 [57016] [0] INFO: ok, got 20 entries in dict2.
2012-08-07 14:47:03 [57016] [0] DEBUG: Dict lookup phase.

real0m4.160s
user0m2.998s
sys 0m0.977s

real0m3.797s
user0m2.738s
sys 0m1.015s

real0m3.732s
user0m2.767s
sys 0m0.938s

-- Bob Jenkins
2012-08-07 14:50:32 [58470] [0] DEBUG: Dict populate phase.
2012-08-07 14:50:34 [58470] [0] INFO: ok, got 20 entries in dict1.
2012-08-07 14:50:34 [58470] [0] INFO: ok, got 20 entries in dict2.
2012-08-07 14:50:34 [58470] [0] DEBUG: Dict lookup phase.

real0m3.747s
user0m2.682s
sys 0m0.919s

real0m3.661s
user0m2.692s
sys 0m0.946s

real0m3.522s
user0m2.606s
sys 0m0.908s

Alex


hash_patch.diff
Description: Binary data

Am 06.08.2012 um 15:59 schrieb Stipe Tolj st...@kannel.org:

 Hi list,
 
 this is a new Dict hash table implementation, which modifies the internal 
 hash algorithm we use in the gwlib/dict.[ch] module.
 
 The short summary is: It is round about 7,5-8 times faster then the existing 
 implementation!
 
 Now, the explanation part:
 
 Running the SVN trunk's test/test_dict on a machine I was benchmarking 
 against gives us the following runtime results:
 
 Average execution speed: 52,x sec.
 OProfile's opreport for test_dict:
 
 CPU: CPU with timer interrupt, speed 0 MHz (estimated)
 Profiling through timer interrupt
 samples  %image name   symbol name
 1900039.3954  test_dictitem_has_key
 1756336.4158  test_dictseems_valid_real
 4528  9.3885  test_dictgwlist_search
 3510  7.2778  test_dictoctstr_compare
 456   0.9455  libc-2.11.3.so   vfprintf
 251   0.5204  libc-2.11.3.so   _int_malloc
 175   0.3629  libc-2.11.3.so   random_r
 159   0.3297  libc-2.11.3.so   __i686.get_pc_thunk.bx
 150   0.3110  test_dictoctstr_len
 148   0.3069  test_dictoctstr_get_char
 139   0.2882  libc-2.11.3.so   random
 
 (BTW, this was on a VMware VM, so we used timer interrupts, but the relative 
 results on a real machine are the same.)
 
 So, what does it tell us?
 
 First of all, most CPU cycles are used for the item_has_key() function 
 internally, which is at the end of the day nothing more then a 
 octstr_compare(). We compare the hash's key Octstr here while searching for 
 the one we're looking for.
 
 The real problem about the current implementation is the hashing of the 
 keys. This happens within key_to_index() and we use this implementation:
 
 static long key_to_index(Dict *dict, Octstr *key)
 {
return octstr_hash_key(key) % dict-size;
 }
 
 where octstr_hash_key() accumulates the single byte values to one long and we 
 modulo against the dict size.
 
 That's ok, for small Dicts. But when the Dict size get's bigger and bigger, 
 we'll notice un-leveled congestion in the hash table. Which means for some 
 hash table buckets we'll have larger chained items in the bucket list, then 
 for others.
 
 This is also where the gwlist_search() hits us from the OProfile results. We 
 spend 10% by simply looking for the right item in the hash bucket list.
 
 So, the key to performance is having a well distributed hash function, which 
 make the overall average list len of the hash table bucket minimal, and well 
 distributed.
 
 The new implementation does this. It is based on the code of Bob Jenkins, 
 which was released to the public domain. I have incorporated the parts into 
 our existing gwlib/dict.[ch] structure, and also added some debugging 
 capabilities to the structure itself.
 
 Ok, you want some figures now? Here is the same test run of test_dict on the 
 same machine, under same conditions:
 
 Average execution speed: 6,7 sec.
 OProfile's opreport for test_dict:
 
 CPU: CPU with timer interrupt, speed 0 MHz (estimated)
 Profiling through timer interrupt
 samples  %image name   symbol name
 568  14.2036  libc-2.11.3.so   vfprintf
 310   7.7519  libc-2.11.3.so   random
 273   6.8267  libc-2.11.3.so   random_r
 193   4.8262  libc-2.11.3.so   

Re: dlr-retry-queue patch

[Alexander Malysh]

Hi Kevin,

beside the fact that SMSCs that sends DLR before ACK with message_id are just 
plain buggy and have to fixed I would try for the
correctly implemented SMSCs to return temp error if DLR not found and they will 
retry later.

For the patch itself here are some comments:

+if ( smpp-dlr_retry_count  0 ) {
+// add the DLR into the retry queue
+struct dlr_retry *retry = gw_malloc(sizeof(struct dlr_retry));

// is not C-Style comment

+static void do_dlr_retry_cleanup (SMPP *smpp)
+{
+long i;
+Msg *dlrmsg = NULL;
+for (i = 0; i  gwlist_len(smpp-dlr_to_retry); i++) {
+struct dlr_retry *dlr;
+dlr = gwlist_get(smpp-dlr_to_retry, i);
+if (dlr != NULL ) {
+if ( difftime(time(NULL),dlr-retry_time) = 0 ) {
+debug(bb.sms.smpp, 0,SMPP[%s]: Attempt %ld of %ld to 
process DLR id%s dst%s, type%d,
+octstr_get_cstr(smpp-conn-id),
+(dlr-dlr_retry_count+1), smpp-dlr_retry_count,
+octstr_get_cstr(dlr-msgid),
+octstr_get_cstr(dlr-destination_address), 
dlr-dlrstat);
+dlrmsg = dlr_find(smpp-conn-id,
+dlr-msgid, /* smsc message id */
+dlr-destination_address, /* destination */
+dlr-dlrstat, 1);
+if (dlrmsg != NULL) {
+debug(bb.sms.smpp, 0,SMPP[%s]: Found matching DLR 
id%s dst%s, type%d,
+octstr_get_cstr(smpp-conn-id), 
octstr_get_cstr(dlr-msgid),
+octstr_get_cstr(dlr-destination_address), 
dlr-dlrstat);
+dlrmsg-sms.msgdata = octstr_duplicate(dlr-msgdata);
+dlrmsg-sms.sms_type = report_mo;
+dlrmsg-sms.account = octstr_duplicate(smpp-username);
+bb_smscconn_receive(smpp-conn, dlrmsg);
+gwlist_delete(smpp-dlr_to_retry,i,1);

you don't adjust i therefore you will miss the next DLR in the queue

+} else {
+dlr-dlr_retry_count++;
+if (dlr-dlr_retry_count = smpp-dlr_retry_count) {
+gwlist_delete(smpp-dlr_to_retry,i,1);

ditto

+error(0,SMPP[%s]: Number of retry excedeed for DLR 
+id%s dst%s, type%d discarding it,
+octstr_get_cstr(smpp-conn-id), 
octstr_get_cstr(dlr-msgid),
+octstr_get_cstr(dlr-destination_address), 
dlr-dlrstat);
+} else {
+dlr-retry_time = time(NULL) + 
smpp-dlr_retry_interval;
+debug(bb.sms.smpp, 0,SMPP[%s]: DLR not yet found 
re-queueing it id%s dst%s, type%d,
+octstr_get_cstr(smpp-conn-id), 
octstr_get_cstr(dlr-msgid),
+octstr_get_cstr(dlr-destination_address), 
dlr-dlrstat);
+}
+}
+   }
+}
+}
+}

+ * execute in a loop do_dlr_retry_cleanup and wait 1sec till the smpp conn is
+ * not quitting
+ */
+static void dlr_retry_thread(void *arg)
+{
+SMPP *smpp;
+smpp = arg;
+/* Make sure we log into our own log-file if defined */
+log_thread_to(smpp-conn-log_idx);
+while (!smpp-quitting) {
+do_dlr_retry_cleanup(smpp);
+gwthread_sleep(1.0);
+}
+}

Please make retry frequency configurable I think 1 sec is too low for some 
configurations when DLR DB should be busy.
I see you have already dlr_retry_interval why not return value how long to 
sleep?

If we will shutdown the bearerbox then we will missing following error because 
you just drop waiting DLRs without notice:

+error(0,SMPP[%s]: got DLR but could not find message or was not 
interested 
+in it id%s dst%s, type%d,
+octstr_get_cstr(smpp-conn-id), octstr_get_cstr(tmp),
+octstr_get_cstr(destination_addr), dlrstat);

Thanks,
Alex

Am 23.07.2012 um 12:55 schrieb Stevenard, Kevin (Kevin) 
kevin.steven...@alcatel-lucent.com:

 Hello Andreas,
 
 The problem of the micro lag in the replication (I say micro because our 
 setup is not overloaded and most of the time lag it is not exceeding 100ms) 
 is not the main motivation of this patch. Even with a single DB server we 
 still have to retry DLRs. 
 
 Our main problem is that we are connected to various SMSC / SMPP gateway and 
 some of them have weird behavior for example few of them sends sometimes the 
 deliver_sm before the submit_sm_resp ... for some of those gateways we have 
 seen that it is always on some specific cases like the end-user is not 
 available or not anymore reachable.
 
 Some gateways also send deliver_sm in random / roundrobin / load related 
 manner. Or start to be crazy when we send too much load even if we stay in 
 the boundaries imposed by them.