bluetooth_le_packet: fix octet number for printing Hop and SCA.

I have been reading the Bluetooth LE spec and looking to the Ubertooth dump at the same time. In particular, I was looking at the following packet:

    systime=1389592517 freq=2426 addr=8e89bed6 delta_t=0.494 ms
    05 22 d6 b3 64 83 15 00 cc 57 6e e5 c5 78 06 cb db c1 b8 5f 3d 03 02 00 38 00 00 00 2a 00 ff ff ff ff 1f 29 49 ad 8d 
    Advertising / AA 8e89bed6 / 34 bytes
        Channel Index: 38
        Type:  CONNECT_REQ
        InitA: 00:15:83:64:b3:d6 (public)
        AdvA:  78:c5:e5:6e:57:cc (public)
        AA:    c1dbcb06
        CRCInit: 005fb8
        WinSize: 03 (3)
        WinOffset: 0002 (2)
        Interval: 0038 (56)
        Latency: 0000 (0)
        Timeout: 002a (42)
        ChM: ff ff ff ff 1f
        Hop: 31
        SCA: 7, 0 ppm to 20 ppm
    
        Data:  d6 b3 64 83 15 00 cc 57 6e e5 c5 78 06 cb db c1 b8 5f 3d 03 02 00 38 00 00 00 2a 00 ff ff ff ff 1f 29
        CRC:   49 ad 8d


I realized that Hop and SCA values look strange. They are taken from the last octet, Hop occupies 5 lower bits and SCA is taken from 3 higher bits. Given the last octet is 0x29, Hop should be 9 and SCA to be 1.

So, I decided to take a closer look. My quick investigation revealed the following code from libbtbb/lib/src/bluetooth_le_packet.c:317

    printf("    ChM:");
    for (i = 0; i < 5; ++i)
            printf(" %02x", p->symbols[34+i]);
            printf("\n");
    }
    printf("    Hop: %d\n", p->symbols[37] & 0x1f);
    printf("    SCA: %d, %s\n",
    p->symbols[37] >> 5,
    CONNECT_SCA[p->symbols[37] >> 5]);


That looks wrong, because ChM loop prints octets 34, 35, 36, 37, 38. It means that Hop and SCA must be taken from octet 39, not 37.

The patch is attached to the ticket. Below is the same patch inlined:

    diff --git a/lib/src/bluetooth_le_packet.c b/lib/src/bluetooth_le_packet.c
    index 179fb3e..42a6ed2 100644
    --- a/lib/src/bluetooth_le_packet.c
    +++ b/lib/src/bluetooth_le_packet.c
    @@ -314,10 +314,10 @@ void le_print(le_packet_t *p) {
     					printf(" %02x", p->symbols[34+i]);
     				printf("\n");
     
    -				printf("    Hop: %d\n", p->symbols[37] & 0x1f);
    +				printf("    Hop: %d\n", p->symbols[39] & 0x1f);
     				printf("    SCA: %d, %s\n",
    -						p->symbols[37] >> 5,
    -						CONNECT_SCA[p->symbols[37] >> 5]);
    +						p->symbols[39] >> 5,
    +						CONNECT_SCA[p->symbols[39] >> 5]);
     				break;
     		}
     	}

(I suspect that the browser might have replaced tabs with spaces in the inlined patch , but anyway)

Below is the example of dump after the patch is applied:

    systime=1389598549 freq=2426 addr=8e89bed6 delta_t=0.494 ms
    05 22 d6 b3 64 83 15 00 cc 57 6e e5 c5 78 96 36 cb da 16 46 8c 04 26 00 38 00 00 00 2a 00 0f f8 ff ff 1f 30 6c 69 ad 
    Advertising / AA 8e89bed6 / 34 bytes
        Channel Index: 38
        Type:  CONNECT_REQ
        InitA: 00:15:83:64:b3:d6 (public)
        AdvA:  78:c5:e5:6e:57:cc (public)
        AA:    dacb3696
        CRCInit: 004616
        WinSize: 04 (4)
        WinOffset: 0026 (38)
        Interval: 0038 (56)
        Latency: 0000 (0)
        Timeout: 002a (42)
        ChM: 0f f8 ff ff 1f
        Hop: 16
        SCA: 1, 151 ppm to 250 ppm
    
        Data:  d6 b3 64 83 15 00 cc 57 6e e5 c5 78 96 36 cb da 16 46 8c 04 26 00 38 00 00 00 2a 00 0f f8 ff ff 1f 30
        CRC:   6c 69 ad

It looks correct to me, because the last octet is 0x30, Hop 16 = 0x10 and SCA = 1.

Please, let me know, if the patch needs more work or completely wrong.

krasin

P.S. This pull request duplicates the ticket on SF.net: https://sourceforge.net/p/libbtbb/tickets/3/
The libbtbb documentation is inconsistent about the place to submit tickets. README.md recomments SF.net, but http://libbtbb.sourceforge.net/ points to github.com.