[rilmodem] SimManager.CardIdentifier not always available

Bug #1245860 reported by Alfonso Sanchez-Beato
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ofono (Ubuntu)
Fix Released
High
Tony Espy

Bug Description

After booting a Galaxy Nexus with a SIM with PUK required:

# dbus-send --system --type=method_call --print-reply --dest=org.ofono /ril_0 org.ofono.SimManager.GetProperties

shows no "CardIdentifier" property (it should, as this property can be read regardless of the SIM being blocked or not).

Doing:

# stop ofono
# start ofono
# dbus-send --system --type=method_call --print-reply --dest=org.ofono /ril_0 org.ofono.SimManager.GetProperties

shows
...
      dict entry(
         string "CardIdentifier"
         variant string "8944110065066933442"
      )
...

-- Edit --

Output of "system-image-cli -i":

current build number: 100
device name: maguro
channel: devel-proposed
last update: 2013-10-18 10:48:50
version version: 100
version ubuntu: 20131017
version device: 20131015

oFono version: 1.12+bzr6839-0ubuntu1

Related branches

Revision history for this message
Tony Espy (awe) wrote :

Note, you can also just run /usr/share/ofono/scripts/list-modems ( it has prettier output too ) to dump the full state of the modem, including interface properties.

Changed in ofono (Ubuntu):
status: New → Confirmed
summary: - CardIdentifier not present on boot
+ [rilmodem] SimManager.CardIdentifier not always available
Revision history for this message
Tony Espy (awe) wrote :

Also, it'd be good to include the touch image # and/or the ofono package version.

description: updated
Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

The root cause seems to be a problem with the initialization sequence. Some requests to RIL were getting the error RADIO_NOT_AVAILABLE, being the reason that RIL_REQUEST_RADIO_POWER(1) had not been called yet. But, that request was sent when ril_set_online() was called, thing that only happened when the SIM card moved to state OFONO_SIM_STATE_READY (see src/modem.c). For locked up SIMs, that was not happening.

This seems to be a flaw in our logic, as the set_online() function of the modem driver is called when the modem is powered AND the SIM is ready. So I have made a call to ril_send_power() in ril.c:sim_status_cb(), which callback calls ofono_modem_set_powered(). This solves this bug.

However, this raises a couple of things we should review:

1.- Probably we should not send RIL_REQUEST_RADIO_POWER(1) when the SIM moves to OFONO_SIM_STATE_READY, as that has already been done.

2.- Maybe this is an opportunity for removing the SIM status request that we do in ril.c, and replace it with a call to ril_send_power(). The reply data is used only to set ril->have_sim, and maybe we can do that later.

Revision history for this message
Tony Espy (awe) wrote :

Are you testing with telepathy-ofono disabled ( ie. via mc-tool request ofono/ofono/account0 disable )?

So commit 34a994fc80e6b5c23b35c8379a067b0c445b7b80 was a merge of my power-control fix. Originally, the ofono/rilmodem/ril code auto-powered on by itself. This commit was a slight re-working of work done for nemomobile.

Essentially, the modem "Powered" property represents "connected to RILD", and "Online" represents radio power ( eg. used to toggle the radio for flight-mode ). AFAIK, SIM IO should work just fine before powering on the radio.

This work was done to prepare for the implementation of FlightMode ( see: https://wiki.ubuntu.com/FlightMode for details ), however the rfkilld daemon work was never finished.

So, today, telepathy-ofono is actually responsible for toggling the state of the modem's "Online" property. If you disable telepathy-ofono, and restart ofono, it will come up with "Powered" = 1 and "Online" = 0.

When run this scenario with a non-PIN-locked SIM, both CardIdentifier and EmergencyNumbers are populated correctly. If I run ofono in the foreground and use RIL_OFONO_TRACE, I can confirm the fact that RADIO_POWER is not sent, and that properties involved are set OK. That said, I do see a couple of GENERIC_FAILURE errors for SIM IO, but these may be normal errors.

description: updated
Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :
Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

After more testing, it seems that this issue affects maguro Galaxy Nexus, but not mako Nexus 4. In the attached log (comment #5), it can be seen that all SIM_IO requests are replied with a RADIO_NOT_AVAILABLE error, until telepathy-ofono sends a RIL_REQUEST_RADIO_POWER. This behaviour is not observed in N4.

It seems reasonable that you can read the SIM even when radio is not powered, so I would say that this is a buggy RIL implementation in maguro. Fixing this would require to change telepathy to use the "Powered" property for starting the modem instead of the "Online" property, and do some changes in our rilmodem implementation.

Revision history for this message
Tony Espy (awe) wrote :

I'm not sure I'm seeing the same thing you are.

On a maguro, running your refactor-sim branch with a PIN-locked SIM, I do the following:

1. su - phablet
2. mc-tool request ofono/ofono/account0 offline
3. exit
4. stop network-manager
5. restart-ofono
6. list-modems

I'm sometimes seeing CardIdentifier, EmergencyNumbers, and PreferredLanguages set, even though the modem is "offline".

The only failure message I see if an error that says, "Requested file structure differs from SIM: 6fb7. All of the other SIM IO calls look fine to me.

Maybe this is a SIM-specific issue?

Note, also I'm testing a PIN-locked SIM vs. a PUK-locked SIM.

The other theory is that maybe the modem stays powered when ofono is re-started? I've asked Tiago for a way to disable telepathy-ofono across reboots.

Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote : Re: [Bug 1245860] Re: [rilmodem] SimManager.CardIdentifier not always available

Hi Tony,

>
> The other theory is that maybe the modem stays powered when ofono is re-
> started? I've asked Tiago for a way to disable telepathy-ofono across
> reboots.
>

I only see this behaviour on boot. To see what is happening, I add
"-d" in /etc/init/ofono.override, and to avoid telepathy setting the
Online property too early, I renamed
/usr/lib/telepathy/telepathy-ofono to make sure it did not start on
boot (hopefully Tiago will show us a better way of doing this :-).

Also, I think that whether the SIM has the PIN activated or not is not
important: renaming telepathy-ofono made this happen always
(otherwise, it could happen or not depending on timing).

Regards,
Alfonso

Revision history for this message
Tony Espy (awe) wrote :

This bug is related to a race in the modem power-up/start-up logic in the ril plugin.

A fix is in the progress for this race condition, and can be found in the following branch:

https://github.com/tonyespy/ofono/tree/ril-power-fix

Changed in ofono (Ubuntu):
status: Confirmed → In Progress
assignee: nobody → Tony Espy (awe)
importance: Undecided → High
Revision history for this message
Tony Espy (awe) wrote :

Confirmed that this works correctly on maguro with the pending ril power fix.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ofono - 1.12+bzr6853-0ubuntu1

---------------
ofono (1.12+bzr6853-0ubuntu1) trusty; urgency=low

  [ Tony Espy ]
  * unit: fix fail-to-build on powerpc
    The previously released version enabled -Wall,
    which triggered build failures due to unused
    functions on powerpc. This is due to the fact
    that the unit tests only run on LITTLE_ENDIAN
    systems via an ifdef, which leaves unused functions
    and data. This change exends the ifdef to cover
    the unused functions and test data.
 -- Ricardo Salveti de Araujo <email address hidden> Tue, 21 Jan 2014 19:43:10 -0200

Changed in ofono (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.