<div dir="ltr">The patch was suggested by Huawei as their modems always return operator names in ASCII in +COPS response. I'd let Franko to provide more details.<div><br></div><div>I haven't seen a real operator using a name that reassembles a hex string, so it's probably not an issue in real practice. It could be an issue in test lab where a call box may configure the operator name as 1234.</div>
<div><br></div><div>Ben<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 26, 2013 at 9:10 AM, Dan Williams <span dir="ltr"><<a href="mailto:dcbw@redhat.com" target="_blank">dcbw@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, 2013-08-26 at 17:07 +0200, Aleksander Morgado wrote:<br>
> On 26/08/13 16:59, Dan Williams wrote:<br>
> >>> Despite +CSCS? may claim supporting UCS2, Huawei modems always report<br>
> >>> > > the oerator name in ASCII in a +COPS response. This patch addresses that<br>
> >>> > > by always assuming the charset is IRA when parsing the operator name in a<br>
> >>> > > +COPS response.<br>
> > Are we sure *all* Huawei modems do this?<br>
><br>
> Ah good point... Franko?<br>
<br>
</div></div>Basically, anything pre-E220 (ie, earlier than 2006) we don't care much<br>
about.<br>
<br>
But about the patch... mm_charset_take_and_convert_to_utf8 does a few<br>
things for UCS2:<br>
<br>
1) checks if the string is in hex by looking for (len % 4) and xdigit<br>
2) if hex, attempts to convert the hex<br>
3) if not, attempts to convert to UTF8<br>
<br>
What operator was triggering the problem? If there are operators like<br>
"3abc" then yeah, it would get misconverted. Just curious here.<br>
<span class="HOEnZb"><font color="#888888"><br>
Dan<br>
<br>
</font></span></blockquote></div><br></div></div></div></div>