PIC-CONTROL

What you need.

• nRF Sniffer files
• nRF52 DK board (or other boards)
• Wireshark

Packet captured from the Blinky Peripheral

The period of blinky sending advertising packet is about 1msec

From this packet, I can see two part of data. One is from the sniffer itself, displaying the channel that it is sniffing, the RSSI (signal strength).

The other is the BLE Link Layer data sent from the peripheral displaying the address, and its peripheral device name.

Received Signal Strength Indicator
RSSI: -17dBm (Very Good Signal Strength)
RSSI: -35dBm (Good)
RSSI: -50dBm (Ok)
RSSI: -70dBm (Poor)

The delta time (end to start): 498us
is the time delay of the end of the previous data packet to the start of the current packet. It is the idling time between packet data transmission.

The delta time (start to start): 802us
is the time delay of the start of the previous data packet to the start of the current packet. It is the time period of the transmission. (transmission frequency of the packet)

Packet Information from the Sniffer

Is probably added information from the sniffer itself. It tells us about the information of the packet. Eg. Timing, RSSI, packet counting, data direction, transmitting channel, etc…

The data in this block is

10 2f 00 02 85 2e 06 0a 01 26 26 00 00 f2 01 00 00


10 | Board: 16

2f 00 02 85 2e 06 | Header
                    2f 00 | Length of payload: 47
                    02    | Protocol version: 2
                    85 2e | Packet counter: 11909
                    06    | Packet ID: 6

0a | Length of packet: 10 (assuming byte number of payload including itself)

01 26 26 00 00 f2 01 00 00 | Payload
                             01    | Flag
                                   | b7 RFU: 0
                                   | b6-b4 PHY: LE 1M (0)
                                   | b3 MIC: 0
                                   | b2 Encrypted: No (0)
                                   | b1 Direction: Slave -> Master (0)
                                   | b0 CRC: OK (1)
                             26    | Channel 38
                             26    | RSSI -38
                             00 00 | Event counter: 0

The advertising channel for the newer Bluetooth BLE protocol can only be at channel 37, 38, 39.

Device Name: Nordic_Blinky
Address: C0:C9:71:80:51:A0
RSSI: -32dBm
Details
Address type: RandomStatic
Advertising type: Connectable undirected
Services:
00001523-1212-EFDE-1523-785FEABCD123
Flags:
– LeGeneralDiscMode
– BrEdrNotSupported
– LeOnlyLimitedDicsMode
– LeOnlyGeneralDicsMode
Appearance: 00-00

Packet BLE Link Layer Data from the Blinky Peripheral

The data is from the Peripheral device, advertising to let other bluetooth device aware on its existence.

The data in this block is

d6 be 89 8e 60 1c a0 51 80 71 c9 c0 03 19 00 00
02 01 06 0e 09 4e 6f 72 64 69 63 5f 42 6c 69 6e
6b 79 69 8d 92


d6 be 89 8e | Access Address: 0x8e89bed6

60 1c       | Packet Header (PDU Type: ADV_IND)
              60 | 
                 | b7 Reserved: False (0)
                 | b6 Tx Address: Random (1)
                 | b5 Channel Selection Algorithm: #2
                 | b4 RFU: 0
                 | b3-b0 PDU Type: ADV_IND (0x0)

              1c | Length: 28 (assume Advertising Address (6bytes) + Advertising Data (22bytes)

a0 51 80 71 c9 c0 | Advertising Address: C0:C9:71:80:51:A0

03 19 00 00 02 01 06 0e 09 4e 6f 72 64 69 63 5f 42 6c 69 6e 6b 79 69 8d 92
                  | Advertising Data
                    03 19 00 00 | Appearance: Unknown
                                  03    | Length: 3
                                  19    | Type: Appearance (0x19)
                                  00 00 | Appearance: Unknown (0x0000)
                    02 01 06    | Flags
                                  02    | Length: 2
                                  01    | Type: Flags (0x01)
                                  06    | 
                                          b7-b5 Reserved
                                          b4    Simultaneous LED to Host (false)
                                          b3    Simultaneous LED to Controller (false)
                                          b2    BR/EDR Not Supported: true
                                          b1    LE General Discoverable Mode: true
                                          b0    LE Limited Discoverable Mode: false
                    0e 09 4e 6f 72 64 69 63 5f 42 6c 69 6e 6b 79
                                | Device Name
                                  0e    | Length: 14
                                  09    | Type: Device Name (0x09)
                                  4e 6f 72 64 69 63 5f 42 6c 69 6e 6b 79
                                        | Device Name: Nordic_Blinky
                    69 8d 92    | CRC: 0x96b149

PDU Type: ADV_IND means Undirected Advertising. To broadcast itself to a Bluetooth Central device for a connection.

Scan Request Packet to Blinky Peripheral

From the packet no. 37, I can see that Blinkly is transmitting a packet. Looking at the end of the “Info” column, I see SCAN_RSP. This is a scan response from Blinky

Looking at a packet before this packet, I can see packet no.36 (source=74:41b0:1d:47:c5) sending out a SCAN_REQ scan request packet. It is other Bluetooth device sending a scan request to Blinky. You can see from the RSSI of -76dBm that this device is quite a distance away from my Blinky device.

As the front data are from Nordic BLE Sniffer, we will skip that and proceed to look at only the data from the Bluetooth Low Energy Link Layer only.

The Access Address (AA) is the same as the previous evaluation that we did. After some research, it is found that this Access Address is standardise to 0x8E89BED6. It is a preamble signal to identify the radio communication on the physical link.

d6 be 89 8e c3 0c c5 47 1d b0 41 74 a0 51 80 71
c9 c0 9a aa f7


d6 be 89 8e | Access Address: 0x8e89bed6

c3 0c       | Packet Header: PDU Type: SCAN_REQ
              c3 | 
                 | b7 Rx Address: Random (1)
                 | b6 Tx Address: Random (1)
                 | b5 Channel Selection Algorithm: #1 (0)
                 | b4 RFU: 0
                 | b3-b0 PDU Type: SCAN_REQ (0b0011)

              0c | Length: 12 (Scanning Address (6bytes) + Advertising Address (6bytes))

c5 47 1d b0 41 74 | Scanning Address: 74:41:b0:1d:47:c5

a0 51 80 71 c9 c0 | Advertising Address: C0:C9:71:80:51:A0

9a aa f7          | CRC: 0x5955ef

Scan Response Packet from Blinky Peripheral

Now going back to look at the Scan Response packet.

d6 be 89 8e 44 18 a0 51 80 71 c9 c0 11 07 23 d1
bc ea 5f 78 23 15 de ef 12 12 23 15 00 00 2a 92
d0


d6 be 89 8e | Access Address: 0x8e89bed6

44 18       | Packet Header: PDU Type: SCAN_RSP
              44 | 
                 | b7 Reserved: False
                 | b6 Tx Address: Random (1)
                 | b5 Channel Selection Algorithm: #1 (0)
                 | b4 RFU: 0
                 | b3-b0 PDU Type: SCAN_RSP (0b0100)
              18 | Length: 24 (Advertising Address (6bytes) + Scan Response Data (18bytes))

a0 51 80 71 c9 c0 | Advertising Address: C0:C9:71:80:51:A0

11 07 23 d1 bc ea 5f 78 23 15 de ef 12 12 23 15 00 00
                  | Scan Response Data (advertising data)
                    11 | Length: 17
                    07 | Type: 128-bit Service Class UUIDs (0x07)
                    23 d1 bc ea 5f 78 23 15 de ef 12 12 23 15 00 00
                       | Custom UUID: 00001523-1212-efde-1523-785feabcd123

2a 92 d0          | CRC: 0x54490b

The scan response returns the data type 128-bit Service Class. This is the long form UUID 00001523-1212-efde-1523-785feabcd123, which identify the service provided by this Bluetooth peripheral.

How CRC is computed?

CRC is 0x54490b base on the hex data of 2a 92 do

Connected to Blinky

This screen shot shows what data will be read to this nRF software when the Blinky gets connected.

This data will be verified with the data communication after the module is connected. We will dive into the data packet details later. We should be able to see all the data as reflected in this nRF Bluetooth app.

The nRF software uses nRF52 Dongle as the bluetooth device to scan for Blinky device. The nRF52 Dongle MAC address is C6:ED:E6:6C:28:CD

Packet Capture to show nRF scanning for Blinky board.

This packets shows Blinky sending advertise packets to broadcast to other bluetooth. It also shows that the nRF software is sending out scan request to check out the blinky device which was advertising itself frequently. The scan request message from nRF to the Blinky is observed to be about 400ms apart. About 2 scan request message per second.

Blinky responsed to the scan request sending back more detail about itself.

Packet Capture to show nRF scan request connection to Blinky

The nRF apps get to connect with Blinky about 135ms after its scan request.

This connection started at packet no. 962, with the nRF Connect connects to the Blinky.

After the connection, the source and destination MAC address seems to be no longer appear.

There will be no more advertising from the Blinky.

Communication is only between nRF apps (Master) and the Blinky (Slave). Period of communication is about 5-10msec.

PDU is no longer indicated after the connection. PDU is for higher level BLE device discovery and connection process.
Type of PDU available
– ADV_IND
– ADV_DIRECT_IND
– ADV_NONCONN_IND
– SCAN_REQ
– SCAN_RSP
– CONNECT_REQ
– ADV_SCAN_IND

Packet Capture to show nRF disconnect from Blinky

When nRF apps disconnect from the Blinky, the Control Opcode: LL_TERMINATE_IND can be observed. Slave response, and shortly after return to its disconnected state and begin to advertise again. Advertise period is about 10msec.

Service Discovery packets after connected

Shortly after the Blinky gets a request to be connected at packet 962, the GATT discovery starts popping out from packet 967 (time 2.845sec) to packet 1036 (time 3.100sec)

Packet 967 from master has a starting handle of 0x0001 to 0xffff, seems to be master asking for services that within these range from the slave.

Packet 970 from slave response with 2 services. One at handle 0x0001, the other at handle 0x000a.

Packet 971 packet from master is almost the same as packet 967. Only the starting handle is different thsi time. It is at 0x000b. This is perhaps master is probing from the slave whether if there are more services from the handle range 0x000b to 0xffff.

The slave response at packet 974 with a handle at 0x000b (which is unknown) with a UUID of 23d1bcea5f782315deef121223150000.

Handle 0x000b eventually stop at packet 978.

The master send a packet no. 981 for a range from starting handle: 0x0001 to 0x0009. Seems that the master understand the messages from slave and starts to adjust its range. It is note that this master has change its read request from “Read By Group Type Request” to “Read By Type Request”.

At packet no. 984, the slave returns even more information. Information about the Generic Access service block.

The master continue to probe at packet 985. Slave packet 988 returns the remain information from the Generic Access service block.

Packet no. 989 to 1004 is master probing deeper (Read Request) from the Generic Access service for more detailed information.

The master starts from “Read By Group Request” (packet 967 to 974) to “Read by Type Request” (packet 981 to 988), and finally “Read Request” (packet 989 to 1004).

These are the GAP profile from what I can see on the Wireshark screen.

Then the master process to Find Information from packet 1007 to 1029. These are the GATT characteristic as displayed.

The last 2 packets (packet 1033, 1036) are Read Request from GAP Profile’s Device Name.

Summary of the connection.

The connection happens at packet no. 962 (time: 2.829sec), and ends at packet no. 2350 (time: 8.027sec).

Within the connection period from packet no. 962 to 2350, the GATT protocol appear. GATT communication (ATT L2CAP protocol) start on packet no. 967 (2.845sec) and ends at packet no. 1036 (3.1sec).

The GATT packets are filtered out from Wireshark. It is noted that it took a total of 28 packets (ATT L2CAP protocol), to complete exposing Blinky’s GATT services to the master device.

Average RSSI maintain good at around –35dBm.

Generic Access Service information can be detected at packet no. 970

Generic Attribute Service information can be detected at packet no. 970

Connect Request Packet

This packet data and the usual data structure to take note. The Bluetooth Low Energy Link Layer packet is always consist of size part.

Bluetooth Low Energy Link Layer

• Access Address (preamble data)
• Packet Header (what this packet is about)
• Initator Address (who request the connection)
• Advertising Address (the peripheral device to accept this connection)
• Link Layer Data (the data)
• CRC (data integrity checking)

Access Address: 0x8e89bed6 (the usual fixed preamble data at the beginning of the BLE data packet)

Packet Header

PDU Type: Connect_REQ (0x5)
Data Length: 34 (address + link layer data)

Initator Address: c6:ed:e6:6c:28:cd

Advertising Address: c0:c9:71:80:51:a0

Link Layer Data

An new Access Address is assigned as 0xc8bb66dc
CRC Init: 0x64fb60
Window Size: 5 (6.25msec)
Window Offset: 0 (0msec)
Interval: 6 (7.5msec)
Latency: 0
Timeout: 400 (4000msec)
Channel Map: ff ff ff ff 1f (default RF Ch 0, 12, 39 for advertising)
Hop: 9
Sleep Clock Accuracy: 0 to 20ppm (7)

CRC: 0x784e01

Hop: 9 means to hop 9 channel away from the current channel. New channel = (curr_channel + hop) mod 37

Connected (Master packet 963)

10 13 00 02 97 16 06 0a 0b 09 21 00 00 ef 04 00
00 dc 66 bb c8 01 00 d0 b6 c8

10 13 00 02 97 16 06 0a 0b 09 21 00 00 ef 04 00 00 | Nordic BLE Sniffer

dc 66 bb c8 01 00 d0 b6 c8 | Bluetooth Low Energy Link Layer

It is noted that the communication Channel is 9. The previous channel during the advertising and connection packet was at Ch 39. This current channel 9 could be the result of the channel hopping.

Access Address: 0xc8bb66dc
The access address is different from the previous one. This same access address is used through out the connection period.

It is noted that the Master & Slave Address being keep tracked. However the address is no where to be found in the packet. This means that the addresses should be tracked by the Wireshark program, probably through the Access Address 0xc8bb66dc

There is only the data header with no data. The data header format has changed. It is different from the format before the connection.
– LLID: L2CAP message
– Next Expected Sequence Number: 0
– Sequence Number: 0 [OK]
– More Data: False
– RFU: 0
– Length: 0

Connected (Slave packet 964)

This slave packet looks very similar from the master packet. The Access Address is the same. The next expected sequence number is 1.

– LLID: L2CAP message
– Next Expected Sequence Number: 0
– Sequence Number: 1 [OK]
– More Data: False
– RFU: 0
– Length: 0

It is observed that both the Next Expected Sequence Number and the Sequence Number keep rotating in sequence 00 01 11 10 ….. It is a sequence number using 2 bits.

More Data could mean if there are more following packets coming which is related to this current packet.

It is also observed that for every pair of master/slave packet, the channel hop by 9 ch.
Ch9, 18, 27, 36, 8, 17, 26, 35, 7, …….
The channel keep hopping. There is also an event counter on the sniffer which will increment for each pair of master/s;ave communication.

The delta delay between the Master and Slave pair is about 150us gap, 230us packet period.

The delta delay between the Slave and Master of the next pair is about 7190us gap, 7270us packet period.

First Attribute Protocol (Master packet 967)

dc 66 bb c8 02 0b 07 00 04 00 10 01 00 ff ff 00
28 4c d0 f3

dc 66 bb c8 | Access Address
02 0b       | Data Header, LLID: Start of L2CAP, Data Length: 11
07 00 04 00 10 01 00 ff ff 00 28 | Bluetooth L2CAP Protocol
                  07 00 | Length: 7
                  04 00 | CID: Attribute Protocol (0x0004)
   10 01 00 ff ff 00 28 | Bluetooth Attribute Protocol
                     10 | Opcode 0x10
                  01 00 | Starting Handler: 0x0001
                  ff ff | Ending Handle: 0xffff
                  00 28 | UUID GATT Primary Service Declaration 0x2800     

This packet seems to be sending a command to start the GATT.

The slave seems to reply nothing (packet 968) like the previous slave response. Seems more like an acknowledge purpose to the master device.

This is followed by Master sending nothing (Master packet 969).

It is noted that packet 968 and 969 doing nothing is labelled as the LE LL protocol (Low Energy Link Layer).

The attribute data packet 967 and 970 are labelled as ATT L2CAP (Logical link control and adaptation protocol).

First Attribute Response Protocol (Slave packet 970)

This is noted in the sniffer wireshark that this packet 970 is the response that is requested from packet 967 (GATT Service request 0x2800). The tools is keeping track of the messages.

More data can be seen by this slave response. The slave is returning 2 groups of attribute data.

• UUID: Generic Access Profile (0x1800)
  • Handle ID (0x0001)
  • End Handle ID (0x0009)
• UUID: Generic Attribute Profile (0x1801)
  • Handle ID (0x000a)
  • End Handle ID (0x000a)