Undocumented OTAP PWD issue?

[Frank Muenchow]

Hello,

I recently started developing a TC65i Java application (using Firmware/SDK V01.100) . Everything is basically well, now I stumbled upon an issue with OTAP SMS passwords and wonder if others already found it and if there's possibly a fix for it.

I set a SMS password including an underline like "update_me" and get an

[OTAP] ERROR: PWD Keywords do not match

 error in the OTAP syslog.

OTAP works well with empty password or passwords like "updateme". It can be verified that the password line is correctly received in the OTAP SMS, as expectable due to 8-bit charset used and  because the underline character (0x5f) is also used in a keyword. So apparently either the received or the internally stored password string is somehow reformatted before doing the comparison. I don't see any related comments in the TC65i Release Notes.

The specific problem is that have already installed a device in the field with this kind of OTAP PWD setting. It would be helpful if the SMS PWD string can be recoded to match the compare. Otherwise, it's just another undocumented issue. I wonder if it's kept with newer firmware releases?

As a side remark, it seems to me that the "Ignore SM PID" parameter isn't working at all, means class 0/PID 0 SMS are always ignored with either "on" or "off" sertting. But no actual problem.

Best regards,
Frank

[Frank Muenchow]

Hello,

 

I found the solution by inspecting the Syslog of an AT command triggered update.

 

It shows a re-coded password

 

[OTAP] Parameters set per AT command:
....

[OTAP] SM Pwd: update§me

 

The character "_" (0x5f) is replaced by "§" (0xa7). Using the same character in the OTAP SMS works.

 

Thanks for your interest

Frank

 

 

 .

[Ahmed Adnane]

Thanks for your contribution

--
javacint group - http://www.javacint.com/
---
You received this message because you are subscribed to the Google Groups "Cinterion Java enabled chips support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javacint+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

ADNANE Ahmed

[Frank Muenchow]

Hello,

 

in the meantime my distributor got a response from Cinterion support.

 

please ask customer to replace _ by \11 in  AT^SJOTAP command . Customer is writing that _ is (0x5f) but this is true only for ASCII - in case of GSM ( which is used by module it  should be (0x11).

 

This works in fact, but doesn't help if the AT^SJOTAP parameter isn't accessible. The answer gives however the key to understand the issue. If you look at the default 7-Bit GSM alphabet (as attached), you see that the internally stored password string is apparently interpreted as 7-Bit GSM when compared with the SMS PWD data. This is somehow strange because the OTAP SMS must be send 8-Bit coded (according to Java user manual and my own test).

 

I would still rate the behaviour as a firmware bug.

 

Best regards,

Frank

  

[em]

Dear Frank,

It is not a bug. Apparently +CSCS is set to GSM. That's why all AT related commands are interpreted as GSM characters.

You would see similar issues if your otap server URL contained _ eg.  Www.domain.com/xxx_yyy/otap

Regards
Jacek

--

[Frank Muenchow]

Hello Jacek,

 

I agree, that the explanation makes sense. But things seems to be a bit different though. Curiously the behaviour doesn't depend on +CSCS setting, it's the same with "UCS2". It looks like that password (and probably other string parameters) entered through ^SJOTAP are always encoded from GSM to 8-Bit (and vice versa when displaying it with ^SJOTAP?), whatever you set with +CSCS. I didn't yet check if similar encoding problems occur with URL strings, but it sounds at least likely. 

 

In so far it looks like a kind of special handling rather than imposed by the default TE to ME charset translation. It should be also noted that at another place where the default GSM alphabet involves problems, for the internet service commands, a dedicated charset selection is offered by ^SICS "alphabet".

 

It would be interesting if the same behaviour can be found with recent Java enabled modems that inherited the ^SJOTAP command. 

 

Thank you for answering,

Frank