Menu
▾
▴
opensync-users — The place to get help for the OpenSync project
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(10) |
Apr
(30) |
May
(11) |
Jun
(8) |
Jul
(28) |
Aug
(113) |
Sep
(74) |
Oct
(43) |
Nov
(111) |
Dec
(31) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(70) |
Feb
(78) |
Mar
(110) |
Apr
(99) |
May
(106) |
Jun
(128) |
Jul
(65) |
Aug
(123) |
Sep
(80) |
Oct
(128) |
Nov
(80) |
Dec
(54) |
| 2007 |
Jan
(89) |
Feb
(83) |
Mar
(56) |
Apr
(56) |
May
(69) |
Jun
(29) |
Jul
(89) |
Aug
(44) |
Sep
(32) |
Oct
(114) |
Nov
(36) |
Dec
(46) |
| 2008 |
Jan
(88) |
Feb
(100) |
Mar
(63) |
Apr
(27) |
May
(39) |
Jun
(61) |
Jul
(35) |
Aug
(11) |
Sep
(9) |
Oct
(19) |
Nov
(28) |
Dec
(72) |
| 2009 |
Jan
(33) |
Feb
(4) |
Mar
(15) |
Apr
(24) |
May
(17) |
Jun
(17) |
Jul
(11) |
Aug
(30) |
Sep
(19) |
Oct
(8) |
Nov
(10) |
Dec
(5) |
| 2010 |
Jan
(5) |
Feb
(10) |
Mar
(12) |
Apr
(1) |
May
(8) |
Jun
(4) |
Jul
(9) |
Aug
(29) |
Sep
(6) |
Oct
(19) |
Nov
(4) |
Dec
(3) |
| 2011 |
Jan
(9) |
Feb
|
Mar
|
Apr
(7) |
May
(2) |
Jun
(9) |
Jul
(3) |
Aug
(2) |
Sep
|
Oct
|
Nov
(7) |
Dec
|
| 2012 |
Jan
(2) |
Feb
(5) |
Mar
(5) |
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(9) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
|
From: Michael B. <mic...@cm...> - 2009-08-19 14:08:15
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ulrich, I read your ticket and libsyncml sends a message to your mobile. You can find it in Thread3079403264-4972.log of ticket #246. Ulrich Brammer wrote: > <LocURI>AT$CGSN > XXXXXX 01 XXXXXX 0</LocURI> I have no idea what this is. > <Cred> > <Meta> > <Format xmlns="syncml:metinf">b64</Format> > <Type xmlns="syncml:metinf">syncml:auth-basic</Type> > </Meta> > <Data>c2N0czpzY3Rz</Data> > </Cred> The OMA DS server authenticates itself to the mobile. Usually the scheme is that the client authenticates to the server. BTW Data is a clear text passphrase. The other stuff looks quite normal. So there are two issues to clarify: 1. Which AT command is used as source? 2. Why does the server authenticates to the client? Best regards Michael - -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqMB3YACgkQ2L0ZGCAwWqti+wCglJ1yAffmgM36iljT+n8NC1wQ IKUAnj+fB/izaaqmEQ7eMUtCC8KX1Tx4 =H5DE -----END PGP SIGNATURE----- |
|
From: Ulrich B. <ubr...@t-...> - 2009-08-19 13:22:00
|
Am Montag, den 10.08.2009, 11:47 +0200 schrieb Michael Bell: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ulrich Brammer wrote: > > I compiled libsyncml from svn libsyncml 0.5.x branch on a Debian Lenny > > system. I tested it with syncml-ds-tool with my Samsung SGH E250i > > mobile. I got the following error message: > > ** Message: ERROR: An internal I/O error occured. Unknown response > > (0x46) > > > > I made traces, see https://libsyncml.opensync.org/ticket/246 > > > > I do not have any knowledge about syncml and do not know how to debug > > further. Is there someone to help? > > Samsung uses 5 different SyncML stacks and no one is fully standard > compliant. So there are two questions. First does your mobile really > supports SyncML? Second which implementation is used? Here is a good > impression: > > http://www.traud.de/gsm/samsung.htm > > Best regards > > Michael I looked into the details of the problem to sync with a Samsung SGH E250: The phone understands the AT+CPROT=0 and answers with the message CONNECT. The phone also respond to the obex connect command. The problem is: syncml-ds-tool does not send a initialization package which contains the target and sourceURI and the authentification. So the commandline arguments to provide these information are not usable in this case. I analyzed the initialization package from the windows software with the wbxml2xml tool. This is the xml-version of the initialization packet: <?xml version="1.0"?> <!DOCTYPE SyncML PUBLIC "-//SYNCML//DTD SyncML 1.1//EN" "http://www.syncml.org/docs/syncml_represent_v11_20020213.dtd"> <SyncML xmlns="SYNCML:SYNCML1.1"> <SyncHdr> <VerDTD>1.1</VerDTD> <VerProto>SyncML/1.1</VerProto> <SessionID>0</SessionID> <MsgID>1</MsgID> <Target> <LocURI>AT$CGSN XXXXXX 01 XXXXXX 0</LocURI> </Target> <Source> <LocURI>Teleca Desktop Synchronisation Server</LocURI> </Source> <Cred> <Meta> <Format xmlns="syncml:metinf">b64</Format> <Type xmlns="syncml:metinf">syncml:auth-basic</Type> </Meta> <Data>c2N0czpzY3Rz</Data> </Cred> </SyncHdr> <SyncBody> <Alert> <CmdID>0</CmdID> <Data>206</Data> <Item> <Target> <LocURI>CONTACTS</LocURI> </Target> <Source> <LocURI>CONTACTS</LocURI> </Source> <Meta> <Type xmlns="syncml:metinf">text/x-vcard</Type> </Meta> </Item> </Alert> <Final/> </SyncBody> </SyncML> The phone answers after a obex get command containing "application/vnd.syncml+wbxml" with: <?xml version="1.0"?> <!DOCTYPE SyncML PUBLIC "-//SYNCML//DTD SyncML 1.1//EN" "http://www.syncml.org/docs/syncml_represent_v11_20020213.dtd"> <SyncML xmlns="SYNCML:SYNCML1.1"> <SyncHdr> <VerDTD>1.1</VerDTD> <VerProto>SyncML/1.1</VerProto> <SessionID>0</SessionID> <MsgID>1</MsgID> <Target> <LocURI>Teleca Desktop Synchronisation Server</LocURI> </Target> <Source> <LocURI>XXXXXX 01 XXXXXX 0</LocURI> <LocName/> </Source> <Meta> <MaxMsgSize xmlns="syncml:metinf">3100</MaxMsgSize> </Meta> </SyncHdr> <SyncBody> <Status> <CmdID>1</CmdID> <MsgRef>1</MsgRef> <CmdRef>0</CmdRef> <Cmd>SyncHdr</Cmd> <TargetRef>AT$CGSN XXXXXX 01 XXXXXX 0</TargetRef> <SourceRef>Teleca Desktop Synchronisation Server</SourceRef> <Data>200</Data> </Status> <Status> <CmdID>2</CmdID> <MsgRef>1</MsgRef> <CmdRef>0</CmdRef> <Cmd>Alert</Cmd> <Data>200</Data> </Status> <Put> <CmdID>3</CmdID> <Meta> <Type xmlns="syncml:metinf">application/vnd.syncml-devinf+xml</Type> </Meta> <Item> <Source> <LocURI>./devinf11</LocURI> </Source> <Data> <DevInf xmlns="syncml:devinf"> <VerDTD>1.1</VerDTD> <Man>Teleca Software Solutions AB</Man> <Mod>Teleca SyncML Client</Mod> <OEM>Teleca Software Solutions AB</OEM> <FwV>1.0</FwV> <SwV>1.0</SwV> <HwV>1.0</HwV> <DevID>XXXXXX 01 XXXXXX 0</DevID> <DevTyp>smartphone</DevTyp> <SupportNumberOfChanges/> <SupportLargeObjs/> <DataStore> <SourceRef>CONTACTS</SourceRef> <MaxGUIDSize>40</MaxGUIDSize> <Rx-Pref> <CTType>text/x-vcard</CTType> <VerCT>2.1</VerCT> </Rx-Pref> <Tx-Pref> <CTType>text/x-vcard</CTType> <VerCT>2.1</VerCT> </Tx-Pref> <DSMem> <MaxMem>0</MaxMem> <MaxID>1000</MaxID> </DSMem> <SyncCap> <SyncType>1</SyncType> <SyncType>2</SyncType> <SyncType>7</SyncType> </SyncCap> </DataStore> <CTCap> <CTType>text/x-vcard</CTType> <PropName>BEGIN</PropName> <ValEnum>VCARD</ValEnum> <PropName>VERSION</PropName> <ValEnum>2.1</ValEnum> <PropName>N</PropName> <PropName>TEL</PropName> <ParamName>WORK</ParamName> <ParamName>HOME</ParamName> <ParamName>CELL</ParamName> <ParamName>FAX</ParamName> <ParamName>PAGER</ParamName> <ParamName>PREF</ParamName> <PropName>EMAIL</PropName> <PropName>NOTE</PropName> <PropName>END</PropName> <ValEnum>VCARD</ValEnum> </CTCap> </DevInf> </Data> </Item> </Put> <Alert> <CmdID>4</CmdID> <Data>200</Data> <Item> <Target> <LocURI>CONTACTS</LocURI> </Target> <Source> <LocURI>CONTACTS</LocURI> </Source> <Meta> <Anchor xmlns="syncml:metinf"> <Last>1</Last> <Next>2</Next> </Anchor> <MaxObjSize xmlns="syncml:metinf">3000</MaxObjSize> </Meta> </Item> </Alert> <Final/> </SyncBody> </SyncML> Best regards Ulrich |
|
From: Tyson W. <twh...@gm...> - 2009-08-14 14:35:24
|
On August 12, 2009 04:17:19 Michael Bell wrote: > To be fair - I never saw such a behaviour from a Nokia mobile ever > before. Did you use a broken libwbxml version some time before? Perhaps > it helps to remove all cached DevInf stuff from the mobile. > > Please see here for more details: > > https://libsyncml.opensync.org/wiki/docs/trunk/HowToRecoverNokiaS40 Hi Michael, Thanks for all the work you've done looking into this. I checked the predefsyncml directory tree, and it didn't have any devinfo files in it. Nonetheless, I deleted the entire tree to make sure. I then installed the Nokia PC Suite under Windows and synced with the phone. It worked fine. Unfortunately, I still gives me the same "Unknown CTCapType for Property: ParamName" error and sent-0.xml shows "SyncML/1.1" while received-0.xml shows "SyncML/1.2" while trying to use syncml-ds-tool. I also looked into upgrading the firmware. However, it seems that the 2760 is not supported by Nokia's upgrade software because it only supports a bluetooth data connection and not a USB one. Cheers! -Tyson |
|
From: Tyson W. <twh...@gm...> - 2009-08-12 14:34:56
|
On August 12, 2009 04:17:19 Michael Bell wrote: > I checked the traces. The server alerted notification is a SyncML 1.1 > message but the phone answers with a SyncML 1.2 message. > > sent-0.xml => SyncML/1.1 > received-0.xml => SyncML/1.2 > > To be fair - I never saw such a behaviour from a Nokia mobile ever > before. Did you use a broken libwbxml version some time before? Perhaps > it helps to remove all cached DevInf stuff from the mobile. > > Please see here for more details: > > https://libsyncml.opensync.org/wiki/docs/trunk/HowToRecoverNokiaS40 I may have. I started with whatever version was packaged with Debian. I'll see what I can do with resetting the phone and let you know how it goes Thanks again! -Tyson |
|
From: Michael B. <mic...@cm...> - 2009-08-12 08:16:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tyson Whitehead wrote: > > I tried again with with the --version 1.1 flag (isn't this the default -- or > at least that is what --help says) and got the same thing > > $ syncml-ds-tool --version 1.1 -b xx:xx:xx:xx:xx:xx yy --wbxml \ > --identifier "PC Suite" --sync text/x-vcard Contacts > ** Message: Remote device was successfully connected. > ** Message: ERROR: Unknown CTCapType for Property: ParamName > > I'll attach the logs in case there is anything different. I checked the traces. The server alerted notification is a SyncML 1.1 message but the phone answers with a SyncML 1.2 message. sent-0.xml => SyncML/1.1 received-0.xml => SyncML/1.2 To be fair - I never saw such a behaviour from a Nokia mobile ever before. Did you use a broken libwbxml version some time before? Perhaps it helps to remove all cached DevInf stuff from the mobile. Please see here for more details: https://libsyncml.opensync.org/wiki/docs/trunk/HowToRecoverNokiaS40 Best regards Michael - -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqCeosACgkQ2L0ZGCAwWqumvgCfRjC4eT4Mvqld99MNp5NS7Rsg BzAAniDWLluz9h0JawhZiOn3YztVuXvr =+XC7 -----END PGP SIGNATURE----- |
|
From: Michael B. <mic...@cm...> - 2009-08-11 16:10:43
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tyson,
I checked the specs and libwbxml. It looks like a bug in the phone. If I
try to sync my Nokia 6300 with SyncML 1.2 then it fails too. Please try
SyncML 1.1 with your phone.
The traces (via private mail) show a buggy SyncML 1.2 DevInf. the phone
embeds ParamName directly into the Property element:
<Property>
<PropName>PRIORITY</PropName>
<ParamName>1</ParamName>
<ParamName>2</ParamName>
<ParamName>3</ParamName>
</Property>
Perhaps the phone has a wrong WBXML lookup table. ParamName is 0x17 and
ValEnum is 0x23. Your firmware is quite old - 12-07-07. My 6300 has a
firmware from 19-08-08.
My mobile directly aborts after the SAN. This means my mobile does not
accept SyncML 1.2 at all.
Best regards
Michael
P.S. syncml-ds-tool has an option to configure the protocol version.
- --
___________________________________________________________________
Michael Bell Humboldt-Universitaet zu Berlin
Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice
Fax: +49 (0)30-2093 2704 Unter den Linden 6
mic...@cm... D-10099 Berlin
___________________________________________________________________
PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkqBmCsACgkQ2L0ZGCAwWqsssACgwwxtCgDpX95I0AtWm4HDnLR7
atMAnRVlg0fNEzBmkXVXRFWugHNFmZru
=L57Z
-----END PGP SIGNATURE-----
|
|
From: Juha T. <Juh...@ik...> - 2009-08-10 18:56:23
|
On Monday 10 August 2009 17:33:49 Pawel Kot wrote: > Good source of knowledge about Nokia OS is > http://www.forum.nokia.com/devices/matrix_all_1.html It's usually up to date how about putting such information into wiki? based on amount spam and extra work cleaning it up, there must be a justification to have it open to anyone to edit, right? Tuju -- Better to have one, and not need it, than to need one and not have it. |
|
From: Michael B. <mic...@cm...> - 2009-08-10 15:17:54
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tyson Whitehead wrote: > On August 10, 2009 05:32:49 Michael Bell wrote: >> This looks like a bug. ParamName is not a property and usually the >> Nokias work because I test with them. I will test it with my mobiles. >> >> BTW has your Nokia a S60 or S40 OS? > > My google understanding is that the 2760 is a S40 5th Edition LE. I'm pretty > sure this is correct as I found several different sights that said it was a > S40, and I didn't find any that claimed otherwise. I tested the trunk with my 6300(i) and it works without any problems. So I am really interested in your traces. Warning: If you are not sure if your traces contain private data then don't send them via mailing list or ticket system. Best regards Michael - -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqAOkAACgkQ2L0ZGCAwWqtHygCgu7yzfjRGgBdHLyZ8dv26UT0p 1pkAoKI4bxI080ZvELxP+B22crwHOx0O =ltbL -----END PGP SIGNATURE----- |
|
From: Pawel K. <paw...@gm...> - 2009-08-10 14:35:35
|
Hi, On Mon, Aug 10, 2009 at 16:17, Tyson Whitehead <twh...@gm...> wrote: > My google understanding is that the 2760 is a S40 5th Edition LE. I'm > pretty > sure this is correct as I found several different sights that said it was a > S40, and I didn't find any that claimed otherwise. > Good source of knowledge about Nokia OS is http://www.forum.nokia.com/devices/matrix_all_1.html It's usually up to date ;) take care, -- Pawel Kot |
|
From: Pawel K. <paw...@gm...> - 2009-08-10 14:34:20
|
Hi, On Mon, Aug 10, 2009 at 16:17, Tyson Whitehead <twh...@gm...> wrote: > My google understanding is that the 2760 is a S40 5th Edition LE. I'm > pretty > sure this is correct as I found several different sights that said it was a > S40, and I didn't find any that claimed otherwise. > Good source of knowledge about Nokia OS is http://www.forum.nokia.com/devices/matrix_all_1.html It's usually up to date ;) take care, -- Pawel Kot |
|
From: Tyson W. <twh...@gm...> - 2009-08-10 14:17:51
|
On August 10, 2009 05:32:49 Michael Bell wrote: > This looks like a bug. ParamName is not a property and usually the > Nokias work because I test with them. I will test it with my mobiles. > > BTW has your Nokia a S60 or S40 OS? Hi Michael, Thanks very much for the quick follow up! : ) My google understanding is that the 2760 is a S40 5th Edition LE. I'm pretty sure this is correct as I found several different sights that said it was a S40, and I didn't find any that claimed otherwise. I'll recompile the latest trunk again tonight and get you a trace. Cheers! -Tyson |
|
From: Michael B. <mic...@cm...> - 2009-08-10 10:07:00
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tyson Whitehead wrote: > Hi, > > I decided to give the trunk syncml-ds-tool and wbxml a try despite the > session_transmit test failing. I get the same problems I get with the lastest > Debian packages (which are version 0.5.3 of libsyncml and 0.10.6 of wbxml). > > $ syncml-ds-tool -b xx:xx:xx:xx:xx:xx yy --wbxml --identifier "PC Suite" -- > sync text/x-vcard Contacts > ** Message: Remote device was successfully connected. > ** Message: ERROR: Unknown CTCapType for Property: ParamName I read the specs and the result does not help a lot. A Property of a CTCap can have parameters which are called PropParam. A PropParam can have parameter name ParamName. The error message means that ParamName element was detected inside of a Property element which is wrong because the PropParam element is missing. Perhaps there is a confusion about the used protocol versions between the mobile and libsyncml. Can you please create traces with the fixes in the SVN repository? (I already fixed the wrong trace statements.) Best regards Michael - -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp/8WEACgkQ2L0ZGCAwWqteaQCfVcgbsKs0Uwal1O4lCb2ofMV3 NnEAn1edQCM4elGNyEeNCYce2Ts9Y/UQ =Ldm+ -----END PGP SIGNATURE----- |
|
From: Michael B. <mic...@cm...> - 2009-08-10 09:46:22
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ulrich Brammer wrote: > I compiled libsyncml from svn libsyncml 0.5.x branch on a Debian Lenny > system. I tested it with syncml-ds-tool with my Samsung SGH E250i > mobile. I got the following error message: > ** Message: ERROR: An internal I/O error occured. Unknown response > (0x46) > > I made traces, see https://libsyncml.opensync.org/ticket/246 > > I do not have any knowledge about syncml and do not know how to debug > further. Is there someone to help? Samsung uses 5 different SyncML stacks and no one is fully standard compliant. So there are two questions. First does your mobile really supports SyncML? Second which implementation is used? Here is a good impression: http://www.traud.de/gsm/samsung.htm Best regards Michael - -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp/7JEACgkQ2L0ZGCAwWqvmvACg5N7mZoNwvZlwGGaSdJpaSUFa d4IAn0ebSJ3AzE3l3dVj2VgKXCT38Twi =Odmv -----END PGP SIGNATURE----- |
|
From: Michael B. <mic...@cm...> - 2009-08-10 09:32:11
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tyson, Tyson Whitehead wrote: > > I decided to give the trunk syncml-ds-tool and wbxml a try despite the > session_transmit test failing. I get the same problems I get with the lastest > Debian packages (which are version 0.5.3 of libsyncml and 0.10.6 of wbxml). > > $ syncml-ds-tool -b xx:xx:xx:xx:xx:xx yy --wbxml --identifier "PC Suite" -- > sync text/x-vcard Contacts > ** Message: Remote device was successfully connected. > ** Message: ERROR: Unknown CTCapType for Property: ParamName This looks like a bug. ParamName is not a property and usually the Nokias work because I test with them. I will test it with my mobiles. BTW has your Nokia a S60 or S40 OS? > and if I enable tracing and logging it segment faults > > $ syncml-ds-tool -b xx:xx:xx:xx:xx:xx yy --wbxml --identifier "PC Suite" -- > sync text/x-vcard Contacts > Segmentation fault This looks like a bug in trace statement after an interface change. trunk: r1251 branches/libsyncml-0.5.x: r1255 > Compiling with debugging information and running under gdb with or without > tracing and logging enabled I get the message > > ** ERROR **: A disconnect event was received but there is no connected > transport. > aborting... Clearly a bug. Perhaps a race condition. Do you have the traces from this error? I committed a patch to trunk. trunk: r1252, r1253 and r1254 branches/libsyncml-0.5.x: r1256 > and backtracing for the third thread above shows > > #0 0x00007f2b7529d065 in raise () from /lib/libc.so.6 > #1 0x00007f2b752a0153 in abort () from /lib/libc.so.6 > #2 0x00007f2b76ccf0de in IA__g_logv (log_domain=0x0, > log_level=G_LOG_LEVEL_ERROR, format=0x7f2b76fbb660 "A disconnect event was > received but there is no connected transport.", args1=0x7f2b72fa9c40) at > /tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gmessages.c:506 > #3 0x00007f2b76ccf163 in IA__g_log (log_domain=0x1a97 <Address 0x1a97 out of > bounds>, log_level=6809, format=0x6 <Address 0x6 out of bounds>) at > /tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gmessages.c:526 > #4 0x00007f2b76f7b897 in smlTransportReceiveEvent (tsp=0x1a92ff0, link_=0x0, > type=SML_TRANSPORT_EVENT_DISCONNECT_DONE, data=0x0, error=0x0) at > /home/tyson/Sync/libsyncml/libsyncml/sml_transport.c:303 > #5 0x00007f2b76fad587 in smlTransportObexClientEvent (handle=0x1a932a0, > object=0x1aa0930, mode=<value optimized out>, event=4, obex_cmd=2, obex_rsp=0) > at /home/tyson/Sync/libsyncml/libsyncml/transports/obex_client.c:570 > #6 0x00007f2b755c1463 in ?? () from /usr/lib/libopenobex.so.1 > #7 0x00007f2b755c0fb7 in ?? () from /usr/lib/libopenobex.so.1 > #8 0x00007f2b76fab21f in smlTransportObexClientSend (userdata=0x1a930b0, This looks like an error during the first message. > Running the debug version from the command line or under valgrind gives the > earlier results (i.e., "ERROR: Unknown CTCapType for Property: ParamName"). > Valgrind also complains about 8 "conditional jumps or moves depending on > uninitializsed values" within ld-2.9.so, but I assume that is irrelevant. I try to simulate this with my mobiles too. Let's see. > * 1 process 6959 0x00007f8f74b2fcc0 in strlen () from /lib/libc.so.6 > > and a backtrace on the first thread gives > > #0 0x00007f8f74b2fcc0 in strlen () from /lib/libc.so.6 > #1 0x00007f8f74afc9ae in vfprintf () from /lib/libc.so.6 > #2 0x00007f8f74b1d43f in vasprintf () from /lib/libc.so.6 > #3 0x00007f8f76544ec0 in IA__g_vasprintf (string=0x3, > format=0x7f8f76806ba6 "%s: connect + no link", args=0x7f8f72844a70) > at /tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gprintf.c:315 > #4 0x00007f8f76531b00 in IA__g_strdup_vprintf (format=0x3 <Address 0x3 out of > bounds>, > args=<value optimized out>) > at /tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gstrfuncs.c:244 > #5 0x00007f8f767c3b9d in smlTrace (type=TRACE_INTERNAL, > message=0x7f8f76806ba6 "%s: connect + no link") Some wrong trace statements. Fixed in trunk and branches/libsyncml-0.5.x > I would be happy to provide any additional information I can or test any > patches that anyone proposes. Well, you already provied more informations than the most other users in the first message. Thanks a lot. The most important question is which mobile OS do you use? I have both but it reduces my workload if I now what I have to test ;) Thanks for the detailed description Michael - -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp/6T0ACgkQ2L0ZGCAwWqvOOACdFhH/t6v7GMzr+g9cak7IBfQW xTsAoNZKF7MunYWE8ZSjGnwcROhcc9nG =dhAC -----END PGP SIGNATURE----- |
|
From: Michael B. <mic...@cm...> - 2009-08-10 08:40:02
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tyson, which version do you use? Tyson Whitehead wrote: > > I've not been able to sync my Nokia 2760 using the Debian opensync packages, > so I've compiled up the trunk version (as of right now) of both wbxml2 and > libsyncml to see if the issues have been resolved. > > Unfortunately, libsyncml seems to be hanging on the session_transmit test. > Turning on the trace shows you first get _event_callback with 1, then with 5, > then it dispatches 2 status, and then it goes into a endless loop of > > smlSessionReceiveBody: command 1 of message 1 found > smlSessionReceiveBody: Now dispatching 1 statuses. Sessionwaiting: 0, prio: 1 > >>>>>>> smlSessionDispatch > smlSessionDispatch: dispatch status - 1 > >>>>>>> _smlSessionCommandHandler > _smlSessionCommandHandler: session cmd type 2 > <<<<<<< _smlSessionCommandHandler - next needed command status 0 for > message 1 is not this one (cmd 1, msg 1) > <<<<<<< smlSessionDispatch - done This means that one SyncML status is not handled. Which platform do you use? I only test with x86 multi core. I release only if our build hosts are clean but we have not all platform configurations of course. Best regards Michael - -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp/3QQACgkQ2L0ZGCAwWqs0gwCgwpt2pwW8WUdI+R/V2NtS8BnD rpkAoKEiQM7gGnQn7BJQN1kjE5P5w4/l =ViRU -----END PGP SIGNATURE----- |
|
From: Ulrich B. <ubr...@t-...> - 2009-08-08 15:06:37
|
I compiled libsyncml from svn libsyncml 0.5.x branch on a Debian Lenny system. I tested it with syncml-ds-tool with my Samsung SGH E250i mobile. I got the following error message: ** Message: ERROR: An internal I/O error occured. Unknown response (0x46) I made traces, see https://libsyncml.opensync.org/ticket/246 I do not have any knowledge about syncml and do not know how to debug further. Is there someone to help? Regards Uli |
|
From: Tyson W. <twh...@gm...> - 2009-08-08 14:27:16
|
I forgot to attach the output of also valgrind on the debug version when tracing and logging was enabled. You see some additional "conditional jump or move depends on uninitialized value" outside of ld-2.9.so ==6998== Thread 3: ==6998== Conditional jump or move depends on uninitialised value(s) ==6998== at 0x6A85E9A: vfprintf (in /lib/libc-2.9.so) ==6998== by 0x6AA843E: vasprintf (in /lib/libc-2.9.so) ==6998== by 0x511EEBF: g_vasprintf (gprintf.c:315) ==6998== by 0x510BAFF: g_strdup_vprintf (gstrfuncs.c:244) ==6998== by 0x4E4FB9C: smlTrace (sml_support.c:160) ==6998== by 0x4E8467E: smlTransportObexClientEvent (obex_client.c:460) ==6998== by 0x683B441: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683AEDE: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683B6AA: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683D1EF: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x4E82C7D: smlTransportObexClientConnect (obex_client.c:1082) ==6998== by 0x4E532F1: smlTransportWorkerHandler (sml_transport.c:153) ==6998== ==6998== Conditional jump or move depends on uninitialised value(s) ==6998== at 0x6A831E0: (within /lib/libc-2.9.so) ==6998== by 0x6A86483: vfprintf (in /lib/libc-2.9.so) ==6998== by 0x6AA843E: vasprintf (in /lib/libc-2.9.so) ==6998== by 0x511EEBF: g_vasprintf (gprintf.c:315) ==6998== by 0x510BAFF: g_strdup_vprintf (gstrfuncs.c:244) ==6998== by 0x4E4FB9C: smlTrace (sml_support.c:160) ==6998== by 0x4E8467E: smlTransportObexClientEvent (obex_client.c:460) ==6998== by 0x683B441: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683AEDE: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683B6AA: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683D1EF: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x4E82C7D: smlTransportObexClientConnect (obex_client.c:1082) ==6998== ==6998== Conditional jump or move depends on uninitialised value(s) ==6998== at 0x6A86507: vfprintf (in /lib/libc-2.9.so) ==6998== by 0x6AA843E: vasprintf (in /lib/libc-2.9.so) ==6998== by 0x511EEBF: g_vasprintf (gprintf.c:315) ==6998== by 0x510BAFF: g_strdup_vprintf (gstrfuncs.c:244) ==6998== by 0x4E4FB9C: smlTrace (sml_support.c:160) ==6998== by 0x4E8467E: smlTransportObexClientEvent (obex_client.c:460) ==6998== by 0x683B441: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683AEDE: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683B6AA: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683D1EF: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x4E82C7D: smlTransportObexClientConnect (obex_client.c:1082) ==6998== by 0x4E532F1: smlTransportWorkerHandler (sml_transport.c:153) ==6998== ==6998== Conditional jump or move depends on uninitialised value(s) ==6998== at 0x6A85719: vfprintf (in /lib/libc-2.9.so) ==6998== by 0x6AA843E: vasprintf (in /lib/libc-2.9.so) ==6998== by 0x511EEBF: g_vasprintf (gprintf.c:315) ==6998== by 0x510BAFF: g_strdup_vprintf (gstrfuncs.c:244) ==6998== by 0x4E4FB9C: smlTrace (sml_support.c:160) ==6998== by 0x4E8467E: smlTransportObexClientEvent (obex_client.c:460) ==6998== by 0x683B441: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683AEDE: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683B6AA: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683D1EF: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x4E82C7D: smlTransportObexClientConnect (obex_client.c:1082) ==6998== by 0x4E532F1: smlTransportWorkerHandler (sml_transport.c:153) ==6998== ==6998== Conditional jump or move depends on uninitialised value(s) ==6998== at 0x6A8577A: vfprintf (in /lib/libc-2.9.so) ==6998== by 0x6AA843E: vasprintf (in /lib/libc-2.9.so) ==6998== by 0x511EEBF: g_vasprintf (gprintf.c:315) ==6998== by 0x510BAFF: g_strdup_vprintf (gstrfuncs.c:244) ==6998== by 0x4E4FB9C: smlTrace (sml_support.c:160) ==6998== by 0x4E8467E: smlTransportObexClientEvent (obex_client.c:460) ==6998== by 0x683B441: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683AEDE: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683B6AA: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683D1EF: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x4E82C7D: smlTransportObexClientConnect (obex_client.c:1082) ==6998== by 0x4E532F1: smlTransportWorkerHandler (sml_transport.c:153) followed by the same sort of thing gdb showed for loading the core file ==6998== Invalid read of size 1 ==6998== at 0x4C22F52: strlen (mc_replace_strmem.c:242) ==6998== by 0x6A879AD: vfprintf (in /lib/libc-2.9.so) ==6998== by 0x6AA843E: vasprintf (in /lib/libc-2.9.so) ==6998== by 0x511EEBF: g_vasprintf (gprintf.c:315) ==6998== by 0x510BAFF: g_strdup_vprintf (gstrfuncs.c:244) ==6998== by 0x4E4FB9C: smlTrace (sml_support.c:160) ==6998== by 0x4E52849: smlTransportReceiveEvent (sml_transport.c:293) ==6998== by 0x4E849DA: smlTransportObexClientEvent (obex_client.c:489) ==6998== by 0x683B441: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683AEDE: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683B6AA: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683D1EF: (within /usr/lib/libopenobex.so.1.5.0) ==6998== Address 0x3 is not stack'd, malloc'd or (recently) free'd ==6998== ==6998== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==6998== Access not within mapped region at address 0x3 ==6998== at 0x4C22F52: strlen (mc_replace_strmem.c:242) ==6998== by 0x6A879AD: vfprintf (in /lib/libc-2.9.so) ==6998== by 0x6AA843E: vasprintf (in /lib/libc-2.9.so) ==6998== by 0x511EEBF: g_vasprintf (gprintf.c:315) ==6998== by 0x510BAFF: g_strdup_vprintf (gstrfuncs.c:244) ==6998== by 0x4E4FB9C: smlTrace (sml_support.c:160) ==6998== by 0x4E52849: smlTransportReceiveEvent (sml_transport.c:293) ==6998== by 0x4E849DA: smlTransportObexClientEvent (obex_client.c:489) ==6998== by 0x683B441: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683AEDE: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683B6AA: (within /usr/lib/libopenobex.so.1.5.0) ==6998== by 0x683D1EF: (within /usr/lib/libopenobex.so.1.5.0) Cheers! -Tyson |
|
From: Tyson W. <twh...@gm...> - 2009-08-08 14:19:58
|
Hi,
I decided to give the trunk syncml-ds-tool and wbxml a try despite the
session_transmit test failing. I get the same problems I get with the lastest
Debian packages (which are version 0.5.3 of libsyncml and 0.10.6 of wbxml).
$ syncml-ds-tool -b xx:xx:xx:xx:xx:xx yy --wbxml --identifier "PC Suite" --
sync text/x-vcard Contacts
** Message: Remote device was successfully connected.
** Message: ERROR: Unknown CTCapType for Property: ParamName
and if I enable tracing and logging it segment faults
$ syncml-ds-tool -b xx:xx:xx:xx:xx:xx yy --wbxml --identifier "PC Suite" --
sync text/x-vcard Contacts
Segmentation fault
Compiling with debugging information and running under gdb with or without
tracing and logging enabled I get the message
** ERROR **: A disconnect event was received but there is no connected
transport.
aborting...
and "info threads" gives
4 Thread 0x7fc30bb40950 (LWP 6912) 0x00007fc30e1751be in
__lll_lock_wait_private ()
from /lib/libpthread.so.0
* 3 Thread 0x7fc30c341950 (LWP 6911) 0x00007fc30e5e4065 in raise () from
/lib/libc.so.6
2 Thread 0x7fc30cb42950 (LWP 6910) 0x00007fc30e6778f6 in poll () from
/lib/libc.so.6
1 Thread 0x7fc310716780 (LWP 6907) 0x00007fc30e16eb92 in
pthread_create@@GLIBC_2.2.5 ()
from /lib/libpthread.so.0
and backtracing for the third thread above shows
#0 0x00007f2b7529d065 in raise () from /lib/libc.so.6
#1 0x00007f2b752a0153 in abort () from /lib/libc.so.6
#2 0x00007f2b76ccf0de in IA__g_logv (log_domain=0x0,
log_level=G_LOG_LEVEL_ERROR, format=0x7f2b76fbb660 "A disconnect event was
received but there is no connected transport.", args1=0x7f2b72fa9c40) at
/tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gmessages.c:506
#3 0x00007f2b76ccf163 in IA__g_log (log_domain=0x1a97 <Address 0x1a97 out of
bounds>, log_level=6809, format=0x6 <Address 0x6 out of bounds>) at
/tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gmessages.c:526
#4 0x00007f2b76f7b897 in smlTransportReceiveEvent (tsp=0x1a92ff0, link_=0x0,
type=SML_TRANSPORT_EVENT_DISCONNECT_DONE, data=0x0, error=0x0) at
/home/tyson/Sync/libsyncml/libsyncml/sml_transport.c:303
#5 0x00007f2b76fad587 in smlTransportObexClientEvent (handle=0x1a932a0,
object=0x1aa0930, mode=<value optimized out>, event=4, obex_cmd=2, obex_rsp=0)
at /home/tyson/Sync/libsyncml/libsyncml/transports/obex_client.c:570
#6 0x00007f2b755c1463 in ?? () from /usr/lib/libopenobex.so.1
#7 0x00007f2b755c0fb7 in ?? () from /usr/lib/libopenobex.so.1
#8 0x00007f2b76fab21f in smlTransportObexClientSend (userdata=0x1a930b0,
link_=<value optimized out>, data=0x7f2b6c002370, error=0x0) at
/home/tyson/Sync/libsyncml/libsyncml/transports/obex_client.c:1287
#9 0x00007f2b76f7c319 in smlTransportWorkerHandler (message=0x7f2b6c002260,
userdata=0x1a92ff0) at
/home/tyson/Sync/libsyncml/libsyncml/sml_transport.c:145
#10 0x00007f2b76f73368 in _queue_dispatch (source=<value optimized out>,
callback=<value optimized out>, user_data=0x1a93180) at
/home/tyson/Sync/libsyncml/libsyncml/sml_queue.c:78
#11 0x00007f2b76cc4f7a in IA__g_main_context_dispatch (context=0x7f2b6c000960)
at /tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gmain.c:1814
#12 0x00007f2b76cc8640 in g_main_context_iterate (context=0x7f2b6c000960,
block=1, dispatch=1, self=<value optimized out>) at /tmp/cdt.XX50MgKl/build-
area/glib2.0-2.20.1/glib/gmain.c:2448
#13 0x00007f2b76cc8b0d in IA__g_main_loop_run (loop=0x7f2b6c000af0) at
/tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gmain.c:2656
#14 0x00007f2b76f79a14 in smlThreadStartCallback (data=0x7f2b6c000a40) at
/home/tyson/Sync/libsyncml/libsyncml/sml_thread.c:118
#15 0x00007f2b76cee574 in g_thread_create_proxy (data=0x7f2b6c000d10) at
/tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gthread.c:635
#16 0x00007f2b74e27faa in start_thread () from /lib/libpthread.so.0
#17 0x00007f2b7533929d in clone () from /lib/libc.so.6
#18 0x0000000000000000 in ?? ()
Running the debug version from the command line or under valgrind gives the
earlier results (i.e., "ERROR: Unknown CTCapType for Property: ParamName").
Valgrind also complains about 8 "conditional jumps or moves depending on
uninitializsed values" within ld-2.9.so, but I assume that is irrelevant.
Enabling tracing and logging, running outside of gdb, and then loading the
dumped core with gdb, "info threads" gives
4 process 6958 0x00007f8f74b7b8f6 in poll () from /lib/libc.so.6
3 process 6960 0x00007f8f74b7b8f6 in poll () from /lib/libc.so.6
2 process 6957 0x00007f8f746791f4 in __lll_lock_wait () from
/lib/libpthread.so.0
* 1 process 6959 0x00007f8f74b2fcc0 in strlen () from /lib/libc.so.6
and a backtrace on the first thread gives
#0 0x00007f8f74b2fcc0 in strlen () from /lib/libc.so.6
#1 0x00007f8f74afc9ae in vfprintf () from /lib/libc.so.6
#2 0x00007f8f74b1d43f in vasprintf () from /lib/libc.so.6
#3 0x00007f8f76544ec0 in IA__g_vasprintf (string=0x3,
format=0x7f8f76806ba6 "%s: connect + no link", args=0x7f8f72844a70)
at /tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gprintf.c:315
#4 0x00007f8f76531b00 in IA__g_strdup_vprintf (format=0x3 <Address 0x3 out of
bounds>,
args=<value optimized out>)
at /tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gstrfuncs.c:244
#5 0x00007f8f767c3b9d in smlTrace (type=TRACE_INTERNAL,
message=0x7f8f76806ba6 "%s: connect + no link")
at /home/tyson/Sync/libsyncml/libsyncml/sml_support.c:160
#6 0x00007f8f767c684a in smlTransportReceiveEvent (tsp=0x1693ff0, link_=0x0,
type=SML_TRANSPORT_EVENT_CONNECT_DONE, data=0x0, error=0x0)
at /home/tyson/Sync/libsyncml/libsyncml/sml_transport.c:293
#7 0x00007f8f767f89db in smlTransportObexClientEvent (handle=0x16942a0,
object=0x7f8f6c001d00, mode=<value optimized out>, event=<value optimized
out>,
obex_cmd=<value optimized out>, obex_rsp=32)
at /home/tyson/Sync/libsyncml/libsyncml/transports/obex_client.c:489
#8 0x00007f8f74e0c442 in ?? () from /usr/lib/libopenobex.so.1
#9 0x00007f8f74e0bedf in ?? () from /usr/lib/libopenobex.so.1
#10 0x00007f8f74e0c6ab in ?? () from /usr/lib/libopenobex.so.1
#11 0x00007f8f74e0e1f0 in ?? () from /usr/lib/libopenobex.so.1
#12 0x00007f8f767f6c7e in smlTransportObexClientConnect (data=0x16940b0)
at /home/tyson/Sync/libsyncml/libsyncml/transports/obex_client.c:1082
#13 0x00007f8f767c72f2 in smlTransportWorkerHandler (message=0x16a12c0,
userdata=0x1693ff0) at
/home/tyson/Sync/libsyncml/libsyncml/sml_transport.c:153
#14 0x00007f8f767be368 in _queue_dispatch (source=<value optimized out>,
callback=<value optimized out>, user_data=0x1694180)
at /home/tyson/Sync/libsyncml/libsyncml/sml_queue.c:78
#15 0x00007f8f7650ff7a in IA__g_main_context_dispatch (context=0x16a0ff0)
at /tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gmain.c:1814
#16 0x00007f8f76513640 in g_main_context_iterate (context=0x16a0ff0, block=1,
dispatch=1,
self=<value optimized out>)
at /tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gmain.c:2448
#17 0x00007f8f76513b0d in IA__g_main_loop_run (loop=0x16a1120)
at /tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gmain.c:2656
#18 0x00007f8f767c4a14 in smlThreadStartCallback (data=0x16a0dd0)
at /home/tyson/Sync/libsyncml/libsyncml/sml_thread.c:118
#19 0x00007f8f76539574 in g_thread_create_proxy (data=0x16a12f0)
at /tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gthread.c:635
#20 0x00007f8f74672faa in start_thread () from /lib/libpthread.so.0
#21 0x00007f8f74b8429d in clone () from /lib/libc.so.6
#22 0x0000000000000000 in ?? ()
I would be happy to provide any additional information I can or test any
patches that anyone proposes.
Thanks!
-Tyson
|
|
From: Tyson W. <twh...@gm...> - 2009-08-08 05:02:29
|
Hi,
I've not been able to sync my Nokia 2760 using the Debian opensync packages,
so I've compiled up the trunk version (as of right now) of both wbxml2 and
libsyncml to see if the issues have been resolved.
Unfortunately, libsyncml seems to be hanging on the session_transmit test.
Turning on the trace shows you first get _event_callback with 1, then with 5,
then it dispatches 2 status, and then it goes into a endless loop of
smlSessionReceiveBody: command 1 of message 1 found
smlSessionReceiveBody: Now dispatching 1 statuses. Sessionwaiting: 0, prio: 1
>>>>>>> smlSessionDispatch
smlSessionDispatch: dispatch status - 1
>>>>>>> _smlSessionCommandHandler
_smlSessionCommandHandler: session cmd type 2
<<<<<<< _smlSessionCommandHandler - next needed command status 0 for
message 1 is not this one (cmd 1, msg 1)
<<<<<<< smlSessionDispatch - done
(I would be happy to send all the earlier stuff the lead up if it is useful)
Thanks!
-Tyson
|
|
From: Michael B. <mic...@cm...> - 2009-08-04 08:03:13
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Samant Maharaj wrote: > I'm trying to write a plugin for conduit (http://www.conduit-project.org/), > a Gnome synchronisation application. The idea is that the plugin would > expose the data in a cell phone such as vcards, calendar entries, tasks and > notes (depending on what the phone supports). Conduit natively knows about > many of these data types and can handle the synchronisation in much the same > way as OpenSync. > > In light of this, I've been looking at libsyncml as a way to implement this > plugin. Conduit plugins are implemented in Python, so I'm thinking of > writing sort of an API layer in C to call libsyncml and then link to this > from the Python code. Did you contact John Carr? He works on some Python or Vala stuff and libsyncml. I started to reduce an re-write the interface because of his comments. > My main problem is that it's not really clear to me how best to use > libsyncml. Unfortunately I haven't found a huge amount of documentation on > how best to use the library. I'm hoping to avoid having to learn the > internals of the SyncML protocol. > > My question is simply, is my plan feasible? If so, where can I find > documentation to help me out? The main recommendation is to only use the high level DS API. The source code includes a tool called syncml-ds-tool which was designed as test tool for phones and as example for the DS API. So the best way to start learning is to look at this example. The high level API reduces the required SyncML knowledge to a minimum but some stuff is still required. You have to understand the difference between slow/full and normal/incremental sync. Additionally you have to understand a concept like sync anchors. I hope this helps you for the first steps. Best regards Michael - -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp362QACgkQ2L0ZGCAwWqsxqwCgwP+rY/QbwQe5QDWgCM8W+9IJ z1oAmgMBdKr7fnWoBuK9Ya5XlB7VcZft =7q4p -----END PGP SIGNATURE----- |
|
From: Michael B. <mic...@cm...> - 2009-08-04 07:57:23
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason Grant wrote: > Hello again, > > I've built of svn head, and am using libsyncml-0.5.x as per my recent > mail. > > When I try and sync my Nokia 6300 over obex, the reconcilation of > changes appears to work correctly (i.e. osynctool reports the correct > changes), but the final send of data hangs, and the phone is not > updated. The trace repeats the _queue_prepare message below until I > kill the process. > > I'm not sure what to try next to resolve what appears to be an issue > related to worker threads. > > Tips appreciated. I am happy to debug/test this, but need some > guidance. > > (Note that I've sync'd contacts between evo and the 6300 using earlier > editions of opensync, but no joy with this edition). Can you send me the full traces? You can remove the private stuff like vCards but I need to see the real communication to understand what's going on. BTW You can test the pure SyncML library with syncml-ds-tool and you phone. Best regards Michael - -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp36gYACgkQ2L0ZGCAwWqsg8wCePG57fagQ94VIeYMmjVLakW3g c14AoIJr+vxo5NcyESsa+MTYD3ahxLpQ =60Eb -----END PGP SIGNATURE----- |
|
From: Samant M. <sam...@gm...> - 2009-08-01 12:05:25
|
Hi, I'm trying to write a plugin for conduit (http://www.conduit-project.org/), a Gnome synchronisation application. The idea is that the plugin would expose the data in a cell phone such as vcards, calendar entries, tasks and notes (depending on what the phone supports). Conduit natively knows about many of these data types and can handle the synchronisation in much the same way as OpenSync. In light of this, I've been looking at libsyncml as a way to implement this plugin. Conduit plugins are implemented in Python, so I'm thinking of writing sort of an API layer in C to call libsyncml and then link to this from the Python code. My main problem is that it's not really clear to me how best to use libsyncml. Unfortunately I haven't found a huge amount of documentation on how best to use the library. I'm hoping to avoid having to learn the internals of the SyncML protocol. My question is simply, is my plan feasible? If so, where can I find documentation to help me out? Thanks in advance, Samant |
|
From: Rainer D. <rd...@we...> - 2009-07-28 20:59:29
|
Am Montag, 13. Juli 2009 schrieb turing79it: > Hi all. > > I just unpacked my new 6220, which I was confident would work with opensync > because of this pages: > > https://help.ubuntu.com/community/NokiaEvolutionSyncing?action=show > http://article.gmane.org/gmane.comp.misc.opensync.user/2865 > > Nonetheless, I cannot get it to work neither with SyncML nor with gnokii. > > Anybody can help me with some pointers/instructions? > > Thanks! > > M. Hi, I also have a 6220c and have at least managed to transfer my contacts to the Nokia. That is what I use (opensync-0.22, Debian lenny): blackbox:~# cat /home/kathrin/.opensync-0.22/group1/2/syncmember.conf <?xml version="1.0"?> <syncmember><pluginname>syncml-obex-client</pluginname><name>Handy (2) </name></syncmember> blackbox:~# cat /home/kathrin/.opensync-0.22/group1/2/syncml-obex-client.conf <config> <username></username> <password></password> <type>2</type> <bluetooth_address>yo:ur:BT:add:re:ss</bluetooth_address> <bluetooth_channel>5</bluetooth_channel> <interface>0</interface> <version>1</version> <identifier>PC Suite</identifier> <wbxml>1</wbxml> <recvLimit>10000</recvLimit> <maxObjSize>0</maxObjSize> <usestringtable>1</usestringtable> <onlyreplace>0</onlyreplace> <contact_db>Contacts</contact_db> <calendar_db>Calendar</calendar_db> <note_db>Notes</note_db> </config>blackbox:~# Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: rd...@we... jabber: rd...@ja... GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ |
|
From: Jason G. <exp...@lo...> - 2009-07-28 10:34:32
|
Hello again, I've built of svn head, and am using libsyncml-0.5.x as per my recent mail. When I try and sync my Nokia 6300 over obex, the reconcilation of changes appears to work correctly (i.e. osynctool reports the correct changes), but the final send of data hangs, and the phone is not updated. The trace repeats the _queue_prepare message below until I kill the process. I'm not sure what to try next to resolve what appears to be an issue related to worker threads. Tips appreciated. I am happy to debug/test this, but need some guidance. (Note that I've sync'd contacts between evo and the 6300 using earlier editions of opensync, but no joy with this edition). J. [1248774932.614840] smlXmlAssemblerRunFull: Message Assembled: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SyncML PUBLIC "-//SYNCML//DTD SyncML 1.1//EN" "http://www.syncml.org/docs/syncml_represent_v11_20020213.dtd"><SyncML xmlns="SYNCML:SYNCML1.1"><SyncHdr><VerDTD>1.1</VerDTD><VerProto>SyncML/1.1</VerProto><SessionID>23099</SessionID><MsgID>2</MsgID><Target><LocURI>IMEI:XXXX</LocURI></Target><Source><LocURI>jas@talby</LocURI></Source><Meta><MaxMsgSize xmlns="syncml:metinf">3584</MaxMsgSize></Meta></SyncHdr> <SyncBody><Status><CmdID>1</CmdID><MsgRef>2</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd><TargetRef>jas@talby</TargetRef><SourceRef>IMEI:XXX</SourceRef><Data>200</Data></Status> <Status><CmdID>8</CmdID><MsgRef>2</MsgRef><CmdRef>4</CmdRef><Cmd>Sync</Cmd><TargetRef>Contacts</TargetRef><SourceRef>/telecom/pb.vcf</SourceRef><Data>200</Data></Status> <Status><CmdID>9</CmdID><MsgRef>2</MsgRef><CmdRef>5</CmdRef><Cmd>Add</Cmd><SourceRef>64</SourceRef><Data>201</Data></Status> <Final></Final></SyncBody></SyncML> ... [1248774932.615559] <<<<<<< smlTransportObexClientSend [1248774932.615576] >>>>>>> smlTransportDataDeref(0xb0a1c928) [1248774932.615593] <<<<<<< smlTransportDataDeref: Freed [1248774932.615610] <<<<<<< smlTransportWorkerHandler [1248774932.615628] _queue_prepare(0x88969c0, 0xaf5fd21c) [1248774932.616721] _queue_prepare(0x88969c0, 0xaf5fd21c) [1248774932.617766] _queue_prepare(0x88969c0, 0xaf5fd21c) [1248774932.618848] _queue_prepare(0x88969c0, 0xaf5fd21c) [1248774932.619916] _queue_prepare(0x88969c0, 0xaf5fd21c) [1248774932.620976] _queue_prepare(0x88969c0, 0xaf5fd21c) [1248774932.622035] _queue_prepare(0x88969c0, 0xaf5fd21c) [1248774932.623082] _queue_prepare(0x88969c0, 0xaf5fd21c) [1248774932.624162] _queue_prepare(0x88969c0, 0xaf5fd21c) [1248774932.625224] _queue_prepare(0x88969c0, 0xaf5fd21c) |
|
From: Jason G. <exp...@lo...> - 2009-07-28 10:00:50
|
Thanks Michael, I now get a clean build. J. On Mon, 2009-07-27 at 17:34 +0200, Michael Bell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jason Grant wrote: > > > > I get the compilation error shown below when building the syncml plugin > > off head (against the libsyncml off head). > > > > I cannot see the definition of SmlBool or SmlError in any of the checked > > out source - hence the error. > > You have to checkout branches/libsyncml-0.5.x and not trunk. > > Best regards > > Michael > - -- > ___________________________________________________________________ > > Michael Bell Humboldt-Universitaet zu Berlin > > Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice > Fax: +49 (0)30-2093 2704 Unter den Linden 6 > mic...@cm... D-10099 Berlin > ___________________________________________________________________ > > PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkptyPkACgkQ2L0ZGCAwWqse6ACgqCHMJ+BjsXXQVUIUe0XTuhDc > luYAoKT2bJAMGoYk+4y+R+JiaGkpP0Or > =5jNJ > -----END PGP SIGNATURE----- |
40 messages has been excluded from this view by a project administrator.
