Re: Fwd: Cinterion plugin patch
On Fri, 25 Nov 2016 21:16:55 +0100 Reinhard Speyerer <rs...@arcor.de> wrote: > On Fri, Nov 25, 2016 at 10:13:08AM +0100, Aleksander Morgado wrote: > > Hey Reinhard & Matthew, > > > > On Thu, Nov 24, 2016 at 10:34 PM, Reinhard Speyerer <rs...@arcor.de> wrote: > > [...] > > > PLS8-E REVISION 02.011: > > > +CUSD: 1,"Hauptmen~:\0A1 Guthabenkonto\0A2 Guthaben Verf~gbarkeit\0A3 > > > Gutschein einl|sen\0A4 Pack Manager\0A7 Tarifinfo\0A8 Hilfe",15 > > > > Any idea if this has any impact on how ModemManager handles USSD in > > this device? Or is this only an issue to the consumer of the USSD > > responses? > > Hi Aleksander, > > I think ModemManager should replace the \xx escapes for devices which > apply them like PLS8 with firmware 02.x and 03.x with the corresponding > character before passing the +CUSD: string to the consumer of the USSD > response. > > Regards, > Reinhard Sorry to butt in, but if you do that won't any USSD messages that have backslashes embedded be mistaken for the badly encoded ones and fixed up erroneously. -- Andrew Bird <a...@spheresystems.co.uk> ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Fwd: Cinterion plugin patch
On Fri, 25 Nov 2016 10:13:08 +0100 Aleksander Morgado <aleksan...@aleksander.es> wrote: > Hey Reinhard & Matthew, > > One further difference I noticed is that USSD responses for AT+CSCS="GSM" > > contain a non-standard \xx escaping for non-printable characters (unless > > I missed some recent TS 27.007 changes). > > > > PLS8-E REVISION 01.090: > > +CUSD: 1,"Hauptmen~: > > 1 Guthabenkonto > > 2 Guthaben Verf~gbarkeit > > 3 Gutschein einl|sen > > 4 Pack Manager > > 7 Tarifinfo > > 8 Hilfe",15 > > > > PLS8-E REVISION 02.011: > > +CUSD: 1,"Hauptmen~:\0A1 Guthabenkonto\0A2 Guthaben Verf~gbarkeit\0A3 > > Gutschein einl|sen\0A4 Pack Manager\0A7 Tarifinfo\0A8 Hilfe",15 > > Any idea if this has any impact on how ModemManager handles USSD in > this device? Or is this only an issue to the consumer of the USSD > responses? What I think curious is that 0x0a is a valid GSM0338 character and should have been interpreted as linefeed ftp://ftp.unicode.org/Public/MAPPINGS/ETSI/GSM0338.TXT Were both modem sessions captured on the same system, as I'm just wondering if what you are seeing is an artifact of the terminal? -- Andrew Bird <a...@spheresystems.co.uk> ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Unexpected COPS format
On Fri, 17 Mar 2017 14:16:50 - <colin.helliw...@ln-systems.com> wrote: > I'm reviewing the info fetched on my modems, and one of them is giving an > unusual format for "AT+COPS=3,2;+COPS?" : > >+COPS: 0,2,"00320033003400310035",0 > > > > This seems to be some sort of 'wide char' hex representation of "23415" > [which is what I'd expect]. > > The modem's AT spec doesn't say anything about it coming back in the form, > but I just wondered if it was a format anyone had encountered elsewhere? > Hi Colin, That's in UCS2 format. Various AT commands (depending manufacturer) return strings in it. It's usually controlled modally by the 'AT+CSCS=' command, but some modems can ignore that (even if it's set to IRA or GSM) for certain commands and return things in UCS2 format. Things like network name etc which they may expect to contain rich characters etc are prime candidates. -- Andrew Bird <a...@spheresystems.co.uk> ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: SIM ICCID with invalid character 'C'
On Wed, 27 Dec 2017 22:09:25 +0100 Aleksander Morgado <aleksan...@aleksander.es> wrote: > Hey, > > It looks like there are SIMs out there that report an ICCID that is > not read correctly by ModemManager: > > [1514406745.769547] (ttyACM2): --> 'AT+CRSM=176,12258,0,0,10' > [1514406745.797843] (ttyACM2): <-- '+CRSM: > 145,15,"9868200C214365870921"OK >[1514406745.798699] couldn't load SIM identifier: 'ICCID > response contained invalid character 'C'' > > Once processed the ICCID would have been reported as: > 898602C0123456789012 > > i.e.: > 89: telecom > 86: china: > 02: cmcc (operator) > character C > 012345678901: 12 digits with the account number, operator-specific format > 2: check digit, I assume > > At the end, this could be a valid 19-digit ICCID, but normally we > would have seen this with a 'F' character as padding, not a 'C' > character in the middle separating the issuer code and the account > number. > > What should we do with this? should we for example, allow having > 19-digit ICCIDs that may include an additional character anywhere to > form the 20-digit value we read from the SIM? > > > -- > Aleksander > https://aleksander.es > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel > It looks like there are plans(2017) to change the format of ISO/7812 allowing an 8 digit IIN at the expense of the account number. I suspect you'll need to get hold of that spec, though I don't beleive it's available for free. See https://en.wikipedia.org/wiki/ISO/IEC_7812 for an overview. Andrew -- Andrew Bird <a...@spheresystems.co.uk> ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
