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