7:25 a.m.
Hi all,
I'm trying to sync my HTC Desire Z to my laptop running Ubuntu. On my
phone I use Funambol Android Sync Client ver 10.0.6. My laptop is
running latest version of syncevolution:
justas@Zaibukas:/$ syncevolution --version
SyncEvolution 1.1.99.6
using libedataserver-1.2.so.14
using libebook-1.2.so.10
using libecal-1.2.so.8
using libecal-1.2.so.8 - might not be compatible!
using libbluetooth.so.3
Loading backend library /usr/lib/syncevolution/backends/syncsqlite.so
Loading backend library /usr/lib/syncevolution/backends/syncecal.so
Loading backend library /usr/lib/syncevolution/backends/syncdav.so
Loading backend library /usr/lib/syncevolution/backends/syncfile.so
Loading backend library /usr/lib/syncevolution/backends/syncakonadi.so
Loading backend
library /usr/lib/syncevolution/backends/syncqtcontacts.so
Loading backend
library /usr/lib/syncevolution/backends/syncaddressbook.so
Loading backend
library /usr/lib/syncevolution/backends/synckcalextended.so
Loading backend library /usr/lib/syncevolution/backends/syncebook.so
Loading backend library /usr/lib/syncevolution/backends/syncxmlrpc.so
Loading backend library /usr/lib/syncevolution/backends/syncmaemocal.so
When I sync via http server I get this output:
[INFO] syncevo-http: new SyncML session for 192.168.2.141
[INFO] sync: matched deviceID fac-352212045389751 against config jphtc
(/home/justas/.config/syncevolution/default/peers/jphtc)
<snip>
[INFO] sync: addressbook: starting first time sync, two-way
[INFO] sync: Local data changes to be applied during synchronization:
[INFO] sync: *** addressbook ***
[INFO] sync: no changes
[INFO] sync:
[INFO] sync: addressbook: started
[INFO] sync: addressbook: first time sync done unsuccessfully
[ERROR] sync: SML (or SAN) error processing incoming message (local,
status 20007)
<snip>
[INFO] sync: First ERROR encountered: SML (or SAN) error processing
incoming
message (local, status 20007)
[INFO] sync:
Data modified locally during synchronization:
[INFO] sync: *** addressbook ***
[INFO] sync: no changes
evolution-log.html is not very helpful as well:
<snip>
[2011-09-11 21:59:57.208] addressbook: started
[2011-09-11 21:59:57.209] ===> smlProcessData failed, returned 0x200B
–
[2011-09-11 21:59:57.209] 'SessionAbort' - Aborting Session,
Status=20007,
</snip>
Any ideas why sync is not working? I can see the syncevolution access my
addressbook without problems, but I can't sync contacts from my phone.
Thanks,
jP
4:07 p.m.
On So, 2011-09-11 at 22:25 +0100, Justas Poderys wrote:
When I sync via http server I get this output:
[INFO] syncevo-http: new SyncML session for 192.168.2.141
[INFO] sync: matched deviceID fac-352212045389751 against config jphtc
(/home/justas/.config/syncevolution/default/peers/jphtc)
<snip>
So this is not the first sync attempt, is it? It must have worked before
to get the device ID and create a corresponding config.
[INFO] sync: addressbook: starting first time sync, two-way
[INFO] sync: Local data changes to be applied during synchronization:
[INFO] sync: *** addressbook ***
[INFO] sync: no changes
[INFO] sync:
[INFO] sync: addressbook: started
[INFO] sync: addressbook: first time sync done unsuccessfully
[ERROR] sync: SML (or SAN) error processing incoming message (local,
status 20007)
<snip>
Looks like the Funambol Android client is sending a malformed message.
There were reports like that a while back; I think the answer in the
Funambol forums at that time was that it was only tested with the
Funambol server.
Can you increase the loglevel to 5
in /home/justas/.config/syncevolution/default/peers/jphtc/config.ini and
try again?
The resulting log will have message dumps of the raw and translated
messages, that may help with debugging. Send them to me and I can have a
look.
evolution-log.html is not very helpful as well:
<snip>
[2011-09-11 21:59:57.208] addressbook: started
[2011-09-11 21:59:57.209] ===> smlProcessData failed, returned 0x200B
–
It's a parser error deep down in the SyncML Toolkit.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
6:36 p.m.
On Mon, 2011-09-12 at 08:07 +0200, Patrick Ohly wrote:
On So, 2011-09-11 at 22:25 +0100, Justas Poderys wrote:
> When I sync via http server I get this output:
>
> [INFO] syncevo-http: new SyncML session for 192.168.2.141
> [INFO] sync: matched deviceID fac-352212045389751 against config jphtc
> (/home/justas/.config/syncevolution/default/peers/jphtc)
> <snip>
So this is not the first sync attempt, is it? It must have worked before
to get the device ID and create a corresponding config.
Yes, I have configured my http server using
http://syncevolution.org/wiki/http-server-howto and i can log in from
Android Funambol client. Problems start when I try su sync.
> [INFO] sync: addressbook: starting first time sync, two-way
> [INFO] sync: Local data changes to be applied during synchronization:
> [INFO] sync: *** addressbook ***
> [INFO] sync: no changes
> [INFO] sync:
> [INFO] sync: addressbook: started
> [INFO] sync: addressbook: first time sync done unsuccessfully
> [ERROR] sync: SML (or SAN) error processing incoming message (local,
> status 20007)
> <snip>
Looks like the Funambol Android client is sending a malformed message.
There were reports like that a while back; I think the answer in the
Funambol forums at that time was that it was only tested with the
Funambol server.
Can you increase the loglevel to 5
in /home/justas/.config/syncevolution/default/peers/jphtc/config.ini and
try again?
I have emailed full trace gziped to your email.
6:49 p.m.
On Mo, 2011-09-12 at 09:36 +0100, Justas Poderys wrote:
On Mon, 2011-09-12 at 08:07 +0200, Patrick Ohly wrote:
> On So, 2011-09-11 at 22:25 +0100, Justas Poderys wrote:
> Looks like the Funambol Android client is sending a malformed message.
> There were reports like that a while back; I think the answer in the
> Funambol forums at that time was that it was only tested with the
> Funambol server.
>
> Can you increase the loglevel to 5
> in /home/justas/.config/syncevolution/default/peers/jphtc/config.ini and
> try again?
I have emailed full trace gziped to your email.
Sorry, I should have been more explicit: I need the full directory, in
particular the syncevolution-log_msg003_006_incoming.xml message dump.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
9:48 p.m.
On Mo, 2011-09-12 at 09:36 +0100, Justas Poderys wrote:
On Mon, 2011-09-12 at 08:07 +0200, Patrick Ohly wrote:
> On So, 2011-09-11 at 22:25 +0100, Justas Poderys wrote:
> > When I sync via http server I get this output:
> >
> > [INFO] syncevo-http: new SyncML session for 192.168.2.141
> > [INFO] sync: matched deviceID fac-352212045389751 against config jphtc
> > (/home/justas/.config/syncevolution/default/peers/jphtc)
> > <snip>
>
> So this is not the first sync attempt, is it? It must have worked before
> to get the device ID and create a corresponding config.
Yes, I have configured my http server using
http://syncevolution.org/wiki/http-server-howto and i can log in from
Android Funambol client. Problems start when I try su sync.
Sorry, didn't have time to look at your log file and message dump
earlier.
There's one thing which is peculiar at the time when the parsing error
occurs:
<Replace>
<CmdID>5</CmdID>
<Item>
<Source>
<LocURI>1587</LocURI>
</Source>
<Meta>
<Type xmlns="syncml:metinf">text/x-vcard</Type>
</Meta>
<Data>...
</Data>
</Item>
<Item>
<Source>
<LocURI>1588</LocURI>
</Source>
<Meta>
<Type xmlns="syncml:metinf">text/x-vcard</Type>
</Meta>
<Data>...
</Data>
</Item>
<Item>
<Source>
<LocURI>1589</LocURI>
</Source>
<Meta>
...
There is more than one item in the <Replace> command. This is okay, OMA
DS 1.2 DataRep explicitly mentions that Replace must contain "one *or
more*" Items. I just wonder whether libsmltk already supports that. Hmm,
yes, it does. So that's not it.
The actual error that it reports is "smlProcessData failed, returned
0x200B" = SML_ERR_XLT_INVAL_SYNCML_DOC = "Document does not conform to
SyncML DTD". Unfortunately it doesn't say where.
Probably I should try to reproduce it life. Unfortunately I don't know
when I'll have the time.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
10:14 p.m.
Patrick Ohly wrote:
On Mo, 2011-09-12 at 09:36 +0100, Justas Poderys wrote:
> On Mon, 2011-09-12 at 08:07 +0200, Patrick Ohly wrote:
>> On So, 2011-09-11 at 22:25 +0100, Justas Poderys wrote:
>> Looks like the Funambol Android client is sending a malformed message.
>> There were reports like that a while back; I think the answer in the
>> Funambol forums at that time was that it was only tested with the
>> Funambol server.
>>
>> Can you increase the loglevel to 5
>> in /home/justas/.config/syncevolution/default/peers/jphtc/config.ini and
>> try again?
>
> I have emailed full trace gziped to your email.
Sorry, I should have been more explicit: I need the full directory, in
particular the syncevolution-log_msg003_006_incoming.xml message dump.
Hi Patrick!
I had the same problem a while ago but stopped investigating because my
time is very limited right now.
What I found was that the incoming message 003_006 (mine was numbered
the same) contained a full copy of the previous message. That was
surprisingly close to the 64k maxMsgSize I had set IIRC. After that
followed another <SyncML> tag starting the next message. However, the
XML was declared (even by the browser) as not well-formed (or not
valid?) because of the repeated top-level tag. Looked to me a bit like
the message buffer had not been cleared after reaching the maximum
message size.
Dunno whether it's a client or server issue. I was using SyncEvolution
1.1.99.5a from Debian unstable and the Android Funambol client 10.0.6. I
could not find that specific log directory just now, but I'll try to
reproduce it next week or so and send you the log directory for
additional reference.
Regards,
André
--
Greetings...
From: Andre Colomb <acolomb(a)schickhardt.org>
10:48 p.m.
On Do, 2011-09-15 at 14:14 +0200, Andre Colomb wrote:
What I found was that the incoming message 003_006 (mine was
numbered
the same) contained a full copy of the previous message. That was
surprisingly close to the 64k maxMsgSize I had set IIRC. After that
followed another <SyncML> tag starting the next message. However, the
XML was declared (even by the browser) as not well-formed (or not
valid?) because of the repeated top-level tag. Looked to me a bit like
the message buffer had not been cleared after reaching the maximum
message size.
I see the same issue, but I discarded it as an artifact of how the
buffer handling internally works: the response message is appended at
the end of incoming messages. It could be that dumping the buffer in an
error case dumps everything because it doesn't know the right length.
Supporting that interpretation is the fact that the Synthesis engine
never sees the <Replace> command. The XML seems well-formed to me until
the end of that and I would expect the libsmltk to report that before
moving on.
It would be useful to verify that it isn't the client sending the
message like that by looking at a Wireshark trace.
Dunno whether it's a client or server issue. I was using
SyncEvolution
1.1.99.5a from Debian unstable and the Android Funambol client 10.0.6. I
could not find that specific log directory just now, but I'll try to
reproduce it next week or so and send you the log directory for
additional reference.
I don't think it would help much. You could do the Wireshark thing, or,
if you are really ambitious, single-step through buildGenericCmd() in
xltdec.c while it processes the offending <Sync><Replace> part. That
should eventually bomb out somewhere with the
SML_ERR_XLT_INVAL_SYNCML_DOC error.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
11:58 p.m.
On Sep 15, 2011, at 14:48 , Patrick Ohly wrote:
I don't think it would help much. You could do the Wireshark
thing, or,
if you are really ambitious, single-step through buildGenericCmd() in
xltdec.c while it processes the offending <Sync><Replace> part. That
should eventually bomb out somewhere with the
SML_ERR_XLT_INVAL_SYNCML_DOC error.
I built some debug printing into the SMLTK a long time ago, however the problem is that
there was no easy way to pass a debug logger handle down into the C-only toolkit to
actually output it. And because just printing it on the console was no option for a shared
library, the corresponding output macro SMLERRPRINTFX() is doing nothing.
To debug a specific case however, you might want to temporarily define that macro, for
example just map it to printf(), in src/syncml_tk/src/sml/xlt/all/xltdec.c:
#define SMLERRPRINTFX(lvl,m) printf m
If you have access to the stdout produced while the sync runs, you'll get much useful
information in case of a decoding error, including some context dump of the text being
parsed, clear text error message and the routine name that caused the error.
Patrick, maybe there is a better way in SyncEvolution context than just printf() that
could be made into a log option for debugging decoding problems?
Best Regards,
Lukas
Lukas Zeller, plan44.ch
luz(a)plan44.ch - www.plan44.ch
4021
days inactive
4025
days old
syncevolution@synevolution.org
7 comments
4 participants
participants (4)
-
Andre Colomb -
Justas Poderys -
Lukas Zeller -
Patrick Ohly