Red Hat Bugzilla – Bug 657712
pan0 interface not created by bluetooth.
Last modified: 2012-08-16 13:26:36 EDT
Description of problem:
bluez-4.77: since upgrade from f13 to f14, access to bluetooth PAN profile
functions have been lost. No pan0 interface is created when bluetoothd starts.
Also see references to "inability get on D-BUS' in logs.
Bluetooth PAN profile fully working in previous release (f13).
Occurs every reboot.
Steps to Reproduce:
1. Configure PAN successfully in f13.
2. upgrade f13 to f14.
No pan0 interface. No pan0 bridge.
pan0 interface created. pan0 bridge created.
You'll certainly have to be more precise than that.
Also note that you need to install the bluez-compat package if you want to configure Bluetooth networking by hand.
Sorry but there is not much to go on. I had NAP configured under f13 and working fine (not using the bluez-compat package with separate pand daemon). A pan0
interface came up at boot and I had had this both bridged to an eth0 (for test purposes) and later ip_forwarded to my usual wlan0 interface. ip provided by a
small dhcpd for BT devices. Apart from configuring the pan0 interface, no changes to the default BT setup. Now, under f14, the kernel tries to start the pan0 interface but it isn't there. This is the only error messages I see. bluetoothd is running and all the kernel modules are loaded (see below).
From the logs it looks like it might be to do with dbus comms.
If you could tell me what information you need, I'll do my best to provide it.
Module Size Used by
fuse 61363 3
visor 11069 0
usbserial 33769 1 visor
rfcomm 67220 8
sco 17180 2
bnep 15390 2
l2cap 51240 16 rfcomm,bnep
vboxnetadp 4967 0
vboxnetflt 13626 0
vboxdrv 1758139 2 vboxnetadp,vboxnetflt
coretemp 6196 0
nls_utf8 1421 1
cifs 232625 2
cpufreq_ondemand 9278 2
acpi_cpufreq 7329 1
freq_table 3955 2 cpufreq_ondemand,acpi_cpufreq
mperf 1481 1 acpi_cpufreq
nf_conntrack_netbios_ns 1574 0
ipt_MASQUERADE 2353 1
iptable_nat 5018 1
nf_nat 20289 2 ipt_MASQUERADE,iptable_nat
uinput 7368 0
snd_hda_codec_realtek 298211 1
snd_hda_intel 24399 2
snd_hda_codec 86743 2 snd_hda_codec_realtek,snd_hda_intel
arc4 1449 2
snd_hwdep 6392 1 snd_hda_codec
ecb 2119 2
snd_seq 53791 0
snd_seq_device 6191 1 snd_seq
snd_pcm 80190 2 snd_hda_intel,snd_hda_codec
iwlagn 208939 0
snd_timer 19892 2 snd_seq,snd_pcm
snd 63968 12 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer
iwlcore 195683 1 iwlagn
mac80211 228732 2 iwlagn,iwlcore
r852 10070 0
sm_common 4276 1 r852
nand 32055 2 r852,sm_common
nand_ids 4258 1 nand
nand_ecc 3936 1 nand
mtd 18231 2 sm_common,nand
soundcore 6576 1 snd
btusb 15482 3
snd_page_alloc 7559 2 snd_hda_intel,snd_pcm
sky2 46473 0
cfg80211 134709 3 iwlagn,iwlcore,mac80211
iTCO_wdt 11256 0
uvcvideo 55489 0
iTCO_vendor_support 2610 1 iTCO_wdt
i2c_i801 11088 0
bluetooth 89276 11 rfcomm,sco,bnep,l2cap,btusb
videodev 41889 1 uvcvideo
v4l1_compat 12970 2 uvcvideo,videodev
serio_raw 4640 0
v4l2_compat_ioctl32 9853 1 videodev
wmi 8138 0
rfkill 17622 4 cfg80211,bluetooth
joydev 9737 0
microcode 18548 0
sdhci_pci 7871 0
sdhci 18464 1 sdhci_pci
firewire_ohci 21170 0
mmc_core 64113 1 sdhci
firewire_core 45817 1 firewire_ohci
crc_itu_t 1563 1 firewire_core
yenta_socket 25186 0
i915 286862 3
drm_kms_helper 25743 1 i915
drm 177972 4 i915,drm_kms_helper
i2c_algo_bit 5205 1 i915
i2c_core 26900 6 i2c_i801,videodev,i915,drm_kms_helper,drm,i2c_algo_bit
video 21637 1 i915
output 2253 1 video
from system log:
Nov 29 20:50:58 robin bluetoothd: Bluetooth deamon 4.77
Nov 29 20:50:58 robin bluetoothd: Starting SDP server
Nov 29 20:50:58 robin bluetoothd: Parsing /etc/bluetooth/input.conf failed: No such file or directory
Nov 29 20:50:58 robin bluetoothd: Parsing /etc/bluetooth/audio.conf failed: No such file or directory
Nov 29 20:50:58 robin bluetoothd: HCI dev 0 registered
Nov 29 20:50:58 robin bluetoothd: HCI dev 0 up
Nov 29 20:50:58 robin bluetoothd: Starting security manager 0
Nov 29 20:50:58 robin bluetoothd: Parsing /etc/bluetooth/serial.conf failed: No such file or directory
Nov 29 20:50:58 robin bluetoothd: Clearing blocked list failed: Invalid argument (22)
Nov 29 20:50:58 robin bluetoothd: probe failed with driver input-headset for device /org/bluez/1923/hci0/dev_78_E7_D1_AC_D0_3E
Nov 29 20:50:58 robin bluetoothd: Adapter /org/bluez/1923/hci0 has been enabled
Nov 29 20:52:13 robin dbus-daemon: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.2" (uid=0 pid=1923 comm="/usr/sbin/bluetoothd) interface="(unset)" member="(unset)" error name="(unset)" requested_reply=0 destination=":1.36" (uid=500 pid=2696 comm="bluetooth-applet))
I have what I believe to be the same problem on Fedora 14 i686.
I have a configuration that has been working under Fedora 12 and, I believe, under Fedora 13. The system has been upgraded with yum.
I don't see any relevant information in the logs, in fact it looks almost exactly like the one already posted in this bug, so I will just post my configuration.
rpm -qa 'bluez*'
main.conf network.conf network.service rfcomm.conf
main.conf and rfcomm.conf are left unchanged from installation
Description=Bluetooth Personal Area Network service
This configuration upon sturtup gave an interface pan0 was was configured with the following part of /etc/rc.local:
echo 1 >/proc/sys/net/ipv4/ip_forward
ifconfig pan0 up
/sbin/iptables -t nat -A POSTROUTING -s 192.168.2.1/24 -j SNAT --to-source 192.168.1.10
route add -net 192.168.2.0 netmask 255.255.255.0 pan0
This, when I connected with my mobile phone (with an IP address in the 192.168.2.0/24 subnet) to the computer via Bluetooth allowed to access the web through my computer. Upon phone connection I could see the created bridge through "brctl show". The connection was not very good and broke sometimes, requiring a restart of the mobile phone to reconnect properly, I'm not sure, maybe because of the STP being probably enabled (it didn't bother me that much, so I didn't try to hunt it down). In particular in my /etc/rc.local there is no mention of pand being run
Now I don't see any pan0 interface and no information in the logs, that creating such an interface failed, "dmesg | grep pan0" and "cat /var/log/messages | grep pan0" return empty strings. At the same time bluetooth is operational and I can for example send a file from my computer to my mobile.
Is this a bug in the BlueZ stack or only and effect of my misconfiguration, I don't know, as documentaion on BlueZ is unfortunately rather sparse.
I tried doing "service pand start", which gives me:
[ 1097.369056] Bluetooth: L2CAP ver 2.14
[ 1097.369060] Bluetooth: L2CAP socket layer initialized
[ 1097.425304] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 1097.425308] Bluetooth: BNEP filters: protocol multicast
[ 1097.449173] Bluetooth: SCO (Voice Link) ver 0.6
[ 1097.449178] Bluetooth: SCO socket layer initialized
[ 1097.786509] Bluetooth: RFCOMM TTY layer initialized
[ 1097.786517] Bluetooth: RFCOMM socket layer initialized
[ 1097.786519] Bluetooth: RFCOMM ver 1.11
in dmesg, unfortunately, I still can't connect with my computer. Wireshark when instructed to listen on the bluetooth interface doesn't show any packets being transmitted.
I dont't know if this is of importance, but I don't use NetworkManager.
This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.
(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached 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 to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.
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: