Some SIMs contain an EFspn with the contents all set to 'filler'
characters, e.g. 0xFF. We mistakenly do not handle these strings
correctly.
Aug 8 11:40:00 mx31tt01 daemon.info ofonod[622]: Aux: >
AT+CRSM=176,28486,0,0,17\r
Aug 8 11:40:00 mx31tt01 daemon.info ofonod[622]: Aux: < \r\n+CRSM:
144,0,FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF\r\n\r\nOK\r\n
Aug 8 11:40:00 mx31tt01 daemon.debug ofonod[622]:
drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90, 00, 17
Aug 8 11:40:00 mx31tt01 daemon.debug ofonod[622]:
src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, tocopy: 17
Aug 8 11:40:00 mx31tt01 daemon.err ofonod[622]: EFspn read
successfully, but couldn't parse
This patch was generated by the following semantic patch
(http://coccinelle.lip6.fr/)
// <smpl>
@fix disable is_null,isnt_null1@
expression *E;
@@
- !E
+ E == NULL
// </smpl>
- Introduce new enum gsm_dialect instead of unsigned char arguments
- Use ISO639 3 letter codes for conversion tables
- Use a single lookup table instead of 4 different ones
Add API for supporting character conversion using national language
variants. Also, add conversion tables for Turkish, Spanish and
Portuguese, and fix the default table. The lookup algorithms were
tweaked to support multiple tables.
Apparently all Cell Broadcasts are always 88 bytes long, with a
6 byte header and 82 byte payload. <cr> character is used as a
terminator and padding for the unused payload