Solution:
The telnet IAC handler in DOSBox-X softmodem.cpp was modified to deny requests to disable binary mode, and in case a client disables binary mode a request to enter binary mode is sent.
Solution:
The telnet IAC handler in DOSBox-X softmodem.cpp was modified to deny requests to disable binary mode, and in case a
client disables binary mode a
request to enter binary mode is sent.
This sounds like a hacky-work-around and not a 'fix'.
If ASCII (non-binary-tx) mode is negotiated succesfully
when SyncTERM first connects to telnet server, then it
should be free to return to ASCII mode later.
It just sounds like there's a bug in the DOSBOX-X
terminal server with tracking the remote and/or local
"BINARY TX" state and that needs to be fixed rather
than just blindly rejecting requests to exit binary
transmission mode.
Maybe you would have had better luck with DOSBOX-
staging instead of of DOSBOX-X?
If ASCII (non-binary-tx) mode is negotiated succesfully
when SyncTERM first connects to telnet server, then it
should be free to return to ASCII mode later.
ASCII mode was never negotiated successfully, the session was in binary mode from the beginning.
SyncTerm is incorrectly 'returning' to ASCII mode after
file transfers.
I don't think I see a pressing need for my system to support ASCII mode telnet as I expect any client should support binary mode. (maybe there's some edge cases in niche implementations or a benefit of ASCII mode that I am missing?)
It just sounds like there's a bug in the DOSBOX-X
terminal server with tracking the remote and/or local
"BINARY TX" state and that needs to be fixed rather
than just blindly rejecting requests to exit binary
transmission mode.
Maybe you would have had better luck with DOSBOX-
staging instead of of DOSBOX-X?
I agree there is likely a bug hiding in the telnet emulation, I may dig deeper for it yet. In the meantime, convincing SyncTerm to stop switching to ASCII modes removes the issue from my system.
Telnet emulation in DOSBox-Staging is broken also. I don't know if it has the same behaviour with ASCII vs binary mode but it has other telnet protocol bugs, like sending binary data from DOSBox does not escape the IAC bytes. (due to this binary transfers work when DOSBox is receiving, but not when sending)
I haven't ruled out DOSBox-Staging in the long term, but DOSBox-X has been working well for me and I have already been patching it to suit my needs (mostly a bit of cleanup/hackjobs in softmodem.cpp). Eventually I hope to get the softmodem code cleaned up enough to submit to the github project.
ASCII mode is the default, so if there's no mention of
"BINARY TX" in either direction during initial
conneciton, then ASCII mode was successfully
negotiated. As I recall, SyncTERM doesn't initate any
explicit Telnet commands regarding BINARY TX upon
initial connection, so unless the Telnet server does
(e.g. sends "DONT BINARY TX"), then SyncTERM is correct
in assuming ASCII mode.
SyncTerm is incorrectly 'returning' to ASCII mode after
file transfers.
SyncTERM *attempts* to return to ASCII mode, but the
server can definitely NAK the messages (as you've discovered).
If the Telnet server explicitly requested the client to
be in BINARY TX mode during initial connection, then I
suppose it could be considered "incorrect" for SyncTERM
to want to *return* to a mode it wasn't already in. But
I'm not clear that's the case since I didn't see a log
of telnet commands sent and received from the start of
the connection.
I don't think I see a pressing need for my system to support ASCII mode telnet as I expect any client should support binary (maybe there's
some edge cases in niche implementations or a benefit of ASCII mode that I am missing?)
I guess you'll find out. :-)
k, cool. I might play with connecting to your BBS and
see what I find wrt its telnet server and comment further.... or not. :-)
telnet://bbs.roonsbbs.hu:1212 <<=-
k, cool. I might play with connecting to your BBS and
see what I find wrt its telnet server and comment further.... or not. :-)
I would appreciate any insight! You have a lot more experience with the protocol and what different clients/servers may expect in the real world than probably anybody here.
Answering a msg of <16 Apr 24>, from you to All:
wow. glad you found it. buuuut... it's not (only?) a dosbox problem,
my maximus/2 behaves the same with synchterm... :)
Answering a msg of <16 Apr 24>, from you to All:
wow. glad you found it. buuuut... it's not (only?) a dosbox
problem, my maximus/2 behaves the same with synchterm... :)
I tested on your board before I had posted and didn't notice trouble
after a file transfer, but then I didn't test very well! The symptoms
can be a bit funny can't they.
I am not sure why Maximus doesn't like to operate within an ASCII
telnet connection as I would expect the telnet interface (Vmodem or DOSBox-X in our cases) to translate anything that needs to be
translated. I wonder if other BBS software has the same behaviour.
If there's a way to send a telnet negotiation command through the
Vmodem connection, you can include after file transfers (or in the top
of the file menu?) the telnet IAC commands to switch to binary mode
and that may solve the problem for you.
telnet://bbs.roonsbbs.hu:1212 <<=-
--- Blue Wave/DOS v2.30
* Origin: Roon's BBS - Budapest, HUNGARY (21:4/148)
I looked at the SyncTERM source and determined that though it attempted to track and restore the binary mode of the Telnet
connection, it didn't take into account the server
initiated commands for setting BINARY TX mode (in
either direction). I committed a fix for that. If you
have a chance and want to try it out, it's in Git and
now and should be in nightly builds (e.g. for Windows,
MacOS) within 24 hours. Let me know if you do try it
and what you discover. I expect it'll resolve this
issue.
If there's a way to send a telnet negotiation command through the
Vmodem connection, you can include after file transfers (or in the top
of the file menu?) the telnet IAC commands to switch to binary mode
and that may solve the problem for you.
did you try other terminal emulators or just synchterm?
side note, blue wave worked on my bbs :)
--- Blue Wave/DOS v2.30
* Origin: Roon's BBS - Budapest, HUNGARY (21:4/148)
Thanks for that. I haven't had a chance to try it out yet but will take a look.
I did spend a bit more time on the DOSBox-X softmodem telnet implementation, I found that my hacky approach to forcing binary mode was in some cases (Netrunner) causing an IAC command loop. So I cleaned up the tracking of telnet state and now don't send IAC WILL in response to an IAC DO if it didn't cause a state change.
I haven't properly implemented ASCII mode yet - I have some more questions. In ASCII mode I understand a raw CR is sent as CR/NULL (or CR/LF in case of a newline). So any CR should be translated to CR/NULL and then from CR/NULL back to CR at the other end (or however that end chooses to interpret it), correct?
Other than CR (and sequences starting with the IAC character 0xFF) are there any other characters or sequences that either need to be escaped or can't be passed via ASCII mode telnet? I'm not sure if I'm still missing other things.
I found that my hacky approach to forcing binary mode was in some cases (Netrunner) causing an IAC command loop. So I cleaned up the tracking of telnet state and now don't send IAC WILL in response to an IAC DO if it didn't cause a state change.
Yup, that's how Telnet is: they used the same byte
value for a request and an acknowledgement. Dumb design.
Other than CR (and sequences starting with the IAC character 0xFF) are
there any other characters or sequences that either need to be escaped or can't be passed via ASCII mode telnet? I'm not sure if I'm still missing other things.
That's it.
If both ends properly translate CR to CR/NULL (and back), doesn't that negate the need for binary mode? (or is both ends properly translating it hoping for too much?)
| Sysop: | tracker1 |
|---|---|
| Location: | Phoenix, AZ |
| Users: | 54 |
| Nodes: | 25 (0 / 25) |
| Uptime: | 174:01:48 |
| Calls: | 367 |
| Files: | 1,364 |
| Messages: | 36,299 |