smltk: DevInf decoding

Some Nokia phones (N900) sent a nor-wellformed DevInf:
The DevInf version was declared as 1.2, while <CTCAP> was not
inside <Datastore>(which is the DevInf 1.1 behaviour). In addition,
the content inside <CTCAP> was in DevInf 1.2 format.

The original approach detects whether this is a DevInf 1.2 or 1.1
by testing whether <CTCAP> was inside <datastore>, thus will think
this is a DevInf 1.1 when decoding the <CTCAP> which fails.

The patch worked around this, when decoding <CTCAP> (precisely the
<Property> or <PropName> inside <CTCAP>), use 1.2 style if we are
decoding <Property> and 1.1 stype when decoding <PropName>

1 files changed, 4 insertions, 1 deletions

diff --git a/src/syncml_tk/src/sml/xlt/all/xltdevinf.c b/src/syncml_tk/src/sml/xlt/all/xltdevinf.c
index b589209..28b2aea 100755
--- a/src/syncml_tk/src/sml/xlt/all/xltdevinf.c
+++ b/src/syncml_tk/src/sml/xlt/all/xltdevinf.c
@@ -812,7 +812,10 @@ Ret_t buildDevInfCtcap(XltDecoderPtr_t pDecoder, VoidPtr_t *ppElem, Boolean_t da
             break;
           case TN_DEVINF_PROPERTY:
             // DS 1.2 case: only </Property> ends the property building process, next token must be read first
-            rc = buildDevInfProperty(pDecoder, (VoidPtr_t)&pCtcap->data->prop,datastoreLocal);
+            // If there is a Property tag, let's take it as DS 1.2 Property Decoding even if the CTCAP is globally
+            // This is found from some Nokia phones (eg. N900, which will send a DevInf v1.2 but the CTCAP
+            // was not inside the datastore as DevInf v1.1)
+            rc = buildDevInfProperty(pDecoder, (VoidPtr_t)&pCtcap->data->prop,TRUE);
             break;
           case TN_DEVINF_PROPNAME:
             // <DS 1.2 case: current token TN_DEVINF_PROPNAME is processed by builder, next occurence of TN_DEVINF_PROPNAME ends property as well