Bug 600137
Summary: | Cannot Configure Bluetooth DUN For Droid Eris | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | wdc | ||||||
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 13 | CC: | anton, aron, dcbw, dougsland, gansalmon, huffman, itamar, jonathan, jyundt, kernel-maint, mackendw, madhu.chinakonda, oded, sseago, warlord | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2011-06-27 17:29:01 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
wdc
2010-06-04 02:05:49 UTC
Can you try this again, reproduce the problem, and include ~/.xsession-errors too? That's where the bluetooth plugin dumps its output, and that's what would get most of the interesting log output. At this stage, NM isn't really involved at all. Created attachment 421423 [details]
.xssession-errors file containing bluetooth status
It turns out that the .xsession-errors file currently active has the bluetooth status from my previous attempts.
Is this sufficient, or would you like me to run another, clean test?
I have the same exact problem, trying to use PdaNet on Droid Incredible with HP Compaq 6510b. Same problem here with a Motorola Droid + ASUS 1005HA running Feodra 13. Same problem with PdaNet on Droid with Dell Latitude D630. I have verified that I *can* send files to the device via bluetooth. I'm seeing this too on F13 with a Nexus 1 and pdanet. Here is the relevant part of .xsession-errors: ** Message: dun_start: starting DUN device discovery... ** Message: dun_start: calling Connect... ** (bluetooth-wizard:21483): CRITICAL **: dbus_g_proxy_add_signal: assertion `g_datalist_id_get_data (&priv->signal_signatures, q) == NULL' failed ** Message: dun_start: finished ** Message: dun_connect_cb: processing Connect reply ** Message: dun_connect_cb: new rfcomm interface '/dev/rfcomm0' ** Message: dun_connect_cb: finished ** (bluetooth-wizard:21483): WARNING **: dun_timeout_cb: Error: timed out detecting phone details. Adding myself to cc. If you see bulk & interrupt URB submission errors in 'dmesg' when doing anything with BT, that indicates kernel problems. I've personally experienced regressions from F11/F12 BT support to a few devices, so I'm not at all confident that things are working well on the kernel side. For now, moving this to the kernel to figure out why the BT/USB issues are happening. I've just now verified that a BT adapter and phone combination that works on F11 no longer works on F13 (Kensington Bluetooth USB Adapter + LG Rumor) with the same symptoms we've seen above with failed URB resubmissions. That points directly to a kernel regression in bluetooth support. FWIW, I'm seeing this with my HTC Evo using PDAnet. From dmesg: btusb_bulk_complete: hci0 urb ffff8801997a8f00 failed to resubmit (1) btusb_intr_complete: hci0 urb ffff8801abe6f540 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff8801abe6fa80 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff8801abe6f6c0 failed to resubmit (1) type=1400 audit(1277259763.448:13868): avc: denied { read } for pid=27912 comm="bluetoothd" name="rfcomm0" dev=devtmpfs ino=173628001 scontext=system_u:system_r:bluetooth_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file Running 2.6.32.12-114.fc12.x86_64 FWIW, here's my output from .xsession-errors: (bluetooth-applet:19766): Gtk-CRITICAL **: gtk_action_set_sensitive: assertion `GTK_IS_ACTION (action)' failed (bluetooth-applet:19766): GLib-GObject-WARNING **: invalid cast from `GtkActionGroup' to `GtkAction' (bluetooth-applet:19766): Gtk-CRITICAL **: gtk_action_set_sensitive: assertion `GTK_IS_ACTION (action)' failed ** Message: has_config_widget 38:E7:D8:47:10:0D DialupNetworking ** Message: has_config_widget 38:E7:D8:47:10:0D OBEXObjectPush ** Message: has_config_widget 38:E7:D8:47:10:0D AudioSource ** Message: has_config_widget 38:E7:D8:47:10:0D A/V_RemoteControlTarget ** Message: has_config_widget 38:E7:D8:47:10:0D Headset_-_AG ** Message: has_config_widget 38:E7:D8:47:10:0D HandsfreeAudioGateway ** Message: has_config_widget 38:E7:D8:47:10:0D Phonebook_Access_-_PSE ** Message: has_config_widget 38:E7:D8:47:10:0D DialupNetworking ** Message: has_config_widget 38:E7:D8:47:10:0D OBEXObjectPush ** Message: has_config_widget 38:E7:D8:47:10:0D AudioSource ** Message: has_config_widget 38:E7:D8:47:10:0D A/V_RemoteControlTarget ** Message: has_config_widget 38:E7:D8:47:10:0D Headset_-_AG ** Message: has_config_widget 38:E7:D8:47:10:0D HandsfreeAudioGateway ** Message: has_config_widget 38:E7:D8:47:10:0D Phonebook_Access_-_PSE ** Message: Default Bluetooth adapter is powered ** Message: dun_start: starting DUN device discovery... ** Message: dun_start: calling Connect... ** Message: dun_start: finished ** Message: dun_connect_cb: processing Connect reply ** Message: dun_connect_cb: new rfcomm interface '/dev/rfcomm0' ** Message: dun_connect_cb: finished ** (bluetooth-wizard:1973): WARNING **: dun_timeout_cb: Error: timed out detecting phone details. (bluetooth-applet:19766): GLib-GObject-WARNING **: invalid cast from `GtkActionGroup' to `GtkAction' (bluetooth-applet:19766): Gtk-CRITICAL **: gtk_action_set_sensitive: assertion `GTK_IS_ACTION (action)' failed I also have the same issue with a Motorola Milestone with Android 2.1 and PDANet 2.42. My outputs for all the above are identical except various memory locations and mac addresses. I've opened a GNOME bug 622545 about it ( https://bugzilla.gnome.org/show_bug.cgi?id=622545 ) as it looked like a GNOME Bluetooth issue from my side. FWIW, I think this might be a PDAnet issue.. I couldn't use DUN against a Mac, either. So it might not necessarily be a Linux problem per se. I disagree with the issue being related to PDAnet. I've had my phone (Verizon Motorola Droid 2.1) running with PDAnet on Windows 7 and OSX (Snow Leopard) without any issues. DUN only seems to fail on Fedora 13. Hmm.. The Mac I tried was running 10.5, not 10.6. But I didn't see any DUN advertisements either way. FWIW, I had the same issue on OpenSuse 11.3 with my treo 700p using DUN. I was getting the DUN timeout during obtaining of the phone details as well. I downgraded the ModemManager version to 0.4-1.0 and it now works. Here is the debug output if that helps: ** (modem-manager:20077): DEBUG: <1280448219.105071> (rfcomm0) device open count is 1 (open) ** (modem-manager:20077): DEBUG: (rfcomm0): probe requested by plugin 'Generic' ** (modem-manager:20077): DEBUG: <1280448219.204411> (rfcomm0): --> 'AT+GCAP<CR>' ** (modem-manager:20077): DEBUG: <1280448220.400251> (rfcomm0): <-- 'A' ** (modem-manager:20077): DEBUG: <1280448220.402205> (rfcomm0): <-- 'T+GCAP<CR>' ** (modem-manager:20077): DEBUG: <1280448220.405209> (rfcomm0): <-- '<CR><LF>+GCAP: +CIS707-A, CIS-856, +MS, +ES, +DS, +FCLASS<CR><LF><CR><LF>OK<CR><LF>' ** (modem-manager:20077): DEBUG: <1280448220.405310> (rfcomm0) device open count is 0 (close) ** Message: (rfcomm0) closing serial device... ** Message: (rfcomm0) type primary claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2 ** Message: (Generic): CDMA modem /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2 claimed port rfcomm0 ** (modem-manager:20077): DEBUG: Added modem /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2 ** (modem-manager:20077): DEBUG: (tty/rfcomm0): outstanding support task prevents export of /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2 ** (modem-manager:20077): DEBUG: Exported modem /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2 as /org/freedesktop/ModemManager/Modems/0 ** (modem-manager:20077): DEBUG: (/org/freedesktop/ModemManager/Modems/0): data port is rfcomm0 ** (modem-manager:20077): DEBUG: Removed modem /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2 Wendell: I was just on the Fedora 13 and SuSE Package sites, and could find no ModemManager 0.4-1.0 Where exactly did you find it? wdc, I don't know about OpenSUSE but you can find Fedora builds here: http://koji.fedoraproject.org/koji/packageinfo?packageID=8770 I haven't tried an older build yet to see if it would fix the problem for me. Yes, koji is where I looked for an 0.4-1.0. There isn't one there. There is 0.3-13 and then 0.4-2. All the Fedora builds are using interim git checkins rather than a particular stable upstream source. When we know where Wendell got what is working, we can associate that with a particular upstream source and patch set. Hi: I grabbed the latest ModemManager source tar ball from gnome.org and using the specfile from the latest factory src rpm @ opensuse "massaged" it as a 4-1.0 release inside. I followed the below procedure: - downoaded ModemManager-4.0.tar.bz2 from gnome.org/pub/sources and dropped it into: /usr/src/packages/SOURCES - installed the latest source RPM I could find in the OpenSUSE factory to get the relevant bits needed to build the package RPM - edited the SPECfile pointing it to the 4.0 tar ball and manually set the release ident portion to 1.0. - then compiled the rpm pkg: # cd /usr/src/packages/SPECS # rpmbuild -ba ModemManager.spec hths, Wendell Created attachment 437508 [details] Output after trying the 0616 source snapshot from gnome.org I tried to reproduce Wendell's setup. I fetched the latest Fedora ModemManager source: ModemManager-0_4-4_git20100720_fc13 And the ModemManager upstream source from: ftp://ftp.acc.umu.se/pub/GNOME/sources/ModemManager/0.4/ModemManager-0.4.tar.bz2 I renamed the downloaded upstream source ModemManager-0.4.dl.tar.bz2 As Wendell did, I modified the spec file, built, installed and restarted ModemManager. I still get the same errors, as shown by the attached file containing output from .xsession-errors and /var/log/messages. Can someone interpret the errors and suggest what might be going on? I will note in passing that I also tested on a similar laptop that is in Fedora testers. It was running the 2.6.34 kernel and ModemManager-0_4-4_git20100720. It failed in the same way. Actually, I think the Kernel problem is now fixed. I just took the 2.6.34.6-47 kernel update and now the resubmission failure error messages no longer happen. Sadly, the DUN STILL does not configure. Here is the new output from /var/log/messages (with one line of extra output before and after the bluetooth stuff.): Sep 3 16:53:04 wdc-laptop ntpd_intres[1477]: DNS 2.fedora.pool.ntp.org -> 169.229.70.183 Sep 3 16:53:35 wdc-laptop bluetoothd[1447]: Discovery session 0xb77cfd10 with :1.69 activated Sep 3 16:53:43 wdc-laptop bluetoothd[1447]: Stopping discovery Sep 3 16:53:45 wdc-laptop bluetoothd[1447]: link_key_request (sba=00:16:CF:F0:AC:3A, dba=00:24:BA:E5:DF:2B) Sep 3 16:53:45 wdc-laptop bluetoothd[1447]: pin_code_request (sba=00:16:CF:F0:AC:3A, dba=00:24:BA:E5:DF:2B) Sep 3 16:54:03 wdc-laptop bluetoothd[1447]: link_key_notify (sba=00:16:CF:F0:AC:3A, dba=00:24:BA:E5:DF:2B, type=0) Sep 3 16:54:03 wdc-laptop bluetoothd[1447]: probe failed with driver input-headset for device /org/bluez/1443/hci0/dev_00_24_BA_E5_DF_2B Sep 3 16:54:11 wdc-laptop bluetoothd[1447]: link_key_request (sba=00:16:CF:F0:AC:3A, dba=00:24:BA:E5:DF:2B) Sep 3 16:54:12 wdc-laptop modem-manager: (rfcomm0) opening serial device... Sep 3 16:54:23 wdc-laptop modem-manager: (rfcomm0) closing serial device... Sep 3 16:54:23 wdc-laptop modem-manager: (rfcomm0) opening serial device... Sep 3 16:54:30 wdc-laptop modem-manager: (rfcomm0) closing serial device... Sep 3 16:54:54 wdc-laptop dbus: [system] Rejected send message, 1 matched rules; type="method_return", sender=":1.11" (uid=0 pid=1443 comm="/usr/sbin/bluetoothd) interface="(unset)" member="(unset)" error name="(unset)" requested_reply=0 destination=":1.69" (uid=500 pid=2255 comm="bluetooth-wizard)) Sep 3 16:56:22 wdc-laptop ntpd[1454]: 0.0.0.0 c615 05 clock_sync Here is the relevant content from .xsession_errors: ** Message: has_config_widget 00:24:BA:E5:DF:2B DialupNetworking ** Message: has_config_widget 00:24:BA:E5:DF:2B OBEXObjectPush ** Message: has_config_widget 00:24:BA:E5:DF:2B AudioSource ** Message: has_config_widget 00:24:BA:E5:DF:2B A/V_RemoteControlTarget ** Message: has_config_widget 00:24:BA:E5:DF:2B Headset_-_AG ** Message: has_config_widget 00:24:BA:E5:DF:2B HandsfreeAudioGateway ** Message: has_config_widget 00:24:BA:E5:DF:2B Phonebook_Access_-_PSE ** Message: has_config_widget 00:24:BA:E5:DF:2B DialupNetworking ** Message: has_config_widget 00:24:BA:E5:DF:2B OBEXObjectPush ** Message: has_config_widget 00:24:BA:E5:DF:2B AudioSource ** Message: has_config_widget 00:24:BA:E5:DF:2B A/V_RemoteControlTarget ** Message: has_config_widget 00:24:BA:E5:DF:2B Headset_-_AG ** Message: has_config_widget 00:24:BA:E5:DF:2B HandsfreeAudioGateway ** Message: has_config_widget 00:24:BA:E5:DF:2B Phonebook_Access_-_PSE ** Message: Default Bluetooth adapter is powered ** Message: dun_start: starting DUN device discovery... ** Message: dun_start: calling Connect... ** Message: dun_start: finished ** Message: dun_connect_cb: processing Connect reply ** Message: dun_connect_cb: new rfcomm interface '/dev/rfcomm0' ** Message: dun_connect_cb: finished ** (deja-dup-monitor:1919): DEBUG: monitor.vala:263: Invalid next run date. Not scheduling a backup. ** (bluetooth-wizard:2255): WARNING **: dun_timeout_cb: Error: timed out detecting phone details. ---- I think the key to forward progress is in the log message: Sep 3 16:54:54 wdc-laptop dbus: [system] Rejected send message, 1 matched rules; type="method_return", sender=":1.11" (uid=0 pid=1443 comm="/usr/sbin/bluetoothd) interface="(unset)" member="(unset)" error name="(unset)" requested_reply=0 destination=":1.69" (uid=500 pid=2255 comm="bluetooth-wizard)) Sep 3 16:56:22 wdc-laptop ntpd[1454]: 0.0.0.0 c615 05 clock_sync My phone said: PdaNet is Connected! Bytes: 0/0 Activities: 0/0 Battery: 85% Just like always. I presume a successful DUN negotiation would involve more than 0 bytes and 0 activities. This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 '13'. 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 13'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 13 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 Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |