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
