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?
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?
Thanks,
Tomas Varaneckas
