Seems to me the simplest solution would be to disable telnet mode on the Linkhub-E. Not having one to work with, and with the various models, firmware versions, and documentation versions out there it makes it a little hard so say for sure. But in the doc that I have been able to view there is a "Common Options" configuration section in the "Connection Settings" of the web GUI. If you change the "Telnet Mode" to "Disable" it should remove the need to do any of this silly IAC processing. On other units you could simply connect to a different TCP port to get a raw sockets connection, but apparently not on this little guy.
Jerry is correct with regard to the other sequences that may be encountered. However you may also see the longer sequences (Will/Wont/ Do/Dont) at the beginning when the connection first comes up. Likes he says, you shouldn't see any later unless you somehow start option negotiation again. Can anyone test to see if this option can be disabled on the Linkhub- E's Xport and if it solves the problem? Paul On Jul 3, 2009, at 10:32 PM, Paul Alfille wrote: > Thank you, this is helpful. > > You solution is the most general. It does require two reads for every > transaction, since there seems to be escape codes somewhere in each > sequence, but it's more robust your way. > > Paul Alfille > > On Fri, Jul 3, 2009 at 6:40 PM, Jerry > Scharf<[email protected]> wrote: >> Paul, >> >> I was being a bit dense with my last email. >> >> You should request the number of bytes you expect. When you scan it, >> start looking for FF FA codes. If that shows up, see if the F0 is >> in the >> read buffer. If so, move the char pointer back to where the FF >> point was >> and ask for the rest of the string (expected - FF...F0 bytes.) If >> the F0 >> isn't in the read buffer, start reading byte by byte into a separate >> variable looking for F0. Once you find that, then do the move the >> pointer and read the rest piece as above. Finally, don't forget to >> scan >> the rest of the strings for more FF FA blocks. It's most sloppy >> when the >> FF is the last character of the initial read buffer... >> >> You can also scan and remove the patterns FF F1 - FF F9 as these >> are 2 >> byte commands that the transmitter can send at any time. It is also >> possible that you could see FF FB xx - FF FE xx 3 byte codes, but >> this >> would be in response to FF FA codes that you would send, so that >> seems >> unlikely. Handling these would be just the same as the FF FA codes >> above. >> >> It really is a blast from the past for me. There was a time when I >> could >> decode telnet streams and FTP command streams on a RT passive >> monitor at >> close to typing speed. Life has gotten so much more complex than >> these >> early protocols. >> >> jerry ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
