Re: ppp using NM

[Dan Williams <dcbw redhat com>]

On Thu, 2007-11-29 at 21:58 +0000, Bastien Nocera wrote:
> 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.

Right, I think DUN is the first priority.

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

Ok, but we need a way to dynamically determine what's around.  Having to
request a scan to find your phone does not fit in the interaction model
here, and we shouldn't have to do that.  If the BT adapter isn't doing
anything, NM should periodically request scans.  If the BT adapter is
doing something, I assume you can't _manually_ scan with hcitool either,
so the point is moot.

What happens when you just power on the phone and the devices are
already paired?  Do they find each other?  Or do you still need to scan
to find the phone?

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

I can't imagine the power drain for scanning is really that much more
than wifi, which is pretty negligible given how often NM (doesn't) scan.
There are intelligent ways to go about scanning.  Is it really that much
worse?  I don't think taking longer to scan is really a problem for the
interaction though, that's just something we have to suck up I think.

> What we could do though, is show the paired phones as top-level objects.

You mean, even if the phone isn't on or actually available at the
moment?  I'd rather not do that if at all possible; because if the
device isn't there, it shouldn't really be shown, because the user can't
do anything with it anyway.

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

Yeah, I don't really want NM doing the pairing.  I would expect that
only _paired_ phones would be exported by NetworkManager as things that
can be used, and only paired phones should show up in the applet menu.
Pairing is already handed nicely elsewhere and as you suggest, we
shouldn't also put that into NM.

However, we do need a clear path to make that happen, and we need to
create a flow for what happens when you plug in the BT adapter and want
to create a BT DUN connection.  We need to have a complete story 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?
> 
> 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.

Great!

Dan