11:37 a.m.
Hello,
I'm using a SIM7600 USB modem (QMI) with Connman and Ofono, however
I've found that I don't get a connection on first boot. I've debugged
this and have some clues as to why...
On first boot (or every boot with a read-only filesystem), I observe
the following:
ofonod[406]: LTE attach IP type: 0
ofonod[406]: src/gprs.c:ofono_gprs_cid_activated() cid 1
ofonod[406]: src/gprs.c:ofono_gprs_cid_activated() cid 1 activated
before atom registered
This occurs because of a bail condition
(!__ofono_atom_get_registered(gprs->atom)) - the git commit for this
("gprs: Ignore activated contexts during init, list them later")
suggests that this was added to avoid duplicate contexts in the case
where a context gets activated before provisioning (perhaps in the
case of LTE). The commit also calls driver->list_active_contexts to
handle this - however list_active_contexts has only been implemented
for the atmodem driver.
Therefore should the qmi driver be updated to implement a
list_active_contexts call that will run get_default_profile_cb and
then share this via ofono_gprs_cid_activated ?
Without this we seem to get a race condition. In the function
drivers/qmimodem/gprs.c:create_wds_cb we rely on the callback related
to QMI_NAS_GET_SS_INFO to eventually call ofono_gprs_cid_activated -
however this must happen before ofono_gprs_register (also in
reate_wds_cb) completes.
My observation is that on first boot, there are no settings in
/var/lib/ofono, thus ofono_sim_add_spn_watch is called to provision
contexts - this takes time and results in the "activated before atom
registered" error. If I kill ofono and start it again - then this time
there are settings, gprs_load_settings no longer returns NULL and so
ofono_gprs_register returns quicker - resulting in everything working.
Is my understanding correct? What is the correct way to address this?
Thanks,
Andrew Muray
1:42 a.m.
Hi Andrew,
On 11/15/21 6:37 PM, Andrew Murray wrote:
Hello,
I'm using a SIM7600 USB modem (QMI) with Connman and Ofono, however
I've found that I don't get a connection on first boot. I've debugged
this and have some clues as to why...
On first boot (or every boot with a read-only filesystem), I observe
the following:
So why would you use a read-only filesystem?
ofonod[406]: LTE attach IP type: 0
ofonod[406]: src/gprs.c:ofono_gprs_cid_activated() cid 1
ofonod[406]: src/gprs.c:ofono_gprs_cid_activated() cid 1 activated
before atom registered
Part of the problem is that the modem is going online too quickly. It would
probably help if the modem was kept in post-sim state long enough to read SPN,
provision contexts, etc.
Not sure if all the drivers were updated to put gprs atom creation into
post_sim. Some might still put it into post_online. So that is another thing
to check.
This occurs because of a bail condition
(!__ofono_atom_get_registered(gprs->atom)) - the git commit for this
("gprs: Ignore activated contexts during init, list them later")
suggests that this was added to avoid duplicate contexts in the case
where a context gets activated before provisioning (perhaps in the
case of LTE). The commit also calls driver->list_active_contexts to
handle this - however list_active_contexts has only been implemented
for the atmodem driver.
Therefore should the qmi driver be updated to implement a
list_active_contexts call that will run get_default_profile_cb and
then share this via ofono_gprs_cid_activated ?
That should certainly help since list_active_contexts was added for this purpose.
Without this we seem to get a race condition. In the function
drivers/qmimodem/gprs.c:create_wds_cb we rely on the callback related
to QMI_NAS_GET_SS_INFO to eventually call ofono_gprs_cid_activated -
however this must happen before ofono_gprs_register (also in
reate_wds_cb) completes.
My observation is that on first boot, there are no settings in
/var/lib/ofono, thus ofono_sim_add_spn_watch is called to provision
contexts - this takes time and results in the "activated before atom
registered" error. If I kill ofono and start it again - then this time
there are settings, gprs_load_settings no longer returns NULL and so
ofono_gprs_register returns quicker - resulting in everything working.
Context settings are stored on disk, so provisioning is no longer needed. Also
most SIM reads are no longer performed since they are now cached in the
filesystem. This should generally result in almost no delay in gprs atom
registration. Hence my question above about the use of a read-only filesystem.
Regards,
-Denis
2:34 a.m.
Hi Denis,
Thanks for the quick response.
On Tue, 16 Nov 2021 at 14:58, Denis Kenzior <denkenz(a)gmail.com> wrote:
Hi Andrew,
On 11/15/21 6:37 PM, Andrew Murray wrote:
> Hello,
>
> I'm using a SIM7600 USB modem (QMI) with Connman and Ofono, however
> I've found that I don't get a connection on first boot. I've debugged
> this and have some clues as to why...
>
> On first boot (or every boot with a read-only filesystem), I observe
> the following:
So why would you use a read-only filesystem?
It's an embedded system, we use a read-only root filesystem to improve
resilience
and security - thus ensuring the root filesystem is identical between
devices. We
bind mount the connman configuration files to a writable partition,
but haven't had
a need to do this for ofono (yet).
In any case, this issue is present on a writable filesystem on first boot.
>
> ofonod[406]: LTE attach IP type: 0
> ofonod[406]: src/gprs.c:ofono_gprs_cid_activated() cid 1
> ofonod[406]: src/gprs.c:ofono_gprs_cid_activated() cid 1 activated
> before atom registered
Part of the problem is that the modem is going online too quickly. It would
probably help if the modem was kept in post-sim state long enough to read SPN,
provision contexts, etc.
Not sure if all the drivers were updated to put gprs atom creation into
post_sim. Some might still put it into post_online. So that is another thing
to check.
We appear to use the gobi plugin, this calls ofono_gprs_create in post_online -
I'll see what happens when I move it to post_sim - thanks for the suggestion.
>
> This occurs because of a bail condition
> (!__ofono_atom_get_registered(gprs->atom)) - the git commit for this
> ("gprs: Ignore activated contexts during init, list them later")
> suggests that this was added to avoid duplicate contexts in the case
> where a context gets activated before provisioning (perhaps in the
> case of LTE). The commit also calls driver->list_active_contexts to
> handle this - however list_active_contexts has only been implemented
> for the atmodem driver.
>
> Therefore should the qmi driver be updated to implement a
> list_active_contexts call that will run get_default_profile_cb and
> then share this via ofono_gprs_cid_activated ?
That should certainly help since list_active_contexts was added for this purpose.
OK
>
> Without this we seem to get a race condition. In the function
> drivers/qmimodem/gprs.c:create_wds_cb we rely on the callback related
> to QMI_NAS_GET_SS_INFO to eventually call ofono_gprs_cid_activated -
> however this must happen before ofono_gprs_register (also in
> reate_wds_cb) completes.
>
> My observation is that on first boot, there are no settings in
> /var/lib/ofono, thus ofono_sim_add_spn_watch is called to provision
> contexts - this takes time and results in the "activated before atom
> registered" error. If I kill ofono and start it again - then this time
> there are settings, gprs_load_settings no longer returns NULL and so
> ofono_gprs_register returns quicker - resulting in everything working.
Context settings are stored on disk, so provisioning is no longer needed. Also
most SIM reads are no longer performed since they are now cached in the
filesystem. This should generally result in almost no delay in gprs atom
registration. Hence my question above about the use of a read-only filesystem.
Indeed.
Thanks,
Andrew Murray
>
> Regards,
> -Denis
306
days inactive
306
days old
2 comments
2 participants
participants (2)
-
Andrew Murray -
Denis Kenzior