Post by atolle on Apr 3, 2006 1:44:59 GMT -5
In order to figure out why Xmodem file transfers were failing when connecting to my BBS via Hyperterminal (on Windows XP), I resorted to breaking out Network Monitor and examining the TCP packets. I discovered that Hyperterminal was attempting to negotiate the Telnet Binary Transmission option, documented in RFC856 (http://www.faqs.org/rfcs/rfc856.html).
I know Jim Brain is busy, so I figured I would take a look at the tcpser1.0rc10 code to see what kind of telnet support it had in it. I was pleased to find there was a nice core for telnet command support, although the Binary Transmission option was not implemented. Also, the mechanism for detecting telnet support depended on the remote terminal sending some telnet option requests as soon as the connection was established. Unfortunately, Hyperterminal doesn't do this.
It turns out tcpser has two modes: telnet and binary. In telnet mode, tcpser will look for the telnet IAC character (255) and interpret it as the beginning of the telnet command. Normally, this means there would be problems transmitting binary data, but implementing RFC856 would get around this. In binary mode, tcpser doesn't try to interpret any commands and always sends/receives binary data. This is useful for a client such as CGTerm, which doesn't implement telnet commands. However, binary mode is not friendly to true telnet terminal programs like Hyperterminal.
I was able to modify tcpser in a couple ways: 1) if CTRL-Z is the first character received from the remote terminal, tcpser will enable telnet mode and report such to the remote user. 2) When running in telnet mode, tcpser now supports binary transmission a la RFC856.
My original idea was to have tcpser send a telnet command upon the initial connection, in order to force a response which would kick in tcpser's telnet mode. However, this turned out to cause problems if the remote terminal was connected via tcpser4j (java tcpser). Tcpser4j responds to telnet commands, but it doesn't request binary transmission, thus breaking things when attempting to send binary data such as in a file transfer. I'm not sure if it even supports RFC856 since I haven't looked at the code yet. Even if it does, I would still need to come up with some way to detect a tcpser4j client and request bi-directional binary transmission. Luckily, tcpser4j is like tcpser in that it falls back to binary mode if it doesn't detect telnet commands.
Therefore, I decided to make it a manual option for users. Hyperterminal users can press CTRL-Z as soon as they connect, and tcpser will enable telnet mode. CGTerm users shouldn't do this because, as I mentioned before, CGTerm expects the line to be operating in binary mode all the time.
I've tested it with Hyperterminal and it works great. Xmodem uploads and downloads both work.
What I'm hoping is that some of you might have other Telnet based terminal programs that you can use to help test it further. If you have a validated account on Sonic Temple BBS, then you should be able to access some of the Upload/Download areas.
Here's how to enable telnet mode when connecting: When you first establish a connection to sonictemple.dyndns.org, you will see a "CONNECTING..." message. As soon as you see this, press CTRL-Z. The CTRL-Z character must be the first character you send. You should get a response of "TELNET MODE ENABLED". If you do not see this, then some other characters were received before the CTRL-Z. It is possible you could see "TELNET MODE ENABLED" even if you didn't type anything... this means your terminal sent a telnet command and tcpser detected it.
After this, you should get the standard "press del/backspace" from the BBS. Try downloading a file using the Xmodem protocol. Hopefully, your telnet client will request binary transmission in both directions prior to the file transfer.
Notes:
To compile the modified tcpser code in a Windows environment, I found out the best thing I could do was download and install Cygwin and its associated development packages. I had never used Cygwin before (and I don't touch Linux systems often), but it is a delight to use. They did a nice job of integrating a Linux-like environment into the Windows API.
I know Jim Brain is busy, so I figured I would take a look at the tcpser1.0rc10 code to see what kind of telnet support it had in it. I was pleased to find there was a nice core for telnet command support, although the Binary Transmission option was not implemented. Also, the mechanism for detecting telnet support depended on the remote terminal sending some telnet option requests as soon as the connection was established. Unfortunately, Hyperterminal doesn't do this.
It turns out tcpser has two modes: telnet and binary. In telnet mode, tcpser will look for the telnet IAC character (255) and interpret it as the beginning of the telnet command. Normally, this means there would be problems transmitting binary data, but implementing RFC856 would get around this. In binary mode, tcpser doesn't try to interpret any commands and always sends/receives binary data. This is useful for a client such as CGTerm, which doesn't implement telnet commands. However, binary mode is not friendly to true telnet terminal programs like Hyperterminal.
I was able to modify tcpser in a couple ways: 1) if CTRL-Z is the first character received from the remote terminal, tcpser will enable telnet mode and report such to the remote user. 2) When running in telnet mode, tcpser now supports binary transmission a la RFC856.
My original idea was to have tcpser send a telnet command upon the initial connection, in order to force a response which would kick in tcpser's telnet mode. However, this turned out to cause problems if the remote terminal was connected via tcpser4j (java tcpser). Tcpser4j responds to telnet commands, but it doesn't request binary transmission, thus breaking things when attempting to send binary data such as in a file transfer. I'm not sure if it even supports RFC856 since I haven't looked at the code yet. Even if it does, I would still need to come up with some way to detect a tcpser4j client and request bi-directional binary transmission. Luckily, tcpser4j is like tcpser in that it falls back to binary mode if it doesn't detect telnet commands.
Therefore, I decided to make it a manual option for users. Hyperterminal users can press CTRL-Z as soon as they connect, and tcpser will enable telnet mode. CGTerm users shouldn't do this because, as I mentioned before, CGTerm expects the line to be operating in binary mode all the time.
I've tested it with Hyperterminal and it works great. Xmodem uploads and downloads both work.
What I'm hoping is that some of you might have other Telnet based terminal programs that you can use to help test it further. If you have a validated account on Sonic Temple BBS, then you should be able to access some of the Upload/Download areas.
Here's how to enable telnet mode when connecting: When you first establish a connection to sonictemple.dyndns.org, you will see a "CONNECTING..." message. As soon as you see this, press CTRL-Z. The CTRL-Z character must be the first character you send. You should get a response of "TELNET MODE ENABLED". If you do not see this, then some other characters were received before the CTRL-Z. It is possible you could see "TELNET MODE ENABLED" even if you didn't type anything... this means your terminal sent a telnet command and tcpser detected it.
After this, you should get the standard "press del/backspace" from the BBS. Try downloading a file using the Xmodem protocol. Hopefully, your telnet client will request binary transmission in both directions prior to the file transfer.
Notes:
To compile the modified tcpser code in a Windows environment, I found out the best thing I could do was download and install Cygwin and its associated development packages. I had never used Cygwin before (and I don't touch Linux systems often), but it is a delight to use. They did a nice job of integrating a Linux-like environment into the Windows API.