All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Wachendorf <pwachend@uni-koeln.de>
To: BlueZ users <bluez-users@lists.sourceforge.net>
Subject: Re: [Bluez-users] hcitool scan returns wrong bdaddr
Date: Sun, 25 Nov 2007 23:44:38 +0100	[thread overview]
Message-ID: <4749FAD6.6080403@uni-koeln.de> (raw)
In-Reply-To: <4745D9EE.4020101@uni-koeln.de>

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

  reply	other threads:[~2007-11-25 22:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-22 19:35 [Bluez-users] hcitool scan returns wrong bdaddr Paul Wachendorf
2007-11-25 22:44 ` Paul Wachendorf [this message]
2007-11-26  5:38   ` Marcel Holtmann
2007-11-26 10:47     ` Paul Wachendorf
2007-11-26 12:27       ` Marcel Holtmann
2007-11-26 18:31         ` Paul Wachendorf
2007-11-29  7:43           ` Dave Young
2007-11-29 20:19             ` Marcel Holtmann
2007-11-30  2:52               ` Dave Young

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4749FAD6.6080403@uni-koeln.de \
    --to=pwachend@uni-koeln.de \
    --cc=bluez-users@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.