如何在 Ubuntu 20.04 上使用 BlueZ 5 和 5.4 内核发送打包的广告数据包

Question

In prior kernels and releases of Ubuntu, it was possible to use the hci socket interface to send an arbitrary set of 31 bytes as an advertising beacon, but in ubuntu 20.04 the hci bluetooth tools were deprecated, as were some elements of the socket API they were using.

The goal is to have some N number of devices broadcast 31 bytes of sensor data to each other at a rate of 5 Hz, and have all N read the packets from the other devices.

With the hci socket API being deprecated, the replacements are the DBus BlueZ API and the Management BlueZ API. The DBus API is limited and seems to only allow a max of 25 bytes. The Management API seems more capable, and it seems to work on Ubuntu 18.04/4.15 kernel (though even there the scan seemed to only pick up the advertisements sporadically when switching between scan and advertise every 100ms while with the hci api it was rock solid), but on Ubuntu 20.04/5.4 kernel, various issues crop up.

• Using the hci socket API seems like it could still be possible, but even running something like hcitool lescan results in btmon saying Command Disallowed . I believe this might be due to LE Extended Advertising being enabled, but I have not figured out how to disable it yet.

• Using the DBus API (or bluetoothctl ) is still limited and doesn't allow the full use of the 31 bytes (or even 30 bytes + length)

• Using the Management API leads to a Advertising Timeout shortly after setting the advertising data, which I think might be from LE Extended Advertising being enabled. This problem persists even if I explicitly set the timeout in the packet.

For example, running

btmgmt add-adv -c -d 1E000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D 1

to send an advertising packet at a fixed MAC with the advertising data being length:31 payload: 0-30 results in a btmon output of:

  < HCI Command:... (0x08|0x0036) plen 25  #631 [hci0] 5676.358401
        Handle: 0x01
        Properties: 0x0013
          Connectable
          Scannable
          Use legacy advertising PDUs: ADV_IND
        Min advertising interval: 1280.000 msec (0x0800)
        Max advertising interval: 1280.000 msec (0x0800)
        Channel map: 37, 38, 39 (0x07)
        Own address type: Public (0x00)
        Peer address type: Public (0x00)
        Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
        Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
        TX power: 127 dbm (0x7f)
        Primary PHY: LE 1M (0x01)
        Secondary max skip: 0x00
        Secondary PHY: LE 1M (0x01)
        SID: 0x00
        Scan request notifications: Disabled (0x00)
> HCI Event: Command Co.. (0x0e) plen 5  #632 [hci0] 5676.359321
      LE Set Extended Advertising Parameters (0x08|0x0036) ncmd 1
        Status: Success (0x00)
        TX power (selected): 7 dbm (0x07)
< HCI Command: L.. (0x08|0x0039) plen 6  #633 [hci0] 5676.359410
        Extended advertising: Enabled (0x01)
        Number of sets: 1 (0x01)
        Entry 0
          Handle: 0x01
          Duration: 2000 ms (0xc8)
          Max ext adv events: 0
> HCI Event: Command Co.. (0x0e) plen 4  #634 [hci0] 5676.361330
      LE Set Extended Advertising Enable (0x08|0x0039) ncmd 2
        Status: Success (0x00)
@ MGMT Event: Com.. (0x0001) plen 4  {0x0003} [hci0] 5676.361372
      Add Advertising (0x003e) plen 1
        Status: Success (0x00)
        Instance: 1
> HCI Event: LE Meta Ev.. (0x3e) plen 6  #635 [hci0] 5676.362333
      LE Advertising Set Terminated (0x12)
        Status: Advertising Timeout (0x3c)
        Handle: 1
        Connection handle: 65535
        Number of completed extended advertising events: 0

Is there a good way to recreate the functionality that was available using the hci socket, or a way to disable extended advertising so that the hci socket works again?

Answer 1

This image from Jos Ryke might help explain what is going on. Of those 31 bytes, 3 were always used for setting the advertising flags.

Looking at the source code for btmgmt those flags are now set with the -g , and -l command line switches. Use general discoverable mode to advertise indefinitely.

static void add_adv_usage(void)
{
    bt_shell_usage();
    print("Options:\n"
        "\t -u, --uuid <uuid>         Service UUID\n"
        "\t -d, --adv-data <data>     Advertising Data bytes\n"
        "\t -s, --scan-rsp <data>     Scan Response Data bytes\n"
        "\t -t, --timeout <timeout>   Timeout in seconds\n"
        "\t -D, --duration <duration> Duration in seconds\n"
        "\t -P, --phy <phy>           Phy type, Specify 1M/2M/CODED\n"
        "\t -c, --connectable         \"connectable\" flag\n"
        "\t -g, --general-discov      \"general-discoverable\" flag\n"
        "\t -l, --limited-discov      \"limited-discoverable\" flag\n"
        "\t -n, --scan-rsp-local-name \"local-name\" flag\n"
        "\t -a, --scan-rsp-appearance \"appearance\" flag\n"
        "\t -m, --managed-flags       \"managed-flags\" flag\n"
        "\t -p, --tx-power            \"tx-power\" flag\n"
        "e.g.:\n"
        "\tadd-adv -u 180d -u 180f -d 080954657374204C45 1");
}

The other 28 bytes must start with a byte declaring the length and a byte declaring what data type the rest of the bytes in the declared length are describing. It is those 28 bytes that is being set with the -d option of btmgmt .

If 28 bytes are not enough, then common workarounds people use is to split the data over multiple adverts or use scan response packet.

There is more detail on the Advertising Data Format in the Core Specification where it defines an Advertising Packet as:

A packet containing an advertising PDU. See [Vol 6] Part B, Section 2.3.1

More data is section:

BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part C | 11 ADVERTISING AND SCAN RESPONSE DATA FORMAT

It has an example for ADV_NONCONN_IND packet type:

PDU Type: 2
ChSel: RFU
TxAdd: 1 (random)
RxAdd: RFU
AdvA: 0xC1A2A3A4A5A6 (a static device address)
AdvData: (3 octets) 0x01 0x02 0x03

Which starts with the flags data type.