-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GDBus.Error:org.bluez.Error.Failed: Software caused connection abort #16178
Comments
@caipiblack I am working on how to cross compile the Matter Controller for OpenWrt however I get no luck. Here is the basic info from my side:
@eve-cxrp would you mind briefly providing some hints about how to cross compile the Controller for OpenWrt?I tried to understand the Doc of GN, but without a cross-compiling example, I find it is really hard to move forward |
Two options:
Forget about the G_SOURCE_FUNC macro, this is because I am not using the correct version of GLIB-2.0 Also, note that currently the GN configuration does not provide install step [...] And I think it's not the priority of the people working on Matter (See here: #1513), so you also have to make a script to export the libraries, headers and binaries that you need to use (or just copy it by hand...) You also have documentation about cross-compilation here: https://github.com/project-chip/connectedhomeip/blob/master/docs/guides/nxp_imx8m_linux_examples.md If you have more questions, please create an issue and ask it in your issue. (To keep this issue focused on the Bluez problem) |
Hi,
I have this error as you when i use PRI 4 to commision my device. |
You can shutdown wifi on your rpi 4b and use Ethernet. Then the commissioning by ble will be ok. |
I understand, this problem has been reported in many and many issues, all the answers converge towards the same direction: it is necessary to deactivate the wifi probably to reduce the risk of a packet loss due to WiFi/Bluetooth co-existance. If the problem is really due to a packet loss then it means that the protocol/stack is possibly not robust against this. This error is one of the most frequent during the commissioning. Currently when it happens in our app, the user have to restart the commissioning process and on the next try it works. It's ok but.. |
I think this is a chip-tool on raspberry pi known issue. I use chip-tool under ubuntu 20.04 on PC is good, so there have some bugs under ubuntu on raspberry pi. |
Hi By the way, #9623 also does not work on my raspberry pi 4 |
This problem is a real problem and it’s not only on raspberry pi. We have the problem on various linux boards:
My conclusion is that: Everything that use Bluez have this problem. It's the cause of most of pairing failure. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
This stale issue has been automatically closed. Thank you for your contributions. |
The Raspberry Pi running the chip tool must have WiFi turned off, otherwise it will cause serious interference to the BLE. You can discover the matter device, but cannot successfully establish the BLE connection. The error log is as you can see. If your Raspberry Pi‘s Wi-Fi is indeed on, please use nmcli or rfkill to turn it off, and then try to commission some matter device , you may see the success rate is almost 100%. #Raspberry Pi Wi-Fi on
#Wi-Fi off
|
hello could you solve the problem? When i run the command:
So why i can get the problem, i didn't know. Did you sovle it? Looking forward to your reply |
Hello, No, i didn’t solved this error. but in fact we have the problem in all the linux devices where we integrate matter (openwrt gateway, yocto hub, linux devices in general) for me it’s on every device that has bluez But now we don’t reproduce the problem because we change how the commissioning is made:
|
Using external BLE adapter can solve the problem |
Problem
Many times I got a Bluez failure during the commissiong of BLE-THREAD devices.
My Matter controller is running on OpenWRT but we also have the problem on Raspbian.
This problem has been reported in many issues but they has been closed without real fix:
#9623
#8407
#8416
Restarting the Bluetooth service or playing with RFKill to turn off/on the BLE dongle works but (i think) is not a solution.
Did someone know the root cause of this problem ? How to fix it ?
The text was updated successfully, but these errors were encountered: