Bug 532049

Summary:	Fails to connect through PAN
Product:	[Fedora] Fedora	Reporter:	Bastien Nocera <bnocera>
Component:	NetworkManager	Assignee:	Dan Williams <dcbw>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	12	CC:	dcbw
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:	2010-06-05 04:45:43 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:

Description Bastien Nocera 2009-10-30 13:07:35 UTC

NetworkManager-0.7.996-5.git20091021.fc12.x86_64
bluez-4.55-1.fc12.x86_64

Oct 30 11:47:46 localhost bluetoothd[1147]: HCI dev 0 down
Oct 30 11:47:46 localhost bluetoothd[1147]: Adapter /org/bluez/1143/hci0 has been disabled
Oct 30 11:47:46 localhost bluetoothd[1147]: Stopping security manager 0
Oct 30 11:47:46 localhost bluetoothd[1147]: HCI dev 0 unregistered
Oct 30 11:47:46 localhost bluetoothd[1147]: Unregister path: /org/bluez/1143/hci0
Oct 30 11:47:46 localhost NetworkManager: bluez_manager_bdaddr_removed_cb: BT device 00:1E:45:AD:F1:96 removed
Oct 30 11:47:46 localhost bluetoothd[1147]: HCI dev 0 registered
Oct 30 11:47:46 localhost dbus: Rejected send message, 3 matched rules; type="error", sender=":1.43" (uid=500 pid=1515 comm="bluetooth-applet) interface="(unset)" member="(unset)" error name="org.freedesktop.DBus.Error.UnknownMethod" requested_reply=0 destination=":1.10" (uid=0 pid=1143 comm="/usr/sbin/bluetoothd))
Oct 30 11:47:46 localhost bluetoothd[1147]: HCI dev 0 up
Oct 30 11:47:46 localhost bluetoothd[1147]: Starting security manager 0
Oct 30 11:47:46 localhost NetworkManager: <info>  Waking up...
Oct 30 11:47:46 localhost NetworkManager: <info>  (eth0): now managed
Oct 30 11:47:46 localhost NetworkManager: <info>  (eth0): device state change: 1 -> 2 (reason 2)
Oct 30 11:47:46 localhost NetworkManager: <info>  (eth0): bringing up device.
Oct 30 11:47:46 localhost NetworkManager: <info>  (eth0): preparing device.
Oct 30 11:47:46 localhost NetworkManager: <info>  (eth0): deactivating device (reason: 2).
Oct 30 11:47:46 localhost NetworkManager: <info>  (eth0): supplicant interface state:  starting -> ready 
Oct 30 11:47:46 localhost NetworkManager: <info>  (eth0): device state change: 2 -> 3 (reason 42)
Oct 30 11:47:46 localhost bluetoothd[1147]: Parsing /etc/bluetooth/serial.conf failed: No such file or directory
Oct 30 11:47:46 localhost bluetoothd[1147]: probe failed with driver input-headset for device /org/bluez/1143/hci0/dev_00_1E_45_AD_F1_96
Oct 30 11:47:46 localhost bluetoothd[1147]: Adapter /org/bluez/1143/hci0 has been enabled
Oct 30 11:47:46 localhost NetworkManager: bluez_manager_bdaddr_added_cb: BT device Bastien's K850i (00:1E:45:AD:F1:96) added (DUN NAP)
Oct 30 11:47:46 localhost NetworkManager: <info>  (00:1E:45:AD:F1:96): new Bluetooth device (driver: 'bluez')
Oct 30 11:47:46 localhost NetworkManager: <info>  (00:1E:45:AD:F1:96): exported as /org/freedesktop/NetworkManager/Devices/3
Oct 30 11:47:46 localhost NetworkManager: <info>  (00:1E:45:AD:F1:96): now managed
Oct 30 11:47:46 localhost NetworkManager: <info>  (00:1E:45:AD:F1:96): device state change: 1 -> 2 (reason 2)
Oct 30 11:47:47 localhost NetworkManager: <info>  (00:1E:45:AD:F1:96): deactivating device (reason: 2).
Oct 30 11:47:47 localhost NetworkManager: flush_routes: assertion `iface_idx >= 0' failed
Oct 30 11:47:47 localhost NetworkManager: flush_addresses: assertion `iface_idx >= 0' failed
Oct 30 11:47:47 localhost NetworkManager: <info>  (00:1E:45:AD:F1:96): device state change: 2 -> 3 (reason 0)

Pretty sure we have a couple of bugs in the code... Hints?

Comment 1 Dan Williams 2009-11-07 01:15:30 UTC

Um, that log looks normal.  What were you expecting?  "connect automatically" doesn't work for Bluetooth, because we have no idea if the device is around or not and thus trying to connect would simply repeatedly fail.  If you pick the device from the menu does it work?

Comment 2 Bastien Nocera 2009-11-07 03:53:44 UTC

The Bluetooth menu item doesn't show up when no other network devices are available.

1. Boot machine up with a network device available
2. See that Bluetooth is available in the menus
3. Stop NetworkManager service, rmmod network-adapter-kernel-modules (in my case "wl"), start NM service
4. No options available in nm-applet's menu
5. Do 3. but with an insmod
6. Bluetooth device shows up in nm-applet

(dhcp is timing out, even when run by hand on the bnep interface when Bluetooth _is_ available, but that's another problem)

Comment 3 Dan Williams 2009-11-07 04:25:19 UTC

Can you attach /var/log/messages when you see this, or run NM from a terminal wtih --no-daemon and paste in the output after you reproduce it?

Comment 4 Bastien Nocera 2009-11-07 04:41:53 UTC

Nothing interesting in the logs, I think the problem is from nm-applet, not NetworkManager itself.

Comment 5 Dan Williams 2009-11-07 05:37:09 UTC

commit 099692db6039cfdd713ccce8e49a69de268581e1
Author: Dan Williams <dcbw>
Date:   Fri Nov 6 21:35:34 2009 -0800

    menu: show BT connections when no other devices are available (rh #532049)

Comment 6 Fedora Update System 2009-11-13 21:32:10 UTC

NetworkManager-0.7.996-7.git20091113.fc12,ModemManager-0.2-4.20091105.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/NetworkManager-0.7.996-7.git20091113.fc12,ModemManager-0.2-4.20091105.fc12

Comment 7 Bug Zapper 2009-11-16 14:41:22 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 Fedora Update System 2009-12-07 07:26:29 UTC

NetworkManager-0.7.996-7.git20091113.fc12, ModemManager-0.2-4.20091105.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.