Re: Reconciling hcidump output with btmon

Hi Dave,

quoted

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:

quoted

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.

quoted

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