BLE Troubleshooting: Pairing, GATT Errors, and “Why Can’t I Read This?”
BLE feels simple until you touch security: characteristics show up but reads fail, writes “succeed” but don’t change behavior, and tooling disagrees about what a device exposes. In most cases, the device is behaving correctly—your mental model is wrong. This guide helps you debug BLE in a controlled environment.
Key terms (the confusion starter pack)
- Pairing: the process that negotiates keys to enable encryption/authenticated access.
- Bonding: storing keys so the relationship persists across reconnects.
- Encryption: link-layer protection; many devices gate “interesting” characteristics behind it.
- ATT/GATT permissions: flags that tell clients when reads/writes require authentication or encryption.
If you see “Insufficient Authentication/Encryption,” that’s not a glitch—your client is being correctly denied.
Common GATT errors and what they mean
- Insufficient Authentication: the operation requires an authenticated pairing method (not “Just Works” in some cases).
- Insufficient Encryption: the link isn’t encrypted (pair first) or encryption level is too low.
- Read Not Permitted / Write Not Permitted: the characteristic is not readable/writable by design.
- Attribute Not Found: you’re using a handle from a different session or stale cache.
- Unlikely Error / Timeout: signal quality, connection interval issues, or the peripheral is overloaded.
Service discovery + caching problems
Many clients cache the GATT table. If firmware changes, bonding changes, or the device exposes different services after pairing, you can end up staring at a stale view.
- Fix: “Forget” the device in your OS/app, clear cache in your BLE tool, and re-discover services after pairing.
- Symptom: Tool A shows a service; Tool B doesn’t; or handles shift across reconnects.
Why characteristics appear but reads/writes fail
1) It’s intentionally gated
Devices often advertise the existence of a characteristic but enforce permissions at operation time. This is normal for device configuration, firmware update, health data, or access control features.
2) You’re connected “wrong” (PHY, interval, MTU)
Some writes fail due to packet sizing (MTU), timing (connection interval), or poor radio conditions. In a lab, shorten distance and reduce interference; then adjust MTU/interval if your tooling supports it.
3) You’re missing a prerequisite state
Some devices require a specific sequence: enable notifications → write unlock → then read protected values. Debug by logging operations and comparing a known-good client app’s behavior.
A repeatable lab workflow
- Pick a lab target you own (dev board or gadget you can reset).
- Capture baseline advertising (name, services, RSSI stability).
- Discover services before pairing and save a snapshot.
- Pair/bond intentionally and then re-discover services.
- Validate permissions (read/write/notify) against what the device claims.
- If you see permission errors: treat it as a success of the security model and pivot to defensive assessment (can keys be protected, can pairing be enforced, is bonding required?).
What changed in 2026
- More devices now gate characteristics behind stronger pairing requirements.
- Client caching behavior remains a top source of false diagnostics.
- BLE stacks increasingly vary by platform, making cross-tool verification essential.
Myth vs reality
Myth: “If the characteristic is visible, it should be readable.”
Reality: Visibility does not imply permission; security state and prerequisites matter.
Validation criteria
- Reads/writes behave consistently before and after pairing transitions.
- Error codes map to expected permission/encryption policy.
- Results are reproducible across at least two BLE client tools.
Quick FAQ
I am connected over BLE—why do I still get no notifications?
Notifications require enabling notify or indicate on the characteristic, usually by writing the Client Characteristic Configuration descriptor (CCCD). You may also need bonding, the correct handle after service re-discovery, or firmware that actually emits events on that characteristic.
What is a CCCD write and why does subscribe fail without it?
The CCCD selects notify or indicate on a characteristic. If the write fails due to permissions or a stale handle, subscription will not work and you will see no incoming notification packets.
Why would notifications work in the vendor app but not in my script?
The vendor app may perform bonding, write hidden control characteristics, or use a different GATT discovery order. Match the same security state and discovery sequence, and compare handle lists against a fresh discovery after bonding.
Deeper symptom walkthrough: BLE: connected but no notifications (CCCD / subscribe).