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. 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. Regards, Eugene
Attachment:
ecchat.tar.bz2
Description: BZip2 compressed data
Attachment:
signature.asc
Description: OpenPGP digital signature