Re: ofono Digest, Vol 74, Issue 5
by Tommi Kenakkala
On 12.06.2015 22:00, ofono-request(a)ofono.org wrote:
> Date: Fri, 12 Jun 2015 11:01:42 -0500
> From: Denis Kenzior<denkenz(a)gmail.com>
> To:ofono@ofono.org
> Subject: Re: SimManager properties and hotswap
> Message-ID:<557B0266.8010707(a)gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> >Problem1
>> >If a client, for example triggered by the Present property change
>> >signal, asks GetProperties during the time window then PinRequired &
>> >LockedPins values are not updated yet.
>> >
> Then the client should simply wait for the relevant signal to arrive.
> Either SubscriberIdentity or PinRequired.
Thanks for the comments. What about LockedPins? Do you consider emitting
it inappropriate?
>> >Problem2
>> >A client can't work around Problem1, it doesn't know when after a
>> >hotswap PinRequired becomes available. sim_pin_query_cb checks
>> >"sim->pin_type = pin_type" before emitting PinRequired changed signal.
>> >Works for boot when pin_type is 0 but not for card hotswap because
>> >sim->pin_type is not reset, instead the old value is preserved.
> Sounds like a bug. Are you hot-swapping two PIN-locked SIMs? Can you
> share a log of what's happening?
Sure, please see [1] & [2].
[2]:
Do correct me if there's a mistake, but sequence is as follows and there
problem is
async steps 2. and 3+4. complete independently.
As a result to me it's not clear to which property or signalling clients
should rely on.
1. ofono_sim_inserted_notify > emit "Present" > sim_initialize
2. sim_iccid_read_cb > emit "CardIdentifier"
3. sim_efpl_read_cb > __ofono_sim_recheck_pin
4. sim_pin_query_cb
> "PinRequired" emitted at startup but not on pin-enabled hotswaps
> "LockedPins" never emitted
Whether this produces problems depends on timing.
>> >One fix proposal to Problem2 is to reset pin_type to
>> >OFONO_SIM_PASSWORD_INVALID in ofono_sim_inserted_notify when removed.
>> >That requires skipping appending PinRequired in sim_get_properties()
>> >if value is OFONO_SIM_PASSWORD_INVALID, otherwise
>> >ofono_dbus_dict_append crashes because sim_passwd_name() didn't have a
>> >value for OFONO_SIM_PASSWORD_INVALID.
>> >(I would've put resetting to sim_free_main_state(), but that's called
>> >when changing PIN fails due to wrong passwords and sim app switches
>> >PUK lock (OFONO_SIM_STATE_LOCKED_OUT), it would reset the password
>> >type already set as puk.)
> Setting it to OFONO_SIM_PASSWORD_INVALID is definitely not the right way
> to go. But there might be other ways to take care of the problem. Can
> you share the logs of what is happening first?
See [1] & [2].
Ok, did you have alternatives already on your mind?
OFONO_SIM_PASSWORD_INVALID was used because at startup it's the initial
value before state is properly read from card. It seemed logical to
"back up" into that state when card is removed and when looking at
sim_pin_query_cb .
>> >Problem3
>> >Similar for LockedPins, but there reason is sim_pin_query_cb() doesn't
>> >emit property change all.
>> >Fix proposal to Problem3 is to emit a change signal sim_pin_query_cb()
>> >if "sim->locked_pins[pin_type]" wasn't already TRUE.
>> >
>> >Please let me know your comments and improvement ideas. I can submit
>> >patches if you're interested.
>> >
> Regards,
> -Denis
[1]:
Logs about use-case: remove & insert a pin-required usim card.
- Same results if same or different pin-enabled card is inserted back.
- Driver implementation waits until password state is available and only
then notifies ofono core via ofono_sim_inserted_notify.
There's an additional __ofono_sim_recheck_pin call seen here after
ofono_sim_inserted_notify from driver to core trigger a password query.
Now when I look at it I'm not sure if it's still needed, but
nevertheless even if it's removed monitor-ofono does not show
"LockedPins" or "PinRequired" being emitted
(logs and code analysis confirm that).
- monitor-ofono output:
{SimManager} [/ril_0] Present = False
{VoiceCallManager} [/ril_0] EmergencyNumbers = 08 000 999 110 112 911
118 119
{SimManager} [/ril_0] Present = True
{VoiceCallManager} [/ril_0] EmergencyNumbers = 110 08 112 999 911 000
{SimManager} [/ril_0] CardIdentifier = <...>
{SimManager} [/ril_0] PreferredLanguages = fi sv en
{SimManager} [/ril_0] Present = False
{VoiceCallManager} [/ril_0] EmergencyNumbers = 08 000 999 110 112 911
118 119
{SimManager} [/ril_0] Present = True
{VoiceCallManager} [/ril_0] EmergencyNumbers = 110 08 112 999 911 000
{SimManager} [/ril_0] CardIdentifier = <...>
{SimManager} [/ril_0] PreferredLanguages = fi sv en
- Truncated ofono src/sim.c output, including some custom log prints:
oFono version 1.16
...
src/modem.c:modem_change_state() old state: 0, new state: 1
src/sim.c:ofono_sim_add_state_watch() 0xdae2a0
src/sim.c:ofono_sim_add_state_watch() 0xdae2a0
src/sim.c:ofono_sim_inserted_notify() inserted: 1, sim->state: 0
src/sim.c:sim_initialize()
src/sim.c:__ofono_sim_recheck_pin()
src/sim.c:sim_pin_query_cb() sim->pin_type: 0, pin_type: 1
src/sim.c:sim_pin_query_cb() Here could add emit "LockedPins" changed
src/sim.c:sim_pin_query_cb() Emitting PinRequired property changed
src/sim.c:sim_pin_retries_check()
src/sim.c:sim_pin_retries_query_cb()
src/sim.c:sim_efpl_read_cb()
src/sim.c:__ofono_sim_recheck_pin()
src/sim.c:sim_pin_query_cb() sim->pin_type: 1, pin_type: 1
src/sim.c:sim_pin_query_cb() Methinks pin_type didn't change, not
emitting PinRequired
src/sim.c:sim_pin_retries_check()
src/sim.c:sim_pin_retries_query_cb()
src/sim.c:ofono_sim_add_state_watch() 0xdae2a0
Requested file structure differs from SIM: 6fb7
src/sim.c:ofono_sim_inserted_notify() inserted: 0, sim->state: 1
src/modem.c:modem_change_state() old state: 1, new state: 1
src/sim.c:ofono_sim_inserted_notify() Here one could reset sim->pin_type
src/sim.c:sim_free_early_state()
src/sim.c:sim_free_main_state()
src/sim.c:ofono_sim_inserted_notify() inserted: 1, sim->state: 0
src/sim.c:sim_initialize()
src/sim.c:__ofono_sim_recheck_pin()
src/sim.c:sim_pin_query_cb() sim->pin_type: 1, pin_type: 1
src/sim.c:sim_pin_query_cb() Methinks pin_type didn't change so didn't
emit change
src/sim.c:sim_pin_retries_check()
src/sim.c:sim_pin_retries_query_cb()
Requested file structure differs from SIM: 6fb7
src/sim.c:ofono_sim_inserted_notify() inserted: 1, sim->state: 1
src/sim.c:__ofono_sim_recheck_pin()
src/sim.c:sim_pin_query_cb() sim->pin_type: 1, pin_type: 1
src/sim.c:sim_pin_query_cb() Methinks pin_type didn't change so didn't
emit change
src/sim.c:sim_pin_retries_check()
src/sim.c:sim_pin_retries_query_cb()
src/sim.c:sim_efpl_read_cb()
src/sim.c:__ofono_sim_recheck_pin()
src/sim.c:sim_pin_query_cb() sim->pin_type: 1, pin_type: 1
src/sim.c:sim_pin_query_cb() Methinks pin_type didn't change so didn't
emit change
src/sim.c:sim_pin_retries_check()
src/sim.c:sim_pin_retries_query_cb()
src/sim.c:ofono_sim_inserted_notify() inserted: 0, sim->state: 1
src/modem.c:modem_change_state() old state: 1, new state: 1
src/sim.c:ofono_sim_inserted_notify() Here one could reset sim->pin_type
src/sim.c:sim_free_early_state()
src/sim.c:sim_free_main_state()
src/sim.c:ofono_sim_inserted_notify() inserted: 1, sim->state: 0
src/sim.c:sim_initialize()
src/sim.c:__ofono_sim_recheck_pin()
src/sim.c:sim_pin_query_cb() sim->pin_type: 1, pin_type: 1
src/sim.c:sim_pin_query_cb() Methinks pin_type didn't change so didn't
emit change
src/sim.c:sim_pin_retries_check()
src/sim.c:sim_pin_retries_query_cb()
Requested file structure differs from SIM: 6fb7
src/sim.c:ofono_sim_inserted_notify() inserted: 1, sim->state: 1
src/sim.c:__ofono_sim_recheck_pin()
src/sim.c:sim_pin_query_cb() sim->pin_type: 1, pin_type: 1
src/sim.c:sim_pin_query_cb() Methinks pin_type didn't change so didn't
emit change
src/sim.c:sim_pin_retries_check()
src/sim.c:sim_pin_retries_query_cb()
src/sim.c:sim_efpl_read_cb()
src/sim.c:__ofono_sim_recheck_pin()
src/sim.c:sim_pin_query_cb() sim->pin_type: 1, pin_type: 1
src/sim.c:sim_pin_query_cb() Methinks pin_type didn't change so didn't
emit change
src/sim.c:sim_pin_retries_check()
src/sim.c:sim_pin_retries_query_cb()
Ps. What's the mailing list practise on attachments, in case there's a
need to provide longish logs?
Thanks for the answers,
Br.
--
Tommi
6 years, 11 months
SimManager properties and hotswap
by Tommi Kenakkala
Greetings
There's an issue for which I'd like to hear your opinion.
ofono_sim_inserted_notify signals org.ofono.SimManager Present property true,
but PinRequired and LockedPins are known only after
__ofono_sim_recheck_pin asks them from driver.
Problem can arise at startup but I've met this especially during
hotswap i.e. when I remove and insert the same/different card.
If a driver completes query_passwd_state synchronously there's less
room for problems, but if driver has to find out the values
asynchronously the time window is longer.
I'm using an implementation of rilmodem, but even the default atmodem
driver asks password state asynchronously (AT+CPIN?).
Problem1
If a client, for example triggered by the Present property change
signal, asks GetProperties during the time window then PinRequired &
LockedPins values are not updated yet.
Problem2
A client can't work around Problem1, it doesn't know when after a
hotswap PinRequired becomes available. sim_pin_query_cb checks
"sim->pin_type = pin_type" before emitting PinRequired changed signal.
Works for boot when pin_type is 0 but not for card hotswap because
sim->pin_type is not reset, instead the old value is preserved.
One fix proposal to Problem2 is to reset pin_type to
OFONO_SIM_PASSWORD_INVALID in ofono_sim_inserted_notify when removed.
That requires skipping appending PinRequired in sim_get_properties()
if value is OFONO_SIM_PASSWORD_INVALID, otherwise
ofono_dbus_dict_append crashes because sim_passwd_name() didn't have a
value for OFONO_SIM_PASSWORD_INVALID.
(I would've put resetting to sim_free_main_state(), but that's called
when changing PIN fails due to wrong passwords and sim app switches
PUK lock (OFONO_SIM_STATE_LOCKED_OUT), it would reset the password
type already set as puk.)
Problem3
Similar for LockedPins, but there reason is sim_pin_query_cb() doesn't
emit property change all.
Fix proposal to Problem3 is to emit a change signal sim_pin_query_cb()
if "sim->locked_pins[pin_type]" wasn't already TRUE.
Please let me know your comments and improvement ideas. I can submit
patches if you're interested.
--
Tommi
6 years, 11 months
Problems provisioning APN from SIMs
by Alex J Lennon
Hi,
A request for some advice.
We're having trouble provisioning APNs for SIMs from certain Telcos, and
it seems to be because of the ordering of providers in serviceproviders.xml
Vodafone and O2 are cases in point. SIMs from either of those two
telcos, used in the UK, will fail to default to the standard APNs upon
provisioning.
In the case of Vodafone it is because an ASDA Mobile provider is present
before the Vodafone provider and both have the same MNC.
It's similar with O2, excepting that in this case there's a Giffgaff
provider before the O2 provider which thus is used for the APN.
I suspect our use case is similar to many others. We have a headless
embedded Linux board and we want an installation technician to be able
to put a SIM in, power the unit, and have everything else automated.
It looks like we may have to implement a custom serviceproviders.xml,
which would be a shame.
I am wondering if there are any other algorithmic or configuration
alternatives we can look at, such as Ofono trying different contexts
until one works? Or some additional Ofono provisioning configuration?
Thanks,
Alex
6 years, 11 months
[PATCH v2] Connecting a phone with mpty call does not trigger CLCC polling
by Kuba Pawlak
If there is more then one active or held call, we are in mpty calls.
We won't get indicator update if any of them is released by CHLD=1x.
So we have to poll it.
---
drivers/hfpmodem/voicecall.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/hfpmodem/voicecall.c b/drivers/hfpmodem/voicecall.c
index afeb35f..e3e6e0f 100644
--- a/drivers/hfpmodem/voicecall.c
+++ b/drivers/hfpmodem/voicecall.c
@@ -1134,6 +1134,10 @@ static void hfp_clcc_cb(gboolean ok, GAtResult *result, gpointer user_data)
struct ofono_voicecall *vc = user_data;
struct voicecall_data *vd = ofono_voicecall_get_data(vc);
unsigned int mpty_ids;
+ GSList *n;
+ struct ofono_call *nc;
+ unsigned int num_active = 0;
+ unsigned int num_held = 0;
if (!ok)
return;
@@ -1142,6 +1146,22 @@ static void hfp_clcc_cb(gboolean ok, GAtResult *result, gpointer user_data)
g_slist_foreach(vd->calls, voicecall_notify, vc);
ofono_voicecall_mpty_hint(vc, mpty_ids);
+
+ n = vd->calls;
+
+ while (n) {
+ nc = n->data;
+
+ if (nc->status == CALL_STATUS_ACTIVE)
+ num_active++;
+ else if (nc->status == CALL_STATUS_HELD)
+ num_held++;
+
+ n = n->next;
+ }
+
+ if ((num_active > 1 || num_held > 1) && !vd->clcc_source)
+ vd->clcc_source = g_timeout_add(POLL_CLCC_INTERVAL, poll_clcc, vc);
}
static void hfp_voicecall_initialized(gboolean ok, GAtResult *result,
--
1.7.11.7
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
6 years, 11 months