SIM PIN Unlock doesn't always trigger an actual unlock action

[Tony Espy]

current build number: 127
device name: krillin
channel: ubuntu-touch/devel-proposed

Two SIMs installed, SIM in the second slot is PIN-locked.

It's possible for a PIN to be entered on the SIM auto-prompt screen ( displayed at boot ) and the subsequent action ( ie. the DBus EnterPin call to ofono ) to get dropped. This results in the SIM still being locked when the user dismisses the greeter.

This bug was discovered while testing an ofono vivid silo. The associated ofono merge request is:

https://code.launchpad.net/~phablet-team/ofono/ww10-update/+merge/250665

The version of ofono in the silo (ubuntu-013) is:

1.12.bzr6888+15.04.20150224-0ubuntu1

There's some kind of race condition involved, as this seldom happens ( ~5% of the time ).

I was finally able to prove that this was unity8 ( or some other upper layer component ) by adding info log messages to the ofono functions that handle the DBus EnterPin method, and the associated callback function. The scenario that clinched it for me was:

1. Boot phone

2. Enter bad PIN and tap check button when prompted for SIM2
[ See that remaining Retries is reported as 2 ]

3. Enter PIN again and tap check button again

4. Examine syslog and notice that there's only a single call to EnterPIN, which is followed by a log message showing the callback failure for the bad PIN entered.

[Michael Terry (mterry)]

I doubt this is unity8's issue. Unity8 only does the following:
- Initiate the original call to com.ubuntu.connectivity1.Private.UnlockAllModems, which seems to be working fine.
- Render the notification dialogs when requested by indicator-network

So I'm inclined to leave investigation to indicator-network team

[Tony Espy (awe)]

Thanks for the comment Mike. All I know is that a DBus call wasn't made to ofono, so it's somewhere in the stack above. I'll make sure to bring this up with the indicator team at this week's network/telephony meeting.

[Tony Espy (awe)]

@Mike

So to be clear, the indicator sends a signal to unity8 which causes it to render the Enter PIN page? When the user clicks the checkmark, what happens, does unity8 make a subsequent DBus request? If so, to what destination and method?

[Michael Terry (mterry)]

@Tony, the indicator makes a libnotify request (which goes over dbus) with a bunch of special x-canonical hints that tells the notification daemon (unity8) to render the notification as a PIN entry. unity8 does so and then responds to the indicator (over dbus).

It is certainly possible that unity8 is not replying to the indicator. Or that the indicator isn't responding back to ofono.

[Michael Terry (mterry)]

(As to the specific destination and methods for libnotify, I'm not entirely sure off the top of my head.)

[Michael Terry (mterry)]

Despite unity8 also being a possible culprit, I was guessing it might be the indicator because the bug description indicated that it mattered which sim slot was locked. unity8 doesn't even get that information. So I figured it was below unity8. But if it looks like the indicator is doing its job fine, I'll give a look at the notification code in unity8.

[Michał Sawicz (saviq)]

> So to be clear, the indicator sends a signal to unity8 which causes it
> to render the Enter PIN page? When the user clicks the checkmark, what
> happens, does unity8 make a subsequent DBus request? If so, to what
> destination and method?

It tells the originator of the PIN request (indicator-network) over
UnityMenuModel that the button was pressed, they can then read the value
and act on it.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Antti Kaijanmäki (kaijanmaki)]

needs more investigation.