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 How reproducible: always Steps to Reproduce: 1. setup a modem in network setup 2. try and get NM to recognize it exists 3. Actual results: NM sits there thinking there is no network even though I created a modem and can connect to it using ifup Expected results: NM understands a modem Additional info:
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 this issue.
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 directly. 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 device?
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 device list.
*** This bug has been marked as a duplicate of 136663 ***