[ofono][rild] "Retries" property does not not work

Bug #1206941 reported by Michael Zanetti
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ofono (Ubuntu)
Fix Released
High
Alfonso Sanchez-Beato

Bug Description

For the SIM Pin dialog we need to display the remaining attempts for unlocking.

The appropriate property for that is "Retries" of the SimManager. Use this command to display it:

qdbus --system --literal org.ofono /ril_0 org.ofono.SimManager.GetProperties

Even though PinRequired is set to "pin", which means the SIM card is waiting for the PIN, the "Retries" property is always empty while it should be a Map with contents something along the lines:

{ "pin" : 3, "puk": 16 }

Changed in touch-preview-images:
status: New → Confirmed
Changed in ofono (Ubuntu):
status: New → Confirmed
Changed in touch-preview-images:
importance: Undecided → High
Changed in ofono (Ubuntu):
importance: Undecided → High
Changed in touch-preview-images:
assignee: nobody → Tony Espy (awe)
Changed in ofono (Ubuntu):
assignee: nobody → Tony Espy (awe)
summary: - "Retries" property does not not work
+ [ofono][rild] "Retries" property does not not work
Revision history for this message
Tony Espy (awe) wrote :

So is this is a pretty obvious, function-didn't get implemented type of bug.

The rilmodem's sim modules doesn't define a function for ofono_sim_driver.(*query_pin_retries).

On the RIL side, there's no RIL message that can be used to query the various PIN retry counts. Instead, the RIL PIN requests all return the current retry value for the specified PIN. Unfortunately, the ofono DBus API doesn't return a PIN retries count when EnterPin is called.

This is definitely a case of RIL/ofono API mismatch...

So, the only possible way I can see to fix is:

1. When a SIM PIN required condition is detected, rilmodem's internal 'pin_retries' is set to 3.
2. If rilmodem's (*send_passwd) function is called, the returned retry value is used to update the internal 'pin_retries' count.
3. If a (*change_passwd) operation succeeds, reset 'pin_retries' to 3

The same technique could be applied to "puk" as well.

I'd appreciate a quick comment as to whether or not this missing feature impacts the current UI design? Can the UI be implemented by just examining the PIN/PUK related properties?

Revision history for this message
Michael Zanetti (mzanetti) wrote :

The UI in the design shows a label with the text:

"x attempts remaining"

To show that I would need to get the value somehow. I couldn't find anything else in the ofono API that would give me this values.

Note that rebooting the phone does not reset the remaining attempts in the SIM card. So your proposed fix has an issue if a new SIM card with an already wasted attempt is inserted. This is especially bad if there is only 1 attempt left where we would tell the user that there are all 3 attempts left.

Isn't there any non-destructive call that returns the remaining attempts?

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

Yea, forgot about the power down case ( which is rare, but could happen ).

I re-reviewed the RIL API, and there really is no other way to get the counts.

So, I guess the best we could do is only initialize 'Retries' after the first attempt to enter a PIN via EnterPin was invoked, and also the same for ChangePin with respect to PUK retries?

Revision history for this message
Michał Sawicz (saviq) wrote :

The only thing I can think of about improving this situation would be to cache/store the number of remaining tries (per-SIM), but obviously that's unreliable if the SIM is taken out and used in another phone...

I'm not sure on the internals of RIL, but I assume if we'd like to fix it, we'd need to do that in android code? And what's worse, in hw-specific blobs as well?

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

Unfortunately, rild is a binary blob. We're also constrained by the generic RIL API which doesn't offer any messages which allow us to query the PIN/PUK retry counts independent of an action.

In theory, this is something that could be fixed for a specific OEM by means of a custom RIL request/reply, however a generic solution isn't really possible.

My suggestion would be to tweak the UI to display the remaining retries after each attempt as I see no way to offer a guarantee that the retry number is correct before an initial unlock attempt is performed.

Tony Espy (awe)
Changed in touch-preview-images:
status: Confirmed → In Progress
status: In Progress → Confirmed
Revision history for this message
Michael Zanetti (mzanetti) wrote :

In this case that's probably the best we can do, yes.

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

I have tested the SIM/PUK behaviour in Galaxy Nexus with Android 4.3, and it never displays the retry counter of either the PIN or the PUK, not even when you have entered any of those wrongly at least once. Interestingly, an old Huwaei phone I have with Android 2.2 prints always the retry counter.

Revision history for this message
Michael Zanetti (mzanetti) wrote :

Tony, any update on this?

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

We recently discovered that the number of retries returned when entering the PIN/PUK is unreliable in the current RIL implementation of Google devices (Galaxy Nexus and Nexus 4 return always 0 and 1 respectively in ENTER_SIM_PIN/PUK).

So, for these devices we will never be able to display the number of available retries. Adaptation of the rilmodem code will be needed when working with OEMs.

Tony Espy (awe)
Changed in touch-preview-images:
assignee: Tony Espy (awe) → nobody
Changed in ofono (Ubuntu):
assignee: Tony Espy (awe) → nobody
Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

Pull request

https://github.com/rilmodem/ofono/pull/79

fixes this partially. The number of available retries for a password will be shown in the Retries property of org.ofono.SimManager when the password has been incorrectly entered, but there is no guarantee that the property will hold any value before entering the password for the first time since ofono started.

Anyway, the UI should check the property in all cases, as possibly some future phones will expose the available retries from the beginning.

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

Note: the previous fix works just for mako, not for maguro.

Tony Espy (awe)
Changed in ofono (Ubuntu):
status: Confirmed → In Progress
Tony Espy (awe)
Changed in ofono (Ubuntu):
assignee: nobody → Alfonso Sanchez-Beato (alfonsosanchezbeato)
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (4.1 KiB)

This bug was fixed in the package ofono - 1.12.bzr6858+14.10.20140501-0ubuntu1

---------------
ofono (1.12.bzr6858+14.10.20140501-0ubuntu1) utopic; urgency=low

  [ Tony Espy ]
  * [ Tony Espy ] build, gril, rilmodem, plugins/ril, test: call-
    forwarding support. [ Alfonso Sanchez-Beato ] build, gril,
    plugins/rildev: dynamic plugin loading for ril-type modems.   The
    new rildev plugin reads an environment variable to determine
    which   device plugin   to load ( defaults to the standard ril
    plugin ). build, gril, plugins/ril, rilmodem, unit: radio-settings
    support.   Allow radio technology ( ie. use 2G-only ) preference to
    be configured. [ Tony Espy ] test: update remaining test scripts to
    Python 3. build, src, plugins, src/gprs: add MMS support.   Added
    new android-provision plugin and associated -apndb code   to
    provision GPRS and MMS contexts using apns-conf.xml as the primary
      provisioning database, while mobile-broadband-provider-info is
    still   queried in order to pickup additional Apns. Also added
    support for   combined Internet/MMS contexts by allowing MMS
    specific properties   to be set for OFONO_GPRS_CONTEXT_TYPE_INTERNET
    contexts. [ Alfonso Sanchez-Beato ] rilmodem/ussd: Fix USSD Initiate
    hang (LP: #1299227 ). gril, rilmodem, unit: add SIM write support.
      This allows ofono's core call-forwarding and message-waiting logic
      to update persistent state on the SIM, in order to preserve it
    across   reboots. build, gril, include, plugins, src,
    drivers/mtkmodem, drivers/rilmodem: add MTK support.   This change
    adds support for MTK-ril modems without breaking compatibility
      with AOSP-ril modems. examples, include, plugins, src: support for
    gid type MVNOs in Android APN database. gril, rilmodem: fix for call
    redirections (LP: #1239869).   This fix checks and ignores a
    Qualcomm specific error   code that indicates a call has been re-
    directed by an   operator while roaming. build, gril, rilmodem,
    unit: add call-barring support. gril, mtkmodem, rilmodem, unit: MTK
    followup changes.   This change adds unit tests for MTK specific
    messages.   It also consolidates parsing logic for parsing data
      call lists, which is a valid payload for multiple message   types.
    Finally, the deactivate data call logic on start-   up has been re-
    worked to query the active calls before   attempting to deactivate
    any. src/smsutil: use UTF-16 instead of UCS-2 (LP: #1269017).   If
    an incoming SMS is indicated to be UCS-2, use UTF-16   instead to
    decode so that emoji's ( which use larger   codepoints than can be
    encoded in UCS-2 ) are properly   decoded. [ Jussi Pakkanen ]
    phonesim: add a DBus control interface.   This control interface has
    been added in order to make   phonesime more flexible for auto-pilot
    testing of   Touch's network-indicator code. [ Alfonso Sanchez-Beato
    ] android-apndb.c/-provision.c: fix string comparisions.   Change
    all usage of g_str_equal() to g_strcmp0(). This   fixes a crash that
    may happen if the SIM doesn't contain   a SPN file. gril: switch
    process to radio user.   Te...

Read more...

Changed in ofono (Ubuntu):
status: In Progress → Fix Released
Bill Filler (bfiller)
no longer affects: touch-preview-images
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.