Bug#384379: [Pkg-bluetooth-maintainers] Bug#384379: WORK-AROUND for "iscan not set"

[Marcel Holtmann]

Hi Hendrik,

> > > Note that deleting the "config" file in /var/lib/bluetooth is an
> > > essential part of the solution.
> >
> > this is a big _NO_. Don't mess with the configuration storage directly.
> > The configuration storage has priority over the hcid.conf file and this
> > is meant to be this way.
> 
> And that's not written down anywhere in the user documentation.

that is the real bug here. Patches for documentation updates are always
welcome.

> > The "iscan" and "pscan" config option are some legacy option that are
> > still available for some strange corner cases for some embedded distros
> > and they are not meant for general and permanent configuration.
> 
> So what's the proposal? Configuration files have to be in /etc and not 
> in /var/lib!

Actually that is not fully correct. The values in /etc are supposed to
be changed be an administrator the values in /var/lib can be changed by
the daemon. And that is exactly what happens.

> The administrator should be able to change the default (visibility or not) or 
> there should be an always working default.

The default is not visible (due security reasons) and if you decide it
to switch it to visible (even with a low-level HCI command) it will only
stay visible for 180 seconds. That is the default starting with 3.x.

> That is currently not the case because the bluetooth guys change stuff but the 
> user frontends do catch up a bit late. Just remember the passkey situation 
> and this is pretty much the same. It probably gets solved in the long run but 
> that's a strange idea of development :-/

It is actually solved for all GNOME and command line users. I don't know
about the KDE guys, but I am sure they have something similar.

> > If people don't learn that hcid.conf are proposed default values for the
> > cold run only, then I might simply remove the whole file in the next
> > upstream release. So stop writing ugly distribution specific hacks and
> > better ask upstream for it. There might might a real bug hiding
> > somewhere.
> 
> If package maintainers and upstream authors don't learn to document such 
> thing, the user will not learn. /etc/bluetooth/hcid.conf is a configuration 
> file and I expect that changes are respected. It is written _NOWHERE_ that 
> this only defines an initial state.
> Reading hcid.conf manpage tells me nothing about that.

Fully agreed. That needs fixing.

> > First of all this is an ugly hack and has no right to exist. Second the
> > configuration storage is meant to be permanent.
> 
> An ugly hack for an ugly situation.
> 
> I give you my point of view:
> _I_ wanted to fix discoverability of my system without some strange DBUS 
> commands that are documented nowhere but in the code.
> Yes, by now I know that hcid/dbus-api.txt exists but only in the source 
> package because it is not in the binary package.

Actually I think the dbus-api.txt document should be included as docs
into the binary package.

> Beside that, running the dbus command suggested in this bug report works, too.
> It should be noted, though, that you have to be root.

No. You have to be console user (or root).

> It probably is the better alternative with exceptions:
> * you cannot change the mode of devices that are currently not plugged in

That is true. The case to change settings for not active devices is
kinda strange. I know that there might be corner cases, but I never
fully got convinced that this is needed.

> * you can only refer to devices by using the device name, not the address

Actually you can use "manager.FindAdapter(address)" to get the path for
an adapter. Remember that the path for an adapter is only a string. It
has no real meaning. You shouldn't trust that they stay the same.

> So is there an easy command line tool for all those dbus options (except using 
> raw dbus command)?: no == very bad usibility (and an awful lot to type for 
> one option)
> 
> So how can you solve this problem with your input:
> * ship the dbus API documenation in the binary packages

Definitely.

> * give the user and root a shell tool to make use of the things in the bluez 
> dbus API without getting bloody hands by using dbus-send

Since we wanna avoid a Python dependency, I seems that there is finally
need for a btconfig tool written in plain C.

> * document in the manpages what you wrote here

Agreed.

Regards

Marcel