Re: PPTP Plugin Updated -- Ver. 0.6.9 Generally PPP capable?
- From: Matthew Garrett <mjg59 srcf ucam org>
- To: Dan Williams <dcbw redhat com>
- Cc: networkmanager list <networkmanager-list gnome org>
- Subject: Re: PPTP Plugin Updated -- Ver. 0.6.9 Generally PPP capable?
- Date: Thu, 8 Jun 2006 16:01:16 +0100
On Thu, Jun 08, 2006 at 10:46:28AM -0400, Dan Williams wrote:
> 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.
If we put stuff in hal, this will (other than the carrier-specific
stuff) just be a matter of calling a couple of device methods. Does that
> 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. If a "known" BT device is around and
> supports DUN, NM will show that device in its menu. The user will then
> be able to select that device and use it for a DUN connection.
I'm not convinced that's a good idea. Discovery seems to take a
significant quantity of power, and I was under the vague impression that
it interfered with existing connections. If you know the mac address of
the device in question, why not just l2ping for it rather than
performing full discovery?
> a) dbus methods to request scans and return scan results, along with
> capabilities of each device (ie, DUN, handsfree, etc, or however that
As I mentioned, I'm considering putting this in hal - would that seem
reasonable? If so, should we discuss the API? This doesn't conflict with
doing stuff directly via bluez, but it means that applications can
potentially share information more easily.
> 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.
Yup. That's straightforward (and again I was considering allowing that
> c) dbus methods to retrieve the rfcomm serial port device name for a
> specific, paired BT device
Indeed. As might be obvious by now, I'd kind of like that to end up in
Matthew Garrett | mjg59 srcf ucam org
] [Thread Prev