Hi, there is a solution to this. After thoroughly stuying the bluez-utils code, I saw the reference to a config file, namely <dir>/<bdaddr>/config. This file needs an entry mode discoverable However, if the file is present in /var/lib/blueooth, that one is used. So you must delete the latter <bdaddr> dir or simply edit the config file there: # rm /var/lib/bluetooth/*/config
After that, just plug the usb-dongle out and back in and there you go :) You still need the following settings in /etc/bluetooth/hcid.conf: mode off: iscan disable; pscan disable; mode connectable: iscan disable; pscan enable; mode discoverable: iscan enable; pscan enable; The last one also needs discovto 0; to actually enable ISCAN on plug-in (doesn't affect mode setting). So cleaning up /var/lib/bluetooth should make those happy that used their bt dongles with earlier versions or change their setting in hcid.conf. REAL SOLUTION: /var/lib/bluetooth should be partly cleaned up if the dongle disappears to make it possible to follow configuration changes (currently NOT done). Care must be taken to only delete the "config" file, not pairing information. The configuration for the mode (off, connectable or discoverable) is already derived from the pscan and iscan settings in hcid.conf (see hcid/dbus.c:2166) BUT ONLY if the "config" file in /var/lib/bluetooth does not exist. This does not mean that the "config" file in it's current use is absolute non-sense as it preserves setting across hcid restarts. Thus, on bt dongle _removal_, the "config" file in /var/lib/bluetooth should be deleted. As this can happen during hcid down time, a udev rule may be a solution. 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! HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
