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

Hi David,

> > >>  This is a totally general PPPD plugin...
> > > 
> > > So I imagine that now we can believe that in some time in the future
> > > NM will make those dialers (gkdial, gnome-ppp etc) obsolete? Yay! :)
> > 
> > For this see
> > 
> > I'm working on it :-)
> This sounds like very interesting work, thanks a lot for looking into
> this!
> As you may or may not know Matthew Garrett (mjg59) is working on
> teaching HAL about Bluetooth devices including providing methods for
> discovering, pairing and querying a Bluetooth device for what services
> it provide. 

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.

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.

> With this work it's very likely that device objects with hal
> capabilities such  'serial.modem.hayescompatible' etc. might show up in
> the hal device tree with links so you can infer what devices it stems
> from. Then detecting the device is simply a matter of querying HAL.
> So I think it make sense to use HAL as the mechanism to discover devices
> and some generic desktop daemon / gizmo to discover Bluetooth devices.
> After all, Bluetooth has other devices that NetworkManager might not be
> interested in. Such as input devices, PDA's, printers and what not.
> We've also discussed today on #hal to teach HAL about IR devices and
> some of these might provide dial-up capabilities as well.

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.

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]