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

On 16/04/12 18:00, Alexander Orlov wrote:
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:

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]