Hi Stipe,
Stipe Tolj wrote:
Hi Tomas,
Tomas Varaneckas wrote:
Hi,
There is obviously something fishy about ota_compiler OMA settings
support. Lines from
http://www.mbuni.org/downloads/1.0.0/mbuni-kannel-patch-full:
+static ota_3table_t oma_ota_attributes[] = {
+ {"version", "1.0", 0x46},
+ {"version", "INLINE", 0x45},
+ {"type", "PXLOGICAL", 0x51},
lines in ota_compiler.c:
static ota_3table_t oma_ota_attributes[] = {
{ "VERSION", "INLINE", 0x45 },
{ "VERSION", "1.0", 0x46 },
differs, eh? that means patch was modified before putting it into CVS.
was it tested afterwards?
now, I have commited Paul's patch with slight changes. Ie. the ordering
of the attributes inside the array. But this has no effect, since the
accessing routines do anyway a linear scan in searching on the values.
I'm new to kannel's architecture, so it's hard for me to see if something
is actually wrong with the code.. However, I've set up kannel 1.4.0, applied
the mbuni patch and got a different dump:
2006-02-04 01:54:56 [4077] [3] DEBUG: data: 01 06 2f 1f 2d b6 91 80 92 34 42
33 43 31 31 31 ../.-....4B3C111
2006-02-04 01:54:56 [4077] [3] DEBUG: data: 42 33 39 44 45 35 39 38 30 33 37
32 30 44 33 44 B39DE59803720D3D
2006-02-04 01:54:56 [4077] [3] DEBUG: data: 44 37 30 37 45 30 38 30 33 36 34
41 36 34 31 46 D707E080364A641F
2006-02-04 01:54:56 [4077] [3] DEBUG: data: 32 00 03 0b 6a 00 c5 46 01 c6 55
01 87 11 06 03 2...j..F..U.....
2006-02-04 01:54:56 [4077] [3] DEBUG: data: 69 6e 65 74 00 01 87 07 06 03 49
6e 74 65 72 6e inet......Intern
2006-02-04 01:54:56 [4077] [3] DEBUG: data: 65 74 4e 41 50 44 45 46 00 01 87
10 06 ab 01 87 etNAPDEF........
2006-02-04 01:54:56 [4077] [3] DEBUG: data: 08 06 03 69 6e 74 65 72 6e 65 74
00 01 87 09 06 ...internet.....
2006-02-04 01:54:56 [4077] [3] DEBUG: data: 89 01 87 14 01 01 c6 00 01 55 01
87 36 06 03 77 .........U..6..w
2006-02-04 01:54:56 [4077] [3] DEBUG: data: 32 00 01 87 00 00 22 06 03 69 6e 65 74
00 01 c6 2....."..inet...
2006-02-04 01:54:56 [4077] [3] DEBUG: data: 00 01 59 01 87 3a 06 03 68 74 74
70 3a 2f 2f 77 ..Y..:..http://w
2006-02-04 01:54:56 [4077] [3] DEBUG: data: 61 70 2e 6b 72 61 6b 2e 64 6b 00
01 87 00 00 1c ap.krak.dk......
2006-02-04 01:54:56 [4077] [3] DEBUG: data: 01 01 01 c6 56 01 87 07 06 03 53
6f 6e 6f 66 6f ....V.....Sonofo
2006-02-04 01:54:56 [4077] [3] DEBUG: data: 6e 20 42 72 6f 77 73 65 72 00 01
01 01 n Browser....
This is closer to Nokia version, attributes are used, no string table generation though..
However, this worked and device got the settings correctly. And the request did not freeze
without response, as it does with latest CVS kannel... I would gladly help
fixing it, but
I'm new to kannel's architecture and not too comfortable with C. Yet, for now I solved my
problems by making a tool which converts XML file to wbxml via libwbxml2 (which does the
conversion well), then cut it to pieces and sending manually message by message (auto
concatenation did not work well, for some reason). Well, this sure is an ugly solution
and I'd be glad to see kannel fixed instead..
the fact is that when i try to send oma settings xml via kannel and
then check the debug dump, i can see that no attributes are used,
wbxml is made with help of inline strings.
Original XML document: (official nokia example)
<?xml version="1.0"?>
<!DOCTYPE wap-provisioningdoc PUBLIC "-//WAPFORUM//DTD PROV 1.0//EN"
“http://www.wapforum.org/DTD/prov.dtd";>
<wap-provisioningdoc version="1.0">
<characteristic type="NAPDEF">
<parm name="NAPID" value="inet"/>
<parm name="NAME" value="InternetNAPDEF"/>
<parm name="BEARER" value="GSM-GPRS"/>
<parm name="NAP-ADDRESS" value="internet"/>
<parm name="NAP-ADDRTYPE" value="APN"/>
<parm name="INTERNET"/>
</characteristic>
<characteristic type="APPLICATION">
<parm name="APPID" value="w2"/>
<parm name="TO-NAPID" value="inet"/>
<characteristic type="RESOURCE">
<parm name="URI" value="http://wap.krak.dk"/>
<parm name="STARTPAGE"/>
</characteristic>
</characteristic>
<characteristic type="BOOTSTRAP">
<parm name="NAME" value="Sonofon Browser"/>
</characteristic>
</wap-provisioningdoc>
The XML document above converted to binary
Nokia given dump without wsp headers (works when sent by hand, not
through kannel's sendota):
030B6A05 696E6574 00C54601 C6550187 ..j. inet ..F. .U..
11068300 01870706 03496E74 65726E65 .... .... .Int erne
744E4150 44454600 01871006 AB018708 tNAP DEF. .... ....
0603696E 7465726E 65740001 87090689 ..in tern et.. ....
01871401 01C60001 55018736 00000603 .... .... U..6 ....
77320001 87220683 0001C600 01590187 w2.. .".. .... .Y..
3A000006 03687474 703A2F2F 7761702E :... .htt p:// wap.
6B72616B 2E646B00 01871C01 0101C656 krak .dk. .... ...V
01870706 03536F6E 6F666F6E 2042726F .... .Son ofon Bro
77736572 00010101
Kannel dump (bleeding edge CVS version):
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 01 06 2f 1f 2d b6 91 81
92 43 37 43 34 42 36 44 ../.-....C7C4B6D
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 44 31 31 34 30 33 30 30
39 44 35 38 45 38 46 33 D11403009D58E8F3
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 44 38 32 33 42 30 30 35
33 36 46 45 32 36 35 39 D823B00536FE2659
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 45 00 03 0b 6a 00 c5 45
03 31 2e 30 00 01 c6 50 E...j..E.1.0...P
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 03 4e 41 50 44 45 46 00
01 87 05 03 4e 41 50 49 .NAPDEF.....NAPI
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 44 00 06 03 69 6e 65 74
00 01 87 05 03 4e 41 4d D...inet.....NAM
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 45 00 06 03 49 6e 74 65
72 6e 65 74 4e 41 50 44 E...InternetNAPD
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 45 46 00 01 87 05 03 42
45 41 52 45 52 00 06 03 EF.....BEARER...
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 47 53 4d 2d 47 50 52 53
00 01 87 05 03 4e 41 50 GSM-GPRS.....NAP
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 2d 41 44 44 52 45 53 53
00 06 03 69 6e 74 65 72 -ADDRESS...inter
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 6e 65 74 00 01 87 05 03
4e 41 50 2d 41 44 44 52 net.....NAP-ADDR
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 54 59 50 45 00 06 03 41
50 4e 00 01 87 05 03 49 TYPE...APN.....I
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 4e 54 45 52 4e 45 54 00
01 01 c6 50 03 41 50 50 NTERNET....P.APP
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 4c 49 43 41 54 49 4f 4e
00 01 87 05 03 41 50 50 LICATION.....APP
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 49 44 00 06 03 77 32 00
01 87 05 03 54 4f 2d 4e ID...w2.....TO-N
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 41 50 49 44 00 06 03 69
6e 65 74 00 01 c6 50 03 APID...inet...P.
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 52 45 53 4f 55 52 43 45
00 01 87 05 03 55 52 49 RESOURCE.....URI
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 00 06 03 68 74 74 70 3a
2f 2f 77 61 70 2e 6b 72 ...http://wap.kr
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 61 6b 2e 64 6b 00 01 87
05 03 53 54 41 52 54 50 ak.dk.....STARTP
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 41 47 45 00 01 01 01 c6
50 03 42 4f 4f 54 53 54 AGE.....P.BOOTST
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 52 41 50 00 01 87 05 03
4e 41 4d 45 00 06 03 53 RAP.....NAME...S
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 6f 6e 6f 66 6f 6e 20 42
72 6f 77 73 65 72 00 01 onofon Browser..
2006-01-31 10:16:09 [8917] [3] DEBUG: data: 01
01 ..
2006-01-31 10:16:09 [8917] [3] DEBUG: Octet string dump ends.
As you can see, nokia dump uses OMA attributes, while kannel simply
puts inline strings. This makes wbxml twice as big, and so far it was
never sent correctly, except for once into one phone (some bogus?).
Can anyone please tell if OMA settings were tested and the feature is
working correctly?
I wonder how you generated this kannel dump, since reviewing
gw/ota_compiler.c:parse_attribute() this should work out with the binary
OMA attributes.
the dump was generated with following request (though, with different sec, but
sec does not influence wbxml itself):
debug level 0, logged in smsbox log
curl
"http://localhost:13013/cgi-bin/sendota?from=SENDER_NUMBER&to=RECIPIENT_NUMBER&username=USER&password=PASS&type=oma-settings&sec=netwpin&pin=%29%64%20%01%10%04%57%58&text=%3C%3Fxml+version%3D%221.0%22%3F%3E%0A%3C%21DOCTYPE+wap-provisioningdoc+PUBLIC+%22-%2F%2FWAPFORUM%2F%2FDTD+PROV+1.0%2F%2FEN%22+%22http%3A%2F%2Fwww.wapforum.org%2FDTD%2Fprov.dtd%22%3E%0A%3Cwap-provisioningdoc+version%3D%221.0%22%3E%0A%3Ccharacteristic+type%3D%22NAPDEF%22%3E%0A%3Cparm+name%3D%22NAPID%22+value%3D%22inet%22%2F%3E%0A%3Cparm+name%3D%22NAME%22+value%3D%22InternetNAPDEF%22%2F%3E%0A%3Cparm+name%3D%22BEARER%22+value%3D%22GSM-GPRS%22%2F%3E%0A%3Cparm+name%3D%22NAP-ADDRESS%22+value%3D%22internet%22%2F%3E%0A%3Cparm+name%3D%22NAP-ADDRTYPE%22+value%3D%22APN%22%2F%3E%0A%3Cparm+name%3D%22INTERNET%22%2F%3E%0A%3C%2Fcharacteristic%3E%0A%3Ccharacteristic+type%3D%22APPLICATION%22%3E%0A%3Cparm+name%3D%22APPID%22+value%3D%22w2%22%2F%3E%0A%3Cparm+name%3D%22TO-NAPID%22+value%3D%22inet%22%2F%3E%0A%3Ccharacteristi
c+type%3D%22RESOURCE%22%3E%0A%3Cparm+name%3D%22URI%22+value%3D%22http%3A%2F%2Fwap.krak.dk%22%2F%3E%0A%3Cparm+name%3D%22STARTPAGE%22%2F%3E%0A%3C%2Fcharacteristic%3E%0A%3C%2Fcharacteristic%3E%0A%3Ccharacteristic+type%3D%22BOOTSTRAP%22%3E%0A%3Cparm+name%3D%22NAME%22+value%3D%22Sonofon+Browser%22%2F%3E%0A%3C%2Fcharacteristic%3E%0A%3C%2Fwap-provisioningdoc%3E"
@Paul: any comments from your side here?
I'll have to try to reproduce this.
Stipe
Best Regards,
Tomas Varaneckas
