Re: Reconciling hcidump output with btmon

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I wrote:

> I understand that "hcidump" has been deprecated for several years. Yet
> the output of "btmon" seems to imply that it is calling "hcidump". That
> doesn't make sense to me. For example,
> 
>  @ RAW Open: hcidump (privileged) version 2.22 {0x0002} [hci0] 1.894682
>  @ RAW Open: hcidump (privileged) version 2.22 {0x0003} 1.894702
>  @ RAW Close: hcidump                          {0x0003} 1.894708
>  @ RAW Close: hcidump                          {0x0002} [hci0] 1.894718

Marcel Holtmann answered:

>I don't know what that is, but it seems that something else in your system is 
>calling hcidump binary. However it is for sure not btmon calling the hcidump b
>inary and you can verify that in the btmon source code.

The lines I quoted are from the stdout of btmon. How would something else
get output mixed into that? Is the Fedora version of btmon modified?

>The hcidump -R functionality is rather useless. If you really want it, then yo
>u can get it by opening the monitor socket directly. I really don't know what 
>you wanted it for.

I wanted to see the actual data stream from my devices. So far as I can
tell, I can't get that from any of the undeprecated Bluez tools.
-- 
         Dave Close, Compata, Irvine CA       +1 714 434 7359
       dave@xxxxxxxxxxx              dhclose@xxxxxxxxxxxxxxxxxx
         "I don't need bodyguards." -- Jimmy Hoffa, June 1975





[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux