Re: PATCH: Support for Bluetooth NAP devices
- From: Dan Williams <dcbw redhat com>
- To: Nathaniel McCallum <nathaniel natemccallum com>
- Cc: networkmanager-list gnome org
- Subject: Re: PATCH: Support for Bluetooth NAP devices
- Date: Tue, 13 May 2008 22:13:18 -0400
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
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.
> 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
] [Thread Prev