[Bluez-users] hcitool scan returns wrong bdaddr

[Bluez-users] hcitool scan returns wrong bdaddr

[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


-------------------------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] hcitool scan returns wrong bdaddr

[Paul Wachendorf]

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
 > HCI Event: Command Status (0x0f) plen 4
    Inquiry (0x01|0x0001) status 0x00 ncmd 1
 > HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:12:EE:58:72:1C mode 1 clkoffset 0x5c3f class 0x5a0204
 > 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)
 > HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
 > 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
 > HCI Event: Command Status (0x0f) plen 4
    Inquiry (0x01|0x0001) status 0x00 ncmd 1
 > HCI Event: Inquiry Result (0x02) plen 15
    bdaddr 00:12:EE:58:72:1C mode 1 clkoffset 0x5c44 class 0x5a0204
 > 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


Paul Wachendorf schrieb:
> 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
> Bluez-users@lists.sourceforge.net
> 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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] hcitool scan returns wrong bdaddr

[Marcel Holtmann]

Hi Paul,

> 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
>  > HCI Event: Command Status (0x0f) plen 4
>     Inquiry (0x01|0x0001) status 0x00 ncmd 1
>  > HCI Event: Inquiry Result (0x02) plen 15
>     bdaddr 00:12:EE:58:72:1C mode 1 clkoffset 0x5c3f class 0x5a0204
>  > 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)
>  > HCI Event: Command Status (0x0f) plen 4
>     Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
>  > 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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] hcitool scan returns wrong bdaddr

[Paul Wachendorf]

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:anonymous@cvs.bluez.org:/cvsroot/bluez login
  cvs -d:pserver:anonymous@cvs.bluez.org:/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


Marcel Holtmann schrieb:
> 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
> Bluez-users@lists.sourceforge.net
> 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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] hcitool scan returns wrong bdaddr

[Marcel Holtmann]

Hi Paul,

> 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:anonymous@cvs.bluez.org:/cvsroot/bluez login
>   cvs -d:pserver:anonymous@cvs.bluez.org:/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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] hcitool scan returns wrong bdaddr

[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 
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] hcitool scan returns wrong bdaddr

[Dave Young]

On Nov 27, 2007 2:31 AM, Paul Wachendorf <pwachend@uni-koeln.de> wrote:
> 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,

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] hcitool scan returns wrong bdaddr

[Marcel Holtmann]

Hi Dave,

>> 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,
>
> 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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] hcitool scan returns wrong bdaddr

[Dave Young]

On Nov 30, 2007 4:19 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Dave,
>
>
> >> 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,
> >
> > 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 :)