Downloading problems with WiModem 232 and a UDS-10
#11
(07-28-2021, 01:05 PM)admin Wrote: Does your "collision" LED ever light up while attempting file transfers?

Never watched it before but I'll experiment with it later on tonight and
report back here.

Thanks.
Reply
#12
(07-28-2021, 01:37 PM)admin Wrote: OK, I am able to upload the TESTFILE at 9600 baud.  That same file won't upload at 57600 baud.  This tells me that there is a timing issue with the UDS-10.  Maybe this is why most people use the UDS-1100 instead?

I was not able to download a binary file with Zmodem at 9600 baud though, so if you can put that TESTFILE that I uploaded in one of your download directories I would like to try to download it at 9600 to see if that works with various protocols.  Zmodem is super touchy, so I was surprised to see the upload work.  I uploaded it also with YModem-1K and that worked fine.  The Xmodem and Ymodem protocols don't have tiny timing windows... they still have windows, but typically it's not an issue for WiFi<>router connections.  In your case you have a Serial<>Ethernet<>router connection.  I did see that the UDS-10 is not fully asynchronous (why it has the collision LED).  Its certainly possible that the timing at higher baud rates is too fast and collisions are occurring.

Okay. I put the TESTFILE in File Sig 3.

19200 baud is as fast as the Atari Mega ST4 can achieve stock.

Thanks.
Reply
#13
Okay, I just downloaded TESTFILE from File Sig 3, on a Windows 10 box, using SyncTerm and Telnet, at 19200 baud.

No problems.


Here's some screenshots:


Attached Files Thumbnail(s)
       
Reply
#14
Oh, I did not notice any collision lights during this download.

Thanks.
Reply
#15
I have several ST and STE machines here. I will try downloading the testfile at 9600 baud and also at 57600. Like I said, that upload wouldn't work at 57600 baud, but it worked fine at 9600 baud.
Reply
#16
OK, so I had no problem downloading the testfile. I got zero errors with a Zmodem transfer. For the fun of it, I also tried with Telnet off (RAW mode) and that also worked - which I fully expected. So, the problem here is the Telnet translation that is being done on your end. I am guessing that it has something to do with the UDS-10 unit itself. Does that actually have a Telnet/Raw setting? It could be that the UDS-10 is sending some sort of Telnet command that is suppose to occur between packets, or maybe even something like changing the escape character from FF to something else? There are literally hundreds of Telnet commands.

One thing I will say is that at 9600 baud I typically see transfers in the upper 800's of characters per second (cps) between two 9600 baud systems. Your system's max transfer speed at 9600 baud is right at 700 cps. That is really slow (by 20%+), so I am wondering what is causing that. I called back at 57600 (which should max your system's 19200 baud out) and I got a successful transfer at 1350 cps.. that's a big drop from the normal 1850's you should be seeing with 19200 baud.

So, at this point I guess I need to know WHAT is actually enabling a Telnet protocol. A ISP or router doesn't, only the device responsible for data transfers, so I guessing it is the UDS-10?
Reply
#17
I looked at the documentation for Telnet and there is in fact a command to set the ESC character(s) called "TNESC". So, that could be causing this issue if the escape character (or 2 byte character pair) is being changed from the standard default of ~ (0xFF). I probably should record whatever Telnet command(s) your BBS send and see what those are. Technically, when a device sends a Telnet request and gets a DON'T/WON'T response it is not suppose to assume anything about the client. Telnet sends a special character (0xFF by default) to tell the connected device that this is a Telnet command coming through. If the 2nd byte sent is also 0xFF then the byte is suppose to be interpreted as just a single 0xFF coming through and it's not really a Telnet command sequence about to occur. The TESTFILE I put together and uploaded/downloaded successfully on your BBS only contains a SPACE character (0x20) or a CR character (0x0D), so there would never be an escape character sent. There are a couple of different "standard" escape characters that are used, but I need to determine what your BBS is sending on startup - maybe it's not and the UDS10 just decides to use its own special escape character. We could figure that out by creating a series of files full of various characters and by process of elimination figure out what escape character is being used. If I knew that I could create a function to set the Telnet escape character as a new modem command. I spent a great deal of time on this Telnet vs. Raw thing, and I would highly recommend the program that I used where I could change between Telnet and Raw connections on the fly, and that is a program called "ZOC8 Terminal". You can Google that to find the download link. This is literally the holy grail for this type of testing because it has every file transfer protocol known to mankind, and you can add an external one if you wanted to create a custom protocol.

I also looked at the manual for the UDS10 and you should have the 'pack control' set to 00 and the 'Telnet terminal type' set to disabled.
Reply
#18
(07-28-2021, 11:49 PM)admin Wrote: OK, so I had no problem downloading the testfile.  I got zero errors with a Zmodem transfer.  For the fun of it, I also tried with Telnet off (RAW mode) and that also worked - which I fully expected.  So, the problem here is the Telnet translation that is being done on your end.  I am guessing that it has something to do with the UDS-10 unit itself.  Does that actually have a Telnet/Raw setting?  It could be that the UDS-10 is sending some sort of Telnet command that is suppose to occur between packets, or maybe even something like changing the escape character from FF to something else?  There are literally hundreds of Telnet commands.

One thing I will say is that at 9600 baud I typically see transfers in the upper 800's of characters per second (cps) between two 9600 baud systems.  Your system's max transfer speed at 9600 baud is right at 700 cps.  That is really slow (by 20%+), so I am wondering what is causing that.    I called back at 57600 (which should max your system's 19200 baud out) and I got a successful transfer at 1350 cps.. that's a big drop from the normal 1850's you should be seeing with 19200 baud.

So, at this point I guess I need to know WHAT is actually enabling a Telnet protocol.  A ISP or router doesn't, only the device responsible for data transfers, so I guessing it is the UDS-10?


Hmm, well, I don't know. What machine did you have you WiModem 232 hooked up to? I have mine hooked up to a Atari Mega STe, running at 16mhz.

Using that setup, while it successfully connects to everything I've called, it simply will not download from DarkForce without CRC erroring out. I've also been
told by a few of my callers using WiModem 232's that they are unable to download as well.

Not sure about the slow speed. Did you notice the CPS download speed on the picture I posted?

Thanks.
Reply
#19
(07-29-2021, 12:40 AM)admin Wrote: I looked at the documentation for Telnet and there is in fact a command to set the ESC character(s) called "TNESC".  So, that could be causing this issue if the escape character (or 2 byte character pair) is being changed from the standard default of ~ (0xFF).  I probably should record whatever Telnet command(s) your BBS send and see what those are.  Technically, when a device sends a Telnet request and gets a DON'T/WON'T response it is not suppose to assume anything about the client.  Telnet sends a special character (0xFF by default) to tell the connected device that this is a Telnet command coming through.  If the 2nd byte sent is also 0xFF then the byte is suppose to be interpreted as just a single 0xFF coming through and it's not really a Telnet command sequence about to occur.  The TESTFILE I put together and uploaded/downloaded successfully on your BBS only contains a SPACE character (0x20) or a CR character (0x0D), so there would never be an escape character sent.  There are a couple of different "standard" escape characters that are used, but I need to determine what your BBS is sending on startup - maybe it's not and the UDS10 just decides to use its own special escape character.  We could figure that out by creating a series of files full of various characters and by process of elimination figure out what escape character is being used.  If I knew that I could create a function to set the Telnet escape character as a new modem command.  I spent a great deal of time on this Telnet vs. Raw thing, and I would highly recommend the program that I used where I could change between Telnet and Raw connections on the fly, and that is a program called "ZOC8 Terminal".  You can Google that to find the download link.  This is literally the holy grail for this type of testing because it has every file transfer protocol known to mankind, and you can add an external one if you wanted to create a custom protocol.

I also looked at the manual for the UDS10 and you should have the 'pack control' set to 00 and the 'Telnet terminal type' set to disabled.

I'm not sure what "pack control" and telnet terminal type are on the UDS-10. I did logon in to the UDS-10 remotely and take a screenshot
of the current settings. Here they are:


Attached Files Thumbnail(s)
   
Reply
#20
I use a stock 14MHz Amiga 1200 for testing everything.  It will run up to at 115200 baud.  Like I said, I have zero issues uploading or download the TESTFILE on your website - at any baud rate.  I was just pointing out that your system is very slow for file transfers.  Keep in mind that you are in located in Kentucky and I am in Arizona.  If you didn't have max throughput on your system locally then that would be a serious problem!  Your setup is not leaving your router, it just loops back.  File transfers to/from you from outside locations have to go through an ISP and various station hops.  All of that adds latency, making file transfers problematic.  Remember that a standard modem had about a maximum of 25ms of latency from New York to Australia.  You are extremely lucky to get a ping time under 25ms across a single state with the Internet.  The latency is what causes problems with several different file transfer protocols, Zmodem in particular.

There are many settings for the UDS10.  Do you have the manual?  It talks about how to change the settings for the pack control and terminal type.  Attached in the manual.

I am going to see if ZOC8 Terminal has a capture mode.  I think it does, so I should be able to connect to your BBS and capture any Telnet specific commands that are sent (if any).   Your BBS might be sending a Telnet code to enable binary transfers just before the file transfer occurs, or maybe there is a Telnet break occurring.  I don't know?   The only thing i know for sure is that there are absolutely no problems uploading or downloading files to your BBS as long as they do not contain "some" character(s), which is likely the special Telnet escape character (IAC). So basically text files work perfectly, but binary files do not.


Attached Files
.pdf   UDS10-UDS100_UG.pdf (Size: 705.92 KB / Downloads: 3)
Reply




Users browsing this thread: 1 Guest(s)