After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 432774 - [enh] Bluetooth DUN support
[enh] Bluetooth DUN support
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
git master
Other All
: Normal enhancement
: ---
Assigned To: Dan Williams
Dan Williams
: 461417 481766 551155 559070 578585 609167 611849 621044 (view as bug list)
Depends on:
Blocks: 603524
 
 
Reported: 2007-04-23 22:31 UTC by Luiz Augusto von Dentz
Modified: 2010-06-09 01:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch 1 of 1 (17.21 KB, patch)
2007-04-23 22:35 UTC, Luiz Augusto von Dentz
none Details | Review
Patch 1 of 1 (26.19 KB, patch)
2007-04-24 18:12 UTC, Luiz Augusto von Dentz
none Details | Review
Patch 1 of 1 (31.07 KB, patch)
2007-04-27 13:59 UTC, Luiz Augusto von Dentz
none Details | Review
Patch 1 of 1 (26.53 KB, patch)
2007-04-27 17:27 UTC, Luiz Augusto von Dentz
none Details | Review
Patch 1 of 1 (30.61 KB, patch)
2007-05-02 14:53 UTC, Luiz Augusto von Dentz
none Details | Review
nm-bluetooth.path (53.36 KB, patch)
2007-05-07 14:20 UTC, Luiz Augusto von Dentz
none Details | Review
nm-applet-bluetooth.patch (14.63 KB, patch)
2007-05-07 14:21 UTC, Luiz Augusto von Dentz
none Details | Review
nm-bluetooth.patch (52.75 KB, patch)
2007-05-07 15:16 UTC, Luiz Augusto von Dentz
none Details | Review
nm-bluetooth.patch (55.98 KB, patch)
2007-05-09 19:09 UTC, Luiz Augusto von Dentz
none Details | Review
nm-applet-bluetooth.patch (14.66 KB, patch)
2007-05-09 19:13 UTC, Luiz Augusto von Dentz
none Details | Review
nm-bluetooth.patch (56.60 KB, patch)
2007-05-14 17:37 UTC, Luiz Augusto von Dentz
none Details | Review
nm-bluetooth.patch (57.66 KB, patch)
2007-05-17 21:26 UTC, Luiz Augusto von Dentz
none Details | Review

Description Luiz Augusto von Dentz 2007-04-23 22:31:24 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:
Comment 1 Luiz Augusto von Dentz 2007-04-23 22:35:35 UTC
Created attachment 86879 [details] [review]
Patch 1 of 1

Add support for interface with net.bluetooth capability.
Comment 2 Luiz Augusto von Dentz 2007-04-23 22:38:19 UTC
There are example available on http://wiki.bluez.org/wiki/Network to setup an network interface.
Comment 3 Luiz Augusto von Dentz 2007-04-24 18:12:17 UTC
Created attachment 86928 [details] [review]
Patch 1 of 1

Fixes typos and indentation
Comment 4 Dan Williams 2007-04-26 01:50:57 UTC
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?
Comment 5 Luiz Augusto von Dentz 2007-04-26 12:50:56 UTC
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?
Comment 6 Dan Williams 2007-04-26 14:25:29 UTC
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.
Comment 7 Dan Williams 2007-04-26 14:29:20 UTC
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.
Comment 8 Luiz Augusto von Dentz 2007-04-26 16:32:42 UTC
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...
Comment 9 Luiz Augusto von Dentz 2007-04-26 16:43:06 UTC
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. 
Comment 10 Marcel Holtmann 2007-04-26 17:17:18 UTC
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.
Comment 11 Luiz Augusto von Dentz 2007-04-27 13:59:40 UTC
Created attachment 87144 [details] [review]
Patch 1 of 1

Remove use of supplicant on Bluetooth interfaces and some fixes.
Comment 12 Dan Williams 2007-04-27 14:41:19 UTC
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.
Comment 13 Luiz Augusto von Dentz 2007-04-27 17:27:41 UTC
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.
Comment 14 Luiz Augusto von Dentz 2007-04-27 17:37:14 UTC
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.
Comment 15 Luiz Augusto von Dentz 2007-04-27 18:23:22 UTC
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.
Comment 16 Tambet Ingo 2007-04-30 09:51:59 UTC
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)?
Comment 17 Dan Williams 2007-04-30 15:37:17 UTC
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.
Comment 18 Luiz Augusto von Dentz 2007-05-02 14:07:01 UTC
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. 
Comment 19 Luiz Augusto von Dentz 2007-05-02 14:53:17 UTC
Created attachment 87389 [details] [review]
Patch 1 of 1

Fixes some leaks and unnecessary overwrites.
Comment 20 Luiz Augusto von Dentz 2007-05-07 14:20:38 UTC
Created attachment 87715 [details] [review]
nm-bluetooth.path

Move Bluetooth wizard to NM daemon and create a bluez manager to implement the wizard.
Comment 21 Luiz Augusto von Dentz 2007-05-07 14:21:53 UTC
Created attachment 87716 [details] [review]
nm-applet-bluetooth.patch

Remove bluetooth wizard from nm-applet.
Comment 22 Luiz Augusto von Dentz 2007-05-07 15:16:34 UTC
Created attachment 87717 [details] [review]
nm-bluetooth.patch

Remove dependency of bluez, bluez must only be used via dbus.
Comment 23 Luiz Augusto von Dentz 2007-05-07 15:20:14 UTC
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.
Comment 24 Dan Williams 2007-05-08 14:31:42 UTC
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!
Comment 25 Luiz Augusto von Dentz 2007-05-09 19:09:56 UTC
Created attachment 87908 [details] [review]
nm-bluetooth.patch

Make fixes needed to make it able to be applied against svn head.
Comment 26 Luiz Augusto von Dentz 2007-05-09 19:13:20 UTC
Created attachment 87910 [details] [review]
nm-applet-bluetooth.patch

Make fixes needed to make it able to be applied against svn head.
Comment 27 Luiz Augusto von Dentz 2007-05-11 14:44:56 UTC
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?
Comment 28 Luiz Augusto von Dentz 2007-05-14 17:37:09 UTC
Created attachment 88168 [details] [review]
nm-bluetooth.patch

Make use of CancelConnect when NoReply error is received.
Comment 29 Luiz Augusto von Dentz 2007-05-17 21:26:54 UTC
Created attachment 88364 [details] [review]
nm-bluetooth.patch

Rework wizard to make use of FindConnection instead of creating everytime a new connection.
Comment 30 Christopher Aillon 2007-08-08 17:14:48 UTC
*** Bug 461417 has been marked as a duplicate of this bug. ***
Comment 31 Teppo Turtiainen 2007-12-26 10:00:19 UTC
*** Bug 481766 has been marked as a duplicate of this bug. ***
Comment 32 Phuah Yee Keat 2008-09-04 02:35:46 UTC
Is this patch going to make it into the 0.7 version?
Comment 33 Dan Williams 2008-09-04 13:17:44 UTC
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.
Comment 34 Dan Williams 2008-09-08 13:29:12 UTC
*** Bug 551155 has been marked as a duplicate of this bug. ***
Comment 35 Dan Williams 2008-11-03 16:27:03 UTC
*** Bug 559070 has been marked as a duplicate of this bug. ***
Comment 36 Dan Williams 2009-04-12 22:33:53 UTC
*** Bug 578585 has been marked as a duplicate of this bug. ***
Comment 37 Bastien Nocera 2009-08-06 13:23:49 UTC
PAN support is already in recent versions of NetworkManager and NetworkManager-applet. Only thing left is DUN support, but that requires ModemManager support.
Comment 38 Dan Williams 2009-10-16 02:37:00 UTC
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.
Comment 39 Dan Williams 2010-01-28 19:45:46 UTC
The 'btdun' branches of both the applet and NM itself are now feature-complete and ready to be merged for 0.8.1.
Comment 40 Bastien Nocera 2010-02-06 15:03:03 UTC
*** Bug 609167 has been marked as a duplicate of this bug. ***
Comment 41 Aliaksandr Dzeshchanka 2010-02-23 10:34:50 UTC
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?
Comment 42 Dan Williams 2010-02-23 22:49:28 UTC
(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!
Comment 43 Dan Williams 2010-02-23 22:50:14 UTC
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!
Comment 44 Bastien Nocera 2010-03-04 23:44:53 UTC
*** Bug 611849 has been marked as a duplicate of this bug. ***
Comment 45 Bastien Nocera 2010-06-09 01:02:45 UTC
*** Bug 621044 has been marked as a duplicate of this bug. ***