Frequent GATT errors #303
Comments
|
Is this library actively maintained? Seems like there hasn't been much response to the most recent bug reports. @philips77 ? |
|
Error 133 does happen frequently on android, it's a known issue. See here for some more informations: https://devzone.nordicsemi.com/f/nordic-q-a/33313/android-gatt-133-error |
|
Hi, sorry for the delay. The library is maintained, but I'm busy with other tasks, so it waits for its time... Looks like the issue is related to how the phone filters scan packets. Have a look at this change in the latest version: 72c0175#diff-da467c50d8806bbe969e81aba215e9b1fc4b34735e13aa46f665fb7ff565aaf6R97 |
This 133 here happens after 30+ sec, so it's a timeout. Android scans for public device address, not random, so it ignores the advertising bootloader. |
|
As filter is not mandatory to scan in background, I think the only thing that could be done is set a different filter. That means we may need to use the "alternative advertising name" feature made with iOS in mind (DFU from SDK 14+). Or set a different filter, e.g. with Secure DFU Service UUID, but that would need to be user configurable setting. |
|
Background scanning seems like it's probably not a very common requirement, whereas the behavior with the current scan filter breaks DFU updates on some devices, so requiring some configuration to support background scanning seems like a reasonable tradeoff. |
|
For what it's worth, in my own Bluetooth code I had found that scan filters worked unreliably on some of my testing devices, so I stopped using them (though again, we don't need to scan in the background). |
|
Yes, we know it's unreliable. I'll check if adding an empty filter works in bg. |
|
Hello @philips77 , any news on this ? Encountering this also on some customer phones (Oppo, Xiaomi, ...) |
|
I was about to open a new issue, but searched for ScanFilter and found this so I'm going to add my notes here as well. As @philips77 pointed out v1.11.1 added the ability to call The other thing I'd like to note is when I would roll back to v1.11.0 things would work fine during a firmware upgrade, but when upgrading back to v1.11.1 I was expecting it to fail again but found that it continued working just fine. However, if I powered off the Redmi phone and started a firmware upgrade process again (DFU Mode) it would more than likely, 95% always fail finding the incremented address during the DFU mode scanning. I also noticed while looking at the BootloaderScannerLollipop.java code it looks like we only scan for 5 seconds and if we timeout after 30seconds it doesn't perform another scan. This is probably a bigger change than this issue, but I feel it may be better to allow scanning for longer than 5 seconds, and at a minimum after each 30 second timeout perform another scan. Almost feels like we may want to scan for the whole connect attempt duration, which I believe is 30 seconds, and when that duration limit is reached call stopScan(). Then repeat the process for X number of attempts. Lastly I use the nRF Toolbar app and noticed that app only uses version v1.10.3 of the DFU library. Is there any reason this app doesn't use the latest DFU library version? Reason I ask is one version considered more stable that the most recent release, or maybe its not having enough time to update all the apps utilizing this library. Mobile Device: |
|
I've rollbacked to 1.11.0 since mid-august and did not encounter any customer issue since. |
|
The scan filter was added, so that scanning was possible in background. Without fillers, scan doesn't return results. I'll release an updated version of this lib soon and will look into this issue.
We're working on a new version, written in kotlin. Perhaps we'll extract dfu from nRF Toolbox and move it to a standalone app, eg. a sample app for dfu project, to make releasing own apps easier. But yes, we just don't have resources to develop new things and maintain all older apps :( |
|
@philips77 Any news about this ? Does the 1.12.0 fixes it ? |
|
Sorry, I didn't have time to look into this yet. All the GATT errors are originiating in the Android system or are coming from the Bluetooth controller, so there's not much we can fix in the library. As a general rule each next version should have less bugs of have more featuers than the older one, so I would recommend upgrading. You may find the change log here: https://github.com/NordicSemiconductor/Android-DFU-Library/releases |
|
Well, as mentionned before in this issue, I was using 1.11.1 in production for a few months, and several customers had this issue. So this is definitely an issue of this library introduced in 1.11.1. You said it yourself : "Looks like the issue is related to how the phone filters scan packets." So my question still stands : is this corrected in the 1.12.0 or should we stick to 1.11.0 ? |
|
The change you're talking about was introduced in 72c0175 (apart from changing tabs to spaces, which makes it unreadable...). scanner.startScan(Collections.singletonList(new ScanFilter.Builder().build()), settings, this);The device addresses are still being checked later in the callback, but perhaps an empty filter can solve both your issues and with scanning in background. If you target API 30 or lower, I can release a 1.11.2 version with requested change, but you may also use 1.11.0 if it works for you. |
|
It's difficult to test because it's happening only on specific devices (1% of our customers).
|
|
Hello @philips77 any new on this issue ? I'd like to update to latest version of the library, but if the original issue has not been fixed some customers will again encounter the same issues |
|
I'm still in Christmas break until next week. As far as I remember, nothing was changed so far with filters. I'll look into it when I'm back. |
|
@philips77 We have updated, and as expected it started to break for some customers, with error GATT error (Xiaomi Redmi Note 9 Pro - what a surprise !) I don't understand how this issue can have stayed open for 2 years with such a clear bug report. With 1.11.0 being unpublished, we are now stuck with broken releases and can't reliably provide updates to our customers |
|
I've locally cloned the library and rollbacked the offloaded filters for everybody, and (as exected) it's now working correctly for Redmi phones and others models that also had the issue (some Xiaomi, Oppo, Samsung, ...) I think you should remove offloaded filters, and later re-implement background DFU with a correctly working implementation (scanning on service UUID maybe ?), after testing on actual devices. |
|
I think passing an empty filter (instead of no filter) will fix the issue of scanning with screen off : Replacing lines 99 to 111 https://github.com/NordicSemiconductor/Android-DFU-Library/blob/main/lib/dfu/src/main/java/no/nordicsemi/android/dfu/internal/scanner/BootloaderScannerLollipop.java#L99-L111 by : |
Information
This GitHub Issue page is for reporting issues or asking questions regarding the iOS DFU library. For general DFU questions, SDK questions, etc, please check our DevZone.
Make sure you are using the latest version of the library:
Also, before creating a new issue, make sure similar issue isn't already opened in open or closed issues.
DFU Bootloader version (please complete the following information):
Device information (please complete the following information):
Describe the bug
Firmware updates frequently fail on some devices, when using library version 1.11.1.
DfuProgressListener.onError()is called witherror=133, errorType=1, message="GATT ERROR"This happens more frequently on some devices than on others. Note that this seems to be a new issue in library version 1.11.1; I have not been able to reproduce it with versions 1.11.0 or 1.10.4.
I ran multiple firmware updates one after the other on several devices to test:
On a Pixel 2, the error happened 5/10 times.
On a OnePlus 3, it happened 1/12 times.
One a Samsung Galaxy S10 it happened 0/10 times.
Logs
In the log below, note the line:
The address is only null when the error occurs.
The text was updated successfully, but these errors were encountered: