Re: [MM] [PATCH 3/3] ZTE: improperly USSD-query encoding

[Aleksander Morgado <aleksander lanedo com>]

Hey Alexander,

>>> When I send an USSD query, it should be encoded to proper charset (UCS2
>>> in my case). But it is not. Because of this USSD queries do not work at
>>> all on my ZTE MF192 modem:
>>>
>>> (ttyACM0): -->  'AT+CUSD=1,"*100#",15<CR>'
>>> (ttyACM0):<-- '<CR><LF>ERROR<CR><LF>'
>>>
>>> In git logs I have found this commit:
>>> http://cgit.freedesktop.org/ModemManager/ModemManager/commit/plugins/mm-modem-zte.c?id=a57618b091faec24d22bfce5f384248c52cd2511
>>>
>>> It disables hex encoding for USSD requests for all ZTE modems.
>>>
>>> With that patch reversed, USSD works fine for me:
>>>
>>> (ttyACM0): -->  'AT+CUSD=1,"002A0031003000300023",15<CR>'
>>> (ttyACM0):<-- '<CR><LF>+CUSD: 0,"04110430043B0430043D0441003A003600390037002C0039003604400020041E043F043B0430044204300020043A043004400442043E04390020043F043E00200431002F043F002004420435043B04350444043E043D04430020002B00370034003900350037003600360030003100360036",72<CR><LF><CR><LF>OK<CR><LF>'
>>> decode_ussd_response(): USSD data coding scheme 72
>>>
>>> So, I think, ModemManager should match modem model and decide, if it
>>> needs hex encodings. What do you think about this?
>>
>> If the case is that some models don't allow UCS2-hex encoded strings 
>> even if UCS2 is the desired charset; then I would default to trying to 
>> use the specified charset and if it fails, then try with the fallback 
>> MM_MODEM_GSM_USSD_SCHEME_7BIT as in that patch. It would just need one 
>> failure to really decide which logic to use. Otherwise we'll end up 
>> needing to maintain some table of devices showing that behaviour, which 
>> is possibly not a good thing to do.
> 
> Aleksander, thank you for reply! I have done the patch witch uses this
> idea. It should work for all modems, but probably needs testing with
> models that don't understand hex-encodings.
> 

I ported this fix to git master, see:
http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=c6c1e0fb50569b9eafd92ba170a8dba42c4948be

I added an additional fallback, so that when we start with the unencoded
try first and it fails, we'll try the encoded one. Are you able to
update this patch with that additional logic so that we can apply it to
MM_05/MM_06?

Cheers!

-- 
Aleksander