Re: PATCH: Support for Bluetooth NAP devices

["Nathaniel McCallum" <nathaniel natemccallum com>]

So what is the right way to scan for devices and determine what
features they support?  How is that handled in balance with battery
life?

On Tue, May 13, 2008 at 7:38 PM, Marcel Holtmann <marcel holtmann org> wrote:
> 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
>
>
>