Re: ppp using NM

[Bastien Nocera <hadess hadess net>]

On Thu, 2007-11-29 at 14:56 -0500, Dan Williams wrote:
> On Thu, 2007-11-29 at 15:48 +0200, Tambet Ingo wrote:
> > On Nov 29, 2007 1:47 AM, Bastien Nocera <hadess hadess net> wrote:
> > > I'll be more than happy writing the GPRS bits of it.
> > 
> > Awesome!
> > 
> > > Is there any
> > > Bluetooth related code in the code you're writing?
> > 
> > No, the current code only handles communications with serial devices
> > like opening, closing, configuring, sending (AT) commands, waiting for
> > any/certain replies, etc. It also implements a GSM (while currently
> > called UmtsDevice, we're looking for a better name for it) device that
> > is implemented on top of serial device and handles the specific AT
> > commands required to establish a connection.
> > 
> > Although I have no idea how bluetooth devices work, I assume there's
> > some magic that needs to happen and as a result there will be a serial
> > device that takes AT commands? If so, then bluetooth (NM) device could
> > be just a subclass of the current GSM device, do it's magic in the
> > initialization phase and let the GSM device take care of everything
> > else.
> 
> I think I've said in a number of places about how I'd like BT DUN to
> work.

Yep, we're just rehashing with a better view of what's been done
though :)

>   The BT adapter should be a top-level device which has the ability
> to create both DUN and PAN connections.

PAN connections are very very different from DUN though, and we
certainly don't need to implement PAN now.

>   For the DUN case, we don't want
> to show the BT _adapter_ in the applet menu, we want to show _phones_.
> So when your phone is around (requires scanning periodically I think?)
> it'll pop into the menu, and it would work just like I posted in my blog
> about how 3G cards would work.  You've got some connections, and they
> apply to your phone, and you pick one.  That's it.

You can't go around scanning forever. People always ask that of
Bluetooth, and you can't do it, especially with older BT 1.0 devices
that can't scan and do something at the same time.

That, and it just drains your battery, and takes a long time to do
(longer than looking for an AP using Wi-Fi).

What we could do though, is show the paired phones as top-level objects.
We could then have sub-menus with the connection providers, and the
ability to create new connections. That way, we can warn the user if the
phone isn't available, without causing problems.

> Something has to handle the pairing, and the NMDevice subclass for BT
> DUN needs to handle talking to BlueZ over D-Bus to pick find the BT
> adapters and make them scan stuff.  We also need to define the NMSetting
> subclass for Bluetooth.  Thoughts here?

I don't think that the pairing should happen in NM. We're hoping to have
the Bluetooth wizard ready soon (depends on whether we manage to get
Marcel to commit our patches ;), and that should be the place where we
create the pairings.

> > > I'm thinking specifically of the ppp-manager having a special casing for
> > > devices that look like Bluetooth addresses, and having it create rfcomm
> > > devices as appropriate (as pppd still doesn't have any native Bluetooth
> > > support).
> > 
> > The way things currently work is that we call pppd only after the
> > serial connection is already established. Can this be done with
> > bluetooth devices as well?
> 
> It's the way it currently works with rfcomm, but I thought that there
> was a way to get rid of the /dev/rfcomm0 device creation step and talk
> directly to the device or something.  Bastien?

Yep, the way is get David Woodhouse to finish his work on native
Bluetooth support in the kernel and in pppd. The good thing is that
using the hcid D-Bus service means we can still work-around the problem
without being too Linux specific, and with good automation.

Cheers