RE: dlr-mask example

[Paul Keogh]

> 2003-03-04 11:02:48 [7] DEBUG: EMI2[VodMT055]: emi2 parsing packet:
> <01/00046/R/51/A//0031650698222:040303110211/C3>
> 2003-03-04 11:02:48 [7] DEBUG: Looking for DLR smsc=VodMT055,
> ts=VodMT055-1, dst=0031650698222, type=8
> 2003-03-04 11:02:48 [7] DEBUG: created DLR message for URL
>  1046727238
> 075&status=%d×tamp=%t&reasoncode=%A&smsc_id=%i>
> 2003-03-04 11:02:48 [7] PANIC: gwlib/octstr.c:2140: seems_valid_real:
> Assertion `ostr->data[ostr->len] == '\0'' failed. (Called from
> gwlib/octstr.c:292:octstr_duplicate_real.)
> 
> Do you know what this means?

It means that there is a coding bug in the EMI2 driver that causes
an assertion failure and the process to exit. There has been a fix
to this driver recently; you could try a CVS build to see if it
resolves your issue.
 

RE: DLRs not found

[Paul Keogh]

> 2002-10-24 14:50:57 [5] DEBUG: Looking for DLR smsc=(null), ts=79, 
> dst=+441234567890 type=1 2002-10-24 14:50:57 [5] DEBUG: DLR 
> not found! 2002-10-
> 24 14:50:57 [5] DEBUG: AT2[/dev/ttyS0]: Received delivery 
> notification but 
> can't find that ID in the DLR storage 2002-10-24 14:50:57 [5] 
> DEBUG: System 
> error 1: Operation not permitted
> 

I have seen a problem on the M20 that mirrors this. It appears that
if there is a temporary failure when sending the message, the DLR
contains an ID that does'nt actually match the one you got from
the modem when sending the message. This is hard to reproduce, so 
I cannot say for absolute sure that this was the cause but it
certainly looked like it.

Does the log show any temporary failures on the outgoing side ?

Do the DLR IDs match with what the modem returned ?
 

RE: problems making with wtls

[Paul Keogh]

> ./configure --with-wtls=openssl --disable-docs
>
> when I type make, everything is OK until I get the following :
>
> gcc -D_REENTRANT=1 -I. -g -O2 -DBROKEN_PTHREADS=1
> -I/usr/include/libxml2
> -I/usr/local/ssl/include  -o gw/wapbox gw/wapbox.o libgw.a
> libwmlscript.a
> libwap.a libgwlib.a -lssl -lpthread -lresolv -lnsl -lm
> -L/usr/lib -lxml2
> -lz -lm -L/usr/local/ssl/lib -lcrypto -lssl
> -L/usr/local/ssl/lib -lcrypto
> libwap.a(wtls_statesupport.o): In function `wtls_decrypt_rc5':
> /home/marpate1/gateway-1.2.0/wap/wtls_statesupport.c:291: undefined
> reference to `RC5_32_set_key'
> /home/marpate1/gateway-1.2.0/wap/wtls_statesupport.c:299: undefined
> reference to `RC5_32_cbc_encrypt'
> /home/marpate1/gateway-1.2.0/wap/wtls_statesupport.c:317: undefined
> reference to `RC5_32_cbc_encrypt'
> libwap.a(wtls_statesupport.o): In function `wtls_encrypt_rc5':
> /home/marpate1/gateway-1.2.0/wap/wtls_statesupport.c:354: undefined
> reference to `RC5_32_set_key'
> /home/marpate1/gateway-1.2.0/wap/wtls_statesupport.c:360: undefined
> reference to `RC5_32_cbc_encrypt'
> /home/marpate1/gateway-1.2.0/wap/wtls_statesupport.c:376: undefined
> reference to `RC5_32_cbc_encrypt'
> collect2: ld returned 1 exit status
> make: *** [gw/wapbox] Error 1
>
> Any ideas?

One possibility is that because RC5 is not a 'free' algorithm (RSA hold
some IP rights in the US and maybe elsewhere), your OpenSSL build did not
have RC5 support enabled by default. You should at least check that OpenSSL
is built with RC5 support at this stage. And as you can see from above, WTLS
needs RC5...

RE: WapKannel Configuration

[Paul Keogh]

> I have the service available and I verify that the ports 9201 
> and 9202 are 
> up.
> 
> I'm using a Motorola Iden cellphone that are connect by the 
> port: 9203,
> But, I don't get the handset access to the home-deck 
> configurating my kannel 
> server.
> Where can I set this port as 9203?
> 

9203 is a WTLS service port. Sounds like you have WTLS security
turned on in the device. Try turning it off and repeating the
connection attempt.
 

RE: POST & multipart.form-data not decompressed correctly

[Paul Keogh]

> Is this a bug or a known feature? If I POST stuff as
> application/vnd.wap.multipart.form-data and the content
> is compressed wml then Kannel lets the whole thing
> through with the same content encoding..without
> decompressing the wmlc. 
> 
> I tried this on another gateway and it decompressed
> the wmlc, and replaced the content with multipart/form-data.
> Isn't that what Kannel should also do?
> 

There is no support in Kannel for the WSP multipart data construct
which I guess is the encoding used for application/vnd.wap.multipart.form-data
MIME types. No support means no encoding or decoding support.

What device generates this content type as a matter of interest ?

<>

RE: R: MMS Push Problem

[Paul Keogh]

> I tryed with "date -r filename" but I just get back the date 
> of creation of
> the file. I can't understand how the X-MMS-Expiry date is 
> encoded. Is there
> any documentation about that? 
> 

Look at 7.2.10 of WAP-209-MMSEncapsulation-20020105-a for Expiry field
encoding.

Then look at WSP for long integer encoding.

RE: charset problem

[Paul Keogh]

> 2002-08-16 14:53:50 [10] DEBUG: Octet string dump
> ends.
> 2002-08-16 14:53:50 [9] DEBUG: HTTP: Status line:
> 
> 2002-08-16 14:53:50 [7] INFO: WSP: Fetched
> 
> (text/vnd.wap.wml, charset='iso-8859-9')
> Entity: line 6: error: Input is not proper UTF-8,
> indicate encoding !
>  ontimer="http://212.65.136.236/TWP
>   ^
> Entity: line 6: error: Bytes: 0xFE 0x67 0x65 0x6C
>  ontimer="http://212.65.136.236/TWP

This is a libxml error; From the libxml src;

/*
 * If we detect an UTF8 error that probably mean that the
 * input encoding didn't get properly advertized in the
 * declaration header. Report the error and switch the encoding
 * to ISO-Latin-1 (if you don't like this policy, just declare the
 * encoding !)
 */

Without trawling the src further, seems like the gateway only accepts
UTF-8 encoding.

RE: MMS Push

[Paul Keogh]

> There is a message in the archives from Aarno Syvänen dated 
> 7th Jan 2002 
> which mentions that WSP must tokenise MMS content types, but this 
> functionality had not been added.  Has this feature been added yet (I 
> have a snapshot of Kannel which is about 2 weeks old)?
> 

No it has'nt, AFAIK. And the intent of the MMS specifications is that MMS should
be transparent to a WAP gateway - ie. the submitting PI/application, should do the
tokenisation rather than the WAP gateway/proxy. That aside, the Kannel
WAP libraries are the best place to start. Look at wap/wsp_header.c to 
see how you should go.

RE: Multiple Kannel BB for HA

[Paul Keogh]

> Has anyone ever deployed multiple BearerBoxes for 
> High-availability purposes ? Do SMS-C usually allow two 
> receivers to bind on the same address range ? How do they 
> handle it usually : distribute load evenly (I'm probably 
> dreaming here).
> Has anyone figured out a good way of doing this ? Maybe with 
> load balancers ?

Yes, we've looked at some architectures for this. As pointed out,
it depends on the SMSC provider and on your position; if you're
just another ESME gateway supplier then you're usually subject to
a retail type of policy, if you're supplying core network technology
in terms of proxy solutions etc., then they're much more flexible.
The SMSC routing algorithm in the BB does have an element of load
sharing but as BBs don't know about each other, you need to get down
to the IP level to share between BBs. A more visionary approach would
be to replace the internal Box comms. with a message queue, thus allowing
a many to many relationship between SMS boxes/clients and BBs. Great
for resilance but don't think it would work for WAP.

RE: Strange kannel behaviour

[Paul Keogh]

> Our Kannel WAP gateway is exhibiting some strange behaviour 
> when visiting
> a few sites.  (Notably wap.ft.com).
> 
> The request gets sent off fine, and Kannel sees an HTTP 302 status
> message, however it never seems to get the headers or the 
> Location header
> and eventually the WAP device just times out.

I've looked specifically at wap.ft.com.

The problem is that the HTTP headers coming back with the 302 indicate
a content length of 10, but there's no body available for reading.
Kannel does'nt treay this as a valid transaction and just returns,
with no indication of an error.

I'll have to put in some HTTP header dumps to confirm the debugger
analysis, but that's what it looks like to me.

RE: SMS bearerboxes hang, how to stop sending an SMS replying "request failed", date format locale

[Paul Keogh]

> 
> The request failed string is hardcoded somewhere the smsbox. 
> (I think in 
> the 1.0.3,
> it's in smsbox_req.c ).

This is now configurable in the current CVS build.

> You should probably upgrade to a newer version. There's been a lot of 
> changes
> and bug fixes since the 1.0.3 version, and nobody really care 
> to apply 
> bugfixes
> to the 1.0.3 version anymore. The cvs version more stable, than you 
> would expect.

For sure. Would'nt dream of using 1.03 anymore.

> As in the year 2028??  Hmm.. Sounds strange.. The 1.0.3 
> version logs the 
> date in GMT, as far as I remember. Is the time correct on the 
> computer 
> kannel is running on?

There may have been a bugfix in this area too. You could check
the Changelog to see.
 

RE: bb_store behaviour (Was: Storage of MT not sent to SMSC (MT queueing on Kannel) ) ?

[Paul Keogh]

> - is it regularly scanned by kannel in order to try to send MO or MT
> (temporary undeliverable) before the next stop/start ?

No. Its only reloaded at the start (and maybe restart).
Retries are the responsibility of the SMSCConn wrapper and
the individual SMSC drivers.

> - the choice of a store file better than a queue directory 
> (like seen with
> SMTP servers like sendmail for example) is it good ? I was 
> wondering if the
> performance and priority managment would not be better with a queue
> directory...

Maybe. But remember its only messages that are unack'd that are
stored. So in production state, the store should be reasonably small.
Directory based needs some overlay hierarchy management to get around
the restrictions of number of files per directory.

> - is it possible to have more information in userguide about 
> the way it
> works (message expiration, format, frequency of message 
> reading and writing)

I'm sure it is. Why don't you add it ?

RE: Storage of MT not sent to SMSC (MT queueing on Kannel) ?

[Paul Keogh]

> I was wondering how MT not sent to SMSC (for any reason like lack of
> connectivity) are stored on Kannel : in RAM or on disk ? As I 
> can't see
> where they could be saved on disk, I supposed they are saved 
> in RAM and they
> are processed later. How does the queueing process work ?
> 
> Thanks in advance for your help.

The current CVS build has a store which if configured stores all
messages in a single file on disk when submitted into the bearerbox
as either MT or MO messages. When the message is successfully transferred 
from the BB to either an SMSC or the SMS Box, an ACK is generated. The
ACK effectively cancels the message in the store.