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: 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 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: 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: 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: 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: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: 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-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: 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: 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: 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 |