Reconciling hcidump output with btmon

Reconciling hcidump output with btmon

[Dave Close]

When I run "hcidump -R", I see (among other output) lines like these,

  > 04 3E 26 02 01 03 01 69 57 93 F1 99 F8 1A 02 01 04 09 09 39
    36 37 35 39 39 38 46 07 16 09 18 EB 03 00 FE 04 16 0F 18 3E
    A5

But trying every available option for "btmon", I can't find anything
remotely similar. How can I get this information using "btmon"? Or can
I -- does "btmon" show this type of information? Is there some other
command that would be more appropriate?

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

My system is running Fedora 34 with these packages:

  bluez-5.62-2.fc34.x86_64 (includes /usr/bin/btmon)
  bluez-deprecated-5.62-2.fc34.x86_64 (includes /usr/bin/hcidump)
  bluez-hcidump-2.5-18.fc34.x86_64 (includes /usr/sbin/hcidump)
-- 
Dave Close, Compata, Irvine CA      "Curiosity is insubordination
dave@compata.com, +1 714 434 7359    in its purest form."
dhclose@alumni.caltech.edu             -- Vladimir Nabokov

Re: Reconciling hcidump output with btmon

[Marcel Holtmann]

Hi Dave,

> When I run "hcidump -R", I see (among other output) lines like these,
> 
>> 04 3E 26 02 01 03 01 69 57 93 F1 99 F8 1A 02 01 04 09 09 39
>    36 37 35 39 39 38 46 07 16 09 18 EB 03 00 FE 04 16 0F 18 3E
>    A5
> 
> But trying every available option for "btmon", I can't find anything
> remotely similar. How can I get this information using "btmon"? Or can
> I -- does "btmon" show this type of information? Is there some other
> command that would be more appropriate?
> 
> 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

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 binary and you can verify that in the btmon source code.

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

Regards

Marcel

Re: Reconciling hcidump output with btmon

[Dave Close]

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@compata.com              dhclose@alumni.caltech.edu
         "I don't need bodyguards." -- Jimmy Hoffa, June 1975

Re: Reconciling hcidump output with btmon

[Marcel Holtmann]

Hi Dave,

>> 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?

because the monitoring socket also records other binaries opening certain Bluetooth specific sockets.

And that is for exactly this reason. Something stupid is going on in your system.

> 
>> 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.

It is a socket. Many tools can dump the raw socket. I think it would be a 3 liner in Python for example. Use tshark or something alike if you want a raw data stream. Looking at raw HCI data is totally pointless.

Regards

Marcel