Re: ppp using NM

[Dan Williams <dcbw redhat com>]

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.  The BT adapter should be a top-level device which has the ability
to create both DUN and PAN connections.  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.

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

Dan