The passive scanning sequence (Figure 9.7) was fully covered at the end of PDF 1012. The scanner sets scan parameters with LE_Scan_Type=0x00, enables scanning, and receives LE_Advertising_Report_Event for each ADV_IND heard. No SCAN_REQ is ever sent — the radio only listens.

Active scanning is identical to passive scanning in setup, with one key difference: LE_Scan_Type is set to 0x01 instead of 0x00. When the scanner receives an ADV_IND or ADV_SCAN_IND, the controller automatically sends a SCAN_REQ back to the Advertiser on the same channel. The Advertiser replies with SCAN_RSP containing extra data. Both the ADV_IND data and the SCAN_RSP data are combined into one LE_Advertising_Report_Event delivered to the host.

/* Active vs passive scan: only scan_type differs           */
sudo hcitool lescan            /* active by default         */
sudo hcitool lescan --passive  /* passive — no SCAN_REQ     */

/* Programmatic active scan:                                 */
le_set_scan_parameters_cp p;
memset(&p, 0, sizeof(p));
p.type   = 0x01; /* 0x01 = ACTIVE (sends SCAN_REQ)         */
p.filter = 0x00; /* accept all                             */
p.interval = htobs(0x0010);
p.window   = htobs(0x0010);
hci_send_cmd(sock, OGF_LE_CTL, OCF_LE_SET_SCAN_PARAMETERS,
             LE_SET_SCAN_PARAMETERS_CP_SIZE, &p);

This is the most important sequence diagram in Chapter 9. It shows the complete flow from advertising on one side and initiating on the other, all the way through to active data exchange. The critical insight: LE_Connection_Complete_Event fires on both hosts — both the connecting side and the accepting side receive this event and learn the connection handle and their role.

The key observations from Figure 9.9:

• Both Device A and Device B receive LE_Connection_Complete_Event — A gets Role=Master, B gets Role=Slave
• The connection handle in the event is the local identifier used in all subsequent HCI commands for this link
• The Master always transmits first at each connection event Anchor Point
• Data Channel PDUs use frequency hopping — different channel for each connection event

/* Watching a BLE connection with btmon:                     */
/* sudo btmon                                                */

/* Central side output:                                      */
/* < HCI Command: LE Create Connection (0x08|0x000d)         */
/* > HCI Event: LE Meta Event (0x3e)                         */
/*   LE Connection Complete (0x01)                           */
/*     Status: Success (0x00)                                */
/*     Handle: 0x0040                                        */
/*     Role: Master (0x00)                                   */
/*     Address: AA:BB:CC:DD:EE:FF                            */
/*     Connection interval: 86.25 ms                         */
/*     Supervision timeout: 720 ms                           */

/* hcitool con — list active connections:                    */
/* Connections:                                              */
/*   LE AA:BB:CC:DD:EE:FF handle 64 state 1 lm MASTER       */

The white list always starts empty after HCI_Reset. The host adds devices, and then activates the filter by setting one or more of three filter policy parameters in existing commands. The three usages are completely independent — each controls a different aspect of how the controller filters traffic.

/* White list setup and activation with BlueZ               */

/* Populate the white list:                                  */
hcitool cmd 0x08 0x0010          /* Clear first             */
hcitool cmd 0x08 0x0011 00 FF EE DD CC BB AA  /* Add device */

/* Usage 1: only WL devices can connect (filter_policy=0x01) */
/* Set inside advertising parameters — see PDF 79 for code   */

/* Usage 2: only see WL devices while scanning               */
le_set_scan_parameters_cp sp;
sp.filter = 0x01;  /* White List filter ON                  */
hci_send_cmd(sock, OGF_LE_CTL, OCF_LE_SET_SCAN_PARAMETERS,
             LE_SET_SCAN_PARAMETERS_CP_SIZE, &sp);

/* Usage 3: connect to first available WL device             */
/* HCI_LE_Create_Connection with filter_policy=0x01         */
/* The peer_address and peer_address_type fields are ignored */

The Host Controller Interface provides the standardised communication bridge between the host software and the controller hardware. Chapter 9 explained how BLE reused the BR/EDR HCI and extended it with LE-specific commands and events. The key takeaways: