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

[Marcel Holtmann]

Hi Hendrik,

> > > I am not sure why SCAN_INQUIRY is not set in discovto is not 0 (see
> > > hcid/main.c:295). This is probably to not make it discoverable after
> > > plugging the bt dongle in and thus correct behaviour. However, I do not
> > > know of any user program that can actually handle that (kdebluetooth
> > > cannot). Thus, in Etch, "discovto 0" should be the default setting!
> > >
> > > A specific configuration for each dongle is already possible in
> > > hcid.conf, so there is no problem to do configuration for specific
> > > devices.
> > >
> > > It actually IS possible to correctly fix this before Etch!
> >
> > great, thanks for investigating this. I'm going to add discovto 0; as
> > default plus adding some documentation about the [IP]SCAN problem. Can I
> > quote this mail?
> 
> Yes, maybe correct grammatical mistakes if present.
> 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.

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.

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.

> I did some testing with udev and the problem actually also is a kernel 
> problem. There is some strange dependency between the uevent call to udev and 
> hcid detecting the device:
> A udev script can only act when the bt dongle is plugged _in_ (ACTION=="add") 
> because on removal, the address sysfs attribute is not available anymore 
> (removed too early).
> The rule to call a script for removal can thus look like:
> SUBSYSTEM=="bluetooth", ACTION=="add", "RUN+=some/script"
> 
> The actual script may look like:
> -----------------some/script------------------
> #!/bin/sh
> BLUEZ_CONF_DIR=/var/lib/bluetooth
> 
> sleep 5
> 
> BDADDR=$(cat "/sys${DEVPATH}/address")
> CONF_FILE=${BLUEZ_CONF_DIR}/${BDADDR}/config
> 
> rm -f ${CONF_FILE}
> ----------------------------------------------
> The sleep is a hack (else the BDADDR is 00:00:00:00:00:00) and I did not test 
> how bad this interacts with what hcid does.
> You cannot do this with hcid itself because it cannot differ between "already 
> present when starting" (coldplug) and hotplug.
> Solution can be the above script with added dbus init call (hcid and dbus must 
> be started before udev, then) and disabled autoinit in hcid.

First of all this is an ugly hack and has no right to exist. Second the
configuration storage is meant to be permanent.

Regards

Marcel