Re: PATCH: Support for Bluetooth NAP devices

["Nathaniel McCallum" <nathaniel natemccallum com>]

If we aren't periodically scanning for bluetooth devices than I assume
we will NEVER autoconnect...  Is that the intention?

So for the UI, we'd have something like VPNs?

If that is correct, can you point me to where I need to start in the code?

On Tue, May 13, 2008 at 10:13 PM, Dan Williams <dcbw redhat com> wrote:
> On Tue, 2008-05-13 at 21:09 -0400, Nathaniel McCallum wrote:
>  > 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?
>
>  We don't scan with Bluetooth automatically.  We should scan when
>  initially setting up the DUN or PAN or NAP connection (or in the
>  connection editor when modifying the connection), because that's the
>  user hitting a "Scan" button explicitly to find the device they want to
>  connect to.  But NM should not be scanning for BT devices like it does
>  for wifi APs.
>
>  Battery life won't really be affected since if the user is dumb enough
>  to keep hitting the "Scan" button in the connection editor when editing
>  a connection, they get the battery life they deserve :)
>
>  Basically, when setting up the connection, there should be an entry for
>  the BT address of the thing you want to connect to on the other side (be
>  it a phone or a remote NAP or whatever).  You can either type in the BT
>  MAC there, or there should be a little "scan" button next to the entry
>  that brings up a list of BT devices that are in range and advertise the
>  right profiles, just like the current Gnome BT applet allows you to look
>  for devices that support OBEX.
>
>  For things like BT which require heavier-weight initial configuration,
>  you won't be able to just connect to something from the applet menu
>  until you've set up the connection manually.  We can try to streamline
>  that setup process as much as possible though, and punt really advanced
>  stuff to the connection editor.
>
>  Dan
>
>
>
>  > 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
>  > >
>  > >
>  > >
>
>