Skip to contentSkip to conversation

hcitool scan returns wrong bdaddr

Bluez-users Paul Wachendorf 3 participants 9 messages Nov 22, 2007 – Nov 30, 2007 Bluetooth drivers

lore
Share & tools
lore

Paul Wachendorf

author
#0 lore raw

Hi,
I have a strange Problem with hcitool on a ARM CPU based embedded system. I have installed a debian system (tried woody, etch and lenny) and tried the bluez-utils from the distribution and self compiled ones. The bluetooth device works fine, but when I run a 'hcitool scan' to discover the bdaddr of remote devices it always returns wrong MACs:

# hcitool scan
Scanning ...
        02:01:00:12:EE:58       n/a
        02:02:00:10:C6:81       n/a

on my normal i386 PC running ubuntu linux, using the same bluetooth device the output is:

$ hcitool scan
Scanning ...
        00:10:C6:81:48:19       NAME-FB399BACD9
        00:12:EE:58:72:1C       V630i

back again on the ARM box I can successfully l2ping 00:12:EE:58:72:1C and an # hcitool name 00:12:EE:58:72:1C
returns "V630i" as suspected , so on I can use ussp-push to send Files to my V630i. So the whole bluetooth subsystem seems to work fine, except of the discovering of remote MACs.

Does anybody has am idea why this wrong MACs are returned? Thanks for your help,

Paul

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

author
#1 lore raw

Hi everyone,
after a lot of testing, I found a (really ugly) workaround for my problem, so I post it here, if someone gets the same wired problem someday:
The verbose mode of hcidump show the right Mac while a 'hcitool scan' on an other console:

# hcidump -V
HCI sniffer - Bluetooth packet analyzer ver 1.39
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Inquiry (0x01|0x0001) plen 5
    lap 0x9e8b33 len 8 num 0
Quoted 1 line

HCI Event: Command Status (0x0f) plen 4

    Inquiry (0x01|0x0001) status 0x00 ncmd 1
Quoted 1 line

HCI Event: Inquiry Result (0x02) plen 15

    bdaddr 00:12:EE:58:72:1C mode 1 clkoffset 0x5c3f class 0x5a0204
Quoted 1 line

HCI Event: Inquiry Complete (0x01) plen 1

    status 0x00
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
    bdaddr 02:01:00:12:EE:58 mode 0 clkoffset 0x0000 (valid)
Quoted 1 line

HCI Event: Command Status (0x0f) plen 4

    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
Quoted 1 line

HCI Event: Remote Name Req Complete (0x07) plen 255

status 0x04 bdaddr 02:01:00:12:EE:58 name ''

Error: Page Timeout

the name request fails of course with a annoying timeout. So I make the scan with python and without name checking (of course you can use hcitool inq too):

import bluetooth
bluetooth.discover_devices(lookup_names = False)

# hcidump -V
< HCI Command: Inquiry (0x01|0x0001) plen 5
    lap 0x9e8b33 len 8 num 250
Quoted 1 line

HCI Event: Command Status (0x0f) plen 4

    Inquiry (0x01|0x0001) status 0x00 ncmd 1
Quoted 1 line

HCI Event: Inquiry Result (0x02) plen 15

    bdaddr 00:12:EE:58:72:1C mode 1 clkoffset 0x5c44 class 0x5a0204
Quoted 1 line

HCI Event: Inquiry Complete (0x01) plen 1

    status 0x00

then I parse the output of hcidump, and get my Macs.

So on I noticed that a part of the "wrong" MACs are like the original ones:

00:12:EE:58:72:1C right one in output of hcidump
02:01:00:12:EE:58 wrong one returned by
python-bluez or hcitool scan/inq

          00:10:C6:81:48:19

02:02:00:10:C6:81

If someone understand the problem here, please give me a hint and help my to get rid of hcidump parsing.
Thanks,

Paul

Quoted 30 lines · Paul Wachendorf

Hi,
I have a strange Problem with hcitool on a ARM CPU based embedded system. I have installed a debian system (tried woody, etch and lenny) and tried the bluez-utils from the distribution and self compiled ones. The bluetooth device works fine, but when I run a 'hcitool scan' to discover the bdaddr of remote devices it always returns wrong MACs:

# hcitool scan
Scanning ...
        02:01:00:12:EE:58       n/a
        02:02:00:10:C6:81       n/a

on my normal i386 PC running ubuntu linux, using the same bluetooth device the output is:

$ hcitool scan
Scanning ...
        00:10:C6:81:48:19       NAME-FB399BACD9
        00:12:EE:58:72:1C       V630i

back again on the ARM box I can successfully l2ping 00:12:EE:58:72:1C and an # hcitool name 00:12:EE:58:72:1C
returns "V630i" as suspected , so on I can use ussp-push to send Files to my V630i. So the whole bluetooth subsystem seems to work fine, except of the discovering of remote MACs.

Does anybody has am idea why this wrong MACs are returned? Thanks for your help,

Paul

Quoted 9 lines

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

maintainer
#2 lore raw

Hi Paul,

Quoted 20 lines

after a lot of testing, I found a (really ugly) workaround for my problem, so I post it here, if someone gets the same wired problem someday:
The verbose mode of hcidump show the right Mac while a 'hcitool scan' on an other console:

# hcidump -V
HCI sniffer - Bluetooth packet analyzer ver 1.39
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Inquiry (0x01|0x0001) plen 5
    lap 0x9e8b33 len 8 num 0
Quoted 1 line

HCI Event: Command Status (0x0f) plen 4

    Inquiry (0x01|0x0001) status 0x00 ncmd 1
Quoted 1 line

HCI Event: Inquiry Result (0x02) plen 15

    bdaddr 00:12:EE:58:72:1C mode 1 clkoffset 0x5c3f class 0x5a0204
Quoted 1 line

HCI Event: Inquiry Complete (0x01) plen 1

    status 0x00
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
    bdaddr 02:01:00:12:EE:58 mode 0 clkoffset 0x0000 (valid)
Quoted 1 line

HCI Event: Command Status (0x0f) plen 4

    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
Quoted 8 lines
Quoted 1 line

HCI Event: Remote Name Req Complete (0x07) plen 255

status 0x04 bdaddr 02:01:00:12:EE:58 name ''

Error: Page Timeout

the name request fails of course with a annoying timeout. So I make the scan with python and without name checking (of course you can use hcitool inq too):

if you would use the D-Bus API, then you don't have this problem. However there was a bug in the 3.22 library that I fixed now. Install the library from CVS and you should be good. Or use 3.21.

Regards

Marcel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

author
#3 lore raw

Hi Marcel,
thanks a lot for your fast resonse.
I have installed dbus on my System so I assumed that bluez would use it. Is this wrong?
I tried to find a archive for 3.21, but found none.
So I load the CVS Version by:

cvs -d:pserver:[email protected]:/cvsroot/bluez login cvs -d:pserver:[email protected]:/cvsroot/bluez co -P libs

for some reason autoconf -o configure configure.in on my embedded box didn't create anything, so I ran it on my PC, copyed the resulting configure script to the box, and run bootstrap and bootstrap-configure. make and make install, produced /usr/lib/libbluetooth.so.2.9.2

but an hcitool scan, still returns
Scanning ...

        02:01:00:12:EE:58       n/a

ldd which hcitool:

        libbluetooth.so.2 => /usr/lib/libbluetooth.so.2 (0x40025000)
        libc.so.6 => /lib/libc.so.6 (0x4003f000)
        /lib/ld-linux.so.2 (0x40000000)

ls -l /usr/lib/libbluetooth.so.2:
/usr/lib/libbluetooth.so.2 -> libbluetooth.so.2.9.2

What's going wrong?
Greetings,

Paul

Quoted 10 lines · Marcel Holtmann

if you would use the D-Bus API, then you don't have this problem. However there was a bug in the 3.22 library that I fixed now. Install the library from CVS and you should be good. Or use 3.21.

Regards

Marcel

Quoted 9 lines

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

maintainer
#4 lore raw

Hi Paul,

Quoted 6 lines

thanks a lot for your fast resonse.
I have installed dbus on my System so I assumed that bluez would use it. Is this wrong?
I tried to find a archive for 3.21, but found none.
So I load the CVS Version by:

Quoted 8 lines

cvs -d:pserver:[email protected]:/cvsroot/bluez login cvs -d:pserver:[email protected]:/cvsroot/bluez co -P libs

for some reason autoconf -o configure configure.in on my embedded box didn't create anything, so I ran it on my PC, copyed the resulting configure script to the box, and run bootstrap and bootstrap-configure. make and make install, produced /usr/lib/libbluetooth.so.2.9.2

use the bootstrap-configure and make sure it gets installed in /usr prefix to make it available. The tarball is at the same location as the 3.22 version, but only one version earlier.

Regards

Marcel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

author
#5 lore raw

Hi Marcel,
I found the 3.21 tarball, thanks. Unfortunately the error still occurs with the resulting libbluetooth.so.2.9.1. Because of the output from ldd, I'm sure that hcitool is linked against the "right" lib. So the Bug must be in 3.21 too, or there is an completely different Problem as I assume, because of the same behavior with libbluetooth.so.2.9.0 from debian lenny, and because you told me that it should work with an D-Bus API, which is installed.
So perhaps the Problem is rooted in my D-Bus setup. I installed it from the debian repository and thought it should work without any further configurations.
I'll search for it,
thank you very much for your time and help,
Regards,

Paul

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

#6 lore raw
Quoted 5 lines · Paul Wachendorf

Hi Marcel,
I found the 3.21 tarball, thanks. Unfortunately the error still occurs with the resulting libbluetooth.so.2.9.1. Because of the output from ldd, I'm sure that hcitool is linked against the "right" lib. So the Bug must be in 3.21 too, or there is an completely different Problem as I

Quoted 8 lines

assume, because of the same behavior with libbluetooth.so.2.9.0 from debian lenny, and because you told me that it should work with an D-Bus API, which is installed.
So perhaps the Problem is rooted in my D-Bus setup. I installed it from the debian repository and thought it should work without any further configurations.
I'll search for it,
thank you very much for your time and help,

Maybe the Dbus api works for you, but the problem with hcitool is still there.

If you could build the bluez-utils/lib with -g and debug the hcitool, you might get the answer then.

Regards
dave

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

maintainer
#7 lore raw

Hi Dave,

Quoted 17 lines
Quoted 8 lines

I found the 3.21 tarball, thanks. Unfortunately the error still occurs
with the resulting libbluetooth.so.2.9.1. Because of the output from ldd, I'm sure that hcitool is linked against the "right" lib. So the Bug
must be in 3.21 too, or there is an completely different Problem as I assume, because of the same behavior with libbluetooth.so.2.9.0 from debian lenny, and because you told me that it should work with an D-

Quoted 8 lines

Bus
API, which is installed.
So perhaps the Problem is rooted in my D-Bus setup. I installed it from
the debian repository and thought it should work without any further configurations.
I'll search for it,
thank you very much for your time and help,

Quoted 5 lines

Maybe the Dbus api works for you, but the problem with hcitool is still there.

If you could build the bluez-utils/lib with -g and debug the hcitool, you might get the answer then.

don't worry. I fixed that already. It was a stupid thinko on my side.

Regards

Marcel

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

#8 lore raw
Quoted 20 lines · Marcel Holtmann

Hi Dave,

Quoted 17 lines
Quoted 16 lines

I found the 3.21 tarball, thanks. Unfortunately the error still occurs
with the resulting libbluetooth.so.2.9.1. Because of the output from ldd, I'm sure that hcitool is linked against the "right" lib. So the Bug
must be in 3.21 too, or there is an completely different Problem as I assume, because of the same behavior with libbluetooth.so.2.9.0 from debian lenny, and because you told me that it should work with an D- Bus
API, which is installed.
So perhaps the Problem is rooted in my D-Bus setup. I installed it from
the debian repository and thought it should work without any further configurations.
I'll search for it,
thank you very much for your time and help,

Quoted 7 lines
Quoted 5 lines

Maybe the Dbus api works for you, but the problem with hcitool is still there.

If you could build the bluez-utils/lib with -g and debug the hcitool, you might get the answer then.

don't worry. I fixed that already. It was a stupid thinko on my side.

Thanks :)