FP5 (VT31): SIM slot goes completely silent when a removable eUICC is inserted

Help Fairphone 5
1

I have a removable eUICC card (ChillaxSIM) in the SIM slot of my FP5, alongside the internal eSIM. Since some point in August, the SIM slot no longer does anything at all with that card.

The symptom, precisely: it is not “no network” — the modem never even searches.

Phone 0: registrationState = NOT_REG_OR_SEARCHING
         rejectCause = 0        (no rejection, ever)
         mCellInfo = []         (no cell measurements at all)
mSimState[0] = LOADED           (card is read fine)

Note NOT_REG_OR_SEARCHING, not NOT_REG_SEARCHING. The stack is idle, not searching.

What rules out the obvious causes:

  • Same slot, ordinary SIM (an old expired one): searches, attaches, gets rejectCause=2. Slot hardware is fine.
  • Same slot, a different removable eUICC (eSTKme): searches, attaches, gets rejectCause=15.
  • Same card, same profile, in a Fairphone 4 (Android 15, DSDS, internal eSIM also active): full service, voice and data, both slots simultaneously.
  • Also works immediately in a Samsung Galaxy.

Checked and excluded on the FP5: modem enabled for the slot, radio power on, no radio-power-off reasons, automatic network selection, allowed network types identical to the working slot, carrier config equivalent between slots, isMultiSimSupported = 0 (allowed), DSDS configured, mobile data and roaming on. Telephony database cleared twice, mobile network settings reset, both LPA services (com.google.android.euicc, com.qualcomm.qti.lpa) disabled and re-enabled, several reboots.

isEmbedded correlated at first but turned out to be irrelevant — on the FP4 the same card is flagged isEmbedded=1 and works, and the flag flips back and forth on both devices during updateEmbeddedSubscriptions runs.

The one thing I cannot inspect is the modem side. isModemEnabledForSlot(0) returns 0 whenever this card is present and recognised, and 1 with any other card — but it looks like a consequence, not a cause.

Timeline: the card demonstrably worked on VT2Y in early August (the slot was transmitting; I have network rejections from a foreign operator to prove it). The phone is now on VT31, and it has not worked since.

My question: has anyone seen an FP5 stop driving the SIM slot when the inserted card presents itself as a eUICC? And is VT31 a plausible suspect, or should I be looking elsewhere?

Thank You all, best regards.

2

Update: third platform tested — a non-Fairphone, non-Android modem takes the same card without complaint

Since the first post I have tested the same removable eUICC in a third, completely
unrelated modem: a Quectel EM120R-GL (MHI/PCIe, MBIM) in a ThinkPad T14 Gen 2i,
running Linux with ModemManager. Same card, same profile, same IMSI.

Quectel EM120R-GL — recognised as eUICC, and it just works

Physical slot 1:  Card status: present, Slot status: active
                  ICCID: 894936000…, Num apps: 2, Is eUICC: yes

SIM:  imsi 2622310…, operator id 26223, operator name GMX FreePhone

23:05:38  3GPP registration state changed (idle -> registering)
23:05:38  3GPP registration state changed (registering -> home)
23:05:39  state changed (registered -> connecting -> connected)

state: connected   access tech: lte   registration: home
packet service: attached   Bearer: connected, apn=internet
LTE  rssi -77 dBm   rsrp -114 dBm   rsrq -19 dB

So a Qualcomm-based modem from a different vendor, under a different OS, with a
different telephony stack, reads the card’s ISD-R, classifies it as an eUICC, sees
the enabled profile’s applications, and attaches within three seconds.

FP5 with the identical card and profile, re-measured the same evening

Slot 0   NOT_REG_OR_SEARCHING, no operator, no cell, rejectCause=0
Slot 1   sim24 (internal eSIM), IN_SERVICE, LTE, HOME

isModemEnabledForSlot(0) = 1
getRadioPowerState(0)    = 1
isSubscriptionEnabled(1) = 1
updateEmbeddedSubscriptions cardId=0 -> result=OK,
    EuiccProfileInfo(nickname=Lebara, state=0),
    EuiccProfileInfo(nickname=GMX FreePhone, state=1)

Everything is on. The modem branch is enabled, the radio is powered, the subscription
is enabled, the profile is enabled, and the LPA reads both profiles off the card
without error. The slot still never leaves NOT_REG_OR_SEARCHING — it does not even
search, so there is no network answer to reject it.

This is stricter than my original post, where isModemEnabledForSlot(0) was 0 and one
could still argue the branch had simply been switched off. It is 1 now, and nothing
changes.

The discriminator is not the card vendor, it is what the card advertises

The same Quectel reports my other removable card, an eSTK.me, as type: physical
with no EID at all — exactly how the FP5 reports it (cardString = ICCID, not EID).
And that card does search and attach on the FP5, right down to receiving reject
causes. The difference between the two cards reproduces identically on Fairphone
hardware and on a Quectel module, so it is a property of the cards, not an Android
quirk. What differs is only what the FP5 does with it.

Summary of all platforms tested with the same card and profile:

Platform recognised as eUICC slot 0 behaviour
FP4, Android 15 yes full service, 11 h continuous
ThinkPad, Quectel EM120R-GL, Linux yes LTE, home, connected
FP5, VT31 yes completely idle, never searches

Questions to anyone here

  1. Does anyone run a removable eUICC (eSTK.me, 9eSIM, ChillaxSIM or similar) in an
    FP5 on VT31, and does slot 0 work?
  2. Did anything change between VT2Y and VT31 in how the modem probes a card for an
    ISD-R? On VT2Y this same card was listed as an ordinary hardware SIM on my FP5 and
    worked; since VT31 it is carried by EID and the slot is silent.