cinterion: modification to fetching unlock retries

[Colin Helliwell]

> On 28 December 2017 at 17:39 Aleksander Morgado wrote:
> 
> 
> >> >> >> > > Hi, I just wondered if there was any appetite for re-visiting this issue. The latest 'GTask' rework to the plugin means I'll need to redo accordingly the patch I've been using - but thought I'd enquire before embarking on that.
> >> >> >> > You're talking about the parallel enables issue, or using AT^SPIC to
> >> >> >> > fetch unlock retries?
> >> >> >> > What patch are you currently using, could you share it somewhere?
> >> >> >>
> >> >> >> Sorry - pasted the wrong URL! See instead:
> >> >> >> https://lists.freedesktop.org/archives/modemmanager-devel/2017-April/004485.html
> >> >> >> I didn't get to a point where I thought my patch would be mainstream-acceptable (it just 'works for me'), but I can post in entirety if necessary. It's essentially as per my original post in the thread.
> >> >> >
> >> >> >
> >> >> > I've modified my patch for a later 'gtask oriented' Master version of MM (66dce6dacc440d8bfe4270562ef5a840c87e5a04 - Dec 5), which I'd like to re-offer for review/comment? (and inclusion?)
> >> >> >
> >> >> >
> >> >> > As I write, it's almost working except two of the queries are sometimes returning "reference data not found" errors:
> >> >> > AT+CSIM=10,"0020000100" -> 63C3
> >> >> > AT+CSIM=10,"002C000100" -> 63CA
> >> >> > AT+CSIM=10,"0020008100" -> 6A88
> >> >> > AT+CSIM=10,"002C008100" -> 6A88
> >> >> >
> >> >> > It seems to be some sort of timing issue (on the Cinterion EHS5) - sometimes I get all four responses successfully, sometimes one/other/both of the last two fail.
> >> >> > I'll try to seek out any telling differences in the logs, but any thoughts as to what sequence/timing might cause this in the modem....? (varying registration time? SIM not fully initialized?)
> >> >>
> >> >> Forgot to attach the patch? :)
> >> >>
> >> >
> >> > Ah well, yes - was waiting to see if there was any interest :)
> >> > Attached here.
> >>
> >> Looks good!
> >> > To try to build in some method of flexibility, I've added a second 'map' of commands, using CSIM.
> >> > There's a couple of #define's to allow for changing whether SPIC or CSIM is tried first.
> >> > If the *first* step of the first map fails, then it switches over and tries the second instead.
> >> >
> >> > I realise my approach may not be to everyone's/anyone's liking. It would be simpler to just add the CSIM commands to the existing map and let it roll through them all, hopefully assembling all values correctly, but I didn't want to prejudge (e.g. if the response to one method contradicts the response to the other!) and possibly open up other problems. However that *would* allow for modems which only support a *mix* of methods, if there are any.
> >>
> >> I think we should keep both maps separate, and only try CSIM if SPIC
> >> fails. Actually, see below.
> >> > What are people's thoughts? I'd like to have a fix of some sort in the mainstream code (since I need it, and have been caught out once by my private patch becoming outdated over time by other changes)
> >>
> >> Yes, let's provide a common solution for this.
> >> > In any case, the helper function is needed for parsing the CSIM responses - I think this is still the same as in the telit plugin. Could it be a generic function?
> >>
> >> Yes, definitely, and we should actually have a generic method based on
> >> CSIM to load unlock retries. I believe this is what we should be
> >> doing:
> >>
> >> 1) Write a generic load_unlock_retries() method in MMBroadbandModem,
> >> based on CSIM only (i.e. just the CSIM map with the 4 commands and
> >> iterate over them to build the resulting MMUnlockRetries). The parser
> >> helper would also be generic, i.e. in mm-modem-helpers.[c|h]. All
> >> AT-based modems would try this method to load unlock retries.
> >> 2) Make the Cinterion implementation run its SPIC based logic, and if
> >> you detect errors with that logic, the plugin falls back to run the
> >> "parent" object implementation (see e.g. load_supported_modes() in the
> >> same Cinterion plugin on how to call the parent method). This would
> >> make the Cinterion plugin use SPIC if supported and otherwise run the
> >> parent CSIM-based logic implemented in step 1.
> >> 3) The Telit implementation is a bit more complex than the generic
> >> one. In Telit we support CSIM locking/unlocking operations, before
> >> running the CSIM sequence of commands, we run CSIM=1 to lock and once
> >> finished, we run CSIM=0 to unlock. The sequence itself is the same as
> >> with the generic implementation, though. So, we could also reuse the
> >> generic one, but in this case, we do the CSIM locking (if supported)
> >> then we run the parent implementation, then we run CSIM unlocking.
> >>
> >> Doing this we would end up with one single CSIM based implementation
> >> in the generic modem, and the cinterion and telit plugins would use
> >> that same implementation as needed.
> >>
> >> What do you think? Does this make sense?
> >>
> >
> > Sounds fine to me. I hadn't realised that only Cinterion plugin uses ^SPIC - are these/equivalent not fetched at all for modems other than Cinterion/Telit? (or with a different cmd?)
> 
> My assumption is that SPIC is Cinterion-only, while CSIM is the
> generic SIM access method that should be supported by modems following
> the 3GPP standards (see 3GPP TS 27.007). The CSIM locking feature from
> Telit is, if I'm not mistaken, a Telit-specific thing, but the actual
> CSIM commands to query are the generic ones.
> 
> Are you up to drafting patches for this? :)
> 

Hmmm, bit nervous tbh! I only have an embedded platform to work on, which makes building n trying out a bit laborious. I'm also totally clueless on anything beginning with a 'g'! ;)
I'm certainly not keen on tackling (3), not being at all familiar with Telit nor having one.
I'll have a look into (1) and (2) if you like - and if you can give me some pointers, especially on hooking stuff into "all AT-based modems"?
Come the end of the holidays though I'm going to be very pressed for time.
:S