Re: NM and Nokia N95

[Dan Williams <dcbw redhat com>]

On Wed, 2009-09-23 at 10:53 +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}%~'
> > 
> > We might have actually fixed a few bugs in this area, what specific date
> > are these checkouts of NM and MM from?
> 
> Dan, I don't think that you have, as of yesterday's git HEAD.
> 
> As I understand, there is a pretty serious problem with the program design here.
> 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. In reality, the modem is technically a tty,
> i.e. a byte-oriented device. It is the kernel's line discipline that clumps
> consecutive bytes that arrived from the tty together and pass them to the caller
> in bulk (i.e. read() returns more than 1 byte). Apparently, it works most of the
> time because the line discipline probably gives up with buffering when the tty
> does not emit new bytes for more than a few milliseconds. Thus, you usually get
> the complete response from the modem in one read buffer, and nothing else but
> the response.
> 
> Still, it is quite "legal" for the kernel to give you the data arriving from the
> modem in arbitrary number of buffers of arbitrary size! You may get e.g. the
> response string cut in several pieces at unknown points, and the regexp will
> never match what it tries to match.
> 
> In this particular case, PPP frames start arriving from the modem instantly
> after CONNECT string, and are passed in the same read buffer as the CONNECT
> string. Which arises two problems: (1) the regex for CONNECT does not match
> because it wants '$' (end of string) after the final CRLF, but there are PPP
> frames there instead, and (2) the chat program consumes data that is intended
> for pppd.
> 
> Because of the PPP protocol redundancy, it is possible to ignore the second
> problem. So, just removing the final '$' from the CONNECT regexp makes the thing
> work. But, this is just a dirty workaround for a fundamental problem. The proper
> 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.

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.

But this is definitely a good point and something for me and others to
keep in mind, thanks!

Dan