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

Reply via email to