[Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Felix Homann]

Hi,

though I already filed bug reports to the Debian BTS [1],[2] I'd like to ask 
for advice here, too.

First, using bluez-utils 3.1-* from Debian/Sid I can't discover my PC from 
other BT devices. I tried this with 3 different BT cards/dongles. Downgrading 
to bluez-utils 2.25-1 makes my system visible again.

Second, kbluetoothd will not find other BT devices when I use a Belkin F8T013 
dongle and bluez-utils 3.1-*, 'hcitool scan' works fine, though. While a  
SPHINX PCMCIA card and an EPoX BT-DG03 work fine with kbluetoothd and 
bluez-utils 3.1-* the Belkin dongle will only play together with bluez-utils 
<=2.25-1.

Any ideas?

Kind regards,

Felix

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379401
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379403

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Marcel Holtmann]

Hi Felix,

> though I already filed bug reports to the Debian BTS [1],[2] I'd like to ask 
> for advice here, too.
> 
> First, using bluez-utils 3.1-* from Debian/Sid I can't discover my PC from 
> other BT devices. I tried this with 3 different BT cards/dongles. Downgrading 
> to bluez-utils 2.25-1 makes my system visible again.
> 
> Second, kbluetoothd will not find other BT devices when I use a Belkin F8T013 
> dongle and bluez-utils 3.1-*, 'hcitool scan' works fine, though. While a  
> SPHINX PCMCIA card and an EPoX BT-DG03 work fine with kbluetoothd and 
> bluez-utils 3.1-* the Belkin dongle will only play together with bluez-utils 
> <=2.25-1.
> 
> Any ideas?

maybe the Inquiry with RSSI quirks are messing it up. Please post the
output of "hciconfig -a".

What happens if you call "hciconfig hci0 inqmode 0"?

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Felix Homann]

On Thursday 27 July 2006 12:43, Marcel Holtmann wrote:
Hi Marcel,

thanks for replying so quickly!

> maybe the Inquiry with RSSI quirks are messing it up.

Whatever that means ;-)

> Please post the output of "hciconfig -a".

Here's the output:

hci0:   Type: USB
        BD Address: 00:00:3A:6A:1B:A0 ACL MTU: 1017:8 SCO MTU: 64:0
        UP RUNNING PSCAN
        RX bytes:592 acl:0 sco:0 events:32 errors:0
        TX bytes:337 acl:0 sco:0 commands:22 errors:0
        Features: 0xff 0xfb 0x8d 0xfe 0x9f 0xf9 0x00 0x80
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'jawaka (Belkin)'
        Class: 0xbe010c
        Service Classes: Networking, Rendering, Capturing, Object Transfer, Audio, Information
        Device Class: Computer, Laptop
        HCI Ver: 2.0 (0x3) HCI Rev: 0x2073 LMP Ver: 2.0 (0x3) LMP Subver: 0x410e
        Manufacturer: Broadcom Corporation (15)

> What happens if you call "hciconfig hci0 inqmode 0"?

kbluetoothd finds other devices after that command! (It doesn't make my PC visible to other 
devices though). Here's the output of "hciconfig -a" afterwards:

hci0:   Type: USB
        BD Address: 00:00:3A:6A:1B:A0 ACL MTU: 1017:8 SCO MTU: 64:0
        UP RUNNING PSCAN
        RX bytes:592 acl:0 sco:0 events:32 errors:0
        TX bytes:337 acl:0 sco:0 commands:22 errors:0
        Features: 0xff 0xfb 0x8d 0xfe 0x9f 0xf9 0x00 0x80
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'jawaka (Belkin)'
        Class: 0xbe010c
        Service Classes: Networking, Rendering, Capturing, Object Transfer, Audio, Information
        Device Class: Computer, Laptop
        HCI Ver: 2.0 (0x3) HCI Rev: 0x2073 LMP Ver: 2.0 (0x3) LMP Subver: 0x410e
        Manufacturer: Broadcom Corporation (15)


Is this a bug within the Belkin dongle? Can I change something in hcid.conf?

Kind regards,

Felix

 


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Marcel Holtmann]

Hi Felix,

> > maybe the Inquiry with RSSI quirks are messing it up.
> 
> Whatever that means ;-)

with bluez-utils-3.x we try to activate Inquiry with RSSI by default and
in your case it doesn't seem to work.

What does "hciconfig hci0 features version" tell you about your dongle.

Please also include the output of "hcidump -X -V" while starting an
inquiry. With inqmode 0 and inqmode 1.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.2, kbluetoothd

[Paulo Wollny]

Hi,

trying to browse my phone (a SE W900i) with OBEX File Transfer, i
allways get an error message.
The phone can start file transfer, but i can not browse and pick files
from the computer (i.e. trying to get the phone files).
Any hint?

Best regards,

Paulo Wollny

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Felix Homann]

On Thursday 27 July 2006 12:58, Felix Homann wrote:

> kbluetoothd finds other devices after that command! (It doesn't make my PC
> visible to other devices though). 

Part of the visibility issue seems to be that only PSCAN will be enabled 
regardless of what I specify in hcid.conf. If I manually do a 'hciconfig hci0 
piscan' everything is fine again. 

Is this a Debian bug?

Kind regards,

Felix

 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Alastair Tse]

Hi,

I'm also experiencing the same behaviour as Felix with a Belkin dongle
(Broadcom) with bluez-libs-3.2, bluez-utils-3.2. This is where ISCAN is
not set even though it is enabled in hcid.conf. I've compiled from
source on a Gentoo Linux box.

One additional thing that I would like to add is that I see this in my
syslog:

Jul 28 00:10:15 qoo hcid[23009]: HCI dev 0 registered
Jul 28 00:10:15 qoo hcid[23009]: Device hci0 has been added
Jul 28 00:10:15 qoo hcid[23009]: Register path:/org/bluez/hci0
fallback:0
Jul 28 00:10:15 qoo hcid[23009]: HCI dev 0 up
Jul 28 00:10:15 qoo hcid[23009]: Starting security manager 0
Jul 28 00:10:16 qoo hcid[23009]: Can't write inquiry mode for hci0:
Connection timed out (110)

If I use Felix's workaround by enabling ISCAN using 'hciconfig hci0
piscan' after the device is up, that error message about inquiry mode
does not come up.

Here is my hciconfig -a before using the workaround 'hciconfig hci0
piscan':

liquidx@qoo /usr/portage $ hciconfig -a
hci0:   Type: USB
        BD Address: 00:03:C9:2D:3E:8F ACL MTU: 377:10 SCO MTU: 16:0
        UP RUNNING PSCAN
        RX bytes:408 acl:0 sco:0 events:18 errors:0
        TX bytes:320 acl:0 sco:0 commands:18 errors:0
        Features: 0xff 0xfd 0x05 0x00 0x00 0x00 0x00 0x00
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'qoo'
        Class: 0x3e0100
        Service Classes: Networking, Rendering, Capturing, Object
Transfer, Audio
        Device Class: Computer, Uncategorized
        HCI Ver: 1.1 (0x1) HCI Rev: 0x2 LMP Ver: 1.1 (0x1) LMP Subver:
0x1007
        Manufacturer: Broadcom Corporation (15)


Hope this helps with nailing down the problem.

Cheers,

Alastair


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Marcel Holtmann]

Hi Felix,

> > kbluetoothd finds other devices after that command! (It doesn't make my PC
> > visible to other devices though). 
> 
> Part of the visibility issue seems to be that only PSCAN will be enabled 
> regardless of what I specify in hcid.conf. If I manually do a 'hciconfig hci0 
> piscan' everything is fine again. 

now you are mixing things. The inquiry mode has nothing to do with the
scan mode.

The inquiry mode defines what inquiry result events you will see.
Basically you wanna use Inquiry with RSSI from the Bluetooth 1.2
specification to additionally get the RSSI value.

The scan mode defines is you are visible and connectable. The D-Bus API
sets you to connectable only unless you disable the discoverable timeout
and set your yourself to discoverable. This is a feature of the new 3.x
generation that will make you automatically unvisible after a certain
amount of time.

These two things are not related. And start sending in "hcidump -X -V"
outputs instead of speculating.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]

Hi Alastair,

> I'm also experiencing the same behaviour as Felix with a Belkin dongle
> (Broadcom) with bluez-libs-3.2, bluez-utils-3.2. This is where ISCAN is
> not set even though it is enabled in hcid.conf. I've compiled from
> source on a Gentoo Linux box.
> 
> One additional thing that I would like to add is that I see this in my
> syslog:
> 
> Jul 28 00:10:15 qoo hcid[23009]: HCI dev 0 registered
> Jul 28 00:10:15 qoo hcid[23009]: Device hci0 has been added
> Jul 28 00:10:15 qoo hcid[23009]: Register path:/org/bluez/hci0
> fallback:0
> Jul 28 00:10:15 qoo hcid[23009]: HCI dev 0 up
> Jul 28 00:10:15 qoo hcid[23009]: Starting security manager 0
> Jul 28 00:10:16 qoo hcid[23009]: Can't write inquiry mode for hci0:
> Connection timed out (110)

the attached patch might help. If we have a Bluetooth 1.0b or 1.1 device
without a quirk to enable inqmode, we shouldn't even try to change the
inquiry mode. Seems that the Broadcom dongles are really sensible if you
try to send a command they don't support.

Regards

Marcel


[-- Attachment #2: patch --]
[-- Type: text/x-patch, Size: 1094 bytes --]

Index: hcid/device.c
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/device.c,v
retrieving revision 1.14
diff -u -r1.14 device.c
--- hcid/device.c	26 Jul 2006 13:42:10 -0000	1.14
+++ hcid/device.c	28 Jul 2006 01:30:41 -0000
@@ -189,6 +189,7 @@
 	if (hci_read_local_version(dd, &ver, 1000) < 0) {
 		error("Can't read version info for hci%d: %s (%d)",
 					dev_id, strerror(errno), errno);
+		hci_close_dev(dd);
 		return -errno;
 	}
 
@@ -200,19 +201,24 @@
 	if (hci_read_local_features(dd, features, 1000) < 0) {
 		error("Can't read features for hci%d: %s (%d)",
 					dev_id, strerror(errno), errno);
+		hci_close_dev(dd);
 		return -errno;
 	}
 
 	memcpy(dev->features, features, 8);
 
 	inqmode = get_inquiry_mode(dev);
+	if (inqmode < 1)
+		goto done;
 
 	if (hci_write_inquiry_mode(dd, inqmode, 1000) < 0) {
 		error("Can't write inquiry mode for hci%d: %s (%d)",
 					dev_id, strerror(errno), errno);
+		hci_close_dev(dd);
 		return -errno;
 	}
 
+done:
 	hci_close_dev(dd);
 
 	info("Device hci%d has been activated", dev_id);

[-- Attachment #3: Type: text/plain, Size: 348 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Felix Homann]

Hi Marcel,

On Friday 28 July 2006 03:20, Marcel Holtmann wrote:
> Hi Felix,
> now you are mixing things. 

I don't think so. In my original post I mentioned two issues. One could be 
worked around by "hciconfig hci0 inqmode 0". kdebluetoothd can find other 
devices afterwards. 

(BTW, why is this only necessary for kdebluetoothd, 'hcitool scan' works fine 
without setting the inqmode first. Why has this not been an issue with the 
2.x series of bluez?)

The other issue didn't get a reply. (Maybe I should have put both issues in 
differnet threads like I did in the Debian BTS, sorry..)

> The inquiry mode has nothing to do with the 
> scan mode.

Sure, but there's still the other issue: My system can't be found by other 
devices. Here's a more detailed report:

1. My system can only be found by other devices if I enable inquiry scan 
manually using 'hciconfig hci0 iscan' (or piscan). It's the only way I found 
so far. 'hciconfig -a' will show "UP RUNNING ISCAN". 

2. "iscan enable;" in hcid.conf will not make my system visible (in 
contradiction to what the man page says), 'hciconfig -a' will show "UP 
RUNNING PSCAN".

3. "pscan disable;" in hcid.conf  will not disable PSCAN.  'hciconfig -a' will 
show "UP RUNNING PSCAN".

4. It doesn't matter (with respect to 'hciconfig -a' output and visibility) at 
all if there is any 'iscan/pscan enable/disable' line at all: PSCAN will show 
up, ISCAN not.

5. All of this happens with every BT card/dongle I have at hand 
(SPHINX/Belkin/EPoX).

> The scan mode defines is you are visible and connectable. The D-Bus API
> sets you to connectable only unless you disable the discoverable timeout
> and set your yourself to discoverable.

How do I set the discoverable timeout? How am I supposed to set myself 
discoverable? Are there new options in hcid.conf? Where is it documented?

> This is a feature of the new 3.x 
> generation that will make you automatically unvisible after a certain
> amount of time.

Where is it documented? (Generally I've been missing such a feature. I just 
don't want to be invisble from the start.)

> These two things are not related.

Yes, read above.

> And start sending in "hcidump -X -V"  outputs instead of speculating.

I did not know of this. Here's the output of "hcidump -X -V" while my phone is 
scanning for devices:

# hcidump -X -V
HCI sniffer - Bluetooth packet analyzer ver 1.31
device: hci0 snap_len: 1028 filter: 0xffffffff

That's really all there is. The output doesn't change after 
issueing 'hciconfig hci0 piscan', but my phone can see my PC afterwards. 
After a minute or so hcidump spits out this:

< HCI Command: Write Scan Enable (0x03|0x001a) plen 1
    enable 2
> HCI Event: Command Complete (0x0e) plen 4
    Write Scan Enable (0x03|0x001a) ncmd 1
    status 0x00
< HCI Command: Read Scan Enable (0x03|0x0019) plen 0
> HCI Event: Command Complete (0x0e) plen 5
    Read Scan Enable (0x03|0x0019) ncmd 1
    status 0x00 enable 2

Afterwards my system is invisble again, I guess that's the timeout you've 
mentioned.

Kind regards,

Felix

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Marcel Holtmann]

Hi Felix,

> > now you are mixing things. 
> 
> I don't think so. In my original post I mentioned two issues. One could be 
> worked around by "hciconfig hci0 inqmode 0". kdebluetoothd can find other 
> devices afterwards. 
> 
> (BTW, why is this only necessary for kdebluetoothd, 'hcitool scan' works fine 
> without setting the inqmode first. Why has this not been an issue with the 
> 2.x series of bluez?)

the default inquiry mode for 2.x is 0. It will never be changed until
you tell it to change. For the 3.x generation the highest possible
inquiry mode will be set. It will be determined from the feature bits or
some hardcoded quirks.

To make inquiry mode 1 or 2, you need to know about Inquiry Results with
RSSI and Extended Inquiry Results. And for some broken dongles also
about Inquiry Results with RSSI and Page Scan. Seems kdebluetooth
doesn't know about them.

And this is where the new D-Bus API comes into play. It takes care of
all these things for you.

> The other issue didn't get a reply. (Maybe I should have put both issues in 
> differnet threads like I did in the Debian BTS, sorry..)
> 
> > The inquiry mode has nothing to do with the 
> > scan mode.
> 
> Sure, but there's still the other issue: My system can't be found by other 
> devices. Here's a more detailed report:
> 
> 1. My system can only be found by other devices if I enable inquiry scan 
> manually using 'hciconfig hci0 iscan' (or piscan). It's the only way I found 
> so far. 'hciconfig -a' will show "UP RUNNING ISCAN". 
> 
> 2. "iscan enable;" in hcid.conf will not make my system visible (in 
> contradiction to what the man page says), 'hciconfig -a' will show "UP 
> RUNNING PSCAN".
> 
> 3. "pscan disable;" in hcid.conf  will not disable PSCAN.  'hciconfig -a' will 
> show "UP RUNNING PSCAN".
> 
> 4. It doesn't matter (with respect to 'hciconfig -a' output and visibility) at 
> all if there is any 'iscan/pscan enable/disable' line at all: PSCAN will show 
> up, ISCAN not.
> 
> 5. All of this happens with every BT card/dongle I have at hand 
> (SPHINX/Belkin/EPoX).

First of all the setting iscan on and pscan off somehow works, but is
totally stupid. It means you set your device visible, but not
connectable. This also means that the remote side can find you, but
can't resolve your name. Think about it.

> > The scan mode defines is you are visible and connectable. The D-Bus API
> > sets you to connectable only unless you disable the discoverable timeout
> > and set your yourself to discoverable.
> 
> How do I set the discoverable timeout? How am I supposed to set myself 
> discoverable? Are there new options in hcid.conf? Where is it documented?

Check utils/hcid/dbus-api.txt in the CVS. It also contains a dbus-test
script that can be used to modify these settings.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Felix Homann]

On Friday 28 July 2006 11:09, Marcel Holtmann wrote:
> First of all the setting iscan on and pscan off somehow works, but is
> totally stupid. It means you set your device visible, but not
> connectable. This also means that the remote side can find you, but
> can't resolve your name. Think about it.

Sure it's stupid. I did it only for testing purposes. I've mentioned it here 
just to illustrate that nothing in hcid.conf related to pscan/iscan seems to 
have any effect at all. (I've "iscan enable; pscan enable;" in my hcid.conf). 

> > How do I set the discoverable timeout? How am I supposed to set myself
> > discoverable? Are there new options in hcid.conf? Where is it documented?
>
> Check utils/hcid/dbus-api.txt in the CVS. It also contains a dbus-test
> script that can be used to modify these settings.

So, there's no way to make my system visible directly after plugging the 
dongle in without switching to CVS versions???? 

Kind regards,

Felix

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Marcel Holtmann]

Hi Felix,

> > First of all the setting iscan on and pscan off somehow works, but is
> > totally stupid. It means you set your device visible, but not
> > connectable. This also means that the remote side can find you, but
> > can't resolve your name. Think about it.
> 
> Sure it's stupid. I did it only for testing purposes. I've mentioned it here 
> just to illustrate that nothing in hcid.conf related to pscan/iscan seems to 
> have any effect at all. (I've "iscan enable; pscan enable;" in my hcid.conf). 
> 
> > > How do I set the discoverable timeout? How am I supposed to set myself
> > > discoverable? Are there new options in hcid.conf? Where is it documented?
> >
> > Check utils/hcid/dbus-api.txt in the CVS. It also contains a dbus-test
> > script that can be used to modify these settings.
> 
> So, there's no way to make my system visible directly after plugging the 
> dongle in without switching to CVS versions???? 

the dbus-test is a Python script. Simple checkout the CVS and use this
one. You need to modify DiscoverableTimeout and Mode. No need to update
the whole BlueZ packages.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Alastair Tse]

On Fri, 2006-07-28 at 03:32 +0200, Marcel Holtmann wrote:
> > Jul 28 00:10:16 qoo hcid[23009]: Can't write inquiry mode for hci0:
> > Connection timed out (110)
> 
> the attached patch might help. If we have a Bluetooth 1.0b or 1.1 device
> without a quirk to enable inqmode, we shouldn't even try to change the
> inquiry mode. Seems that the Broadcom dongles are really sensible if you
> try to send a command they don't support.

Marcel,

Thanks for the patch. That does get rid of the connection timed out
error in syslog. Although I'm still experiencing the fact that ISCAN is
not enabled, although that seems to be another problem associated with
the way 3.x works for detecting features (According to the another
thread).

Thanks,

Alastair




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Felix Homann]

Hi Marcel,

On Friday 28 July 2006 11:38, Marcel Holtmann wrote:
> the dbus-test is a Python script. Simple checkout the CVS and use this
> one. You need to modify DiscoverableTimeout and Mode. No need to update
> the whole BlueZ packages.

Here's what I get:

#./dbus-test
  File "./dbus-test", line 178
    @dbus.decorators.explicitly_pass_message
    ^
SyntaxError: invalid syntax

BTW, if I could change settings via dbus-test would they be remembered the 
next time I plug the dongle in?

Furthermore, if iscan/pscan options in hcid.conf are not working as before it 
shoud be mentioned somewhere in the documentation.

Kind regards,

Felix

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Marcel Holtmann]

Hi Felix,

> > the dbus-test is a Python script. Simple checkout the CVS and use this
> > one. You need to modify DiscoverableTimeout and Mode. No need to update
> > the whole BlueZ packages.
> 
> Here's what I get:
> 
> #./dbus-test
>   File "./dbus-test", line 178
>     @dbus.decorators.explicitly_pass_message
>     ^
> SyntaxError: invalid syntax

no idea what's wrong here. I am not a Python expert.

> BTW, if I could change settings via dbus-test would they be remembered the 
> next time I plug the dongle in?

Yes. All changes over the D-Bus API will be remembered. This is also
includes the device name and the class of device.

> Furthermore, if iscan/pscan options in hcid.conf are not working as before it 
> shoud be mentioned somewhere in the documentation.

This stuff will all go away. It is part of the cleanup process.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Felix Homann]

Hi Marcel,

On Friday 28 July 2006 12:06, Marcel Holtmann wrote:
> This stuff will all go away. It is part of the cleanup process.
>
> Regards
>
> Marcel

thank you very much for your efforts! I think I'll go back to bluez-utils 
2.25-1 then until I can control the visibility somehow. 

Kind regards,

Felix

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Marcel Holtmann]

Hi Felix,

> > This stuff will all go away. It is part of the cleanup process.
> 
> thank you very much for your efforts! I think I'll go back to bluez-utils 
> 2.25-1 then until I can control the visibility somehow. 

you can use dbus-send, but that is a little bit more complicated.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[hugues]

>>>>> "Marcel" == Marcel Holtmann <marcel@holtmann.org> writes:

    Marcel> Hi Felix,
    >> > the dbus-test is a Python script. Simple checkout the CVS and use this
    >> > one. You need to modify DiscoverableTimeout and Mode. No need to update
    >> > the whole BlueZ packages.
    >> 
    >> Here's what I get:
    >> 
    >> #./dbus-test
    >> File "./dbus-test", line 178
    >> @dbus.decorators.explicitly_pass_message
    >> ^
    >> SyntaxError: invalid syntax

    Marcel> no idea what's wrong here. I am not a Python expert.

Not an expert either, but i might have a clue:

$ python2.3 ./dbus-test

  File "./dbus-test", line 178
    @dbus.decorators.explicitly_pass_message
    ^
SyntaxError: invalid syntax

$ python2.4 ./dbus-test

Usage: ./dbus-test [-i <dev>] [-l] [-h] <cmd> [arg1..]
  -i <dev>   Specify device (e.g. "hci0" or "/org/bluez/hci0")
  -l         Listen for events (no command required)
  -h         Show this help
Manager commands:
	InterfaceVersion
	ListAdapters
	DefaultAdapter
Adapter commands:
	GetAddress
	GetVersion
	GetRevision
	GetManufacturer
	GetCompany
	GetMode
	SetMode
	GetDiscoverableTimeout
	SetDiscoverableTimeout
	IsConnectable
	IsDiscoverable
	IsConnected
	ListConnections
	GetMajorClass
	ListAvailableMinorClasses
	GetMinorClass
	SetMinorClass
	GetServiceClasses
	GetName
	SetName
	GetRemoteVersion
	GetRemoteRevision
	GetRemoteManufacturer
	GetRemoteCompany
	GetRemoteName
	GetRemoteMajorClass
	GetRemoteMinorClass
	GetRemoteServiceClasses
	GetRemoteAlias
	SetRemoteAlias
	ClearRemoteAlias
	LastSeen
	LastUsed
	DisconnectRemoteDevice
	CreateBonding
	CancelBondingProcess
	RemoveBonding
	HasBonding
	ListBondings
	GetPinCodeLength
	GetEncryptionKeySize
	DiscoverDevices
	DiscoverDevicesWithoutNameResolving
	CancelDiscovery

So maybe python version should be at least 2.4 ?!

    >> BTW, if I could change settings via dbus-test would they be remembered the 
    >> next time I plug the dongle in?

    Marcel> Yes. All changes over the D-Bus API will be remembered. This is also
    Marcel> includes the device name and the class of device.

    >> Furthermore, if iscan/pscan options in hcid.conf are not working as before it 
    >> shoud be mentioned somewhere in the documentation.

    Marcel> This stuff will all go away. It is part of the cleanup process.

    Marcel> Regards

    Marcel> Marcel



    Marcel> -------------------------------------------------------------------------
    Marcel> Take Surveys. Earn Cash. Influence the Future of IT
    Marcel> Join SourceForge.net's Techsay panel and you'll get the chance to share your
    Marcel> opinions on IT & business topics through brief surveys -- and earn cash
    Marcel> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
    Marcel> _______________________________________________
    Marcel> Bluez-users mailing list
    Marcel> Bluez-users@lists.sourceforge.net
    Marcel> https://lists.sourceforge.net/lists/listinfo/bluez-users


-- 
Hugues Lafarge                    || Email: Hugues.Lafarge@afp.com
Agence France Presse              || Phone: +33 1 40 41 77 15
4 rue de la bourse, 75002 Paris   ||   Fax: +33 1 40 41 79 24
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This e-mail, and any file transmitted with it, is confidential and  intended solely for the use of the individual or entity to whom it is addressed. If you have received this email in error, please  contact the sender and delete the email from your system. If you are  not the named addressee you should not disseminate, distribute or copy  this email.

For more information on Agence France-Presse, please visit our web site at http://www.afp.com

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Felix Homann]

Hi Marcel,

On Friday 28 July 2006 12:33, Marcel Holtmann wrote:
> > I think I'll go back to bluez-utils
> > 2.25-1 then until I can control the visibility somehow.
>
> you can use dbus-send, but that is a little bit more complicated.
>

Thanks :-)

but with 2.25 I know (partially) what I'm doing and where. My system does just 
what I want it to. Right now, I can't see any advantage from my user's point 
of view in using the new version due to the lack of documentation and 
control. Even if I can manage to get it done via dbus-send somehow , it's 
simpler just to downgrade the package.


Kind regards,

Felix

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Marcel Holtmann]

Hi Felix,

> > > I think I'll go back to bluez-utils
> > > 2.25-1 then until I can control the visibility somehow.
> >
> > you can use dbus-send, but that is a little bit more complicated.
> >
> 
> Thanks :-)
> 
> but with 2.25 I know (partially) what I'm doing and where. My system does just 
> what I want it to. Right now, I can't see any advantage from my user's point 
> of view in using the new version due to the lack of documentation and 
> control. Even if I can manage to get it done via dbus-send somehow , it's 
> simpler just to downgrade the package.

feel free to use whatever suits you best, but I am not fixing any bugs
for the 2.x generation anymore.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Felix Homann]

Hi,

On Friday 28 July 2006 12:40, hugues wrote:
> So maybe python version should be at least 2.4 ?!

Yes, dbus-test works with python 2.4. Thank you very much!

"dbus-test -i hci0 SetMode discoverable" made my system visible again. Took me 
some minutes to find out what key words SetMode expects.

I'll probably  keep the 3.x series now ;-)

Kind regards,

Felix 


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Felix Homann]

Hi Marcel,

On Friday 28 July 2006 12:06, Marcel Holtmann wrote:
> > BTW, if I could change settings via dbus-test would they be remembered
> > the next time I plug the dongle in?
>
> Yes. All changes over the D-Bus API will be remembered. This is also
> includes the device name and the class of device.

No, unfortunately the settings I've changed via dbus-test are lost after 
unplugging the dongle.

So, I'm stuck again: My system won't be visible after plugging the dongle in 
unless I manually make it visible again, and there's no way to configure it 
differently...or am I missing something?

Kind regards,

Felix



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Marcel Holtmann]

Hi Felix,

> > > BTW, if I could change settings via dbus-test would they be remembered
> > > the next time I plug the dongle in?
> >
> > Yes. All changes over the D-Bus API will be remembered. This is also
> > includes the device name and the class of device.
> 
> No, unfortunately the settings I've changed via dbus-test are lost after 
> unplugging the dongle.
> 
> So, I'm stuck again: My system won't be visible after plugging the dongle in 
> unless I manually make it visible again, and there's no way to configure it 
> differently...or am I missing something?

they must stay, because otherwise it is a bug. You did set the
discoverable timeout to zero, do you?

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Felix Homann]

Hi Marcel,

On Friday 28 July 2006 17:07, Marcel Holtmann wrote:
> > No, unfortunately the settings I've changed via dbus-test are lost after
> > unplugging the dongle.
>
> they must stay, because otherwise it is a bug. You did set the
> discoverable timeout to zero, do you?

sure, I have. It's probably a bug then. But keep in mind I'm using dbus-test 
with the Debian distributed bluez-utils (3.1-3), maybe it's already fixed in 
3.2..

Here's what I did:

# dbus-test -i hci0 SetDiscoverableTimeout 0
# dbus-test -i hci0 SetMode discoverable
# dbus-test -i hci0 GetMode
discoverable
# dbus-test -i hci0 GetDiscoverableTimeout
0

Unplug the dongle, then immediately after plugging it in again:

# dbus-test -i hci0 GetDiscoverableTimeout
180
# dbus-test -i hci0 GetMode
discoverable

Wait some (~3) minutes:

# dbus-test -i hci0 GetMode
connectable

Kind regards,

Felix




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Felix Homann]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

Hi Marcel,

On Thursday 27 July 2006 13:04, Marcel Holtmann wrote:
> with bluez-utils-3.x we try to activate Inquiry with RSSI by default and
> in your case it doesn't seem to work.

Thanks, for clarifying.

> What does "hciconfig hci0 features version" tell you about your dongle.

Please, take a look into the attached features-version.log.

> Please also include the output of "hcidump -X -V" while starting an
> inquiry. With inqmode 0 and inqmode 1.

I've attached some files containing the ouptut of 'hcidump -X -V'. Those with 
hcitool in their name have been produced while doing a 'hcitool scan', those 
with kdebluetooth while scanning for devices with kdebluetoothd. The 
corresponding inqmode should be obvious from the file names.

Kind regards,

Felix

[-- Attachment #2: scan_hcitool_inq_0.log --]
[-- Type: text/x-log, Size: 3696 bytes --]

HCI sniffer - Bluetooth packet analyzer ver 1.31
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Write Scan Enable (0x03|0x001a) plen 1
    enable 2
> HCI Event: Command Complete (0x0e) plen 4
    Write Scan Enable (0x03|0x001a) ncmd 1
    status 0x00
< HCI Command: Read Scan Enable (0x03|0x0019) plen 0
> HCI Event: Command Complete (0x0e) plen 5
    Read Scan Enable (0x03|0x0019) ncmd 1
    status 0x00 enable 2
< HCI Command: Inquiry (0x01|0x0001) plen 5
    lap 0x9e8b33 len 8 num 0
> HCI Event: Command Status (0x0f) plen 4
    Inquiry (0x01|0x0001) status 0x00 ncmd 1
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349f class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349f class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Complete (0x01) plen 1
    status 0x00
< HCI Command: Inquiry (0x01|0x0001) plen 5
    lap 0x9e8b33 len 6 num 0
> HCI Event: Command Status (0x0f) plen 4
    Inquiry (0x01|0x0001) status 0x00 ncmd 1
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349d class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349d class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349d class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349d class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349d class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349d class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349e class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x349d class 0x50020c

[-- Attachment #3: scan_hcitool_inq_1.log --]
[-- Type: text/x-log, Size: 4956 bytes --]

HCI sniffer - Bluetooth packet analyzer ver 1.31
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Inquiry (0x01|0x0001) plen 5
    lap 0x9e8b33 len 8 num 0
> HCI Event: Command Status (0x0f) plen 4
    Inquiry (0x01|0x0001) status 0x00 ncmd 1
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8d class 0x50020c rssi -66
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8d class 0x50020c rssi -66
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8d class 0x50020c rssi -65
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -75
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8d class 0x50020c rssi -65
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -74
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8d class 0x50020c rssi -66
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8d class 0x50020c rssi -66
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -75
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8d class 0x50020c rssi -66
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -68
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -68
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -69
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -71
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -66
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -67
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8b class 0x50020c rssi -67
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -66
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8b class 0x50020c rssi -72
> HCI Event: Inquiry Complete (0x01) plen 1
    status 0x00
< HCI Command: Inquiry (0x01|0x0001) plen 5
    lap 0x9e8b33 len 6 num 0
> HCI Event: Command Status (0x0f) plen 4
    Inquiry (0x01|0x0001) status 0x00 ncmd 1
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -65
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8b class 0x50020c rssi -72
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -66
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -68
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8b class 0x50020c rssi -73
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -66
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8b class 0x50020c rssi -75
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -66
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8b class 0x50020c rssi -76
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8b class 0x50020c rssi -73
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -66
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8b class 0x50020c rssi -73
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -66
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8c class 0x50020c rssi -66
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x2a8b class 0x50020c rssi -66
> HCI Event: Inquiry Complete (0x01) plen 1
    status 0x00

[-- Attachment #4: scan_kdebluetooth_inq_1.log --]
[-- Type: text/x-log, Size: 1096 bytes --]

HCI sniffer - Bluetooth packet analyzer ver 1.31
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Inquiry (0x01|0x0001) plen 5
    lap 0x9e8b33 len 6 num 0
> HCI Event: Command Status (0x0f) plen 4
    Inquiry (0x01|0x0001) status 0x00 ncmd 1
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3631 class 0x50020c rssi -72
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3631 class 0x50020c rssi -67
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3631 class 0x50020c rssi -70
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3630 class 0x50020c rssi -70
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3631 class 0x50020c rssi -68
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3631 class 0x50020c rssi -68
> HCI Event: Inquiry Complete (0x01) plen 1
    status 0x00

[-- Attachment #5: scan_kdebluetooth_inq_0.log --]
[-- Type: text/x-log, Size: 2536 bytes --]

HCI sniffer - Bluetooth packet analyzer ver 1.31
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Inquiry (0x01|0x0001) plen 5
    lap 0x9e8b33 len 6 num 0
> HCI Event: Command Status (0x0f) plen 4
    Inquiry (0x01|0x0001) status 0x00 ncmd 1
< HCI Command: Inquiry (0x01|0x0001) plen 5
    lap 0x9e8b33 len 6 num 0
> HCI Event: Command Status (0x0f) plen 4
    Inquiry (0x01|0x0001) status 0x12 ncmd 1
    Error: Invalid HCI Command Parameters
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3c5d class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3c5d class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3c5c class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3c5c class 0x50020c
> HCI Event: Inquiry Complete (0x01) plen 1
    status 0x00
< HCI Command: Inquiry (0x01|0x0001) plen 5
    lap 0x9e8b33 len 6 num 0
> HCI Event: Command Status (0x0f) plen 4
    Inquiry (0x01|0x0001) status 0x00 ncmd 1
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3c5d class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3c5d class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3c5c class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3c5d class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3c5c class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3c5c class 0x50020c
> HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:17:4B:1D:85:0A mode 1 clkoffset 0x3c5d class 0x50020c
< HCI Command: Inquiry (0x01|0x0001) plen 5
    lap 0x9e8b33 len 6 num 0
> HCI Event: Command Status (0x0f) plen 4
    Inquiry (0x01|0x0001) status 0x12 ncmd 1
    Error: Invalid HCI Command Parameters
> HCI Event: Inquiry Complete (0x01) plen 1
    status 0x00
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
    bdaddr 00:17:4B:1D:85:0A mode 2 clkoffset 0x0000
> HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Flush Occurred (0x11) plen 2
    handle 12
> HCI Event: Remote Name Req Complete (0x07) plen 255
    status 0x00 bdaddr 00:17:4B:1D:85:0A name 'Fex N70'

[-- Attachment #6: features-version.log --]
[-- Type: text/x-log, Size: 881 bytes --]

hci0:	Type: USB
	BD Address: 00:00:3A:6A:1B:A0 ACL MTU: 1017:8 SCO MTU: 64:0
	Features: 0xff 0xfb 0x8d 0xfe 0x9f 0xf9 0x00 0x80
		<3-slot packets> <5-slot packets> <encryption> <slot offset> 
		<timing accuracy> <role switch> <hold mode> <sniff mode> 
		<park state> <RSSI> <SCO link> <HV2 packets> <HV3 packets> 
		<u-law log> <A-law log> <CVSD> <power control> 
		<transparent SCO> <broadcast encrypt> <EDR ACL 2 Mbps> 
		<EDR ACL 3 Mbps> <enhanced iscan> <interlaced iscan> 
		<interlaced pscan> <inquiry with RSSI> <extended SCO> 
		<EV4 packets> <EV5 packets> <no. 34> <AFH cap. slave> 
		<AFH class. slave> <3-slot EDR ACL> <5-slot EDR ACL> 
		<AFH cap. master> <AFH class. master> <EDR eSCO 2 Mbps> 
		<EDR eSCO 3 Mbps> <3-slot EDR eSCO> <extended features> 
	HCI Ver: 2.0 (0x3) HCI Rev: 0x2073 LMP Ver: 2.0 (0x3) LMP Subver: 0x410e
	Manufacturer: Broadcom Corporation (15)

[-- Attachment #7: Type: text/plain, Size: 348 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #8: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Marcel Holtmann]

Hi Felix,

> > > No, unfortunately the settings I've changed via dbus-test are lost after
> > > unplugging the dongle.
> >
> > they must stay, because otherwise it is a bug. You did set the
> > discoverable timeout to zero, do you?
> 
> sure, I have. It's probably a bug then. But keep in mind I'm using dbus-test 
> with the Debian distributed bluez-utils (3.1-3), maybe it's already fixed in 
> 3.2..
> 
> Here's what I did:
> 
> # dbus-test -i hci0 SetDiscoverableTimeout 0
> # dbus-test -i hci0 SetMode discoverable
> # dbus-test -i hci0 GetMode
> discoverable
> # dbus-test -i hci0 GetDiscoverableTimeout
> 0
> 
> Unplug the dongle, then immediately after plugging it in again:
> 
> # dbus-test -i hci0 GetDiscoverableTimeout
> 180
> # dbus-test -i hci0 GetMode
> discoverable
> 
> Wait some (~3) minutes:
> 
> # dbus-test -i hci0 GetMode
> connectable

that is a bug and it is still present in bluez-utils-3.2. I have no idea
how, but somehow the unplug and replug sets the default discoverable
timeout of 3 minutes. If you look at the stored value it is still 0, but
this doesn't help.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Marcel Holtmann]

Hi Felix,

> > with bluez-utils-3.x we try to activate Inquiry with RSSI by default and
> > in your case it doesn't seem to work.
> 
> Thanks, for clarifying.
> 
> > What does "hciconfig hci0 features version" tell you about your dongle.
> 
> Please, take a look into the attached features-version.log.
> 
> > Please also include the output of "hcidump -X -V" while starting an
> > inquiry. With inqmode 0 and inqmode 1.
> 
> I've attached some files containing the ouptut of 'hcidump -X -V'. Those with 
> hcitool in their name have been produced while doing a 'hcitool scan', those 
> with kdebluetooth while scanning for devices with kdebluetoothd. The 
> corresponding inqmode should be obvious from the file names.

the dumps are fine. With inquiry mode 0 you see only Inquiry Result
events and with inquiry mode 1 (in your case the default that hcid will
set on adapter init) you see only Inquiry Result with RSSI events. The
Linux kernel and hcid+hcitool are capable of handling all for possible
events that are out there:

	inqmode 0: Inquiry Result
	inqmode 1: Inquiry Result with RSSI
	inqmode 1: Inquiry Result with RSSI and Page Scan
	inqmode 2: Extended Inquiry Result

The Inquiry Result with RSSI and Page Scan shows only up on a couple of
broken Silicon Wave based adapters where these guys where to stupid to
read the final Bluetooth 1.2 specification. However BlueZ works around
their mistake.

It seems that kdebluetoothd needs to updated and the best would be if
they start using the new D-Bus interface, because this takes care of all
this adapter specific things.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Several problems with bluez-utils 3.1, kbluetoothd and a Belkin dongle in Debian

[Marcel Holtmann]

Hi Alastair,

> > the attached patch might help. If we have a Bluetooth 1.0b or 1.1 device
> > without a quirk to enable inqmode, we shouldn't even try to change the
> > inquiry mode. Seems that the Broadcom dongles are really sensible if you
> > try to send a command they don't support.
> 
> Thanks for the patch. That does get rid of the connection timed out
> error in syslog. Although I'm still experiencing the fact that ISCAN is
> not enabled, although that seems to be another problem associated with
> the way 3.x works for detecting features (According to the another
> thread).

it really looks like a bug. Feel free to send in a patch to fix it.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users