Huawei plugin sometimes fails to load operator code

[Fangxiaozhi (Franko)]

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