Well the Lantronix devices arrived and thanks to Rick Haseman we have got them working and found out all sorts of useful information.
The Lantronix MSS100 is a neat little box 9x6cm that connects a blue ethernet cable to a serial port. Only uses 4 watts so much better than leaving a PC on all the time. You start off talking to it via the serial port and give it an IP address and a password. Then you can log into it with a number of different methods - via telnet from hyperterminal, or via some custom software on the lantronix site, or even just by typing the ip address into a browser. There are about 20 settings to get right, but they all make sense when you read the manual.
Then - open up port 3001 with portforward on the router and anyone can log in.
Then we started at 300 baud and worked up to 38400. Still working fine for logging in and running wordstar etc.
Then we tried xmodem, and it fell over just like it fell over with Leif's program. .COM programs simply would not work. So - time for some detective work. It was going to be one of two things - the baud rate or a byte. We know that the PC can talk to the board directly at 38400 so unlikely to be the baud rate but nevertheless, lots of testing revealed even at 300 baud it falls over at the same place. So - it must be a byte. I found this nifty free program called hexedit
http://www.hexedit.com/ and it ended up being the missing link in solving this mystery. I was so impressed I sent them a $20 donation via paypal.
Hexedit has helped me debug the N8VEM source binary in the past, but this time I wanted to use it to make big (20k) files filled with arbitrary bytes. These files could then be downloaded via xmodem to see if they work. So I made some files with characters I was suspicious about, eg 00, 03 (^C), xon, xoff, escape, break, delete and FF. Well, they all worked except FF.
Next, and this was the bit that really impressed me with hexedit, I wanted to create a binary file with random bytes. And there it was, as one of the options! The reason for this is that while FF is a problem, what if another byte was a problem as well? So I took my binary file, found the first FF, did an xmodem transfer and yes, it failed on the packet I expected it to fail. So, change that byte, resend, see if it is FF, and yes it was. So deleting all the FF bytes means xmodem works.
Next step, send a big text file via xmodem. I've sent a 25k .asm and that works. Then, try an even bigger file. Well, it falls over at packet #255, (32k)and packet #255 is FF. So, we are limited to xmodem with text files and files <32k. I guess one could use UNLOAD to turn a .COM into a hex file.
Why is this so?
Well, searching a telnet help forum I came across this:
'FF' means IAC, which stands for "Interpret As Command". All telnet control sequences start with IAC, consequently, your program should look for IAC, and any time it receives it, a subroutine in your program should take control and handle the escape codes.
So, the problem is not with Leif's program, nor with xmodem, nor with the Lantronix devices. The problem lies with the terminal program (hyperterminal in my case, but probably others too). It seems telnet and xmodem don't like each other! I've just realised too that the reason I can xmodem via the com port from hyperterminal is that this is not using telnet.
Some possible solutions, and advice here would be most gratefully received.
1) is there a raw mode, where FF isn't interpreted?
2) is there some other login protocol besides telnet?
3) is it possible to chop up a program, rebuild it at the other end, and also convert it so there are no FF codes?
4) is there another way - eg use a file transfer protocol that doesn't use FF - I have a feeling Kermit might be the only one that can do this, but one would need the source code to get kermit working on the n8vem.
Anyway, if anyone has any ideas they would be appreciated.
As an aside, there are two n8vem boards online at present. 121.45.125.169 and try either port 23 for one or port 3001 for the other. Only thing is my ISP seems to be changing my IP address every few hours at the moment. Maybe don't xmodem any .com files for the moment - keep it to smaller text files?!
Addit - I added the dyndns service as suggested. When you log into telnet, instead of the IP address above, try n8vem.homedns.org
and use port 23 for one board and 3001 for the other. I think the link should be live by now. If it works, then at least every time I turn my computer on it will update the address.
Addit addit - blimey, they changed my ip address again!! This seems to be every half an hour or so. Well the address this minute, is 121.45.201.131. But I did log in again from n8vem.homedns.org and that seems static.
addit next morning - still a very fickle system. Somehow something disabled my PC's local area network connection (I hope it wasn't dyndns) and then dyndns couldn't find the internet, and then my isp changed the ip address again, and then the link broke. 121.45.197.210 (?for the next half an hour). The 3001 is working, but I wouldn't be relying on this yet for a mission to the moon. Hmm - more testing and the IP address has changed twice in the last 10 minutes. Each time it changes, dyndns takes a few minutes to update, so this isn't a very stable solution. It probably needs a static IP address...
addit 14th April - the boards are offline for the moment due to my telephone line becoming so noisy over the last week that you can't hold a voice conversation. I suspect this explains the dropouts and IP addresses changing. I'm getting the phone company to fix this, but one positive outcome is that it is good to test the system with the IP address changing as this means we have a system with dyndns that can handle repeated changing of the IP address so should easily be able to handle the more normal situation of it changing very infrequently. I'm also working on w3sock.dll and vb.net writing my own telnet program. w3sock.dll can pass through all characters from 0 to 255, which is a big step forward from hyperterminal, teraterm etc. However, w3sock.dll appears to have a bug where it can only read back lines that have a carriage return at the end. Reading back characters one at a time does not seem to work, nor does reading in the buffer. Options now - code Kermit for this board. Find the bug in w3sock.dll so it can read in characters one at a time. Find another .dll for winsock. Find a terminal program that can pass through xFF.
