[PATCH] WSP headers with value

Ok, regarding the Siemens SX1 kludge and the WSP headers with as only value byte, I'd like to get at least a vote for commiting this patch from the following developers: Aarno, Paul, Slava please. You guys haven't stated yet nothing regarding a vote. Please do so. I'd like to keep it that wa

Re: [PATCH] WSP headers with value

Hi, all. +1 from me Just one comment. This patch will be good as far as no any header with special treatment for "No-value". We unpack fields in wsp_unpack_well_known_field(). I checked that in current specs no any header with special hanling for "No-value". But if it will be added, than this patch

Re: [PATCH] WSP headers with value

Have you tested the modification ? What will be result of parsing 0x80 0x00 ? Accept: is ok according the rfc 2616. (Because this is a low level parsing function, you definitely want to test.) Aarno On 27.1.2005, at 13:04, Stipe Tolj wrote: Ok, regarding the Siemens SX1 kludge and the WSP header

Re: [PATCH] http client/server timeout

Hi, Great work! Definitly +1 for this approach. Draft tests seems to works. Alexander Malysh wrote: Hello together, please find attached patch that implements http server & client idle timeout. In order to efficient handle timeouts and don't start "yet another thread" we use already available fdset

CIMD2 dlr-mask?

Hello! I'm taking the dlr-functionality into use with a CIMD2 SMSC-connection. In CIMD2 the dlr-bits are defined in the following way: 1 - temporary error 2 - validity period expired 4 - delivery failed 8 - delivery successful 16 - message cancelled 32 - message deleted by the operator 64 - first t

Re: Kannel concatenation bug & Q

Hi! Here is the example: I sent: 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789morethan160bytes like: http://localhost:64235/cgi-bin/sendsms?user=foo\&password=bar\&from=12345\&to=5

Re: WTLS?

Hi Marcus, Marcus Schmöger wrote: Hi, I would like to know about the current status of WTLS integration into Kannel. The info on the website is somewhate ambiguous about this. At http://www.kannel.org/addons.shtml one of the three addons (the one from 3ui) is not available anymore. It is still a

[HELP] WTLS stack?

Hi list, any crypto gurus arround who are willing to pick up the WTLS code for review and adding the kwtls (external add-on module) to the existing code? See Mantis bug#038 and http://www.kannel.org/download/wtls/ for more details on the WTLS stack. I'd like to see this getting going to someone

Re: [PATCH] http server fixes

Alexander Malysh wrote: Hi together, hopefully all of us have overcome those long new year holidays and are back to normal live & development ;) attached you can find a patch that includes some http server fixes: - don't close listen filedescriptor when accept failed (that can be caused bei client

Re: [PATCH] bb_boxc: popup threads after accept

Alexander Malysh wrote: Hi together, attched you can find a patch that change behaviour in communication thread creation. With this patch threads are created only _after_ successful accept and so eliminate possible DOS (IMHO: it's unwise to popup thread before check whether this box allowed/denied)

Re: [PATCH] Bug #0000168 checks/check_ppg.sh: test: argument expected

Stefan Radman wrote: Hi, I've submitted a bug to the Mantis system and followed up with a patch (attached to the bug). Can someone review the patch and see if it's acceptable? Alex seems to be very busy ;-) All the necessary info is in the bug track. commited to cvs, in slightly reduced form. Thank

Re: cannot detect modem

David wrote: Hi, i've tried using wvdialconf and according to it, my gsm modem seems working fine, here is the output from wvdialconf: ttyS0<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud ttyS0<*1>: ATQ0 V1 E1 -- OK ttyS0<*1>: ATQ0 V1 E1 Z -- OK

Re: Coding autodetection

Hi Enver, Enver ALTIN wrote: Hi, On Tue, 2005-01-25 at 15:32 +0300, Roman wrote: I have kannel 1.4.0 and some scripts, which used in exec statement in kannel.conf service section. These scripts can return result in UCS2 or GSM coding(english or another language). Is there way in kannel(without patc

Re: [PATCH] preliminary confirmed sendsms

Alexander Malysh wrote: Kalle Marjola wrote: On Thu, 2004-10-07 at 12:52, Alexander Malysh wrote: Hi Kalle, patch looks good except this "really horrible kludge"... Well I thought that first check it out and if people like it and we decide what to do about it (see choices a, b and c) then I bother

Fwd: [Kannel-Users] Re: SMS message ids

Any chance we could get the dlr notification to include the message_ids that can be found in bearerbox.log? Thanks, -M@ Begin forwarded message: From: Stipe Tolj <[EMAIL PROTECTED]> Date: January 27, 2005 7:39:04 PM PST To: Matthew Hixson <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], Davy Chan

Re: [PATCH] WSP headers with value

Replying to Stipe Tolj: > Aarno, Paul, Slava As already said, I have no objections :) -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head

Re: [Kannel-Devel] SMS message ids in DLR reports generated by Kannel

On Thu, 27 Jan 2005, Matthew Hixson wrote: Any chance we could get the dlr notification to include the message_ids that can be found in bearerbox.log? More to the point: 2005-01-27 04:11:53 [30186] [8] DEBUG: SMPP PDU 0xb5d9d4b0 dump: 2005-01-27 04:11:53 [30186] [8] DEBUG: type_name: submit_sm_r

Config-based Optional Parameter Functionality

Dear Kannel Developers: I've written about this before, but I thought I would bring it up again because I hate patching. Many SMSC's are starting to use the optional SMPP parameters for information like billing issues, carrier failures, etc. Kannel really doesn't allow for this -- it detects the p

SMS message ids from dlr

Dear Kannel Devel, The one feature that Kannel is missing is to receive the message_id that is given back to kannel as part of the submit_sm_resp as a dlr parameter. This is very useful as the only other way to receive the message_id is via the deliver_sm, which may never arrive if there was a pro

Re: [PATCH] preliminary confirmed sendsms

> I'm +1 for a)! without reviewing the code, but from the semantical > perspective. > > AFAIK, this has yet not been commited to cvs, right? > Nope, I just digged it out.. I can commit it to CVS (change things commented when I last time sent it out) right now.. > Kalle, what is the consensus ab