You are all exactly on the mark! I got feedback from Bill Farmer (head of iButtonLink):
------------------------------------------------- If I had to guess, I bet you still don't have a proper telnet client in OWFS (you probably are just opening a socket to port 10001). The FF FA 2C 6A 60 FF F0 characters is the telnet protocol in the XPORT trying to do Will/Wont negotiation with the Telnet Client (you) and OWFS is not responding appropriately. Lantronix changed their Telnet server in the latest release of the Xport firmware. This is the reason the "extra" characters are different than the last time. The negotiation still matches the RFC so if you had been a proper client, you would never have seen the change at the user level. You still have the same options as the last time we talked about this. 1. If you are going to use Telnet protocol (the default condition), you must adhear to the Telnet RFC. (At a minimum, the Will/Won't negotiations must be detected and stripped from the data stream before passing to the user). 2. Reconfigure the Xport to use socket communications (turn Telnet OFF) so that the Will/Won't queries are not seen by your user code. -------------------------------------------------- I'm still loathe to make people change their Linkhub-E configuration, so I've coded to Jerry Scharf's protocol interpretation. It seems to work with the new client. Does anyone dare test on a non-upgraded Linkhub-E? Using a "proper telnet client" sounds like added dependencies and libraries, unless anyone has a good suggestion of code? Paul Alfille On Sat, Jul 4, 2009 at 10:24 AM, Ziggy<[email protected]> wrote: > 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 > ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
