Bugzilla – Bug 462866
bluetooth sync with palm no longer works
Last modified: 2009-06-29 05:32:54 UTC
Under opensuse 11.0 I was able to connect to my Palm using "pilot-xfer -l -p bt:". Now that I've upgraded to 11.1 I can no longer do this. I start listening on the Linux side and when I try and sync from the Palm side I get "Unable to initiate HotSync operation because the port is in use by another application". Syncing to my Mac laptop works just fine still so it seems this a problem on the Linux side. How can I figure out what other application on my Linux machine is talking to the bluetooth and causing this problem or figure out which configuration parameters I need to change for 11.1?
Is this a problem with bluetooth or pilot-link? Vladimir (Nadvornik or Botka), please have a look at this.
I think with bluetooth. The stock pilot-link on suse 11.0 worked with bluetooth, the stock version on 11.1 doesn't work. Now if I build pilot-link from source it worked on 11.0 and if I build from the same source on 11.1 it still doesn't work. So in that scenario what changed was libbluetooth, which changed from version 2 to version 3.
Maybe this is the same problem as with Bug 467247 - not posiible to create rfcomm.
Solution of this bug can help also to Alexey Ilin <dencorpos@gmail.com>
I am not able to reproduce the error. Here is the configuration. HW: Palm TX SW: bluez 4.22-2.1, pilot-link 0.12.3-2.56 The Palm device is paired with the PC and I wait for the synchronization request from the Palm. # pilot-xfer -p bt:00:07:E0:B3:DD:03 -l Listening for incoming connection on bt:00:07:E0:B3:DD:03... When I start the HotSync synchronization in the Palm I can see the "connected!" message followed by the list of the Palms files. Can you reproduce the procedure?
You seem to have newer versions of the libraries than I do. I'm using the latest patches for 11.1 as well. bluez-4.19-1.5 pilot-link-0.12.3-2.51 HW: Palm 700p In the past I haven't used my hardware address: pilot-xfer -p bt: -l Listening for incoming connection on bt:... Then I start HotSync on my palm and nothing. The connection eventually times out from my palm. I just tried it now with my hardware address and I still get the same results. >pilot-xfer -p bt:00:07:E0:B8:DC:05 -l Listening for incoming connection on bt:00:07:E0:B8:DC:05... Same problem if I'm root or my regular user. I've paired the device and I can find it with "hcitool scan". What other information can I provide to help debug this issue? I have the output of hcidump from an 11.0 box (where it works) and my 11.1 box (where it doesn't work). Would that help?
Wait a second, I still had my palm set to sync over USB for that test. Now I tried again and using "-p bt:" gives me the error that the port is in use. Using "-p bt:00:07:E0:B8:DC:05" works!
OK, it worked once. After that I tried syncing with jpilot and it core dumped. So I tried a reboot in case the core dump left something hanging and now I can't sync with my palm again. I get the same error about the port being in use.
The bluetooth (BT) synchronization with Palm works, so I resolve this bug as invalid. There is an Xorg related problem with jpilot. "jpilot: xcb_io.c:182: process_responses: Assertion" . Please try to file new bug against Xorg or jpilot. The jpilot seems a more likely candidate, since the error occurs with BT communication only. No such problems can be observed with USB connected Palm.
Upon a reboot of the Linux machine and a reboot of the Treo 700p I am unable to sync via bluetooth using the command pilot-xfer -l -p bt:00:07:E0:B8:DC:05 The error on the Palm is "Unable to initiate HotSync operation because the port is in use by another application.". I have not executed jpilot since the reboot of the system, so this should not be a contributing factor in this bug report.
"Unable to initiate HotSync operation because the port is in use by another application." is misleading. I can get this message if I do not start the pilot-xfer. So the HotSync can tell nothing about the PC and still claims the port being used by another application. You can try and reproduce it. As a consequence it is obvious that the pilot-xfer must be started first, so the Palm can find the virtual serial port via BT when the HotSync is activated. This worked for you before. The jpilot crash, you reported, happens after the HotSync is done. Jpilot uses pilot-xfer. Please check all components and procedures and try again. If it does not work post the output of: # hciconfig -a # hcitool scan
I am starting the pilot-xfer first. It'll work for me once in a while and then it stops working. >hciconfig -a hci0: Type: USB BD Address: 00:0C:41:E1:DF:33 ACL MTU: 192:8 SCO MTU: 64:8 UP RUNNING PSCAN ISCAN RX bytes:831 acl:0 sco:0 events:41 errors:0 TX bytes:438 acl:0 sco:0 commands:37 errors:0 Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: Link mode: SLAVE ACCEPT Name: 'jon-0' Class: 0x4a0104 Service Classes: Networking, Capturing, Telephony Device Class: Computer, Desktop workstation HCI Ver: 1.1 (0x1) HCI Rev: 0x20d LMP Ver: 1.1 (0x1) LMP Subver: 0x20d Manufacturer: Cambridge Silicon Radio (10) >hcitool scan Scanning ... 00:07:E0:B8:DC:05 eggplant treo 00:10:60:D3:07:4B JEN
Created attachment 277196 [details] output of hcidump while syncing under 11.0
Created attachment 277198 [details] output of hcidump while attempting to sync under 11.1
Created attachment 277200 [details] output of strace of pilot-xfer -l on 11.0
Created attachment 277201 [details] output of strace of pilot-xfer -l on 11.1
Thank you for the information. Here is the difference between the 11.0 and the 11.1 version. It works in 11.0 3683 accept(3, {sa_family=AF_BLUETOOTH, sa_data="\5\334\270\340\7\0\26\0\4\270\1\0\0\0"}, [10]) = 5 3683 dup2(5, 3) = 3 ,but not in 11.1 1174 accept(3, 0x7ffff7c7ea00, [10]) = ? ERESTARTSYS (To be restarted) 1174 --- SIGINT (Interrupt) @ 0 (0) --- I can not reproduce the problem on my 11.1 with Palm TX. In my strace I see the correct connection: accept(3, {sa_family=AF_BLUETOOTH, sa_data="\3\335\263\340\7\0\26\0\364\267\1\0\0\0"}, [10]) = 5 dup2(5, 3) Unfortunately at present I am not able to debug it in more details. Here is the listing of the relevant packages I use. # zypper se -si bluez Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository --+----------------+---------+------------+--------+--------------------------------------------------------- i | bluez | package | 4.36-51.1 | i586 | (System Packages) i | bluez | patch | 865 | noarch | openSUSE-11.1-Update i | bluez | patch | 485 | noarch | openSUSE-11.1-Update i | bluez-alsa | package | 4.36-51.1 | i586 | (System Packages) i | bluez-compat | package | 4.36-51.1 | i586 | (System Packages) i | bluez-cups | package | 4.36-51.1 | i586 | (System Packages) i | bluez-firmware | package | 1.2-28.88 | i586 | http://download.opensuse.org/distribution/11.1/repo/oss/ i | bluez-gnome | package | 1.8-2.5 | i586 | http://download.opensuse.org/distribution/11.1/repo/oss/ i | bluez-hcidump | package | 1.42-17.41 | i586 | http://download.opensuse.org/distribution/11.1/repo/oss/ i | bluez-test | package | 4.36-51.1 | i586 | (System Packages) vlado:/home/vlado # zypper se -si pilot Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository --+-----------------+---------+-----------------+------+--------------------------------------------------------- i | evolution-pilot | package | 2.24.1.1-4.14.1 | i586 | openSUSE-11.1-Update i | gnome-pilot | package | 2.0.16-3.167 | i586 | http://download.opensuse.org/distribution/11.1/repo/oss/ i | jpilot | package | 1.6.0-2.28 | i586 | http://download.opensuse.org/distribution/11.1/repo/oss/ i | pilot-link | package | 0.12.3-2.56 | i586 | http://download.opensuse.org/distribution/11.1/repo/oss/ Do you still observe the problem ?
Yes I still see the problem. Here is my zypper output. It appears that you have a newer bluez. Where did that come from? The same question applies to pilot-link. Is this perhaps a difference between 32-bit and 64-bit? >zypper se -si bluez Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository --+----------------+---------+-------------+--------+------------------ i | bluez | package | 4.22-6.1.10 | x86_64 | Updates_for_11.1 i | bluez | patch | 865 | noarch | Updates_for_11.1 i | bluez | patch | 485 | noarch | Updates_for_11.1 i | bluez-devel | package | 4.22-6.1.10 | x86_64 | Updates_for_11.1 i | bluez-firmware | package | 1.2-28.72 | x86_64 | openSUSE-11.1-Oss i | bluez-gnome | package | 1.8-2.5 | x86_64 | openSUSE-11.1-Oss i | bluez-hcidump | package | 1.42-17.39 | x86_64 | openSUSE-11.1-Oss i | bluez-test | package | 4.22-6.1.10 | x86_64 | Updates_for_11.1 >zypper se -si pilot Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository --+----------------+---------+-------------+--------+------------------ i | jpilot | package | 1.6.0-2.31 | x86_64 | openSUSE-11.1-Oss i | jpilot-Backup | package | 0.51-68.134 | x86_64 | openSUSE-11.1-Oss i | perl-PDA-Pilot | package | 0.12.3-2.46 | x86_64 | openSUSE-11.1-Oss i | pilot-link | package | 0.12.3-2.51 | x86_64 | openSUSE-11.1-Oss
You can easily update your packages from [1] . I just updated successfully to the latest bluez from the Faactory [2]. And it works for me . The packages are always built for all supported architectures. Use the "1-Click button" and the correct architecture will be selected. [1] http://software.opensuse.org/search [2] i | bluez | package | 4.42- home:michal-m:branches:home:seife:Factory Did the update help ?
I just installed the new bluez and libbluetooth3 packages and it's now syncing! Here are the packages I updated: S | Name | Type | Version | Arch | Repository --+----------------+---------+------------+--------+------------------ i | bluez | package | 4.42-67.1 | x86_64 | (System Packages) i | bluez-devel | package | 4.42-67.1 | x86_64 | (System Packages) i | bluez-test | package | 4.42-67.1 | x86_64 | (System Packages) i | libbluetooth3 | package | 4.42-67.1 | x86_64 | (System Packages) It even synced twice in a row. Now I'll just have to watch that it still syncs tomorrow, that's been a problem before.
OK, now syncing with jpilot-sync seems to finish ok, but then core dumps: Loaded symbols for /usr/lib64/python2.6/lib-dynload/_struct.so Reading symbols from /usr/lib64/python2.6/site-packages/gtk-2.0/gobject/_gobject.so...done. Loaded symbols for /usr/lib64/python2.6/site-packages/gtk-2.0/gobject/_gobject.so Core was generated by `jpilot-sync -b'. Program terminated with signal 11, Segmentation fault. #0 0x00007f7d0ff8c797 in sdp_gen_tid () from /usr/lib64/libbluetooth.so.3
It worked again this morning, with the exception of the segfault on close. It'd be nice if this segfault didn't happen and leave core files lying around.
Reading symbols from /usr/lib64/python2.6/lib-dynload/operator.so...done. Loaded symbols for /usr/lib64/python2.6/lib-dynload/operator.so Reading symbols from /usr/lib64/python2.6/lib-dynload/_struct.so...done. Loaded symbols for /usr/lib64/python2.6/lib-dynload/_struct.so Reading symbols from /usr/lib64/python2.6/site-packages/gtk-2.0/gobject/_gobject.so...done. Loaded symbols for /usr/lib64/python2.6/site-packages/gtk-2.0/gobject/_gobject.so Core was generated by `jpilot-sync -b'. Program terminated with signal 11, Segmentation fault. #0 0x00007f030430e797 in sdp_gen_tid () from /usr/lib64/libbluetooth.so.3 (gdb) where #0 0x00007f030430e797 in sdp_gen_tid () from /usr/lib64/libbluetooth.so.3 #1 0x00007f0304314087 in sdp_service_attr_req () from /usr/lib64/libbluetooth.so.3 #2 0x00007f03088d38f3 in ?? () from /usr/lib64/libpisock.so.9 #3 0x00007f03088f4223 in pi_close () from /usr/lib64/libpisock.so.9 #4 0x0000000000416f18 in jp_sync () #5 0x0000000000417c28 in sync_once () #6 0x0000000000419e3e in setup_sync () #7 0x000000000040b406 in main ()
Thank you for reporting. As the pilot-xfer works now I am going to close this bug as FIXED. The annoying crashes of jpilot are not caused by the BT subsystem. Update to the jpilot 1.6.2 does not help. You can consider to file a bug against the jpilot.