Huawei plugin sometimes fails to load operator code

[Ben Chan]

Hi Franko,

That doesn't address the issue when
mm_iface_modem_3gpp_reload_current_operator tries to load the operator
code via +COPS.

Does MU736 support disabling certain unsolicited results? I tried, but
it doesn't seem to support
AT^CURC=2,<sleep_UR_mask>,<working_UR_mask>. Another option is that we
can use AT+CFUN=1 / =4 instead of AT^RFSWITCH=1 / =0 for MU736. How do
you think?

Thanks,
Ben

On Sat, Aug 17, 2013 at 3:06 AM, Fangxiaozhi (Franko)
<fangxiaozhi at huawei.com> wrote:
> Dear Aleksander and Ben:
>
>         Sorry, this is a issue on MU736 that the AT response will mix an unexpected unsolicited message sometimes.
>         Is it possible to implement a new "scan_networks_finish" function for Huawei modem in mm-broadband-modem-huawei.c?
>         In the new modem_3gpp_scan_networks_finish, we can filter out the unexpected unsolicited message in the response before we call mm_3gpp_parse_cops_test_response.
>
>         And by the way, on Huawei modules, the response of +COPS is based on ASCII coding, but not UCS2 coding.
>         So we also have to implement the new " load_operator_code_finish " and " load_operator_name_finish " function for Huawei modem in mm-broadband-modem-huawei.c
>
>         What do you think?
>
> Best Regards,
> Franko Fang
>
>>-----Original Message-----
>>From: Aleksander Morgado [mailto:aleksander at lanedo.com]
>>Sent: Friday, August 16, 2013 4:10 PM
>>To: Ben Chan
>>Cc: modemmanager-devel at lists.freedesktop.org; Dan Williams; Fangxiaozhi
>>(Franko)
>>Subject: Re: Huawei plugin sometimes fails to load operator code
>>
>>On 08/16/2013 09:00 AM, Ben Chan wrote:
>>> I noticed that the Huawei plugin sometimes fails to load the operator
>>> code. The issue is that the plugin doesn't register any handler for
>>> the ^RFSWITCH unsolicited message. When an unhandled ^RFSWITCH
>>> unsolicited message gets mixed with a +COPS response containing the
>>> operator code, e.g. <CR><LF>^RFSWITCH: 1,1<CR><LF><CR><LF>+COPS:
>>> 0,2,"310410",2<CR><LF>, the mm_3gpp_parse_cops_test_response() fails
>>> to extract the operator code.
>>>
>>> It's kinda tricky to register a handler to ignore ^RFSWITCH
>>> unsolicited messages as the solicited and unsolicited messages only
>>> differ by an extra "OK".
>>>     solicited: <CR><LF>^RFSWITCH: 1,1<CR><LF><CR><LF>OK<CR><LF>
>>>     unsolicited: <CR><LF>^RFSWITCH: 1,1<CR><LF>
>>>
>>> As AT^CURC=2 is not supported on the MU736, I can't specify an
>>> unsolicited indication mask to filter out ^RFSWITCH.
>>> mm_3gpp_parse_cops_test_response() could be changed to handle this
>>> situation better, but something else may fail.  I wonder if there is a
>>> better way to resolve this issue.
>>>
>>> AT command is such a messy business :-/
>>
>>Tricky indeed, yes. The only thing I can think of is to do the following:
>>
>> * Configure unsolicited result handler for ^RFSWITCH when the modem is
>>enabled and remove it when it is disabled.
>>
>> * When ^RFSWITCH? is executed in load_power_state(), store the
>>GAsyncResult in self->priv; and use a NULL user_data. In
>>huawei_rfswitch_check_ready() we would load the GAsyncResult from
>>self->priv, if any. Given that ^RFSWITCH? may be called before the modem
>>is fully enabled, we may actually be receiving the result in
>>mm_base_modem_at_command_finish() instead of via unsolicited messages;
>>we do need to consider both cases.
>>
>> * When a ^RFSWITCH? message is received (either a real unsolicited one or
>>one due to a ^RFSWITCH? query), if there is a stored GAsyncResult for a
>>load_power_state() operation in self->priv, set the result in it, complete it and
>>unref it; and finally clear the stored GAsyncResult pointer, so that
>>huawei_rfswitch_check_ready() can afterwards detect that it was already
>>finished.
>>
>> * In the unlikely case that load_power_state() is run and there is already a
>>GAsyncResult stored; just finish the previous GAsyncResult with a CANCELLED
>>error. Don't think this will ever happen anyway, just in case.
>>
>>What do you think?
>>
>>--
>>Aleksander
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel