SIM hot swapping race condition

[Yannick Serafini]

I've recently encountered race conditions related to SIM hot-swapping events and wanted to delve deeper into this mechanism.

The race conditions occurred in scenarios where I failed to insert the SIM card correctly on the first attempt.
Here's the problematic sequence:
0. URC for hot swap has been enabled in previous session (Fibocom MC610 modem memorizes this parameter in NVM)
1. Partial SIM insertion triggers "+SIM: Inserted" URC
2. ModemManager begins modem creation process
3. Before completion, a "+SIM: Removed" URC is received (due to unstable insertion)
4. SIM is finally inserted correctly
5. ModemManager completes modem setup with SIM apparently detected

The issue is that the unsolicited message "+SIM: Removed" arrives before the hot-swap handler is registered, causing this URC data to end up in unrelated modem properties (like manufacturer information).
Sometimes, the SIM state incorrectly shows "sim-failure" and I suspect it is related.

To address this, I implemented a default unsolicited message handler in setup_port (same as in the Cinterion implementation) to catch URCs that arrive before the hot-swap handler is registered.

This works initially, but fails when the SIM is activated because of the following sequence:
1. Modem is detected
2. port_setup() is called
3. hot swap setting is configured
4. SIM is unlocked
5. Modem is recreated
6. port_setup() is called again
7. setup_sim_hot_swap() is NOT called because it's inhibited by the sim_hot_swap_configured flag in mm-iface-modem.c

At this point, only the general handler defined in port_setup() remains active, which overrides the specialized handler from the initial hot swap configuration.
This causes SIM events to be ignored.

I don't really understand why cleanup_sim_hot_swap is not supposed to disable the hot swap feature by sending the AT command to disable the URC from the modem and obviously clear the sim_hot_swap_configured flag, ideally with a cleanup_sim_hot_swap_finish.
That would however not handle the case of a crash letting hot swap enabled in the modem so an approach to handle URC from the beginning (or least as soon as possible) would be probably ideal.

I'm interested in your opinion here, I think my issue is mainly related to the fact the hot swap feature is persistent in the modem but more generally, do you see a good approach to fix this issue?

Yannick Serafini