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

[Dan Williams <dcbw redhat com>]

On Thu, 2006-06-08 at 16:01 +0100, Matthew Garrett wrote:
> 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 
> seem reasonable?

Yup.  I have no problem with method calls on HAL.

> > 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?

If there's an easy way to do this without doing system("l2ping xxx")
then I'll do it, but I pretty much refuse to add more system() calls to
NM and I'm trying to take them all out.  I haven't looked at the logic
of l2ping yet, but if it's really complicated, could this functionality
be moved into BlueZ itself and exposed via dbus?

However, this idea is quite a bit more attractive than scanning, yes.
This also assumes that people won't have that many BT devices they pair
with that do DUN, which likely is an OK assumption (but it's not for
802.11, of course).

> > a) dbus methods to request scans and return scan results, along with
> > capabilities of each device (ie, DUN, handsfree, etc, or however that
> > works)
> 
> 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.

Sure; as long as I can get a list of BT devices that support DUN, I'm
happy, wherever it comes from.  I've got a preference for HAL though,
since that reduced the number of potential cracks through with stuff can
fall, and reduces the potential for mismatch of information between two
services like HAL and BlueZ.

> > 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 
> via hal)
> 
> > 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 
> hal :)

Agreed.  Ideally, stuff like DUN would end up being a
property/capability on the device's node in the HAL device list.  NM
could then query for devices supporting that capability quite easily.

Dan