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