133 errors
See original GitHub issueHello
I’m getting a lot of the GATT 133 errors when trying to do a DFU. We’ve implemented the buttonless DFU and it works perfectly on IOS, but I keep getting the 133 in the DFUService. See attached logs: Any hints on what can be done to minimise this issue?
10-31 18:46:29.557 31469-31469/xxx D/BluetoothGatt: close()
10-31 18:46:29.567 31469-31469/xxx D/BluetoothGatt: unregisterApp() - mClientIf=9
10-31 18:46:30.037 31469-31469/xxx I/DfuService: DfuService onCreate
10-31 18:46:32.087 31469-31748/xxx I/DfuBaseService: Connecting to the device...
10-31 18:46:32.087 31469-31748/xxx D/BluetoothGatt: connect() - device: CD:B0:6F:A2:39:6E, auto: false
10-31 18:46:32.097 31469-31748/xxx D/BluetoothGatt: registerApp()
10-31 18:46:32.097 31469-31748/xxx D/BluetoothGatt: registerApp() - UUID=991273b2-06c7-4c4b-b129-c3282904c6e7
10-31 18:46:32.137 31469-31496/xxx D/BluetoothGatt: onClientRegistered() - status=0 clientIf=9
10-31 18:46:32.537 31469-31481/xxx D/BluetoothGattServer: onServerConnectionState() - status=0 serverIf=8 device=CD:B0:6F:A2:39:6E
10-31 18:46:32.537 31469-31481/xxx D/BluetoothGattServer: Server disconnected, update device to list
10-31 18:46:32.547 31469-31481/xxx D/AppManager: Server onConnectionStateChange DISCONNECTED DFU-H41J Address: CD:B0:6F:A2:39:6E
10-31 18:46:32.547 31469-31480/xxx D/BluetoothGatt: onClientConnectionState() - status=133 clientIf=9 device=CD:B0:6F:A2:39:6E
10-31 18:46:32.557 31469-31480/xxx E/DfuBaseService: Connection state change error: 133 newState: 0
10-31 18:46:32.557 31469-31748/xxx E/DfuBaseService: Device got disconnected before service discovery finished
10-31 18:46:32.567 31469-31748/xxx D/BluetoothGatt: refresh() - device: CD:B0:6F:A2:39:6E
10-31 18:46:32.567 31469-31748/xxx I/DfuBaseService: Refreshing result: true
10-31 18:46:32.567 31469-31748/xxx I/DfuBaseService: Cleaning up...
10-31 18:46:32.567 31469-31748/xxx D/BluetoothGatt: close()
10-31 18:46:32.577 31469-31748/xxx D/BluetoothGatt: unregisterApp() - mClientIf=9
10-31 18:46:33.257 31469-31469/xxx I/DfuService: DfuService onDestroy
Issue Analytics
- State:
- Created 7 years ago
- Reactions:4
- Comments:17 (4 by maintainers)
Top Results From Across the Web
Code Error 133 - Microsoft Community
While playing a game my pc froze completely (no keys working no mouse movement, nothing) then gave me a blue screen. this has...
Read more >CWE-133: String Errors (4.9) - MITRE
CWE CATEGORY: String Errors ; HasMember, Base - a weakness that is still mostly independent of a resource or technology, but with sufficient...
Read more >Overview of the 133 errors and 122 warnings detected in the...
Inconsistency between metadata and code customizations is a major concern in modern, configurable enterprise systems. The increasing reliance on metadata, in ...
Read more >Model 133 and Model 136 Error Code definition - Endevco
Model 133 input Select errors occur when "Volt" is selected without a Current Excitation, i.e. an open or shorted Isotron/IEPE input.
Read more >RFC 133 - File Transfer and Error Recovery - IETF Datatracker
File Transfer and Error Recovery (RFC 133, April 1971. ... Network Working Group R. L. Sunberg Request for Comments: 133 Harvard University NIC...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

Hello, I just discovered one thing that had a major impact on the amount of 133 errors we got while doing DFU. As you mention over the problem might be correlated with connection parameters and many before has mentioned that 133’s can origin from timing issues.
What we saw was that after sending the necessary commands to put the device in bootloader modus and disconnecting, the act of connecting to the “new” (changed mac-address) device would randomly fail. After a full day of BLE sniffing and debugging I realised that when the connection failed, with an 133 error, Android had not sent any connection request over the air, so the whole “could not connect” or “got disconnected before service discovery” was generated internally in Android.
The solution that I tried was to do a short scan before trying to connect. I didn’t care about the scan results, this was just a way to put the Bluetooth radio in another state. And it seems to work.
So the procedure is as follows:
This might help some others struggling with the same error. Please let me know if anyone has more info regarding this issue.
Yeah, thats the big problem, it happens quite frequently. Like over 50% of the time. Any ideas what triggers this behaviour?