Troubleshooting
connect() fails with an attestation error
attestationRejected / AttestationRejected
The attestation reached Wi-DAS but didn't match a registered app.
- Android — the wrong certificate. Easily the most common cause. Register Google's app-signing cert SHA-256, not your upload cert. See the Play App Signing trap.
- iOS — the app isn't registered. Confirm your Team ID + bundle ID are registered against
your
clientId. - A bundle or package mismatch. The attested identity has to match your registry entry exactly.
Fix the registration; there's nothing to retry.
attestationUnavailable / AttestationUnavailable
The platform couldn't produce an attestation at all.
- iOS — you're on the Simulator. App Attest isn't available there. Test on a real device.
- Android — no Google Play Services. Play Integrity depends on it, so de-Googled devices can't attest. Those devices sit outside this tier by design.
Degrade the UI here. Don't loop on it.
connect() fails with entitlementMissing / EntitlementMissing
Either your partnerId/clientId is unknown or disabled, or on iOS a required capability is off.
Check that App Attest and Hotspot Configuration are both enabled.
passpointInstallFailed / PasspointInstallFailed
The certificate was issued, but the profile wouldn't install.
- iOS — check the Hotspot Configuration entitlement and that the Keychain access group you
passed matches your Keychain Sharing group. The client cert and Secure Enclave key have to share it
so a
SecIdentitycan form. - Android — check the Wi-Fi permissions merged and that the device supports Passpoint suggestions.
The certificate installs but the device won't join Wi-Fi
This one is usually a network-side trust issue on the RADIUS end.
- RADIUS rejects EC certificates. The SDK defaults to EC P-256. If your Wi-DAS RADIUS server doesn't accept EC EAP-TLS client certificates, the key algorithm needs to fall back to RSA-2048. Confirm during on-device testing.
- Server-trust path can't build. The profile anchors server trust on the supplied
serverCaPemand refuses to install without it. Your AAA/RADIUS server has to present its full intermediate chain in the handshake. Send only the leaf and path-building fails. It's a network configuration detail, not an SDK bug.
status() keeps returning valid from local data
When the status lookup is unavailable, status() falls back to the validity window it stored
locally, which is expected. The real revocation check happens at RADIUS: a revoked certificate can't
complete EAP-TLS whatever status() says. So treat status() as advisory UI, and lean on the
network for the truth.
Retry, or fix the config?
| Symptom | Retry? |
|---|---|
network / Network | ✅ Retry with backoff. |
serviceUnavailable (iOS) | ✅ Retry with backoff. |
attestationRejected, entitlementMissing, issuanceRejected | ❌ Fix registration/config first. |
attestationUnavailable | ❌ Unsupported environment; degrade the UI. |
revoked / Revoked | ❌ disconnect() and tell the user. |
Still stuck?
If none of the above fixes it, contact your Wi-DAS technical contact with the error code, the platform, and whether you're testing on a real device.