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 _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
