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
