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

[Marcel Holtmann <marcel holtmann org>]

Hi Matthew,

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

bad idea. If now low-level ACL links exists you need to page the device
and if it is not available you have to deal with page timeout. While a
device is paging another one, you can't page a second device or run an
inquiry. We will have other applications than NetworkManager making use
of the local Bluetooth adapter. And in case for Headset or Headphone
usage this can be end up in bad user experience.

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

We need to coordinate that. For now I would propose using the BlueZ
D-Bus API, because we are going to make that one final.

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

You should still think about the PIN stuff. The pairing action itself
will be done by BlueZ D-Bus API, but the new passkey agent interface
allows you to integrate the PIN input in your own wizard etc. This is
really cool. You can also generate a random PIN and then provide it via
a dialog etc.

And the SIM access profile has some weird requirements like 16 character
long PINs and at least an encryption key of 64-bit. The SIM access
profile can be used to authenticate a wireless LAN via your SIM card.
The Nokia 770 is actually supporting this already.

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

You might wanna run PPP directly over a RFCOMM socket, but if we bind it
to a RFCOMM TTY it should be possible to retrieve is device name. As I
mentioned we have support for this, but it is not on by default.

Regards

Marcel