On Thu, 2011-09-15 at 13:22 +0200, Aleksander Morgado wrote: > > (ttyHS0): --> 'AT_OPSYS?<CR>' > > Sep 15 10:43:34 ThinClient modem-manager[2081]: <debug> > > [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <-- > > '<CR><LF>ERROR<CR><LF>' > > Sep 15 10:43:34 ThinClient modem-manager[2081]: <debug> > > [mm-serial-parsers.c:412] mm_serial_parser_v1_parse(): Got failure > > code 100: Unknown error > > Sep 15 10:43:34 ThinClient modem-manager[2081]: <debug> > > [mm-at-serial-port.c:298] debug_log(): (ttyHS0): --> 'AT+CSCS=?<CR>' > > Sep 15 10:43:34 ThinClient modem-manager[2081]: <debug> > > [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <-- '<CR><LF>_OPSYS: > > 3,2<CR><LF><CR><LF>OK<CR><LF>' > > Sep 15 10:43:34 ThinClient modem-manager[2081]: <debug> > > [mm-at-serial-port.c:298] debug_log(): (ttyHS0): --> 'AT > > +CMER=3,0,0,1<CR>' > > To me the real issue here seems to be that the reply to "AT_OPSYS?" is > split in a first "ERROR" string and then "_OPSYS: 3,2 OK". The serial > parsers will consider the ERROR part as being a full response, and > therefore ModemManager issues the "AT+CSCS?" command next, and then we > get the second chunk of the OPSYS reply as if it were the reply to the > AT+CSCS... The fix could be to let "ERROR" be considered as a partial > reply by providing a custom regex in the response parsers, similar to > what it was done here: > > http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=262edb96d50138a724173840fc63ca93ede322c2
That's a really weird response though. I can't recall having seen a modem return ERROR *and* a valid response. Perhaps the response there is actually an unsolicited response that's been enabled by the AT_OSSYS=1. It may be that the modem simply isn't quite ready yet when we start poking it? That could also be the reason why AT_OSQI=1 is failing. What Option modem is this again? Dan _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
