> On 28 December 2017 at 14:19 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. 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. [Another 'selfish' reason is that I'm not keen on a load of spurious errors being caused in the log. Same way as I nag people to fix compilation warnings ;)] 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) 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? But - unless we go a different way on this - I'd particularly be grateful for review of the patch w.r.t. leaks etc on completion.
13-add-csim-for-cinterion.patch
Description: Binary data
_______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
