+CEREG signals denied before being registered

[Aleksander Morgado]

Hey,

> >> I have another question about the Fibocom MA510-GL: When +COPS=0 is
> >> issued, often the modem emits the following sequence of URC which makes
> >> ModemManager abort the simple connect flow:
> >>
> >> +CEREG: 0 (idle)
> >> +CEREG: 2 (searching)
> >> +CEREG: 3 (denied)
> >> +CEREG: 5,... (registered, roaming)
> >>
> >> I guess this might not be in accordance with the specs, but I'm not
> >> sure. It also doesn't always do that but when it does it jumps from
> >> denied to registered within seconds. What would be an acceptable way to
> >> handle this?
> >>
> >
> > That's a good question, I'm not sure what to reply here. The COPS=0
> > request comes from a "Register automatically" user request, or as part
> > of Simple.Connect(). The outcome of that operation is one single
> > result, we don't report back "several results". In this case, the
> > first "final" result we get from the modem is +CEREG: 3, so "denied",
> > and from my point of view, that is the result that we should probably
> > return, as we don't know what else will come afterwards.
> >
> > If a new "Register automatically" happens after that sequence, what
> > does the modem do? i.e. if you run COPS=0 and we get the CEREG
> > idle+searching+denied+registered sequence and just after that you run
> > again COPS=0, does it go over all those 4 states again, or does it
> > return +CEREG: 5 right away?
> >
>
> This is the issue. After the failed automatic registration (denied),
> another +COPS=0 is issued which may again lead to the denied state.
> Eventually, the denied state is skipped and the simple connect state
> machine can move on to actually connecting. Obviously, this is
> non-optimal because we do many registration attempts and the network
> will not like this and the overall connection duration is long.
>
> There is probably no generic way to resolve this because the current
> implementation seems correct. But do you have guidance how to fix this
> with - perhaps with a non-upstreamed patch? Perhaps, we could start a
> timer when getting the denied status update and wait some time for the
> registered state update before returning with a failed state?
>

Yes, that is an option. But how much would you say you want to wait?
5s, 10s, 15s?
Maybe this logic could be upstreamed, but we would need to understand
what happens in other cases, e.g. what do MBIM and QMI modems report
under the same scenario?

-- 
Aleksander