Hi Denis,
Den tors 8 aug. 2019 kl 00:08 skrev Denis Kenzior <denk...@gmail.com>:
> Hi Richard,
>
> On 8/7/19 4:44 PM, Richard Röjfors wrote:
> > Hi,
> >
> > Just want to hear your thoughts of how to fix an issue I saw.
> >
> > The modem was told to activate with COPS=0, that took time.
> > And a context was activated ME PDN ACT, almost immediately when
> > registered (LTE).
>
> Interesting. How'd you get here? From what I understand you somehow
> got from post_sim to post_online in record time such that the sim atom
> hasn't finished initializing?
>
I think what happened was that the network.c called register_auto very
early.
Then a lot of commands were queued up, waiting for it to finish, it took
long time several seconds.
Then very quickly the modem registered the LTE context automatically.
Unfortunately I can not dig up the complete log right now, this is what I
had saved in my scratch buffer.
21:01:42 daemon.info ofonod[547]: Aux: > AT+CPMS=?\r
21:01:42 daemon.info ofonod[547]: Aux: < \r\n+CPMS:
("BM","ME","MT","SM","SR"),("ME","MT","SM"),("ME","MT","SM")\r\n
21:01:42 daemon.info ofonod[547]: Aux: < \r\nOK\r\n
21:01:42 daemon.info ofonod[547]: Aux: > AT+CRSM=178,28480,1,4,34\r
21:01:42 daemon.info ofonod[547]: Aux: < \r\n+CRSM:
144,0,"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"\r\n
21:01:42 daemon.info ofonod[547]: Aux: < \r\nOK\r\n
21:01:42 daemon.debug ofonod[547]:
../git/drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90, 00, 34
21:01:42 daemon.info ofonod[547]: Aux: > AT+COPS=0\r
21:01:46 daemon.debug ofonod[547]: ../git/src/modem.c:get_modem_property()
modem 0x1b717b8 property SystemPath
21:01:51 daemon.debug ofonod[547]: ../git/src/modem.c:get_modem_property()
modem 0x1b717b8 property SystemPath
21:01:52 daemon.info ofonod[547]: Aux: < \r\nOK\r\n
21:01:52 daemon.info ofonod[547]: Aux: > AT+CMGF=0\r
21:01:52 daemon.info ofonod[547]: Aux: < \r\n+CIEV: 2,2\r\n
21:01:52 daemon.info ofonod[547]: Aux: < \r\n+CGEV: ME PDN ACT 4\r\n
21:01:52 daemon.info ofonod[547]: Aux: < \r\n+CGEV: NW CLASS "B"\r\n
21:01:52 daemon.info ofonod[547]: Aux: < \r\n+CREG:
5,"0080","00000006",7\r\n
So I think the interesting part is the ME PDN ACT here. and you see before
the cops=0 sim is still reading stuff...
> Really, a connection manager should not Online the modem until the
> SubscriberIdentity has been pushed out via signal...
>
> >
> > So gprs got notified that the CID was activated. But at that stage SIM
> > had not finished, it was queued after the COPS=0 and there is a long
> > sequence... So gprs had not read its provision contexts.
> > So a new context was created.....
>
> Yes, so in theory gprs atom doesn't even appear on D-Bus until the SPN
> is read from the SIM and the contexts are bootstrapped. So in theory
> you can merge these somewhere during ofono_gprs_finish_register and the
> application won't know any difference
>
Ahh didn't think of that, that makes things easier...
>
> >
> > Later on provision contexts were read and a second context was added for
> > the same APN...
> >
> > Ideas of how to fix this:
> > 1. Delay creation of context until the GPRS atom is registered, but that
> > is racy in case the context gets activated (we have no check for
> > deactivation without a created context).
>
> This could work if we added a list_contexts method or something...
>
That would work, but be a bigger change.
>
> > 2. Merge provision context into the created context when provisioning
> > happens and send proprtychanged.
>
> You might not even need the PropertyChanged at all...
>
Good point. I vote for option 2, I think its less intrusive. agree its an
OK way forward?
BR
Richard
_______________________________________________
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono
