Huawei mode changing updated

[Aleksander Morgado]

On 09/12/13 18:28, Dan Williams wrote:
>>> > > [mm-at-serial-port.c:436] debug_log(): (ttyUSB2): --> 'AT^PREFMODE?<CR>'
>>> > > [mm-at-serial-port.c:436] debug_log(): (ttyUSB2): <-- '<CR><LF>^MODE:
>>> > > 0<CR><CR><LF><CR><CR><LF>^RSSILVL:0<CR><CR><LF><CR><CR><LF>^HRSSILVL:0<CR><LF>'
>>> > > [mm-at-serial-port.c:436] debug_log(): (ttyUSB2): <--
>>> > > '<CR><LF>^PREFMODE: 2<CR><LF><CR><LF>OK<CR><LF>'
>>> > > [mm-iface-modem.c:2416] after_set_load_current_modes_ready(): couldn't
>>> > > load current allowed/preferred modes: 'Unexpected PREFMODE response:
>>> > > '^RSSILVL:0
>>> > > 
>>> > > ^PREFMODE: 2''
>>> > > 
>>> > > for the EC168C, likely because the RSSILVL regex doesn't get enabled
>>> > > until the modem gets enabled, but you can still change allowed/preferred
>>> > > modes before that.  This isn't a blocker though, and can be fixed later.
>> > 
>> > That shouldn't happen, as all expected unsolicited messages are fully
>> > disabled (as in, we detect them and ignore them) during setup_ports(),
>> > which happens right before running the initialization sequence.
>> > 
>> > What I believe is happening is that the ^RSSILVL message comes with an
>> > extra <CR> that the regex that we have in place doesn't expect; i.e. we
>> > need "\\r+" instead of just "\\r". Could you confirm that?
> You are completely correct.  I did that patch, tested it with the
> EC168C, and pushed it to git master.  It does not conflict with any of
> the changes in aleksander/huawei-modes.

Great :) Just rebased and merged the branch now.

-- 
Aleksander