Huawei mode changing updated

Dan Williams dcbw at redhat.com
Mon Dec 9 09:28:45 PST 2013


On Mon, 2013-12-09 at 12:58 +0100, Aleksander Morgado wrote:
> > 
> > One issue I had was:
> > 
> > [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.

Dan



More information about the ModemManager-devel mailing list