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

[Antony J Mee <A J Mee ncl ac uk>]

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
> works)
> 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?
>
> Dan
>
>
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>