It's the cvs version, but I'll release it as 2.7p23. Paul Alfille
On Sat, Jul 4, 2009 at 4:25 PM, Jerry Scharf<[email protected]> wrote: > 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 > ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
