Jump to content
IGNORED

Wifi modem! Telnet from any computer with a serial port


Vorticon

Recommended Posts

Thank you, Jim, I appreciate your looking into this. I must confess that I am no Telnet guru myself.

 

Shift838 and I spent some time earlier this year testing various configurations and settings with the Lantronix UDS-10 device, wifi232 device, and tcpser (serial to IP emulation). One of us might still have our testing logs - I'll take a look for them this weekend.

 

The Lantronix UDS device connected to Heatwave is set with Telnet enabled, which could mean the UDS device is trying to negotiate with the WiModem232 behind the scenes and/or enables the escaping based on its response or lack thereof. I could temporarly turn off the UDS Telnet mode setting if you'd like to try testing that sometime. I also wonder what would happen if you turn on the telnet escaping on your end?

 

For reference, the BBS sends and receives data to/from the RS232 without any byte manipulation or escaping. So if there is some escaping, it is being managed by the UDS. This is where Shift838 and I got a bit twisted up in our testing as we tried to find a solution that would work with all devices. I'll circle back to this thread in the morning after I catch some shut-eye.

 

Edit: I did a quick test by connecting to Heatwave with Hyperterminal. With the UDS set to negotiate the Telnet terminal type, file transfers work properly. If I turn the negotiation off, transfers fail with short packets. In the gameroom is a Telnet test program that shows every other successive 0xFF byte is being gobbled by either Hyperterminal or the UDS, when the UDS telnet negotiation is turned off. (This configuration caused some trouble for people in the past so for now I have re-enabled telnet negotiation).

Edited by InsaneMultitasker
  • Like 1
Link to comment
Share on other sites

Standard Telnet requires that 0xFF is used as a the escape sequence start byte. Two consecutive 0xFF bytes are treated as a normal 0xFF. I tried with both the escaping on and off and got the same results. I have not seen a single BBS (so far) that actually does Telnet escaping, so it's definitely not required. Only portals (like tty.sdf.org:23) that are Telnet specific require the Telnet translation with the WiModem. The first thing that these portals do is send a Telnet command to obtain the supported Telnet features. I return only a couple of features. Before I did that, none of these portals would actually proceed to the login point.

 

I will get Hyperterminal and see if I can transfer files correctly myself. If so, then I can dumb the serial stream via a sniffer to look at the data and try to figure out what's going on. The hardware works, so this is just a firmware issue that I should be able to resolve.

Link to comment
Share on other sites

Well, I went to your Game Door and tried the TELNET test. With the translation mode set to ON, the TELNET test passes perfectly with all lines being correct, including 255. If I turn off the translation, then all lines are correct *except* 255 (which I would expect). So, it seems that my Telnet translation is correct. Maybe there is some other issue, like with the packet size or speed. I will try using a really low baud rate to see if that changes anything.

Link to comment
Share on other sites

It feels like there should be a simple fix here but it has certainly been elusive. I created a new download area called "Telnet Test" for any upload/download testing. I'll generate a file containing records with all ASCII codes 0-255 and place it in that area in case it is needed for any future sniffing/testing.

Link to comment
Share on other sites

I had a few minutes to poke around with Ethereal. With the UDS Telnet mode option set, here is what I am seeing in the first few packets:

 

From UDS to Hyperterminal (and DOS telnet): (port 9640->PC)
fffb01 will echo
fffb03 will suppress go ahead

 

In response from Hyperterminal to UDS (and dos telnet) (PC->9640)
fffd01 Do Echo
fffd03 Do suppress go ahead

 

I did not see any other telnet commands in the data stream.

 

When I turned off the UDS Telnet mode option:

(1) I see no telnet commands in the data stream

(2) the DOS telnet client echoed locally; I was able to send a fffb01 sequence (from the BBS) to turn this off

(3) the escape sequence results matched your post #78, in that for every two 0xFF sent by the BBS, only one was displayed.

 

Edit: what I found regarding the suppress go ahead

https://tools.ietf.org/html/rfc858

 

Netrunner terminal also uses the Suppress Go Ahead option.

 

Qodem goes a bit further, using the Echo, Suppress Go Ahead, and transmit binary options. 8-bit is assumed by the other terminals.

Edited by InsaneMultitasker
Link to comment
Share on other sites

Correct. Every client I've looked at sends a command to the host (UDS) upon connection, to suppress the Go Ahead command.

 

Also, when Hyperterminal receives a file from the BBS, Hyperterminal sends a telnet command "DO transmit binary" and the UDS responds with "WILL transmit binary". The same handshake is done from UDS to hyperterminal immediately thereafter. Not sure if or how this plays into the equation. My only 'fear' is heading down the proverbial rabbit hole with these Telnet commands. ;) I'll poke around a bit more later tonight or tomorrow morning.

Link to comment
Share on other sites

Suppressing the GA makes sense, but it still seems that Telnet escaping is still being done.

 

I need to get Hypertem.. it's not included with Windows 10. I could look at the data stream and see what's going on that way.

 

I can see why no BBS's for the Apple, Mac, Amiga, and PC use Telnet escaping!

Link to comment
Share on other sites

Yeah, I believe that this has something to do with the UDS-10. It is definitely doing Telnet escaping - otherwise the Telnet test program you have would always fail. From reading through some history it seems that this has been a problem for other WiFi type devices and your BBS's? Is there a way to completely disable Telnet escaping on the UDS-10 itself?

Edited by JimDrew
Link to comment
Share on other sites

I agree that the UDS must be doing Telnet Escaping for 0xFF. But if I turn the UDS telnet mode off, then the BBS would need to do its own Telnet escaping, and wouldn't that be the same as the UDS performing the escaping?

 

I can change the UDS setting this evening (or some other time) if you'd like to try it with the telnet mode turned off.

Link to comment
Share on other sites

Well, if you made the C64 user port (edge card fingers) wired correctly to your TI system, you could then just plug in my WiModem (C64 version). It's 5vdc so it would work. The WiModem232 requires RS-232 levels (+/-12vdc), so it won't work directly with the 1284P. The WiModem for the C64 has Rx/Tx/RTS/CTS/DCD lines. It's missing RI (Ring Indicator), but it seems that most programs just look for "RING" to appear and then answer (like for a BBS).

 

 

I might grab one of those when I get some extra $$. How much support circuitry is on there other than the WiFi SOC that I see? I'm thinking we might be able to also use the same WiFi SOC directly on our cartridge boards (with whatever support circuitry is needed) if I can prove out your C64 user port works or doesn't work. The 1284P only hooks up GND, RX, and TX for right now, so we'd have to either tell it to do soft flow control or figure out what to do about the RTS/CTS/DCD lines on the WiFi SOC.

Link to comment
Share on other sites

You can connect any 5v CPU with a serial port directly to the WiModem for the C64 - it has 5v TTL logic. The WiModem has proper level shitters (not simple resistors that draw excessive current) and a power supply circuit, besides the RF module.

Edited by JimDrew
Link to comment
Share on other sites

Well proper shitting is important but I'm unclear at what level shitting should occur. Is this happening at normal stool height? I do have two stories on my house so I could do some level 2 shitting and record that data. I also have a basement that would yield some level 0 shitting data but there is no pot down there so the data may not be hard.

 

Ohhhhh. Sorry. Nevermind.

  • Like 3
  • Haha 1
Link to comment
Share on other sites

Happy New Year!

 

If the 0xFF character is the problem, I'm confused as to how the others BBSs and terminal emulators are handling it. It seems the Lantronix UDS-10 is doing what is expected by escaping the 0xFF character, leading to successful transfers (in some cases). I could duplicate this function in the BBS but I don't see how it would be any different than the UDS.

 

I captured a few more packets below to show what happens with the UDS telnet mode enabled and disabled.

 

--------------------

Disconnect mode 0xC0 (telnet mode enabled)
TCP packet sent from Hyperterminal to UDS.

Single 0xFF is doubled by Hyperterminal then stripped upon receipt by UDS.
File transfer completed successfully.
0000 3c 7a 8a 7d 19 87 6c 62 6d eb 98 cf 08 00 45 00 <z.}..lbm.....E.
0010 00 e2 a4 3d 40 00 80 06 40 21 c0 a8 00 64 4a c1 ...=@...@!...dJ.
0020 09 ea 0d 62 25 a8 25 01 2d 13 29 90 7c 10 50 18 ...b%.%.-.).|.P.
0030 fd b1 16 8c 00 00 ff 00 ff ff 00 ff ff 00 ff ff ................
0040 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ................
0050 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ................
0060 ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff ................
0070 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ................
0080 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ................
0090 ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff ................
00a0 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ................
00b0 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ................
00c0 ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff ................
00d0 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ................
00e0 ff ff 00 ff ff 00 ff ff 00 20 20 20 20 20 9c d3 ......... ..
00f0

----------------
Disconnect mode 0xC0 (telnet mode enabled)
TCP packet sent from BBS UDS to Hyperterminal.
Single 0xFF is doubled by UDS then stripped upon receipt by Hyperterminal.

File transfer completed successfully.
0000 6c 62 6d eb 98 cf 3c 7a 8a 7d 19 87 08 00 45 00 lbm...<z.}....E.
0010 00 e3 ac c6 40 00 3f 06 78 97 4a c1 09 ea c0 a8 ....@.?.x.J.....
0020 00 64 25 a8 0d 62 29 90 87 e1 25 01 2d eb 50 18 .d%..b)...%.-.P.
0030 07 ff 27 91 00 00 01 0e f1 33 20 ff ff 00 ff ff ..'......3 .....
0040 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ................
0050 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ................
0060 ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff ................
0070 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ................
0080 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ................
0090 ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff ................
00a0 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ................
00b0 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ................
00c0 ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff ................
00d0 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ................
00e0 ff ff 00 ff ff 00 ff ff 00 ff ff 00 ff ff 00 20 ...............
00f0 20

----------------
Disconnect mode 0x80 (telnet mode disabled).
TCP Packet sent from UDS to Hyperterminal.

The 0xFF is not escaped or doubled. Upon receipt by Hyperterminal it is discarded as the start of a Telnet sequence.
File transfer fails due to short packets.

0000 6c 62 6d eb 98 cf 3c 7a 8a 7d 19 87 08 00 45 00 lbm...<z.}....E.
0010 00 7a ac 0e 40 00 3f 06 79 b8 4a c1 09 ea c0 a8 .z..@.?.y.J.....
0020 00 64 25 a8 0e 35 7e c1 a2 8a 8a 59 12 bc 50 18 .d%..5~....Y..P.
0030 07 ff 39 4b 00 00 00 ff 00 ff 00 ff 00 ff 00 ff ..9K............
0040 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff ................
0050 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff ................
0060 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff ................
0070 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff ................
0080 00 ff 00 20 20 20 20 20
...

Link to comment
Share on other sites

I agree that the UDS must be doing Telnet Escaping for 0xFF. But if I turn the UDS telnet mode off, then the BBS would need to do its own Telnet escaping, and wouldn't that be the same as the UDS performing the escaping?

 

Technically, you don't need escaping at all. None of the Apple II, C64, or Amiga BBS's use any type of escaping and operate normally, including file transfers. Escaping only appears to be necessary if you are accessing a portal or BBS that specifically uses Telnet commands (like tty.sdf.org:23). I can run two terminal programs, one on my C64 and one on my Amiga and connect together (via ATDT) and chat with myself and transfer files. However, Telnet escaping with the WiModems must be OFF or the file transfers will not work. Edit: this just made me realize that if both WiModem's have escaping ON it should still work, but it doesn't - and that's because I am not escaping the outgoing data, just the received data. I need to fix that.

 

Have you tried just disabling all Telnet stuff?

Edited by JimDrew
Link to comment
Share on other sites

 

Technically, you don't need escaping at all. None of the Apple II, C64, or Amiga BBS's use any type of escaping and operate normally, including file transfers. Escaping only appears to be necessary if you are accessing a portal or BBS that specifically uses Telnet commands (like tty.sdf.org:23). I can run two terminal programs, one on my C64 and one on my Amiga and connect together (via ATDT) and chat with myself and transfer files. However, Telnet escaping with the WiModems must be OFF or the file transfers will not work. Edit: this just made me realize that if both WiModem's have escaping ON it should still work, but it doesn't - and that's because I am not escaping the outgoing data, just the received data. I need to fix that.

 

Have you tried just disabling all Telnet stuff?

I tried disabling it, and if I connect two UDS-10s together (TI to TI), I can transfer files successfully. I can also transfer successfully if both UDS devices have telnet enabled. So the only time transfers fail is when the client expects telnet escaping, either at the terminal or the device level. This makes sense to me. On the PC, SyncTerm failed to transfer files with the UDS Telnet disabled; I discovered it has a raw tcp setting that I will test tonight.

 

I've never transferred files to/from the C64, Amiga, or similar BBSs so I have no good reference point. I pretty much assumed that since they were using telnet, that they were making use of the escaping through the hardware or software.

 

It will also be interesting to see what happens when the WiModems escape the outgoing data. Would be great if that solves the transfer issue. That said, I am still going to evaluate (and test) shutting off the Heatwave telnet feature as well as adding some minimal Telnet support to TIMXT (terminal emulator) based on what I have learned so far.

Link to comment
Share on other sites

Syncterm gives me problems on the winderz pc downloading files from hidden reef which is going through a telnet to thekeep.net then dialing out to the modem at HR this seems to be a sw bug as it is a crash at the end of the file..

 

I had to use qodem on that pc to download successfully using xmodem.. unfortunately qodem's ansi isn't up to snuff so i am forced to switch back to syncterm to use the online games etc on my bbs..

 

you are welcome to use thekeep.net as a test as well.. lmk if i can be of assistance..it's running worldgroup 3.x with it's own telnet server

 

Greg

Link to comment
Share on other sites

I've never transferred files to/from the C64, Amiga, or similar BBSs so I have no good reference point. I pretty much assumed that since they were using telnet, that they were making use of the escaping through the hardware or software.

 

 

There is no escaping done ever.. It's just raw data packets. I have been selling the WiModem for the C64 for nearly 2 years and the first I had ever heard about Telnet was about 2 months ago when someone was trying to contact tty.sdf.org:23 and the terminal software just sat there and then hung up. It turns out tty.sdf.org sends a request for the terminal type. Once I supported it, you can log in no problem.

 

Edit: so I have looked into the Telnet a bit more and it seems that ONLY port 23 is suppose to be handled as a Telnet type connection. That makes sense because the only portals I have seen all have port 23 as their port. Everything else has no Telnet escaping at all.

Edited by JimDrew
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...