When for security reasons or any other, packets in the btsnoop logs are
not complete, then Included length is smaller then Original size.
For the moment, Bluez always assumes to get complete packets.
If it not happen, then it stops decoding after fist packet which
Original size is bigger then Included lenght. e.g.
In the file where we had some ISO packets but with payload = 0,
btmon ended like that:
./btmon -r btsnoop.log
Bluetooth monitor ver 5.66
After the fix logs looks like that (from the same btsnoop log)
> HCI Event: Number of Completed Packets (0x13) plen 5 #1 0.926288
Num handles: 1
Handle: 96
Count: 2
> HCI Event: Number of Completed Packets (0x13) plen 5 #2 0.932776
Num handles: 1
Handle: 97
Count: 2
> HCI Event: Number of Completed Packets (0x13) plen 5 #3 0.945915
Num handles: 1
Handle: 96
Count: 2
And here is an example how truncated ACL packet will look after fix.
> ACL Data RX: Handle 64 flags 0x02 dlen 51 #138 7.118921
invalid packet size (10 != 51)
2f 00 04 00 1b 05 11 01 01 00 /.........
Łukasz Rymanowski (1):
btmon: Fix decoding truncated data
src/shared/btsnoop.c | 2 +-
tools/btsnoop.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
--
2.34.1
