Paul, It won't be today, but if you point me at the code I can test the code against mine some time in the next week.
jerry Paul Alfille wrote: > 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 ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
