Re: PATCH: Support for Bluetooth NAP devices

[Marcel Holtmann <marcel holtmann org>]

Hi Dan,

> > Unfortunately, I left my cell phone at home.  I'll have to provide
> > lshal output later.  However, I don't really think it is necessary.
> > 
> > An Access Point is to wifi what a NAP (Network Access Point) is to bluetooth.
> 
> Right; where does the NAP get defined?

the Bluetooth network service has the definition. You can use D-Bus to
retrieve the list of configured access point.

Remember that Bluetooth has a 1:N mapping for host controller to access
points. You can connect to multiple access points at the same time using
the same Bluetooth radio.

> > The major differences is that for wifi the interface (ex. wlan0)
> > pre-exists the wireless connection, while for bluetooth the interface
> > (bnep0) has the same lifecycle as the wireless connection.  Once the
> > connection is established via Bluez (bnep), the pseudo-Ethernet
> > interface is created.  If the connection is torn down, the interface
> > disappears.  While the interface exists, it is treated exactly like a
> > normal Ethernet interface.
> 
> NM should be taking care of telling BlueZ to establish the bnep device;
> that's the issue here and why the patch you posted isn't a complete
> solution.

Using the Bluetooth network service you simply call Connect() via D-Bus
on the access point path.

The BlueZ source contains a file network-api.txt with the API
description of the network service.

> It's the same thing with DUN: NM needs to control the whole lifecycle of
> the rfcomm connection.  I don't want to have to set the thing up first
> in BlueZ, and then in NetworkManager.  You might have to pair the device
> with BlueZ, but that's fine.
> 
> NM connections should contain enough information to tell BlueZ what to
> do with the device.  You plug in your device, and NM recognizes that has
> a connection for that device.  NM tells BlueZ to create the bnep
> interface, and then NM connects with the bnep interface.
> 
> For DUN, NM show all the DUN connections you have defined, when you have
> a BT adapter plugged in.  When you chose one of those connections from
> the menu, NM will request BlueZ connect to the phone defined in that
> connection, and get something to create the rfcomm device, which it will
> then hand to pppd for the PPP connection.

You can use the Bluetooth serial service for creating this RFCOMM
device. Check serial-api.txt document from the BlueZ source.

> > I hope this makes sense.  Ideally, NM should treat each bluetooth
> > adapter (hci) as an "interface" (even though there is no interface)
> > and have NAP presence detection (similar to scanning for wifi APs).
> 
> NM should treat the adapter as a top-level device, just like wifi, cdma,
> gsm, and ethernet devices are treated.  When you want to connect via a
> NAP (or when NM autoconnects as such) then NM should instruct BlueZ to
> make the BT bits happen, and NM will handle the rest (layer 3 and
> above).
> 
> > However, this is non-trivial, and may not even be desirable.  However,
> > with this trivial patch, NetworkManager can work with these devices
> > NOW, it just requires that the connection be established outside of NM
> > (via bluez pand or the bluez network service).
> 
> Unfortunately, I'd like to fix this correctly, because if you don't, you
> either have to break API later or carry around the functionality people
> expect.  Bastien Nocera is working on bringing up DUN support which
> we'll use as the driver use-case for BT devices.
> 
> Any interest in expanding the patch to treat hci devices as top-level
> objects?  I think we can hash out some of the details if you are.

Actually using the HCI top-level device is the only right way of doing
this. That is also your entry point into the network and serial service.

Regards

Marcel