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
On Nov 30, 2007 4:19 AM, Marcel Holtmann <[email protected]> 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 :)
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Nov 27, 2007 2:31 AM, Paul Wachendorf <[email protected]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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
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:[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
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
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
> [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
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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
> [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