Unable to pair/connect with bluetoothctl #172
Comments
|
Perhaps something from what is described here will help you: |
|
Unfortunately no, it doesn't help. I tried LYWSD03MMC with PIN, LYWSD03MMC without PIN and CGG1-M without PIN. It is as if this bluetooth adapter cannot connect/pair at all. It scans fine but refuses to connect. :-( I will see if I can pair/connect to another type of bluetooth device and/or if I can insert a second (USB) receiver in this raspberry pi. |
|
Got a bit further by using btmon. It seems to create a connection successfully but then cancel it for some reason: Now looking at https://www.spinics.net/lists/linux-bluetooth/msg67241.html and https://stackoverflow.com/questions/43529336/bluez-5-unknown-connection-identifier if those provide some hints on what's going wrong. Reporting it here in case some else using this firmware runs into the same problem. Edit: lowering the advertising interval to 1s brought me one step closer. I can now successfully connect! Pairing gives another error now but I guess that's okay because the bluetooth subsystem simply doesn't know what to do with this device. Solution: It seems that on more recent Linux kernels it's only possible to connect to these kind of BLE devices if the advertising interval is smaller than 2 seconds because of a newly added timeout in the kernel. |
|
For the BLE standard, the maximum advertising interval is 10 seconds. |
|
I know. The Linux kernel people basically broke it by implenting this
"auto" connection stuff with its 2s timeout. The workaround is to stay
within 2s advertising interval if you want to be able to connect fron such
a broken kernel.
…On Tue, 4 Jan 2022, 14:15 Victor, ***@***.***> wrote:
For the BLE standard, the maximum advertising interval is 10 seconds.
—
Reply to this email directly, view it on GitHub
<#172 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABQ47VVLPASFTNDIJD7CHDUULXILANCNFSM5LC3EC4A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Core Specification 5.3 4.4.2.2.1 Advertising interval Accessory Design Guidelines for Apple Devices Release R15: The accessory should first use the recommended advertising interval of 20 ms for at least 30 seconds. Someone from Apple got into Linux :) |
|
|
|
I found this thread today because I was facing issues connecting to my devices (wanted to change something) and I thought it could be related to me enabling the PIN in the past, but in the end, bringing them next to the computer helped me to connect to them using So now I'm curious and thinking if it was not bringing them near the computer the thing that helped and was just pure luck and if I should lower the advertising time (which I guess impacts battery life)...
Do you have any references for this? Because I use Arch Linux and I should have a pretty fresh kernel and Bluetooth stack: |
My advertising time was set to 5000ms and that was too high for my kernel to ever connect. It would just not work at all. I then changed to 1000ms which worked wonders ofcourse. In the end I set them to 2500ms (default value) because I was curious if I would then end up being able to connect sometimes (luck). This turned out not to be the case. Even with 2500ms I can connect reliably. With 5000ms it is totally impossible. I tried that. I didn't try all values in between.
Read the stackoverflow thread linked above. |
Ok, thanks for the detailed info. I'll keep them at 2500ms, I guess my issue was more related to signal strength then, I've been doing more tests and I can connect reliably to them if I put them near the computer.
Sorry I missed those links! Thanks. |
Ok after reading those references and doing some digging and if I understood correctly: Kernel <3.17: 20 seconds timeout for BLE connections. This last change is from a later date than the SO and mailing list posts so I guess that 2500 is indeed good enough and my problem was 100% signal strength. |
Thanks for the digging! That totally explains my situation because I'm running a kernel > 4.16 so apparently the timeout is 4s in my case and that's why 2500ms works but 5000ms doesn't. The signal strength / connection issues are more apparent in LYWSD03MMC devices because of a missing condensator. You can find more info on that elsewhere. I actually replaced one of my LYWSD03MMC devices by a CGG1-M because I want to use it as a display for external data and I need to reliably be able to connect to it. |
The reliability of the connection cannot be at the level of 2500 ms. One lost reception and the second sending of a connection request will be in 5000..5020 ms, when the second advertisement arrives. |
This means there is no Bluetooth LE support on Linux! |
Interesting... but this capacitor can easily be added. Is that capacitor between + and - lines of battery? there are C24 and C25. Which value they should be? I'm guessing that smaller is around 100nF and bigger in a micro range...? |
|
Desirable more than 10 μF (С24) and more 100 nF (C25). All Qingping devices - all capacitors are installed. |
|
If these capacitors can be omitted in normal operation by Xiaomi , adding them wouldn't increase standby leakage current ? |
|
pvvx: thanks for info! I have such SMD's at home, so i'll solder them. |
When they first implemented it they set a 20 seconds timeout. But after some time they added the 2 seconds timeout (that later they raised it to 4) for "auto-connections". Is not clear to me (mostly because I do not have knowledge of the BLE protocol) what they mean by auto-connections, they mention that is when a connection is established as a consequence of receiving an advertising report, but no clue what this really means. This is the commit where they first included it:
|
Where did "High Duty Cycle Advertising" come from?
Но термометр не передает ADV_DIRECT_IND, а передает тип рекламы ADV_IND (code: 0). When the device is paired and does not have a keyboard or display, and the pin code is remembered, a quick connection with negotiation is performed. "quick" - in the understanding that a new PIN code is not requested and a new connection key is not required ... It is completely incomprehensible why there is "High Duty Cycle Advertising" here? |
|
nRF Connect, Advertiser, set option: Connectable, interval: 4000 (2500 ms): The "[bluetooth] # connect" does not make any requests for on the BLE air. Linux is dead. |
|
@pvvx I've replicated your test with the same nRF Connect parameters and with this kernel and Bluetooth stack versions: I can connect with reliability using interval 4000 (2500ms), I've made several tests. However, if I change the interval to 8000 (5000ms) it is impossible to connect! I'll will try to recomplie the kernel changing that value and maybe is worth to write to the Kernel Bluetooth maintainers. |
Sometimes it connects to a thermometer and a smartphone with a timing of 2.5 seconds. But more often than not, it's a mistake. Even on NanoPi R1, OpenWrt 18.06.1: Smartphone with Android and Windows PC is always connected. |
That kernel version has the timeout set to 2s, that's probably why.
I'll recompile the kernel with a higher limit and perform some tests, and will ask why this limit in the mailing list. |
|
I recompiled my kernel version with the following patch (setting the timeout to 20 seconds) and I can connect setting nRF Connect with interval to 16000 (10000ms), it still fails sometimes. In any case, I didn't read the specification for the recommended timeout, but I guess is max interval x2 so maybe with 21s is more reliable. With lower intervals, I tested 12000 (7500ms), and 8000 (5000ms), connected every time. So... I guess I'll be asking in the Bluetooth kernel mailing list tomorrow. diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index b80415011dcd..562c27b12d40 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -344,7 +344,7 @@ enum {
#define HCI_AUTO_OFF_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
#define HCI_POWER_OFF_TIMEOUT msecs_to_jiffies(5000) /* 5 seconds */
#define HCI_LE_CONN_TIMEOUT msecs_to_jiffies(20000) /* 20 seconds */
-#define HCI_LE_AUTOCONN_TIMEOUT msecs_to_jiffies(4000) /* 4 seconds */
+#define HCI_LE_AUTOCONN_TIMEOUT msecs_to_jiffies(20000) /* 20 seconds */
/* HCI data types */
#define HCI_COMMAND_PKT 0x01 |
|
@skgsergio - Useless venture. Linux is long dead - it was killed by the Arduino generation. Why is the second advertising event expected after receiving the first reception of the advertising event, if it was possible to establish a connection (send a connection request) at the first reception? |
|
Set ATC_0B5EED advertise interval to 10000 ms. Test 'bluetoothctl' No ATC_0B5EED scan for 10 minutes! Scan ATC_0B5EED finds at once! None device ATC_0B5EED ! Connection! Go 'bluetoothctl'... Linux, what can I say ... :) :) 'bluetoothctl' cannot scan if there is no 'flag' in the advertisement and cannot connect with an error if the advertisement interval is more than 2 sec. |
|
Windows 10, Chrome and BT-USB adapters. Adapter labeled 'Basseus' - scanning ok. |
|
I wrote to the mailing list (no response yet, but I've found later an old 2016 thread where they say what is their reason not to increase it: link to the response). Anyway, then I found digging more in the kernel and in bluez that there is a Bluetooth management API and it allows you to change the timeout. The downside is that is only present since kernel 5.9 and bluez 5.56:
This can be called using bluez's For example, with nRF Connect setting interval to 12000 (7500ms): It is pretty hidden but it worked for me, it has the same effect and when I recompiled the kernel. Keep in mind this option doesn't persist reboots. |
|
Ok, there is a way of properly configuring it and making it persist. It requires bluez 5.55 or newer and kernel 5.9 or newer.
The limit seems to be 0x4000 (16384). |
The most stupid excuse (those. complete incompetence): If the adapter does not allow simultaneous operation with other functions, then the connection interval is calculated by a timer. PS: Clearly Arduno crawled into Linux. |
|
TLSR825x (similar to Xiaomi LYWSD03MMC) automatically calculates the advertisement interval in 2 steps and then adjusts to switch synchronous advertisements and receive advertisements from the follower. Reception window: Discrepancies, because the ad interval should contain a random additive to reduce collisions: |
Strange enough that it also works without problems on Android because it´s a Linux based operating system.... But on my Samsung S21 with original Android 12 from Samsung disconnect from time to time. In notice also that the battery of the sensor need to be almost new when connect. Than it will work a lot better. Also on Mint 21. But i like your firmware very much and works really nice! Thank you. :) |
“Based on” Linux – long ago rewritten by Google. All that's left of Linux is the name. :) |
I didn't manage to make it work, tried values between 10000 and 16384 (I have fw advertisement interval of 10s). |
I'm not sure if there's something wrong with the setup of the bluetooth controller in my raspberry pi 3 so I'm seeking for confirmation here that what I'm trying to do should work with custom firmware.
Using bluetoothctl with transport set to 'le' I'm trying to do the following things:
I tried this with multiple LYWSD03MMC and CGG1-M devices and always get above results. I should be able to pair and/or connect to these devices running custom firmware, right?
The reason I'm trying to connect is because I want to send custom data to the LCD. Receiving and decoding advertisements from these devices has always worked fine but that doesn't require an active connection.
I also tried gatttool but I get Transport endpoint is not connected there. Supposedly gatttool is not supported anymore so I'm not sure if that has anything to do with my bluetoothctl issues.
The text was updated successfully, but these errors were encountered: