Red Hat Bugzilla – Bug 453024
Bluetooth DUN modem connections don't work with NM
Last modified: 2009-03-24 13:27:18 EDT
Description of problem:
I'm using FC9 on a laptop with bluetooth and a LG CU500 3G phone as a modem.
I've successfully set this up so that "ifup CU" opens a connection and provides
internet access. I updated /etc/bluetooth/rfcomm.conf to add /dev/rfcomm0 as a
serial connection to my phone and then setup up wvdial to do the dialing. My
problem is that I cannot get NetworkManager to play nice with it.
First of all, NM doesn't want to let me add the device. I tried "edit
connections...", tab to mobile broadband connections and hit the "add" button.
However, nothing happens. In every other tab "add" brings up a dialog, but not
in the "mobile broadband" tab.
I manually connect using "ifup CU", but network manager doesn't recognize that
there is a connection. I use NM to control my VPN connections in a normal wired
connection, but since NM thinks there is no connection, it won't let me choose a
VPN connection to activate.
Finally, Firefox thinks that I'm offline when starting up and I always have to
uncheck "offline" after the first failure message. I think I read that firefox
is using dbus to determine if a network conneciton is present. I guess DBUS is
also unaware that I have an active modem connection.
I've googled for this and can't find any manual or help on fc9 with modems and
network manager. I'd really appreciate some help on getting a good modem
experience with NM.
Version-Release number of selected component (if applicable):
NetworkManager.i386 1:0.7.0-0.9.4.svn3675. installed
NetworkManager-glib.i386 1:0.7.0-0.9.4.svn3675. installed
NetworkManager-gnome.i386 1:0.7.0-0.9.4.svn3675. installed
NetworkManager-openvpn.i386 1:0.7.0-14.svn3632.fc9 installed
NetworkManager-vpnc.i386 1:0.7.0-0.7.7.svn3627. installed
Steps to Reproduce:
1. setup a modem in network setup
2. try and get NM to recognize it exists
NM sits there thinking there is no network even though I created a modem and can
connect to it using ifup
NM understands a modem
You need to tag the modem appropriately in HAL's .fdi files as either a CDMA or
a GSM modem. The right file for this is
/usr/share/hal/fdi/information/10-freedesktop/10-modem.fdi. Match your phone in
some manner (maybe match rfcomm0) and then it will show up in NetworkManager.
This is more of a HAL bug rather than an NM bug, because HAL isn't correctly
tagging the serial interface. There is work going on upstream in HAL to address
I'm sorry I'm a bit confused about this response. Two things:
1) the error log is saying
Jun 30 09:14:24 mimzy nm-system-settings: ifcfg-fedora: parsing
/etc/sysconfi g/network-scripts/ifcfg-ATT ...
Jun 30 09:14:24 mimzy nm-system-settings: ifcfg-fedora: error: Unknown
connection type 'Modem'
which isn't talking about HAL at all, but seems to be trying to read the ifcfg
2) doing lshal doesn't list the /dev/refcomm device at all. Shouldn't I expect
to see the device if HAL is indeed involved in improperly telling NM about the
I hope I'm not violating some bug etiquette, but I reopened this because I've
done some more investigating and the problem isn't as simple as described. I
downloaded the NM source and set it up for some debugging to try and figure out
what is going on. Below is what I found. Remember I am using a GSM phone, but
connecting to it using a wireless bluetooth connection which I setup as
/dev/rfcomm0 using /etc/bluetooth/rfcomm.conf. I have automatic binding so the
/dev/rfcomm0 device is there after the bluetooth service starts.
1) HAL will never report the /dev/rfcomm0 device until I've actually initiated a
connection and I restart haldaemon. Then lshal will show the rfcomm0 device.
2) I changed the fdi file and added the modem capability to the rfcomm device.
3) Network manager still doesn't recognize the device because the parent
(/org/freedesktop/Hal/devices/bluetooth_acl_1256e0c179_0) doesn't have
"info.linux.driver"=serial. This can be seen by looking at the lshal output
that I will attach. The rfcomm0 device *is* correctly labelled as serial.
4) I tried using the fdi file trick to add "info.linux.driver=serial" to the the
parent device (/org/freedesktop/Hal/devices/bluetooth_acl_1256e0c179_0), but no
luck: it just won't let me add this to the parent. I was able to add it to
other hal entries, but that particular device won't take it.
5) I made my own version of NM that bypassed the parent serial check for my
device and sure enough the connection now appears in the NM applet menu. I can
edit the connection now (before I could never add a broadband connection but I
think this is a known bug with nm-applet?).
6) when I drop the connection to /dev/rfcomm0 then hal removes the device and
nm-applet no longer shows it in the menu.
I'm guessing but the modem support in NM seems to assume that the modem device
is always reported by HAL and doesn't understand that the /dev/rfcomm0 device
doesn't appear until you try and access it.
Created attachment 311112 [details]
Output of lshal with /dev/rfcomm0 active
Created attachment 311176 [details]
HAL file to create a permenant bluetooth serial device so NM can see it
Ok, based on an e-mail that Dan sent me I created my own fdi file to create my
own serial device for the bluetooth and that worked. I've attached the file to
the bug in case anyone else needs an example of how to do this.
I did still have some problems. 1) after I start the laptop and login HAL
doesn't see my psuedo device until I restart HAL; I'm looking into why this is
the case. 2) selinux target policy is preventing pppd from accessing
/var/run/pppd2.tdb; I've set enforcing off until I can make a custom policy to
allow this, but I'm a little suspicious that this is specific too my setup since
pppd is used by all broadband modems isn't it?
Mind filing a bug about the pppd2.tdb file? It's only used with multilink PPP
but should be able to be read/written to by pppd anyway.
I might be able to hack up NM serial detection for the moment to handle the
RFCOMM -> ACL -> HCI -> Parent traversal to grab info.linux.driver and make your
life easier too, until real BT DUN support lands.
I've entered a bug (#453024) on the pppd2.tdb
If you look at HAL file I attached in #5 you can see that I just added my own
parent with info.linux.driver as serial. I had to guess on the driver since I
couldn't find anything up the chain. Fortunately, this seems to work. Are you
saying that you can modify NM so I don't need to make the dummy parent?
Finally, I think I understand what is going on with the hal daemon. When I do
boot then NM-applet shows the GSM connection since lshal shows my dummy DUN
device. However, if I suspend, when then lshal doesn't show my dummy DUN until
I restart it. I think the same thing happens with the real /dev/rfcomm0 device
that is automatically added by the bluetooth daemons. I'm going to do some more
testing, but this smells like a haldaemon bug with respect to a suspend.
Talked it over with davidz yesterday. What happens is that rfcomm devices
you've defined in /etc/bluetooth/rfcomm.conf are created when the 'bluetooth'
service is started (/etc/init.d/bluetooth). These devices are "virtual" devices
and when they are first accessed, the BT stack attempts to connect to the listed
BT device and start up the serial stuff.
rfcomm devices aren't seen in HAL by design, since they actually aren't hardware.
Adding proper BT DUN support to NM will fix this, but it's going to be pretty
involved. Basically, you'll add a mobile broadband connection for your phone,
specifying the type (CDMA or GSM). When you choose to connect to it (we can't
autoconnect since we can't scan for the phone ever because BT scanning sucks
power and interrupts existing connections) NM will create the necessary rfcomm
port and do the right thing.
But until then it might be a bit difficult to hack the rfcomm stuff into HAL's
*** This bug has been marked as a duplicate of 136663 ***