Telnet problem with atari server about zimodem HOT 11 CLOSED

Have you turned on internal byte debugging? at&o1

from zimodem.

Nope. But can try

from zimodem.

Cool... On the ESP32, it should be very well behaved, but still worth mentioning: don't leave at&o1 on long: you'll run out of SPIFFS space. Best way to use the feature is to turn it on right before you do your test, and then as soon after the problem as you can: enter at&o0 to turn it off and dump the log into some terminal you can capture and study. After at&o0, the log will persist, so you can repeat that command to dump the same log over and over. It will only reset it next time you do at&o1.

from zimodem.

You know, for ESP users such as yourself, I can easily make at&o1 also pipe to the second UART .. which is probably what you really want anyway...or, hmm.. maybe at&o2 :)

from zimodem.

Actually, you can already do that -- pipe the detailed debug log to the second uart. The command for that is at&o88

from zimodem.

huge amount of HEX Telnet session, hard for me. I need to study RFC then I can understand.
atarinet-log.txt

from zimodem.

this is how it looks without debug and when dial from phonebook

from zimodem.

So, the garbage might be your old computer trying to render telnet codes. I'd recommend trying ATDT2 instead of ATD2

from zimodem.

ATDT will only ends with NO CARRIER. It is also visible in that posted log before.

from zimodem.

I'll take a look at what irc.atarinet.com:800 is doing.

from zimodem.

Well, I was able to reproduce the issue and peek into the details of what's going on, and the simple answer is: we can't get there from here.

Slightly less simple: the atari irc server is expecting screen-attached-client telnet negotation that a blind and dumb modem simply can't respond to, since the modem has no screen. Further, the built in zimodem telnet filter was designed simply to inform telnet servers how weak it is, and expects the server to be OK with that. Atari IRC is definitely not ok with that. In fact, even the Windows telnet client, which supports far more than Zimodem, is rejected by it.

The downright complicated. Here is a breakdown of all the telnet codes being sent, and the response sent by the modem. Basically Atari asks for the universe, and Zimodem says 'No Can Do". After all that, it disconnects.

The only good news I can give you is that I'm pretty sure I fixed those weird $ff pass throughs that were occurring, AND I added debug logging to capture the details of the telnet codes. As for your problem, I can't fix it from here.

Your only hope would be to find a true IRC client for your old computer that can handle all the features Atari is demanding.

01B019 SocI: FF FD 18 - do termtype
01B01A SocO: FF FB 18 - will termtype
01B01B SocI: FF FD 20 - terminal speed
01B01B SocO: FF FC 20 - wont terminal speed
01B01B SocI: FF FD 23 - x display location
01B01B SocO: FF FC 23 - wont x display loc
01B01C SocI: FF FD 27 - new env option
01B01C SocO: FF FC 27 - wont new env option
01B01C SocI: FF FD 24 - env option
01B060 SocO: FF FC 24 - wont env option
01B074 SocI: FF FA 18 01 FF F0 -- termtype
01B074 SocO: FF FA 18 00 35 41 36 39 36 44 36 46 36 34 36 35 36 44 FF F0 - termtype
01B087 SocI: FF FB 03 - will supress go ahead
01B087 SocO: FF FE 03 - dont supress go ahead
01B088 SocI: FF FD 01 - do echo
01B088 SocO: FF FC 01 - wont echo
01B088 SocI: FF FD 22 - do linemode
01B08D SocO: FF FC 22 - wont linemods
01B08F SocI: FF FD 1F - do negotiate window size
01B08F SocO: FF FC 1F - wont ""
01B090 SocI: FF FB 05 - will status
01B090 SocO: FF FE 05 - dont status
01B090 SocI: FF FD 21 - do remote flow control
01B090 SocO: FF FC 21 - wont remote flow control
01B093 SerO: 4E 4F
DCD going inactive.

from zimodem.