gattlib_adapter_scan_enable() must be called first for gattlib_connect() to work.

[tvonderhaar]

I have modified the Owon multimeter program "owonb35.c" from:

https://github.com/DeanCording/owonb35

to work with the current gattlib version (0.7.2). The original code could connect to the device without doing a scan first by supplying the known device address to "gattlib_connect()". The original code "owonb35.c" was written 6 years ago and it appears gattlib has changed significantly since then. All the gattlib examples that work connect through the "gattlib_adapter_scan_enable() " call back.

The error returned from "gattlib_connect()" is "invalid parameter" when no scan is performed first. If a scan is performed first than no error occurs. Must a scan be performed before calling "gattlib_connect()" or is there a bug in the current gattlib library?

Also, the "owonb35.c" code attempts a scan retry every 2 seconds if a scan fails. It calls "gattlib_adapter_scan_disable()" before calling "gattlib_adapter_scan_enable()" on retries. On the second retry scan "gattlib_adapter_scan_disable()" fails with the unknown gattlib error code "0X1000C524". Is this also a bug?

There is no documentation I can find describing the overall architecture of gattlib. Some documentation describing what functions must be called before others can be called would be useful(ex. "gattlib_adapter_open()" needs to be called before before calling "gattlib_adapter_scan_disable()".) The sphinx and doxygen docs contain very minimal information.

Thanks,
Tom

[20Alex16]

Hi,

Short answer: Gattlib seems not to be able to acquire a handle to an active connection.

Long answer: From what I understand from its behavior, it seems like if a connection was already established before launching the program, the device advertising will obviously stop advertising, therefore will not be listed when scanning. gattlib_internal.h file does provide some interesting functions that potentially could workaround this mishap.

"invalid parameter" is coming from the connection which is NULL (missing handle). You can also notice the error param is 1 (meaning invalid parameter as well).

My suggestion (as proposed by ChatGPT and supposing you have bluetoothctl working on your system) is pretty rudimentary: do a force disconnect, which will trigger the other device to fall to an advertisement state, that you can re-scan then try to reconnect:

static void force_disconnect(const char *addr) {
    char cmd[128];
    snprintf(cmd, sizeof(cmd), "bluetoothctl disconnect %s >/dev/null 2>&1", addr);
    system(cmd);
}

I agree, this solution is not elegant or pleasant, but gets the job done.

It is worth mentioning this line from project description:

On Bluez versions prior to v5.42, gattlib used Bluez source code while it uses D-Bus API from v5.42.
D-Bus API can be used on version prior to Bluez v5.42 by using the CMake flag -DGATTLIB_FORCE_DBUS=TRUE

It seems like the old project was using bluez calls, which could provide the necessary handle. Moving to dbus, this was not properly migrated and this feature broke.