Hi Andris, On 21.05.2012, at 15:43, Andris Pavenis wrote:
> Tried to test whether synchronization works with Xperia-S own SyncML client > (comes with Android 2.3.7 installed on phone, software version 6.0.A.3.73) > using custom libsynthesis based SyncML server. > > - the first problem was chunked transport encoding use by phone software > initially not supported by mentioned above server software. It was however > easy enough to fix. > - the next problem is failure of libsynthesis to get authentication > information sent by phone extracted from messages. Also decoded incoming > WBXML messages saved into XML format are corrupt. I found a bug which was causing this, and commited a fix in the luz branch (see https://gitorious.org/libsynthesis). The problem was that the XML encoder in the SyncML toolkit could not handle empty tags, but the SonyEricsson devInf contains a <OEM></OEM> empty tag. So now the XML conversion of the messages you captured from the Xperia-S (aka LT26i) now work ok. However, this does not explain the auth problems. > For unknown reason the client tries to synchronize at first without > authentication even when both user name and password are specified in its > configuration. Authentication is first provided in second attempt of 4 > totally. 3 of 4 incoming WBXML format packets seems to contain authentication > information but also wbxml2xml does not show it I don't see any authentication in the incoming messages, not in the XML translation and also not when looking at hexdumps of the WBXML. The only thing I see is the <LocName> test, but that's not enough for an auth attempt, there must be some credentials. It is valid (or even recommended) for a device to try first without any credentials to see what auth method the server requests. So the first of these attempts is perfectly ok, and the server responds with an authentication challenge for MD5 auth, which is the secure method which does not require user/pw to be transmitted over the line, but only a hash. However, for some reason the LT26i does not respond to that challenge, but retries the "probe" again. One reason for this could be that the device does not actually get the response, but just some transport level error, and thus just resends it's first message serveral times. You said that there was some problem with chunked transport encoding - maybe there's a similar problem in the other direction such that the server result arrives garbled at the phone's end? > [...] > Last tests was done with current GIT version of libsynthesis from master > branch. I recommend using the luz branch for testing - as it is always ahead of master and contains the latest patches before they are in master. Best Regards, Lukas _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
