Re: PPTP Plugin Updated -- Ver. 0.6.9 Generally PPP capable?

Dan Williams wrote:
Here's the ideal NM situation.
Users will need to pre-pair and preconfigure their BT devices for use
with NM.  We'll likely include an application that will allow users to
scan for and select a BT device, pair with it, and set up the
carrier-specific GSM/CDMA settings for the dialup connection.
Ok so this all exists in the current PPP plugin... Well, barring the
ability to select the device from a list - I think the BlueZ Dbus API
will be the way forward there if only to avoid having to compile
against the BlueZ libs. But this is a minor detail.

Once the BT device is set up and known to NetworkManager, NM will
periodically request scans from BlueZ much like it does for wireless
networks from wpa_supplicant now.
Scanning may or may not be the way forward.  We'll have to see what
comes out in the wash with that.  For the moment, provided the necessary
logical bit to enable/disable connections (by some abstract criteria) is in place, we may simply use more liberal criteria. For Bluetooth connections the presence of an hci device would suffice for example.
The slick auto-connect of the wireless and wired networks is not so urgent
for other network types.  Not least because they my incur charges!
 If a "known" BT device is around and
supports DUN, NM will show that device in its menu.
That device?   You mean "the connections related to that device" yes?
Several may have been configured.

  The user will then
be able to select that device and use it for a DUN connection.
Select a connection to be established.
For this, we'll need a few things from BlueZ and HAL:

a) dbus methods to request scans and return scan results, along with
capabilities of each device (ie, DUN, handsfree, etc, or however that
b) dbus methods to pair with a device.  We _don't_ want NM to do the
actual pairing or anything, but NM should be able to just call pair(),
have whatever BlueZ dialog is need for PIN pop up, and then receive a
return code of success or failure.
c) dbus methods to retrieve the rfcomm serial port device name for a
specific, paired BT device
All that stuff can be done at present with relatively few calls to the
BlueZ libs directly or via libbtctl. So I imagine the DBUS code whether
it's in BlueZ directly or via HAL will be equally slick.

Bluetooth aside, I am more interested in the more general implications
for NetworkManager.  I think I'd better start a new thread though.
It doesn't really matter to me where I get the list of available BT
devices from, whether it's BlueZ or HAL, but I'd rather get them from
HAL if I can.

Marcel, Matthew: does this match with your ideas for how apps would use
BlueZ and BT infrastructure?


NetworkManager-list mailing list
NetworkManager-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]