GNOME Bugzilla – Bug 432774
[enh] Bluetooth DUN support
Last modified: 2010-06-09 01:02:45 UTC
Please describe the problem: NetworkManager currently does not support interfaces with net.bluetooth capabablity. Steps to reproduce: 1. Have 2 or more device with Bluetooth that support PAN profile 2. Setup the connection using pand or Blue Network Service 3. Connect the peers Actual results: Nothing happens Expected results: To be able to configure the interface created. Does this happen every time? yes Other information:
Created attachment 86879 [details] [review] Patch 1 of 1 Add support for interface with net.bluetooth capability.
There are example available on http://wiki.bluez.org/wiki/Network to setup an network interface.
Created attachment 86928 [details] [review] Patch 1 of 1 Fixes typos and indentation
Thanks for taking a look at bluetooth! A few points... 1) I don't think we'll ever run 802.1x over the bluetooth device, so there's no need for a supplicant manager with the bluetooth object 2) This appears to be _just_ for bluetooth PAN, right? I'd really like to use bluetooth DUN too, so we need to be able to use the BT adapter for both PAN and DUN. Can that happen at the same time, or do adapters only use one profile at a time? I think what this means is that the base Bluetooth class should just interrogate the profiles that the device supports, and then allow the user to activate a connection he/she chooses (or auto-connect using one of those connections). Since the DUN stuff exports a serial port, we want to start PPP on that port for DUN rather than activating PAN stuff; ie the base BT class has to be flexible enough to handle both. 3) Instead of the supplicant manager, we probably want NM to be "NetworkWizard" thing that's show on that wiki page. i.e., when I insert a Bluetooth adapter, NM should recognize the adapter and configure it to do what the user wants. If the user has configured DUN for the adapter, and the user's phone has BT on and is in-range, the DUN connection should show up in the BT device's submenu in the applet. If the user has a PAN connection configured, that connection would show up in the submenu too. When Tambet gets the new config framework implemented we'll be able to set both these up with NM. Thoughts?
1) My bad, will fix that asap. 2) Up to now is just for PAN, but I planning to do the DUN also. I guess we can be flexible enough with just one BT class, but we may have to deal with PAN and DUN hal properties together... Anyway this its ok for me. Current bnep implementation only creates the devices when it is connected to a host meaning that hal only announce the device(net.bluetooth) when we already have a configured PAN. 3) Because of 2 i choose to do the "NetworkWizard" on nm-applet instead of doing in NetworkManager, that way we create/scan for profiles we support and once it is connected hal will announce the new device, NM will recognize it and nm-applet will display it. I guess this way is more flexible because we dont want to have nm-applet talking to NM and then NM to Bluez Network Service, we can let nm-applet to go straight Bluez. Im already working in a patch to nm-applet so a can file a bug to nm-applet with the wizard integrate into the applet, Do you agree?
The problem with your approach to (3) is that right now we're not doing much policy in the applet. We want to move there, but that's not possible quite yet. Having all the logic in the applet won't allow NM to activate a bluetooth device when the applet's not running, which is a major thing we're going to do in 0.7. So if all the logic is in the applet, then you have to duplicate all that logic in the system-settings daemon too, which is only about configuration now and not policy. In general, we want to have most of the actual process of setting up devices and configuring them done in NM, not in the userspace. If it's done in userspace, you cannot lock it down or provide security gating for it. I'd prefer to have the NetworkWizard pieces and the setup of the BT device itself in NM, not in an untrusted userspace bit. NM is the thing that gates information that userspace reads. There's not really a problem with the applet -> NM -> Bluez, because the applet only provides configuration information to NM and calls "activate device" and such. It's not really that much information. Furthermore, NM does device discovery, not the applet. The architecture looks like this: ____________ | Applets | ____|____________|_______________ | | | NetworkManager | |_________________________________| | | | | | wpa_supplicant | Bluez | serial | |________________|_______|________| NM is the serivce that detects and configures the various network devices that the system has. Not the applet. Hardware specific services like wpa_supplicant and Bluez are driven by NM, and NM will also have to directly drive ethernet and serial ports that it detects from HAL.
NM will have to detect that a bluetooth device has been plugged in, ask for the support profiles, and filter out the connections that aren't applicable to the device. Remember, you define a connection but that connection doesn't have to be specific to a bluetooth adapter itself. If I plug in a BT 1.2 adapter, NM needs to filter out the connections that aren't applicable to that one, even if some of those connections might require something that BT 2.0 has. It's about the connections, not about the hardware. We will have the ability to lock a specific connection to a specific device (based on hardware address or somesuch), but that's the unusual case.
ok lets go by parts: Even if you have the applet not running the device will be still there, Bluez Network Service does store the connections, so in boot load you may not have the applet yet but the configuration will be restored just as before. Neither NM ot nm-applet have to care about policy, we do that on bluez. There is no logic to duplicate, its very simple to configure in nm-applet and NM dont have to even to care what the interface is for, the only things NM could do are ignore or not the devices and activate/deactivate. Second what would configure the device is Bluez not nm-applet, so if we choose to have NM to deal with the configuration I guess we end up duplicating the Bluez Network API and so is pointless to have 2 daemons in the system bus doing the same thing. As I said I have much of the code done, but if those changes are really necessary the patches will be delayed, and even if we do the wizard on NM this will not stop someone using Bluez API messing with network interfaces. Im open for suggestions...
Please do not get me wrong, Im just trying figure out what the best solution, perhaps we could have done all the Bluez Network Service in NM.
The important thing is that Network Manager is desktop specific while BlueZ also has to handle the cases of embedded devices where you don't have Network Manager and in some cases you don't even have HAL. So all the scanning, device configuration and setup has to be done by BlueZ. Network Manager is only a client. We have to keep this in mind all the time. Another thing is that you don't wanna duplicate any logic in Network Manager. We aim to provide a generic interface for using Bluetooth access points without any real knowledge about the inner workings of Bluetooth. This includes an abstraction of PAN and LAP profiles. Currently we only support PAN, but LAP support is on the todo list. So all the configuration has to be done through the org.bluez.network API to reduce any overhead and avoid code duplication. This API allows you to list the configured access points and connect to them. The access to org.bluez.network however can be done directly in nm-applet or in a lower layer directly through the Network Manager core.
Created attachment 87144 [details] [review] Patch 1 of 1 Remove use of supplicant on Bluetooth interfaces and some fixes.
NM provides a configuration framework that stores configuration for stuff that Bluez shouldn't care about, like PPP settings, IP settings, etc. That's not someting I think Bluez should be doing by itself. What I want out of bluez is a way to control BT devices so that NM doesn't have to touch the hardware and call ioctl()s itself. Second, NM (and the nm applet) implements the policy for which access point the BT device should be connecting to, when that device should be activated, and which users are allowed to use that device. Thrid, NM doens't need Bluez to store any configuration. I'm fine with Bluez storing this stuff generally because it works in places where NM is inappropriate, but NM will still need a way to override what Bluez stores. _Exactly_ like how NM pushes configuration information to wpa_supplicant and doesn't use /etc/wpa_supplicant.conf. Bluez shouldn't depend on any configuration files of its own, and the D-Bus interface should be flexible enough to allow clients to set up the Bluez configuration through D-Bus themselves. Again, from my read of the diagram on the wiki page, NM should be the NetworkWizard piece.
Created attachment 87158 [details] [review] Patch 1 of 1 Patch for nm-applet. PS: This make the applet to deal with the bluetooth wizard we can move it to NM latter if really necessary.
We need to think about inquire, for now I leave to user manually set when we wants to scan. But we could set it to periodic scan, or maybe leave to bluetooth applet to configure this... Also would be nice to have some animation when scanning if possible.
I have talked with marcel and we could have periodic inquiry running, then manually scan would be disable and we could have the signal strength.
I'm 100% with Dan in that the applet shouldn't talk directly with org.bluez. Just as the applet does not talk directly with wpa_supplicant, dhcp, named, etc, it should not talk with bluetooth "manager" directly. I've reviewed the patches and here are my comments: Patch from comment #11. s/wireless/bluetooth/ in manager_set_bluetooth_enabled() src/nm-device-bluetooth.c: Do not override constructor if it doesn't do anything. Do not override NMDevice->is_up if it doesn't do anything. In nm_device_bluetooth_finalize(), priv->name and priv->uuid are leaked. In set_property(), priv->name and priv->uuid are leaked on subsequent calls. In introspection/nm-manager.xml, do not add another '<property name="State" type="u" access="read"/>'. Other than these small changes, the patch looks good. Patch from comment #13. It looks generally ok, but as already said, the direct communication with bluez should be done only by NetworkManager. The only thing that looked wrong to me was +#define GN_UUID "00001117-0000-1000-8000-00805f9b34fb" in src/menu-items.c. Also, maybe it's better to add a submenu for blutooth devices (like vpn)?
WRT the GUI bits, the operating assumption was that each hardware device gets a menu item, more or less, like they have now with wired & wireless. In the case of an ethernet device, if you've created more than one connection config for that device, it would show up under a sub-menu. Wireless is an exception here, and maybe bluetooth should be an exception as well. Only connections that are _valid_ should be shown as allowed in the menu. For example, you don't see saved connection information for wireless networks that NM can't see in the current location, even if they are in GConf. Likewise, if I'm doing DUN from my phone, I should _NOT_ see that DUN connection in the BT adapter's sub-menu unless my phone is on and in-range of the laptop's BT adapter. .------------------------------------. | O Wired Network > |--------------------. | Wireless Networks | Home (DHCP) | | O foobar E |||||||||||| | Work (static) | | O bork |||||| |--------------------` | O blah ||| | | O school ||||||||| | | ---------------------------------- | | Bluetooth adapter > |--------------------. | ---------------------------------- | Dialup to Sprint | | VPN Connections > | PAN to Foobar | | Dialup Connections > |--------------------` | ---------------------------------- | | Connect to other wireless... | | Create new wireless... | `------------------------------------` Or something like this. Somewhat like VPN connections. We may need disconnect items in the submenus too.
I dont know if we really need to differ between wireless and bluetooth in the menu, so we may want to reuse other wireless and new wireless dialogs to bluetooth connections too. Also Wireless Networks should display the bluetooth networks. This will also be handy for upcoming Winet (UWB) support.
Created attachment 87389 [details] [review] Patch 1 of 1 Fixes some leaks and unnecessary overwrites.
Created attachment 87715 [details] [review] nm-bluetooth.path Move Bluetooth wizard to NM daemon and create a bluez manager to implement the wizard.
Created attachment 87716 [details] [review] nm-applet-bluetooth.patch Remove bluetooth wizard from nm-applet.
Created attachment 87717 [details] [review] nm-bluetooth.patch Remove dependency of bluez, bluez must only be used via dbus.
I would like to mark the bluetooth wizard as a subject to change, we might want some general wizard for bluetooth something like osx has and makes NM specific wizard for bluetooth network obsolete.
Fine to mark it subject to change, we'll just have to work through the details as we go along. I don't have the best idea how the actual BT device _setup_ should work, but I think I've got a pretty good idea of how the actual connection process should work. I'll go over the patches again in the next few days, thanks!
Created attachment 87908 [details] [review] nm-bluetooth.patch Make fixes needed to make it able to be applied against svn head.
Created attachment 87910 [details] [review] nm-applet-bluetooth.patch Make fixes needed to make it able to be applied against svn head.
We have done the DUN profile implementation using our BLUEZ serial service, but I missing the interface or something to configure the serial port created. Does NM has support for dialup networks?
Created attachment 88168 [details] [review] nm-bluetooth.patch Make use of CancelConnect when NoReply error is received.
Created attachment 88364 [details] [review] nm-bluetooth.patch Rework wizard to make use of FindConnection instead of creating everytime a new connection.
*** Bug 461417 has been marked as a duplicate of this bug. ***
*** Bug 481766 has been marked as a duplicate of this bug. ***
Is this patch going to make it into the 0.7 version?
No, Bluetooth is a focus of whatever follows 0.7 though. It's going to be be done a bit differently than this patch, but it will get done.
*** Bug 551155 has been marked as a duplicate of this bug. ***
*** Bug 559070 has been marked as a duplicate of this bug. ***
*** Bug 578585 has been marked as a duplicate of this bug. ***
PAN support is already in recent versions of NetworkManager and NetworkManager-applet. Only thing left is DUN support, but that requires ModemManager support.
And most of the stuff for DUN support was recently added (see the btdun branches of both NM and the applet). It'll land for 0.8.1.
The 'btdun' branches of both the applet and NM itself are now feature-complete and ready to be merged for 0.8.1.
*** Bug 609167 has been marked as a duplicate of this bug. ***
Is it possible to add optional possibility of manual setting of initstring for connection? My old Siemens/Benq-Siemens phones didn't supports by NM out of box and it will be great if we could set initstring like AT+CGDCONT=1,"IP","my.provider.apn" and dial AT *99***1# without any AI from NM. Maybe, button like "Advanced" for that would be good?
(In reply to comment #41) > Is it possible to add optional possibility of manual setting of initstring for > connection? My old Siemens/Benq-Siemens phones didn't supports by NM out of box > and it will be great if we could set initstring like > AT+CGDCONT=1,"IP","my.provider.apn" and dial AT *99***1# without any AI from > NM. Maybe, button like "Advanced" for that would be good? This should work fine; if not it's a bug. ModemManager will automatically send that string for you. What we need to make sure happens correctly is the capabilities detection and init sequence. If the phone has problems with the default init string we should add a small plugin for the phone with the right init sequence. Would you mind filing a new bug for your device and including the 'modem-manager --debug' output (as described in http://live.gnome.org/NetworkManager/Debugging) when the problem occurs? Thanks!
Bluetooth DUN support has been merged to NetworkManager and nm-applet master. Please test, and if you run into problems lets file new bugs for the specific issue. Thanks!
*** Bug 611849 has been marked as a duplicate of this bug. ***
*** Bug 621044 has been marked as a duplicate of this bug. ***