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

[Marcel Holtmann <marcel holtmann org>]

Hi Dan,

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

you will get discovered devices via signals. This basically only
includes the BD_ADDR, the class of device and the RSSI value. So you
don't have to actually scan for devices. This already works and the
BlueZ D-Bus API also signals you when it starts scanning for new devices
and when a scan is finished. It is designed the way that even when
another application scans for new devices you can also see the list of
devices.

In the future it will also take care of the service discovery and send
signals for available services. However this hasn't been implemented so
far.

Remember that Bluetooth devices can be switched invisible and thus you
won't see them anymore. So you need to store "used" devices by yourself.

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

We have this already. Just fixing some minor details, but this is one of
the most tested features of the new BlueZ D-Bus API. For the PIN dialog
you can choose to provide one for yourself or actually let the default
one handle it for you. I actually would advise to provide your own one,
but this is a minor detail.

> c) dbus methods to retrieve the rfcomm serial port device name for a
> specific, paired BT device

We have something like that, but by default it is not activated now. It
needs more testing and I wanna release the other features first.

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

Who cares in the end. I would go for the HAL solution by myself, but
that's a long way to go. It is not that easy to get a really nice and
easy implementation. Bluetooth is not an easy solution. It is full of
weird protocols.

Regards

Marcel