Huawei plugin sometimes fails to load operator code

[Ben Chan]

If the unsolicited message handler callback is set to NULL, the
message is still consumed and then discarded, which prevents a
solicited ^RFSWITCH? from getting a response.

How about this:
- Add an enable flag to MMAtUnsolicitedMsgHandler, which is set to
TRUE by mm_at_serial_port_enable_unsolicited_msg_handler (for both new
or overwriting case)
- Add mm_at_serial_port_enable_unsolicited_msg_handler(self, regex,
enable) to enable/disable a unsolicited message handler.
- Disable the unsolicited ^RFSWITCH handler right before calling
^RFSWITCH?, re-enable it upon receiving a response for ^RFSWITCH? or
timeout.

Thanks,
Ben

On Mon, Aug 19, 2013 at 12:42 AM, Aleksander Morgado
<aleksander at lanedo.com> wrote:
> On 19/08/13 08:50, Ben Chan wrote:
>> 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?
>
> Wait, if the problem is with ^RFSWITCH unsolicited messages being cached
> before the actual ^RFSWITCH? result; why not just disable the ^RFSWITCH
> unsolicited message handler (within MM; by setting it to NULL) whenever
> we want to run ^RFSWITCH? and re-enable it again (with the proper
> callback) once we got the response?
>
> --
> Aleksander