Bug#384379: [Pkg-bluetooth-maintainers] Bug#384379: WORK-AROUND for
"iscan not set"
Hendrik Sattler
debian at hendrik-sattler.de
Sat Dec 30 14:56:33 UTC 2006
Am Samstag 30 Dezember 2006 14:58 schrieb Filippo Giunchedi:
> On Wed, Dec 27, 2006 at 12:27:22PM +0100, Hendrik Sattler wrote:
> > 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.
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.
HS
More information about the Pkg-bluetooth-maintainers
mailing list