Blog
July 10, 20266 min read

eduroam won't connect on your Pixel? Check the Anonymous Identity field

GrapheneOSNetworking802.1XDebugging

On GrapheneOS and stock Pixels, an eduroam profile can look perfectly configured and still fail: the Wi-Fi associates, then authentication silently times out. On many university accounts the culprit is a single empty field. Here is how to prove it and fix it.

The symptom

The network shows “Saved / Connection failure” or “Can't connect. Try again later.” Normal Wi-Fi and mobile data work fine — only eduroam fails. That last part matters: it rules out broken hardware before you even start. The radio associates with the access point (you briefly see “Connecting…”), then drops after roughly 40 seconds, never reaching the four-way handshake or getting an IP.

Confirm it's authentication, not hardware

“It must be a hardware fault” is the common misdiagnosis. A radio fault would break every network. This breaks only at the 802.1X / EAP stage — pure software and configuration. With ADB and USB debugging on, you can watch it happen:

# Watch the Wi-Fi state machine for the eduroam attempt
adb shell dumpsys wifi | grep -i eduroam | tail

# The tell-tale line — associates, then the phone itself bails:
NETWORK_DISCONNECTION_EVENT ssid:"eduroam"
   reasonCode: 3 locallyGenerated: true

# On repeated tries the access point gets blocklisted:
blockReason=REASON_FAILURE_NO_RESPONSE

reasonCode 3 + locallyGenerated: true about 40 seconds after associating is an EAP timeout: the phone started the login handshake and gave up waiting. A wrong password fails fast with a rejection — a 40-second stall points at the outer identity / TLS stage instead.

Blocklist gotcha

After a few failures, Android blocklists those access points for minutes to hours and stops auto-retrying them. So even after you fix the config, auto-reconnect may look dead. Force it: open the network and tap Connect, or toggle Wi-Fi off and on.

The root cause

Open the eduroam profile (Wi-Fi → the network → the pencil → Advanced) and look at Anonymous identity. On a failing Android 14+ device it's often empty.

That empty field is the bug. The anonymous (outer) identity is the cleartext name your phone presents before the encrypted tunnel opens — it's what eduroam uses to route your login back to your home institution. Many institutions require it to carry the full realm. Leaving it blank is only the pre-Android-14 fallback; on modern Android the server never answers, and you get REASON_FAILURE_NO_RESPONSE.

The fix

Set Anonymous identity to your full eduroam username, including the realm — the same user@institution you use for Identity. Leave everything else as your institution specifies (commonly PEAP / MSCHAPV2, and “Trust on first use” or your institution's CA + domain).

  1. Open the eduroam network → pencil / Modify → expand Advanced options.
  2. Type your full user@institution into Anonymous identity.
  3. Confirm Identity and password are correct, then Save.
  4. Tap the network and press Connect — don't wait for auto-reconnect; those APs may still be blocklisted.

Within a second or two it should authenticate and pull an IP:

adb shell dumpsys wifi | grep "mWifiInfo SSID"
SSID: "eduroam", Supplicant state: COMPLETED,
   IP: 10.232.221.62 ... VALIDATED

adb shell ping -c2 1.1.1.1
64 bytes from 1.1.1.1: time=7.1 ms 0% packet loss
If it still fails

If the outer identity is set and it still won't authenticate, check in order: (1) your account is actually enabled for eduroam, not just campus Wi-Fi; (2) CA certificate + Domain match your institution's published values; (3) try Privacy → “Use device MAC” — a few deployments reject randomized MACs; (4) as a clean reset, Forget the network and re-add it, or use the official geteduroam / eduroam CAT installer, which fills every field correctly.

Why this happens

eduroam is a roaming federation: when you're on a host campus (even in another country), your login is relayed back to your home institution's server. The outer identity is the address on that envelope. Older Android tolerated a blank or bare outer identity because the phone fell back to the real one; Android 14+ tightened this, so a blank field now produces an unroutable request — and a server that simply never replies. One field, carrying the realm, puts the address back on the envelope.

Found this useful, or hit a variation of it? Let me know.