Description of problem: When I plug my device in via USB, synce-hal recognises it and does some initial configuration. But, since all of the other synce components are expecting Odccm to be running, nothing can communicate with the device. Trying to install odccm generates the message that synce-hal has obsoleted it. The result is an unusable synce system. Version-Release number of selected component (if applicable): synce-hal-0.14-3.fc12.x86_64 How reproducible: Always Steps to Reproduce: 1. Plug in a Windows Mobile Device (a Motorola Q in my case) 2. try to connect via pls, pstatus, synce-gnome Actual results: pls/pstatus: ** Message: Device /org/freedesktop/Hal/devices/net_80_00_69_xx_xx_xx not fully set in Hal, skipping ** Message: Odccm is not running, ignoring synce-gnome: Waiting for odccm to start Expected results: file listing, device status, etc. Additional info:
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug is still present in Fedora 14.
I am seeing the same problem in Fedora 14. I connect my HTC Touch Pro 2 and rndis is working. The device gets an IP address. But nothing can actually let me access the device. pls shows: ** Message: Device /org/freedesktop/Hal/devices/net_80_00_60_0f_e8_00 not fully set in Hal, skipping ** Message: Odccm is not running, ignoring pls: Could not find configuration at path '(Default)'
I'm also seeing the same problem: $ pstatus ** Message: Device /org/freedesktop/Hal/devices/usb_device_49f_3_noserial_if0_serial_usb_0 not fully set in Hal, skipping ** Message: Odccm is not running, ignoring pstatus: Could not find configuration at path '(Default)' /var/log/messages shows: Mar 6 22:07:11 rmk-PC kernel: [255104.627208] usb 1-5.4: new full speed USB device using ehci_hcd and address 13 Mar 6 22:07:11 rmk-PC kernel: [255104.712834] usb 1-5.4: New USB device found, idVendor=049f, idProduct=0003 Mar 6 22:07:11 rmk-PC kernel: [255104.712843] usb 1-5.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Mar 6 22:07:11 rmk-PC kernel: [255104.713525] ipaq 1-5.4:1.0: PocketPC PDA converter detected Mar 6 22:07:11 rmk-PC kernel: [255104.713946] usb 1-5.4: PocketPC PDA converter now attached to ttyUSB0 Mar 6 22:07:12 rmk-PC pppd[25383]: Warning: can't open options file /root/.ppprc: Permission denied Mar 6 22:07:12 rmk-PC pppd[25384]: pppd 2.4.5 started by root, uid 0 Mar 6 22:07:12 rmk-PC pppd[25384]: Serial connection established. Mar 6 22:07:12 rmk-PC pppd[25384]: Using interface ppp0 Mar 6 22:07:12 rmk-PC pppd[25384]: Connect: ppp0 <--> /dev/ttyUSB0 Mar 6 22:07:13 rmk-PC pppd[25384]: local IP address 192.168.131.1 Mar 6 22:07:13 rmk-PC pppd[25384]: remote IP address 192.168.131.129 Mar 6 22:07:14 rmk-PC ntpd[6053]: Listen normally on 34 ppp0 192.168.131.1 UDP 123 Allowing ppp+ in the firewall configuration allows more progress, but then spits out a selinux error: The source process: hal-dccm Attempted this access: name_connect On this tcp socket: port 990 You should report this as a bug. You can generate a local policy module to allow this access. Allow this access for now by executing: # grep hal-dccm /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp These two actions (firewall and changing selinux config) appears to fix my problem.
synce-connector-0.15.2-3.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/synce-connector-0.15.2-3.fc16
Package synce-connector-0.15.2-3.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing synce-connector-0.15.2-3.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/synce-connector-0.15.2-3.fc16 then log in and leave karma (feedback).
synce-connector-0.15.2-4.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
On F17 with synce-gnome I get: [iranzo@x201 ~]$ synce-gnome Waiting for odccm to start package: synce-connector-0.15.2-5.fc17.x86_64, and I've tried the dbus patch in org.synce.dccm.conf for adding " <allow send_type="method_call"/>" as per BZ760991 with no luck so far. [iranzo@x201 ~]$ sync-engine -v DEBUG SynCE sync-engine starting up 2012-08-29 13:32:33,702 DEBUG syncengine : running main loop 2012-08-29 13:32:33,702 DEBUG syncengine : creating SyncEngine object 2012-08-29 13:32:33,747 DEBUG syncengine : installing signal handlers 2012-08-29 13:32:33,749 INFO engine.syncengine.kernel : _CBDCCMStatusChanged: udev dccm came online [iranzo@x201 Inditex]$ pls -d 3 ** Message: No devices connected to dccm ** Message: Odccm is not running, ignoring [synce_info_from_file:105] unable to open file: /home/iranzo/.synce/active_connection pls: Could not find configuration at path '(Default)' ¿Is this the same problem?