Re: PATCH: Support for Bluetooth NAP devices

[Dan Williams <dcbw redhat com>]

On Tue, 2008-05-13 at 17:39 -0400, Nathaniel McCallum wrote:
> On Tue, May 13, 2008 at 4:11 PM, Dan Williams <dcbw redhat com> wrote:
> > On Sat, 2008-05-10 at 14:42 -0700, Nathaniel McCallum wrote:
> >  > Bluetooth NAP devices are pretty simple really.   You connect and (at
> >  > least in Linux) they emulate an ethernet device.
> >
> >  Can you send me the lshal output for when you've got one of these
> >  devices plugged in?
> >
> >  Also, what sets up the device?  How do you pair it?  When you plug it
> >  in, do you need to do any additional setup on the device before it has a
> >  bnepX interface?
> 
> 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 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.

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.

> When the bnep interface is created, HAL creates two new objects.  HAL
> does NOT report this as an ethernet device because, in reality, it
> isn't.  So instead of 'net.80203' occurring in both the
> info.capability and info.category keys, 'net.bluetooth' appears.  HAL
> also does not report the driver because in every case this type of
> device will use the bnep module. So my patch basically tells
> NetworkManager: assume 'net.bluetooth' == 'net.80203'.
> 
> The FDI file makes HAL report the driver name (which will ALWAYS be
> 'bnep' on this type of device).  This FDI should not be in upstream
> HAL because it is really specific to NM's usage of HAL. I'll leave it
> up to you to determine if NM's behaviour in this regard is correct.
> If it is correct, than the FDI file will need to be installed with NM.
>  If it is not correct, then fix NM and the FDI file can be ignored.
> 
> 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.

Dan