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

[Marcel Holtmann <marcel holtmann org>]

Hi Matthew,

> > we will have a full D-Bus API for most common tasks in the next BlueZ
> > release. It will be bluez-utils-3.0 and we are just working on the last
> > few blocker bugs. My actual plan is to get it out this week.
> 
> Yup. I've been working on this with CVS.

watch out for some final API changes. We might do one last one.

> > The API includes support for device discovery, pairing functions and a
> > couple of signals for stuff that might happen behind your back. So in
> > most cases there is no longer need to query stuff. However it doesn't
> > support service discovery at the moment. We need to rewrite the SDP
> > layer to make it fully asynchronous and there was simply no time for it,
> > but this will be addressed in future versions.
> 
> I planned on mirroring bluetooth information in hal, rather than leaving 
> it up to applications to query bluez directly. There's two reasons for 
> this:

Be careful how you do the mirroring. We spent a lot of time discussing
what methods and signals are actually needed. Especially if you have a
passive application etc. I would prefer that you call into the BlueZ
D-Bus whenever possible instead of storing the information by yourself.

> 1) It makes it easier for applications if there's one source of 
> information about hardware they can drive. Networkmanager, for instance, 
> will want to know about bluetooth devices, ir devices, any 
> serially-connected modems we can probe, usb modems (where supportable) 
> and so on.

If we can achieve this, I am all for it. However it is not really
trivial and we must make sure that certain information are kept in a
central place or requested every time. You will see some corner cases
with a couple of devices over time. For example when they change the
RFCOMM channel number if you reboot them. Scary stuff like that, that
even we haven't addressed so far.

> 2) For certain trivial purposes, it means that the application doesn't 
> need to rely on the bluez API - any different bluetooth stack can just 
> be hidden behind hal.

The BlueZ D-Bus API is designed to hide from BlueZ library or kernel
specific things. So in general you can reuse it for FreeBSD etc. Any
Gnome application using the BlueZ D-Bus API should work on any system
that provides a Bluetooth stack this interface.

Don't try to duplicate that effort, because it is a mess and some
internal code of hcid is really scary.

> > To make Bluetooth fully HAL aware you need to include SDP into the
> > kernel and you don't wanna to that. Trust me. The protocol is so bad and
> > the number of remote exploits would increase, because you simply can't
> > get the implementation right.
> 
> Though hal generally pulls stuff out of sysfs, there's no reason that it 
> has to. The current interface that I'm playing with is something like 
> the following:
> 
> Bluetooth HCI controllers will provide a "Scan" method. Calling 
> org.freedesktop.Hal.Device.Bluetooth.Scan on that controller will then 
> populate the hal tree with any discovered devices and their names (where 
> available). Each of these devices will support two further methods - 
> "Browse" and "Pair". Pair is fairly obvious, and Browse will make sdp 
> calls to further populate the hal tree with individual services (it 
> makes sense to think of these as individual devices from the hal point 
> of view). So, we might end up with something like this:
> 
> pci
>   usb controller
>       bluetooth controller
>           phone
>              obex ftp
>              dial up networking
> 
> with appropriate capabilities flags.

We kept the design flat on purpose for now, because we are still in some
kind of learning process of which HCI and SDP functions (GAP profile)
you should really provide to the applications.

However if we can present all Bluetooth functionality through HAL, I am
all for it. However the service discovery needs a lot of work and I made
the decision not to include it in the bluez-utils-3.0 release.

If you have any public code available, let me know. I like to play with
it a little bit.

> None of this is strictly dependent upon bluez providing a dbus 
> interface, though that makes life a great deal easier than having to 
> do things the old way.

The old way is horrible and we still need to do a lot of code cleanups
after the bluez-utils-3.0 release. And we need a new passkey agent.

> > One of my ideas is to have an enhanced pand with D-Bus support that will
> > take care of PAN and LAN access connections. So NetworkManager can use
> > this daemon to establish Bluetooth connections.
> 
> That would also be cool.

Goes along with a generic Bluetooth audio daemon, but that's another
story.

Regards

Marcel