[BlueZ,v2,0/1] Btmon: Fix handling not complete packets

Message

Łukasz Rymanowski March 11, 2023, 11:36 p.m. UTC

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(-)

Comments

[e-mail] March 14, 2023, 7:50 p.m. UTC | #1

Hello:

This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <[e-mail]>:

On Sun, 12 Mar 2023 00:36:39 +0100 you wrote:
> 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:
> 
> [...]

Here is the summary with links:
  - [BlueZ,v2,1/1] btmon: Fix decoding truncated data
    https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=6ae44c74aaf9

You are awesome, thank you!