syncml-http-client problems

[Martin Dittmar]

Hello everyone,

I'm trying to use the opensync syncml-http-client to sync with a Funambol SyncML server.
(SVN Versions: syncml plugin 3207; libsyncml 402)

In a sync process, I get the following error message:

/home/mdi/mobSync/opensync-src2/libsyncml/libsyncml/sml_session.c:1328:E:smlSessionGetSessionID: Assertion "session" failed

So I suppose the client is losing it's connection.

Wireshark tells me, that the client is contacting the server, and the server is responding with "HTTP 200 OK" and the attached SyncML answer.
After that the client seems to lose it's connection and stops.

Do you have any ideas how to fix this?
Is the software currently working? If yes, does it only work with Oracle Groupware by now?

Best regards,
Martin Dittmar, Berlin

Attachment: funambol_answer.xml

[Martin Dittmar]

Hello again,

It seems, the wrong assertion came from code only needed for debug reasons. After removing it, I get an error:

contact sink of member 1 of type syncml-http-client had an error: wrong initial node. expected SyncHdr


But the first node of the answer under the <SyncML> tag is <SyncHdr>. (See attachment of original message)
Is this an incompatibility of the server or a client problem?

Thanks for your help,
Martin

[Michael Bell]

Hi Martin,

I'm on a conference for the next two days. So it can happen that a real
reaction has to wait until wednesday.

Martin Dittmar schrieb:

> I'm trying to use the opensync syncml-http-client to sync with a Funambol
> SyncML server.
> (SVN Versions: syncml plugin 3207; libsyncml 402)

Quite new. that's fine.

> In a sync process, I get the following error message:
>
> /home/mdi/mobSync/opensync-src2/libsyncml/libsyncml/sml_session.c:1328:E:smlSessionGetSessionID:
> Assertion "session" failed

Sounds like a problem with the event management in the syncml plugin.

> Do you have any ideas how to fix this?
> Is the software currently working? If yes, does it only work with Oracle
> Groupware by now?

The software is only tested with OCS until now because I failed with
Funambol. I simply get Funambol not working on my machine :(

I habe no ideas what's going wrong. Can you please enable debugging and
send the traces please? The answer from the Funambol server looks correct.

Best regards

Michael
--
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: [phone]       ZE Computer- und Medienservice
Fax:  [phone]       Unter den Linden 6
michael.bell@...   D-10099 Berlin
_______________________________________________________________

X.509 CA Certificates / Wurzelzertifikate

http://ra.pki.hu-berlin.de


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Martin Dittmar]

Hi Michael,

thanks for your answer.

The logs and configuration can be found here: http://martov.de/sml/syncml-logs.zip (too big to attach)
The source of the sync error is

"smlXmlParserGetHeader: wrong initial node. expected SyncHdr"

although the XML data seems to be fine.

The same error already occurs when trying to discover object types - the
process hangs because of the "expected SyncHdr" error, so to start
synchronizing the syncmember.conf file with matching object types had to be
created by hand.

This problem seems to occur with all funambol servers (local and commercial,
e.g. scheduleworld.com)

Regards, Martin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Michael Bell]

Hi Martin,

Martin Dittmar schrieb:

> It seems, the wrong assertion came from code only needed for debug reasons.
> After removing it, I get an error:

Which debugging code produces this error (file and line of code)?

> contact sink of member 1 of type syncml-http-client had an error: wrong
> initial node. expected SyncHdr
>
> But the first node of the answer under the <SyncML> tag is <SyncHdr>.
> (See attachment of original message)
>
> Is this an incompatibility of the server or a client problem?

This sounds like a client problem.I will test it tomorrow.

Best regards

Michael
--
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: [phone]       ZE Computer- und Medienservice
Fax:  [phone]       Unter den Linden 6
michael.bell@...   D-10099 Berlin
_______________________________________________________________

X.509 CA Certificates / Wurzelzertifikate

http://ra.pki.hu-berlin.de


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Michael Bell]

hi Martin,

Martin Dittmar schrieb:

> "smlXmlParserGetHeader: wrong initial node. expected SyncHdr"
>
> although the XML data seems to be fine.

First thanks a lot for this observation. I attached a patch for a better
error message but I think the problem is RespURI in the SyncML header.

Second which trace statement caused the initial problem. You noticed in
an earlier mail that you commented out a buggy tracement. Where can I
find this statement? Please send the patch or description for this
issue. It is highly important for the code stability to fix all problems
step by step. I know this can take some time ;)

Best regards

Michael
--
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: [phone]       ZE Computer- und Medienservice
Fax:  [phone]       Unter den Linden 6
michael.bell@...   D-10099 Berlin
_______________________________________________________________

X.509 CA Certificates / Wurzelzertifikate

http://ra.pki.hu-berlin.de

Index: sml_xml_parse.c
===================================================================
--- sml_xml_parse.c (revision 403)
+++ sml_xml_parse.c (working copy)
@@ -1676,7 +1676,8 @@
  }
 
  else {
- smlErrorSet(error, SML_ERROR_GENERIC, "wrong initial node. expected SyncHdr");
+ smlErrorSet(error, SML_ERROR_GENERIC, "Element %s not supported for SyncHdr.",
+ (char *)xmlTextReaderConstName(parser->reader));
  goto error_free_header;
  }
  }


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Michael Bell]

Hi Martin,

I completed the XML parser. It does now support RespURI and NoResp. This
does not mean that the library supports RespURI. Perhaps some words
about the core of the problem.

It looks like Funambol uses RespURI to force the client to always send a
special session ID in the URL. If a SyncML peer receives a RespURI in
the header then the new target must be RespURI and I think we must
connect to the new URL - this means we need a new connection inside of a
session!

Reference: OMA-TS-SyncML_RepPro-V1_2_1-20070813-A.pdf page 23

I think this is close to a disaster from the viewpoint of the library
because we must do a connect inside of a session without sending a
connect event because the interface only nows one session.

The other problem is the pure logic behind this because of the transport
layers.

OBEX: If a RespURI is received over OBEX then only the target must be
changed because an URI is not known in terms of OBEX.

HTTP: If a RespURI is received over HTTP then the target and perhaps the
connection URI must be changed. The problem is that the HTTP binding
(OMA-TS-SyncML_RepPro-V1_2_1-20070813-A.pdf) does not say anything about
RespURI.

I personally think that we should update the transport layers. The
advantage is that the RepPro document only talks about messages in the
context of RespURI and not about packages. So we can immediately modify
the transport layer.

I think the best solution would be a new function in the transport layer
interface like SetRespURI with a SmlLocation object. If the function is
not supported then TRUE is returned. If the function is supported then
the call is forwarded. BTW I think we only need this function for HTTP
clients, so the change is minimal.

Any further comments or ideas?

Michael

P.S. I attached the parser patch for testing only.
--
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: [phone]       ZE Computer- und Medienservice
Fax:  [phone]       Unter den Linden 6
michael.bell@...   D-10099 Berlin
_______________________________________________________________

X.509 CA Certificates / Wurzelzertifikate

http://ra.pki.hu-berlin.de

Index: libsyncml/sml_elements_internals.h
===================================================================
--- libsyncml/sml_elements_internals.h (revision 403)
+++ libsyncml/sml_elements_internals.h (working copy)
@@ -65,6 +65,8 @@
  SmlProtocolType protocol;
  SmlLocation *source;
  SmlLocation *target;
+ SmlLocation *respURI;
+ SmlBool noResp;
  unsigned int messageID;
  unsigned int maxmsgsize;
  unsigned int maxobjsize;
Index: libsyncml/sml_elements.c
===================================================================
--- libsyncml/sml_elements.c (revision 404)
+++ libsyncml/sml_elements.c (working copy)
@@ -304,6 +304,9 @@
  if (header->target)
  smlLocationUnref(header->target);
 
+ if (header->respURI)
+ smlLocationUnref(header->respURI);
+
  smlSafeFree((gpointer *)&header);
 
  smlTrace(TRACE_EXIT, "%s", __func__);
Index: libsyncml/parser/sml_xml_parse.c
===================================================================
--- libsyncml/parser/sml_xml_parse.c (revision 403)
+++ libsyncml/parser/sml_xml_parse.c (working copy)
@@ -1654,18 +1654,38 @@
  } else if (!strcmp((char *)xmlTextReaderConstName(parser->reader), SML_ELEMENT_VERPROTO)) {
  if (!_smlSyncHeaderParseProto(&((*header)->protocol), parser, error))
  goto error_free_header;
+ } else if (!strcmp((char *)xmlTextReaderConstName(parser->reader), SML_ELEMENT_SESSIONID)) {
+ if (!_smlXmlParserGetString(parser, &((*header)->sessionID), SML_ELEMENT_SESSIONID, error))
+ goto error_free_header;
  } else if (!strcmp((char *)xmlTextReaderConstName(parser->reader), SML_ELEMENT_MSGID)) {
  if (!_smlXmlParserGetID(parser, &((*header)->messageID), SML_ELEMENT_MSGID, error))
  goto error_free_header;
- } else if (!strcmp((char *)xmlTextReaderConstName(parser->reader), SML_ELEMENT_SESSIONID)) {
- if (!_smlXmlParserGetString(parser, &((*header)->sessionID), SML_ELEMENT_SESSIONID, error))
- goto error_free_header;
  } else if (!strcmp((char *)xmlTextReaderConstName(parser->reader), SML_ELEMENT_TARGET)) {
  if (!_smlLocationParse(&((*header)->target), parser, error))
  goto error_free_header;
  } else if (!strcmp((char *)xmlTextReaderConstName(parser->reader), SML_ELEMENT_SOURCE)) {
  if (!_smlLocationParse(&((*header)->source), parser, error))
  goto error_free_header;
+ } else if (!strcmp((char *)xmlTextReaderConstName(parser->reader), SML_ELEMENT_RESPURI)) {
+ /* Only one RespURI is allowed.
+ * If the header is not correct (more than one RespURI)
+ * then the last RespURI is taken.
+ */
+ if ((*header)->respURI) {
+ smlTrace(TRACE_ERROR, "%s: There is more than on RespURI.", __func__);
+ smlLocationUnref((*header)->respURI);
+ }
+ char *uri = NULL;
+ if (!_smlXmlParserGetString(parser, &uri, SML_ELEMENT_RESPURI, error))
+ goto error_free_header;
+ if (!((*header)->respURI = smlLocationNew(uri, NULL, error))) {
+ smlSafeCFree(&uri);
+ goto error_free_header;
+ }
+ smlSafeCFree(&uri);
+ } else if (!strcmp((char *)xmlTextReaderConstName(parser->reader), SML_ELEMENT_NORESP)) {
+ /* This is an empty element. So the parser must not move one step forward. */
+ (*header)->noResp = TRUE;
  } else if (!strcmp((char *)xmlTextReaderConstName(parser->reader), SML_ELEMENT_META)) {
  if (!_smlMessageParseSynchdrMeta(parser, &((*header)->maxmsgsize), &((*header)->maxobjsize), &((*header)->emi), error))
  goto error_free_header;
@@ -1676,7 +1696,8 @@
  }
 
  else {
- smlErrorSet(error, SML_ERROR_GENERIC, "wrong initial node. expected SyncHdr");
+ smlErrorSet(error, SML_ERROR_GENERIC, "Element %s not supported for SyncHdr.",
+ (char *)xmlTextReaderConstName(parser->reader));
  goto error_free_header;
  }
  }
Index: libsyncml/sml_defines.h
===================================================================
--- libsyncml/sml_defines.h (revision 403)
+++ libsyncml/sml_defines.h (working copy)
@@ -32,6 +32,8 @@
 #define SML_ELEMENT_SOURCE "Source"
 #define SML_ELEMENT_LOCURI "LocURI"
 #define SML_ELEMENT_LOCNAME "LocName"
+#define SML_ELEMENT_RESPURI "RespURI"
+#define SML_ELEMENT_NORESP "NoResp"
 #define SML_ELEMENT_SYNC "Sync"
 #define SML_ELEMENT_STATUS "Status"
 #define SML_ELEMENT_CMDID "CmdID"


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Michael Bell]

Hi Martin,

I fixed the syncml plugin and libsyncml for Funambol. libsyncml can
handle now RespURI in SyncHdr. This is only supported for HTTP clients.
All other plugin modes will crash on RespURI.

The SyncML plugin was fixed too because there was a bug in finalize
(wrong memory pointer handling) and the new more strict disconnect
handling uncovered a mistake for OMA DS clients. Only a new session must
be started after the first session ended. A disconnect is not necessary
and is definitely wrong.

I tested with Funambol and OCS. Both work now. The SVN revision are like
follows:

libsyncml rev 412
syncml plugin rev 3218

Best regards

Michael
--
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: [phone]       ZE Computer- und Medienservice
Fax:  [phone]       Unter den Linden 6
michael.bell@...   D-10099 Berlin
_______________________________________________________________

X.509 CA Certificates / Wurzelzertifikate

http://ra.pki.hu-berlin.de


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Michael Banck-3]

On Wed, Mar 12, 2008 at 06:00:30PM +0100, Michael Bell wrote:
> I tested with Funambol and OCS. Both work now.

Whoa, great work!


Michael

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Martin Dittmar]

Hi Michael,
> I tested with Funambol and OCS. Both work now.
Thank you a lot for helping so quickly!

Still there is some issue with Funambol:

Funambol version 6.5 returns while/after synchronisation an error 408
(Timeout). The Funambol 6.5 changelog writes:
* Improved session handling: if the server receives a request for an
already expired session, the HTTP status code 408 (request timeout) is
 returned

In fact, this problem occurs when opensync is trying to connect the 2nd
time ("sent4.xml") to really synchronize data. At this time, the session
of the first run is closed on the server. So, in the syncml XML data,
the jSessionID of the old session is *not* given in LocURI (which is
expected). But wireshark shows that the jSessionID is given in the URL
while connecting to funambol (which is  propably not the right behavior)

I suppose, Funambol has been a bit more tolerant in version 5 (which is
used by scheduleworld com) and just ignored the (wrong) sessionID, which
now leads to an error.

The complete logs can be found here: http://martov.de/sml/funambol-logs.zip


> You noticed in an earlier mail that you commented out a buggy
> tracement. Where can I find this statement?

The assertion I commented out was "smlAssert(session);" in the function
"smlSessionGetSessionID"  (libsyncml/sml_session.c line 1332 in current
svn version). After that, I saw the right error message ("SyncHdr...").
I don't really understand why this assertion could hide the right error
message... At least it doesn't seem wrong at this place.

Regards, Martin


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Michael Bell]

Martin Dittmar schrieb:

> Hi Michael,
>> I tested with Funambol and OCS. Both work now.
> Thank you a lot for helping so quickly!
>
> Still there is some issue with Funambol:
>
> Funambol version 6.5 returns while/after synchronisation an error 408
> (Timeout). The Funambol 6.5 changelog writes:
> * Improved session handling: if the server receives a request for an
> already expired session, the HTTP status code 408 (request timeout) is
>  returned

Funambol 6.5 works now but only with SyncML 1.2. There is a bug in their
devinf parsing code which causes crashs on SyncML 1.1 devinf with more
than one datastore.

Best regards

Michael
--
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: [phone]       ZE Computer- und Medienservice
Fax:  [phone]       Unter den Linden 6
michael.bell@...   D-10099 Berlin
_______________________________________________________________

X.509 CA Certificates / Wurzelzertifikate

http://ra.pki.hu-berlin.de


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel