Re: ppp using NM

[Marcel Holtmann <marcel holtmann org>]

Hi Dan,

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

we can't keep scanning around. Bluetooth is not designed like this and I
have mentioned this multiple times now. It will get you the worst
experience ever. Besides the unneeded power consumption (inquiry is an
expensive operation) you will have problems if you have an HID or audio
connection open. There is already enough interference in the 2.4 GHz
band, you don't wanna make it more.

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

You can easily list already paired devices and you will get signals if
new devices have been paired or if a bonding has been removed. So
listing paired devices would be absolutely enough.

In the case a device is not in range when selecting it you get a page
timeout. Same as if the access point has been switched off since the
last time you've seen the beacon.

Also a device could be non-discoverable, but still connectable. In this
case the scanning will not show the device, but it could be used. So
scanning all the time gives you nothing. It wastes resources, blocks the
baseband and consumes power.

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

It is already bad in case of Wifi. It is not negligible. If there is no
UI to update and you have a connection, there is no need to scan at all.
However NM keeps scanning.

And we don't talk about the interference between Bluetooth and Wifi when
we keep scanning all the time. Use a spectrum analyzer to see what
happens. Bluetooth is designed in a way that makes it quite robust, but
it has its limits. Wifi on the hand is not robust at all.

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

See my comment above. Scanning doesn't help you to determine if a phone
is in range or not. It simply doesn't work this way.

Regards

Marcel