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 <[EMAIL PROTECTED]> 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 > > > _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
