Re: NM and Nokia N95

[Dan Williams <dcbw redhat com>]

On Thu, 2009-09-24 at 04:03 +0400, Eugene Crosser wrote:
> Dan Williams wrote:
> 
> >>>> ** (modem-manager:9049): DEBUG: (ttyACM2): --> 'AT+CGDCONT=1, "IP", 
> >>>> "3internet"<CR>'
> >>>> ** (modem-manager:9049): DEBUG: (ttyACM2): <-- '<CR><LF>OK<CR><LF>'
> >>>> ** (modem-manager:9049): DEBUG: (ttyACM2): --> 'ATD*99***1#<CR>'
> >>>> ** (modem-manager:9049): DEBUG: (ttyACM2): <-- 
> >>>> '<CR><LF>CONNECT<CR><LF>~\-1}#\-64!}!} } }2}#}$\-64#}!}$}%\-36}"}&} }*} } 
> >>>> g}%~'
> 
> >> The problem is, when chatting to the modem, modem-manager reads a buffer-full of
> >> data at a time from the serial device. Then, it tries to match the contents of
> >> the buffer against some regexps.
> [...]
> >> fix would be redesign the modem manager to read one byte at a time, and match on
> >> the fly (rather than by regexp-s). This is how the programs that communicate
> >> with modems, like the old good 'chat', or my own 10 year old 'ifmail', have to
> >> be designed.
> > 
> > We could, though honestly that's a bitch given that most every modem
> > does things differently and can emit different strings and formats for
> > most commands.  We'd essentially end up re-writing sequential regexps.
> > So I'd rather do everything in my power to try to get a string out of
> > the card (including polling the fd until a timeout if need be) and use
> > regexps there.  And honestly if the card is that slow that its feeding
> > data to the kernel in such a way that the ldisc can't reasonably batch
> > them up, we have more problems with the card than we can handle.
> 
> Well, I don't completely agree that you really want full regexes here. What you
> indeed need is a "match with multiple choices". I believe that it would cover
> all real life use cases.
> 
> > We could also do matching as you suggest, but targeted for commands like
> > CONNECT where we expect to get immediate binary data.  Not a bad idea.
> 
> That would not be possible without ability to notice alternative strings, like
> "NO CARRIER". If you have multiple choice match implemented, you cover not only
> CONNECT case but also all the rest of them.
> 
> I'll stop criticizing at this point and offer you a deal: an extremely small
> library that that does multiple choice matching of the incoming stream on the
> fly, and also has a convenient enough way to select "variable parts" of the
> response, such as capabilities string from AT+GCAP, or connect speed that may
> follow the 'CONNECT' string. Please take a look and if you like it, you can use
> the code as example, or indeed in any way you wish. Warning: not production
> quality code, just a proof of concept. But it is tested and works with my Nokia
> phone.

We do need to fix up ModemManager's EOL parsing at least to split on new
lines, and get rid of most of the CR/LF stuff in the regexps.  The only
cases where CR/LF isn't the EOL is stuff like connect of course.  Or GSM
MUX-ing.  You bring up some very good points, and I did see one case
with a PCMCIA-based Sierra 850 (oddly enough, an HSDPA card using
PCMCIA) that MM did get a split response from the read().  NM 0.7 did do
the splitting on CRLF which worked out pretty well there, and we need to
do that in MM.

I have looked into gatchat from the ofono project, but that's mainly
interesting not because of it's approach to parsing (which is still
quite procedural a-la NM 0.7.x) but because it implements the hugely
icky GSM MUX-ing protocols that are required to mux multiple serial
streams over one tty.  I don't really want to duplicate that work in MM,
so maybe there's a point of synergy at least.

> I am attaching tar to this message because it is really small and should not be
> a problem to the readers of the mailing list.

Thanks, I'll take a look.  There's definitely areas to be improved all
over the place.  Thanks for your insight.

Dan