Connect failed (error 36: GDBus.Error:org.bluez.Error.Failed.... about bluez_inc HOT 6 CLOSED

I see you are not stopping the discovery. I would recommend to do that before connecting. Some adapters cannot connect properly while a discovery is on progress.

If that doesn't help, it is probably a Bluez issue....

from bluez_inc.

I have tried both with and without stopping the discovery. No difference i behaviour.

Using sudo hcitool lescan I can see that my nRF Uart shows itself with two services:

E7:FA:F2:24:BF:B6 nrf Uart 0
E7:FA:F2:24:BF:B6 (unknown)

I guess that is because it also have the DFU service on board.
How is multiple device addresses handled by the library?
I can see that in the adapter.c, in binc_set_discovery_filter(), the DuplicateData is set true. Is that going to have some consequences for devices having two different services?

    GVariantBuilder *arguments = g_variant_builder_new(G_VARIANT_TYPE_VARDICT);
    g_variant_builder_add(arguments, "{sv}", "Transport", g_variant_new_string("le"));
    g_variant_builder_add(arguments, "{sv}", DEVICE_PROPERTY_RSSI, g_variant_new_int16(rssi_threshold));
    g_variant_builder_add(arguments, "{sv}", "DuplicateData", g_variant_new_boolean(TRUE));

from bluez_inc.

I tried to remove the DFU-service from the nRF Uart 0-device, and now it connects.
Can it be that the library (or BlueZ) does not cope with two different services on the same address?

My hypothesis is that if the RPi tries to connect to the DFU, which is encrypted, the nRF Uart reject the connection, and hence the error le-connection-abort-by-local?

It is a bit odd, since I assume the library should filter on the service-uuid?

from bluez_inc.

It is totally normal that a peripheral support multiple services. The devices I use to test all have that. So that's not it.

You can connect so that works. However, it seems that the service discovery is failing. Are you able to discover the services if you use 'bluetoothctl' on the command line? And when using applications like 'nRF Connect' on iOS/Android?

I suspect you get the same disconnect issue when using 'bluetoothctl'....if not, then it might be a library issue.

If you can't stay connected when using 'nRF connect' on a mobile phone, there may be something wrong with how you defined your services on the peripheral.

from bluez_inc.

A good friend of mine said "There are no such thing as ONE error".

Error 1: The reason for one of the peripheral disconnect cases was a sporadic HW failure on the peripheral. The crystal for the RTC suffered occasionally bad connection which lead to timing issues. Due to the timing issues, the peripheral initiated a disconnect, and hence the le-connection-abort-by-local.

Error 2: It seems to me that something has changed on the RPi during the last years with respect to BLE. My SW has been running without issues for ~1.5 year. However, somewhere in the latest Buster upgrades (and in Bullseye) something has changed. I'm not skilled enough in the inner workings of BLE/BlueZ/DBus to spot what. Earlier on I could connect to a peripheral without initiating a scan from the SW. To solve the issues I have faced, I had to change this to first try to connect without a scan, and if it fails, do a scan and then connect. It seems to me like somewhere along the path there is introduced buffering on the RPi, where the BLE device info is kept in the buffer for a certain time and then forgotten. To me it seems also like the need for a scan differs and is based on DBus and BlueZ versions as well as if the library is mostly DBus dependent or not.

The "good" thing is that most of my problems were related to my lack of knowledge, and not the libraries used. Now everything seems to work like expected.

from bluez_inc.

Good to hear you got it working and that it is not a library issue. I have been working with Bluez for a while now but I feel the quality of Bluez is a bit inconsistent. Some versions are more stable than others and newer isn't always better....

from bluez_inc.