Re: [PATCH] WSP headers with end-of-string 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 is
Stipe Tolj wrote:
Ok,
regarding the Siemens SX1 kludge and the WSP headers with
end-of-string 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 way in order to have a negotiated consensus.
Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
Index: wap/wsp_headers.c
===
RCS file: /home/cvs/gateway/wap/wsp_headers.c,v
retrieving revision 1.19
diff -u -r1.19 wsp_headers.c
--- wap/wsp_headers.c 8 Aug 2004 20:39:56 - 1.19
+++ wap/wsp_headers.c 21 Jan 2005 01:11:50 -
@@ -110,7 +110,7 @@
unsigned long len;
val = parse_get_char(context);
-if (val = 0 val 31) {
+if (val 0 val 31) {
*well_known_value = -1;
parse_limit(context, val);
return WSP_FIELD_VALUE_DATA;
@@ -126,7 +126,7 @@
*well_known_value = -1;
/* We already consumed the Quote */
return WSP_FIELD_VALUE_NUL_STRING;
-} else {
+} else {/* implicite val == 0 */
*well_known_value = -1;
/* Un-parse the character we just read */
parse_skip(context, -1);
--
Vjacheslav Chekushinmailto:[EMAIL PROTECTED]
Latvian Mobile Phone Companyhttp://www.lmt.lv
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's threads. With this patch applied we will have a possibility to set timeout for all filedescriptors in fdset and after timeout elapsed registered callback function with POLLERR as event will be called. I'm surprised with sooo little code change reach full working server/client timeout handling :) Maybe we want implement (yet missing) things too: - dont wait for set-timeout instead find the min timeout (this part is not implemented yet because will cause parformance bust due to a need to rescan the whole fdset after all callbacks were executed and anyway for boxes with high traffic earlier timeout check will catch). - timeout for each fd (IMHO: it's oversized for our needs) Comments votes please! -- Vjacheslav Chekushinmailto:[EMAIL PROTECTED] Latvian Mobile Phone Companyhttp://www.lmt.lv
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=54321\text=0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789morethan160bytes
and by sniffing I got:
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..E.
0010 01 03 65 ee 40 00 40 06 d6 04 7f 00 00 01 7f 00 [EMAIL
PROTECTED]@.
0020 00 01 80 2c 27 11 6b cb 19 15 6c 60 58 c0 80 18 ...,'.k...l`X...
0030 7f ff b7 49 00 00 01 01 08 0a 00 03 11 1c 00 02 ...I
0040 ff 06 00 00 00 cf 00 00 00 04 00 00 00 00 00 00
0050 00 0a 00 00 01 31 32 33 34 35 00 02 01 35 34 33 .12345...543
0060 32 31 00 43 00 00 00 00 00 00 00 00 9f 05 00 03 21.C
0070 02 02 01 30 31 32 33 34 35 36 37 38 39 30 31 32 ...0123456789012
0080 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 3456789012345678
0090 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 9012345678901234
00a0 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 5678901234567890
00b0 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 1234567890123456
00c0 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 7890123456789012
00d0 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 3456789012345678
00e0 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 9012345678901234
00f0 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 5678901234567890
0100 31 32 33 34 35 36 37 38 39 30 31 32 04 26 00 01 123456789012...
0110 01 (Checkout the last 5 bytes)
for the first message , and
00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..E.
0010 00 7c 65 ef 40 00 40 06 d6 8a 7f 00 00 01 7f 00 .|[EMAIL
PROTECTED]@.
0020 00 01 80 2c 27 11 6b cb 19 e4 6c 60 58 d9 80 18 ...,'.k...l`X...
0030 7f ff 5a 25 00 00 01 01 08 0a 00 03 11 1e 00 03 ..Z%
0040 11 1e 00 00 00 48 00 00 00 04 00 00 00 00 00 00 .H..
0050 00 0b 00 00 01 31 32 33 34 35 00 02 01 35 34 33 .12345...543
0060 32 31 00 43 00 00 00 00 00 00 00 00 1d 05 00 03 21.C
0070 02 02 02 33 34 35 36 37 38 39 6d 6f 72 65 74 68 ...3456789moreth
0080 61 6e 31 36 30 62 79 74 65 73an160bytes
For the second message.
As you can see, the UDH is where it sould, but there are some 5 bytes at
the end of the first message that I just cant recognize.
Thanx!
==Oscar
On Thu, 2005-01-27 at 02:27, Aarno Syvänen wrote:
Can you send an example segment ? UDH is at the beginning.
Aarno
On 26.1.2005, at 23:27, Oscar Medina Duarte wrote:
Hi
On Wed, 2005-01-26 at 04:08, Aarno Syvänen wrote:
Hi,
On 26.1.2005, at 03:04, Oscar Medina Duarte wrote:
Hi list !
I'm doing some tests with Kannel's concatenation, and there are two
things I found relevant (4 me al least).
First, messages part of a concatenated message have a 159 chars long
message body (Including headers), while IMO (cause I dont remember
that
being an issue in concatenation specs {ETSI TS 03.40 v7.5.0 @
9.2.3.24})
should/could be 160, in this case, for me it seems like we are not
using
one char per message.
Second, in all of the not last messages of a concatenated long
message, there are 5 bytes at the end that look like a IE for me,
those
are : 0x04 0x26 0x00 0x01 0x01. I dont have a clue on what that IE
looking might be, could some one please tell me?
This cannot be IE. First byte would be information element identifier,
second
information element length. So (8 byte) concatenation IE should start
with
0x00 0x03.
mhmh... OK, then, any ideas, what would those 5 bytes might be?
Kannel would not split an escaped character, so sometimes segments can
be
shorter.
I'm not escaping any chars, Im just sending plain ascii text numbers.
thanx !
==Oscar
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 available via
http://www.kannel.org/download/wtls/
At http://www.kannel.org/roadmap.shtml#projects the text says, that 3G
LAB is working on adding this and plans to have it ready in May. May of
which year, please?
now, 3G LAB (now Trigenix) has been working on the WTLS stack in Kannel and
there have been certain parts integrated already, see wap/wtls* source files.
Unfortunatly it's yet not functional.
If you consider in adding WTLS abilities to Kannel I may advice to take the
kwtls sources and addopt them to the existing WTLS stack sources in Kannel's tree.
Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
[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 who is eager to dig his head into
crypto stuff and get Kannel WTLS-enabled. I'd expect that it is not too much
work to do, since kwtls works in some extend. Only code reviewing and cutting
things together is the major thing about the task.
Anyone interested?
Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
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).
Comments and votes please!
post-cvs-commit review: +1
Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
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.
Thanks a lot for submission.
Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
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 parameters, but is unable to actually turn them into some sort of passable escape code(s) via sms-service. Take for example this log dump: 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x0427) 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read as 1 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x001e) 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read as 29 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1402) 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read as 1 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1404) 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read as 22 2005-01-27 16:46:56 [30186] [7] ERROR: SMPP: Unknown TLV(0x1404,0x0016,4154265420576972656c657373205365727669636573) for PDU type (deliver_sm) received! 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1530) 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read as 3 2005-01-27 16:46:56 [30186] [7] ERROR: SMPP: Unknown TLV(0x1530,0x0003,504244) for PDU type (deliver_sm) received! 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1531) 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read as 90 2005-01-27 16:46:56 [30186] [7] ERROR: SMPP: Unknown TLV(0x1531,0x005a,4e6f2050686f6e65204e756d6265723a20537562736372696265722070686f6e65206e756d62657220776173206e6f74206d617463686 56420696e2074686520515073732073797374656d206f722041575320506f7274616c20) for PDU type (deliver_sm) received! 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1532) 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read as 6 2005-01-27 16:46:56 [30186] [7] ERROR: SMPP: Unknown TLV(0x1532,0x0006,2d3230313030) for PDU type (deliver_sm) received! 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1533) 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read as 90 2005-01-27 16:46:56 [30186] [7] ERROR: SMPP: Unknown TLV(0x1533,0x005a,4e6f2050686f6e65204e756d6265723a20537562736372696265722070686f6e65206e756d62657220776173206e6f74206d617463686 56420696e2074686520515073732073797374656d206f722041575320506f7274616c20) for PDU type (deliver_sm) received! 2005-01-27 16:46:56 [30186] [7] DEBUG: SMPP[mysmsc]: Got PDU: 2005-01-27 16:46:56 [30186] [7] DEBUG: SMPP PDU 0xb5c9a5e0 dump: 2005-01-27 16:46:56 [30186] [7] DEBUG: type_name: deliver_sm 2005-01-27 16:46:56 [30186] [7] DEBUG: command_id: 5 = 0x0005 2005-01-27 16:46:56 [30186] [7] DEBUG: command_status: 0 = 0x 2005-01-27 16:46:56 [30186] [7] DEBUG: sequence_number: 877 = 0x036d [...] My dream for the config file: group = smsbox smsc-id = mysmsc [...] optparam = 0x1404:22:N:billerr_msg optparam = 0x1530:3:M:happy_tag optparam = 0x1531:90:K:secret_code optparam = 0x1532:6:J:test_msg_id optparam = 0x1533:90:L:secret_code2 Now the following takes place: When an SMS arrives, it can be passed to sms-service, using %N, %M, %K, %J and %L (assuming those are available), so I can grab them with a PHP script and do something with them. When submitting an SMS to kannel, I can set the URL to: http://localhost:13013/cgi-bin/sendsms?user=[...]billerr_msg=you+spent+too+muchhappy_tag=funtext_msg_id=123FFF And kannel will modify the PDU to include the data passed and send that to the SMSC. That is my dream. Beckman --- Peter Beckman Internet Guy [EMAIL PROTECTED] http://www.purplecow.com/ ---
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 about it in the group?` As normally, consensus is based on 2-3 voices =] So I implemented new configuration variable for this, 'immediate-sendsms-reply' which must be set to 'true' to make it behave like it did earlier; as a default, new system is going to be used. (it is a compatibility breaker then as it changes the HTTP reply text content/code) -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
