Bluetooth LE (BTLE) prograaming for Linux

[coppice]

Is anyone familiar with BTLE GATT programming for Linux? I've done some Bluetooth classic programming for Linux in the past, and that's very straightforward, using the standard Bluez library and header files installed on most Linux systems. GATT is a lot different. When I looked for examples in C I find very few, and they all seem to require that I get the source code of Bluez and delve in, not just for the example code, but for lots of support stuff too. Am I missing something? Shouldn't I be able to find all the support stuff in standard installed libraries?

[eutectique]

My (limited) experience of Linux side of BLE is that you need bluez sources to do C application development. There are also Python and JS libraries, I used them briefly to test and validate my BLE devices from Linux, while the other team was preparing their mobile applications.

FYI, I used nRF52DK turned into the packet sniffer for Wireshark.

[dobsonr741]

For a quickyie,  use python:
https://github.com/pybluez/pybluez/tree/master/examples/ble

[coppice]

For a quickyie,  use python:
https://github.com/pybluez/pybluez/tree/master/examples/ble

Thanks, but found the Python support already. The Python support for GATT seems quite good. You can even find some reasonable support for running GATT applications in Javascript from a browser. Its C support I find lacking.

I used the Python support to check that I can communicate with my BT device properly. Now I want to do some serious development in C.

[coppice]

My (limited) experience of Linux side of BLE is that you need bluez sources to do C application development. There are also Python and JS libraries, I used them briefly to test and validate my BLE devices from Linux, while the other team was preparing their mobile applications.

FYI, I used nRF52DK turned into the packet sniffer for Wireshark.

I haven't tested this, but it looks like you can use the cheap nRF52480 dongle for sniffing BTLE. See https://hackaday.com/2021/03/23/a-crash-course-on-sniffing-bluetooth-low-energy/ .

[eutectique]

I haven't tested this, but it looks like you can use the cheap nRF52480 dongle for sniffing BTLE. See https://hackaday.com/2021/03/23/a-crash-course-on-sniffing-bluetooth-low-energy/ .

NordicSemi has sniffer images for quite a few of their boards.

[dare]

BLE programming under linux is largely done by using D-Bus to talk to BlueZ BLE objects.  D-Bus itself is language independent.  However when it comes to BlueZ example code, most of the stuff on the web seems to be written in Python.  Still, once you understand D-Bus it is not that hard to adapt the D-Bus calls to languages, such as C.  If you're new to BLE and BlueZ, then I do suggest experimenting/prototyping in Python first, before tackling C.  Its just a lot easier to iterate/learn that way.

Here is the documentation on the BlueZ D-Bus API, such as it is: https://github.com/bluez/bluez/tree/master/doc.  The more interesting ones are device-api.txt, adapter-api.txt, gatt-api.txt and advertising-api.txt.  Be forewarned, this documentation is *very* weak, and I've often had to go to the web, or to the BlueZ code itself, to understand the subtleties of how to use it.

In case it is useful, here's a trivial BlueZ-based BLE client application I wrote in Python as a demonstration: https://github.com/jaylogue/nrf52-baseline-app/blob/master/app-client.py.  Again, once you understand how the D-Bus BLE interfaces work, it should be straightforward to reproduce this application in other languages. 

This script is part of a larger "baseline" example BLE application I built for the Nordic nRF52840: https://github.com/jaylogue/nrf52-baseline-app  I never did get around to writing any documentation for this project, but if you're interested I'm happy to answer questions.  It is a pretty clean example of using the nRF52840 plus the Nordic BLE SoftDevice in a bare-metal application.

As for sniffing BLE, I prefer to use the Sniffle firmware (https://github.com/nccgroup/Sniffle) running on a zzh! RF stick (https://electrolama.com/projects/zig-a-zig-ah/).  The Sniffle firmware has the ability to hop along with BLE channel changes, which make it easier to capture advertising traffic.

[wilhe_jo]

I usually stick to Qt as I prefer KDE.

As a side effect, cross-compile to windows and android is pretty easy.

73

[coppice]

As for sniffing BLE, I prefer to use the Sniffle firmware (https://github.com/nccgroup/Sniffle) running on a zzh! RF stick (https://electrolama.com/projects/zig-a-zig-ah/).  The Sniffle firmware has the ability to hop along with BLE channel changes, which make it easier to capture advertising traffic.

That sounds interesting, but when I look here https://www.tindie.com/products/electrolama/zzh-cc2652r-multiprotocol-rf-stick/ it seems to be unavailable right now. I should get one of the Nordic dongles in a couple of days. I'll see how that works out.

[coppice]

I now have an rRF52480 dongle, programmed with the sniffer software. It works OK on a Windows machine. However on my Linux (Fedora) machine the extcap software doesn't seem to interface with the dongle port correctly. If I run "py nrf_sniffer_ble.py --extcap-interfaces" I get

Code: [Select]

extcap {version=4.1.1}{display=nRF Sniffer for Bluetooth LE}{help=https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Sniffer-for-Bluetooth-LE}
control {number=0}{type=selector}{display=Device}{tooltip=Device list}
control {number=1}{type=selector}{display=Key}{tooltip=}
control {number=2}{type=string}{display=Value}{tooltip=6 digit passkey or 16 or 32 bytes encryption key in hexadecimal starting with '0x', big endian format.If the entered key is shorter than 16 or 32 bytes, it will be zero-padded in front'}{validation=\b^(([0-9]{6})|(0x[0-9a-fA-F]{1,64})|([0-9A-Fa-f]{2}[:-]){5}([0-9A-Fa-f]{2}) (public|random))$\b}
control {number=3}{type=string}{display=Adv Hop}{default=37,38,39}{tooltip=Advertising channel hop sequence. Change the order in which the sniffer switches advertising channels. Valid channels are 37, 38 and 39 separated by comma.}{validation=^\s*((37|38|39)\s*,\s*){0,2}(37|38|39){1}\s*$}{required=true}
control {number=7}{type=button}{display=Clear}{tooltop=Clear or remove device from Device list}
control {number=4}{type=button}{role=help}{display=Help}{tooltip=Access user guide (launches browser)}
control {number=5}{type=button}{role=restore}{display=Defaults}{tooltip=Resets the user interface and clears the log file}
control {number=6}{type=button}{role=logger}{display=Log}{tooltip=Log per interface}
value {control=0}{value= }{display=All advertising devices}{default=true}
value {control=0}{value=[00,00,00,00,00,00,0]}{display=Follow IRK}
value {control=1}{value=0}{display=Legacy Passkey}{default=true}
value {control=1}{value=1}{display=Legacy OOB data}
value {control=1}{value=2}{display=Legacy LTK}
value {control=1}{value=3}{display=SC LTK}
value {control=1}{value=4}{display=SC Private Key}
value {control=1}{value=5}{display=IRK}
value {control=1}{value=6}{display=Add LE address}
value {control=1}{value=7}{display=Follow LE address}
Which seems to have everything right, except the interfaces line. The log from extcap when Wireshark is running shows it correctly recognises /dev/ttyACM0 as the dongle's port, but extcap seems to exit immediately after opening that port. Has anyone else had a similar experience?

[eutectique]

I only used sniffer with Wireshark in Xubuntu, couldn't help you, sorry.

[coppice]

I found what is wrong with the sniffer software on my Fedora Linux machine. It seems like most modern Linux machines should have similar problems.

To use the serial ports on a Linux machine you have to be a member of the "dialout" group. The install instructions tell you to sort that out. However, the Nordic code also tries to use traditional lock files in /var/lock, but messes them up. Root status is needed on modern Linux machines to create and write files in /var/lock (or /run/lock). So, they put the lock files for things like serial ports in a subdirectory called /var/lock/lockdev, which anyone can write to. I changed the Python code for the Nordic capture software to use /var/lock/lockdev , and it still gets things wrong. It never removes the locks it has created. For the moment I have disabled the locking and unlocking code, by simply changing the tests in Filelock.py to look for the system be an "xlinux" one, instead of a "linux" one. Now I can capture OK.

[Chat GPT]

You are correct that programming with the Bluetooth Generic Attribute Profile (GATT) using the Bluez library can be more involved than using the Bluetooth classic programming interface. GATT is a protocol that operates on top of the Bluetooth Low Energy (BLE) standard, which is quite different from classic Bluetooth.

It is true that finding examples of GATT programming with Bluez can be challenging, as the official documentation is often geared towards Bluetooth classic programming. However, there are some resources available online that may be helpful, such as the Bluez GATT D-Bus API documentation, which provides detailed information about the GATT API functions and their parameters.

In short, programming with GATT using Bluez does require some additional effort compared to classic Bluetooth programming, but it is certainly possible to develop GATT applications with the Bluez library once you have the necessary development packages and documentation.

[coppice]

In short, programming with GATT using Bluez does require some additional effort compared to classic Bluetooth programming, but it is certainly possible to develop GATT applications with the Bluez library once you have the necessary development packages and documentation.

Of course its possible to develop for GATT. The problem is something that mature has normally been packaged to the point of making basic examples trivial to put together. When there is more open source code around in Javascript than in C, it seems to strongly suggest the hurdles have really inhibited serious application building. Whether I look for documentation, examples, or support libraries, its all weak.