Created attachment 843621 [details] log entries from the failed PAN connect attempt Description of problem: On Newly F19-to-F20 fedup'd system: Bluetooth PAN connection no longer works (worked under F19/bluez4) Version-Release number of selected component (if applicable): 208-9.fc20 How reproducible: Always Steps to Reproduce: 1. Pair Android Nexus 4 with F20 laptop 2. Leave the PAN checkbox selected in dialog at the end of pairing process. 3. On the panel status/control drop-down (top right) select Bluetooth-Connect from the network options Actual results: Connect fails (see attached journal entries) Expected results: Expected a stable network connection as was the case under F19. Additional info: In the log, it looks like systemd-udevd is renaming the just-created bnep0 interface to enp0s26f1u2. That then seems to throw off the DHCP client which is still looking for bnep0, and the connection attempt fails. The BNEP network interface was not being renamed under F19. Is this new behavior intended?
Created attachment 848324 [details] Log from connection attempt NetworkManager updated to latest 1:0.9.9.0-23.git20131003.fc20, same behavior. Is this a NetworkManager bug? From the logs it does look like a race between NetworkManager and systemd-udevd.
Sounds like a problem in NM (or in the communication between bluez and NM), it should not use the iface name before getting notification from udev about it's availability, but use ifindex instead. Reassigning.
After today's update of NM to 1:0.9.9.0-26.git20131003.fc20, bnep works. However, it seems to be because NM is racing ahead of systemd-udevd and prevents its "Predictable interface names" functionality from actually working. The interface stays named bnep0. Is this a race? Jan 23 11:37:56 gaspode NetworkManager[1065]: <warn> Dispatcher script timed out: Script '/etc/NetworkManager/dispatcher.d/10-sendmail' timed out. Jan 23 11:38:03 gaspode NetworkManager[1065]: <info> Activation (98:D6:F7:B3:FB:B9) starting connection 'tessera Network' Jan 23 11:38:03 gaspode NetworkManager[1065]: <info> (98:D6:F7:B3:FB:B9): device state change: disconnected -> prepare (reason 'none') [30 40 0] Jan 23 11:38:03 gaspode NetworkManager[1065]: <info> NetworkManager state is now CONNECTING Jan 23 11:38:03 gaspode NetworkManager[1065]: <info> Activation (98:D6:F7:B3:FB:B9) Stage 1 of 5 (Device Prepare) scheduled... Jan 23 11:38:03 gaspode NetworkManager[1065]: <info> Activation (98:D6:F7:B3:FB:B9) Stage 1 of 5 (Device Prepare) started... Jan 23 11:38:03 gaspode NetworkManager[1065]: <info> Activation (98:D6:F7:B3:FB:B9) Stage 2 of 5 (Device Configure) scheduled... Jan 23 11:38:03 gaspode NetworkManager[1065]: <info> Activation (98:D6:F7:B3:FB:B9) Stage 1 of 5 (Device Prepare) complete. Jan 23 11:38:03 gaspode NetworkManager[1065]: <info> Activation (98:D6:F7:B3:FB:B9) Stage 2 of 5 (Device Configure) starting... Jan 23 11:38:03 gaspode NetworkManager[1065]: <info> (98:D6:F7:B3:FB:B9): device state change: prepare -> config (reason 'none') [40 50 0] Jan 23 11:38:03 gaspode NetworkManager[1065]: <info> Activation (98:D6:F7:B3:FB:B9) Stage 2 of 5 (Device Configure) complete. Jan 23 11:38:05 gaspode systemd[1]: Reached target Bluetooth. Jan 23 11:38:05 gaspode bluetoothd[924]: connected Jan 23 11:38:05 gaspode dnsmasq[1952]: no servers found in /etc/resolv.conf, will retry Jan 23 11:38:05 gaspode NetworkManager[1065]: <info> Activation (98:D6:F7:B3:FB:B9 bnep0/bluetooth) Stage 2 of 5 (Device Configure) successful. Will connect via PAN. Jan 23 11:38:05 gaspode systemd-udevd[12081]: error changing net interface name bnep0 to enp0s26f1u2: Device or resource busy Jan 23 11:38:05 gaspode NetworkManager[1065]: <info> (bnep0): driver 'unknown' does not support carrier detection. Jan 23 11:38:05 gaspode NetworkManager[1065]: <info> Activation (98:D6:F7:B3:FB:B9) Stage 3 of 5 (IP Configure Start) scheduled. Jan 23 11:38:05 gaspode NetworkManager[1065]: <info> Activation (98:D6:F7:B3:FB:B9) Stage 3 of 5 (IP Configure Start) started... Jan 23 11:38:05 gaspode NetworkManager[1065]: <info> (98:D6:F7:B3:FB:B9): device state change: config -> ip-config (reason 'none') [50 70 0] Jan 23 11:38:05 gaspode NetworkManager[1065]: <info> Activation (bnep0) Beginning DHCPv4 transaction (timeout in 45 seconds) Jan 23 11:38:05 gaspode NetworkManager[1065]: <info> dhclient started with pid 12097 Jan 23 11:38:05 gaspode NetworkManager[1065]: <info> Activation (98:D6:F7:B3:FB:B9) Stage 3 of 5 (IP Configure Start) complete. bnep0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.44.195 netmask 255.255.255.0 broadcast 192.168.44.255 inet6 fe80::227:13ff:fe96:48a3 prefixlen 64 scopeid 0x20<link> ether 00:27:13:96:48:a3 txqueuelen 1000 (Ethernet) RX packets 1664 bytes 496033 (484.4 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1809 bytes 242290 (236.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
NM does use ifindexes throughout (except where external tools require interface names). What is happening here is that when NetworkManager is requesting that Bluez create a PAN connection, Bluez is returning the interface name to NetworkManager. Bluez does not return an interface index, only an interface name. In any case, NM needs to handle renames better, and while this issue is not purely an NM problem, NM should be able to cope with it better.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora 'version' of '20'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I'm definitely still getting this in fedora 22.