src/syncterm telnet_io.c 1.29 1.30
Update of /cvsroot/sbbs/src/syncterm
In directory cvs:/tmp/cvs-serv24265

Modified Files:
telnet_io.c
Log Message:
Fix warnings



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/syncterm telnet_io.c 1.30 1.31
Update of /cvsroot/sbbs/src/syncterm
In directory cvs:/tmp/cvs-serv7952

Modified Files:
telnet_io.c
Log Message:
Bug-fix: when using Telnet, we would *always* send the terminal type
(if the server supported the option), as "ANSI". Now, if the current cterm emualation is PETASCII [sic], or ATASCII, send "PETSCII" or "ATASCII"
instead.

Now this brings up a couple of discussion points:
1. Should that default Telnet term-type be "ANSI-BBS" (or "ansi-bbs") instead? 2. Similarlly, RLogin connections *always* send the term-type as "ansi-bbs" -
I think a similar change is needed in rlogin.c to be technically correct,
but we should probably be consistent about how SyncTERM in ANSI-BBS emulation
mode identifies itself ("ANSI", "ANSI-BBS", or "ansi-bbs").
3. If there is terminal type advertised via SSH, that probably needs addressing
as well.




---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/syncterm telnet_io.c 1.31 1.32
Update of /cvsroot/sbbs/src/syncterm
In directory cvs:/tmp/cvs-serv31770

Modified Files:
telnet_io.c
Log Message:
Resolve GCC warning: enumeration value ‘CTERM_EMULATION_ANSI_BBS’ not handled in switch



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: src/syncterm/telnet_io.c
By: rswindell to CVS commit on Mon Oct 22 2018 07:18 pm

Resolve GCC warning: enumeration value ‘CTERM_EMULATION_ANSI_BBS’ not

That's another system where I need to run 'update-locale --reset LANG=C' (to get rid of the unicode chars). <sigh>

digital man

This Is Spinal Tap quote #9:
David St. Hubbins: I mean, it's not your job to be as confused as Nigel.
Norco, CA WX: 60.2øF, 89.0% humidity, 0 mph S wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/syncterm telnet_io.c 1.32 1.33
Update of /cvsroot/sbbs/src/syncterm
In directory cvs:/tmp/cvs-serv9634

Modified Files:
telnet_io.c
Log Message:
Improve compatibility with some crappy Telnet server (e.g. in C64 BBSes):
Send CR/NUL for <Enter> rather than CR/LF. Although the Telnet spec (RFC854) requires that either combination be accepted as a single "new line" character, some Telnet servers treat CR and LF as separate input characters and do weird things (e.g. treat the LF as a second <Enter> key or <^J> or invalid input).
If we ever come across a Telnet server that does something weird with CR/NUL (and works better receiving CRLF) then perhaps we'll need a configuration option. Hopefully not. Of course, in binary mode, none of this applies.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/syncterm telnet_io.c 1.35 1.36
Update of /cvsroot/sbbs/src/syncterm
In directory cvs:/tmp/cvs-serv10488

Modified Files:
telnet_io.c
Log Message:
Revert r1.33

Per RFC-5198:
2. In Net-ASCII, CR MUST NOT appear except when immediately followed
by either NUL or LF, with the latter (CR LF) designating the "new
line" function. Today and as specified above, CR should
generally appear only when followed by LF. Because page layout
is better done in other ways, because NUL has a special
interpretation in some programming languages, and to avoid other
types of confusion, CR NUL should preferably be avoided as
specified above.

It's not worth breaking all connections for some broken telnet servers. Especially since we do not explicitly want CR behaviour which is the only
place it's allowed.

Per RFC-854:
the sequence "CR NUL" must be used where a carriage return alone is
actually desired;

It's quite possible that these "telnet servers" are actually raw socket
servers and should use raw sockets rather than telnet.




---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/syncterm telnet_io.c 1.37 1.38
Update of /cvsroot/sbbs/src/syncterm
In directory cvs:/tmp/cvs-serv29256

Modified Files:
telnet_io.c
Log Message:
putcom():
Don't make a blocking-call to send/sendsocket() without first checking writability with select().



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/syncterm telnet_io.c 1.39 1.40
Update of /cvsroot/sbbs/src/syncterm
In directory cvs:/tmp/cvs-serv11296

Modified Files:
telnet_io.c
Log Message:
Increase putcom() timeout to 10 seconds to allow network buffers to drain.




---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/836593162c49c5ccf5469240
Modified Files:
src/syncterm/telnet_io.c
Log Message:
Whitespace cleanup

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/2bae9a96e637c06d8f48c8c6
Modified Files:
src/syncterm/telnet_io.c
Log Message:
Track Telnet Binary TX mode set by server via Telnet (IAC) commands

As reported by Chris/akacastor (21:1/162), SyncTERM would always assume the Telnet session was in ASCII mode until/unless conn_binary_mode_on() was called which is only called at the beginning of a file transfer, which sets the conn_api.binary_mode accordingly. Unfortunately, if the Telnet server
requested binary mode itself (e.g. during initial connection), SyncTERM would (try to) set the connection back to ASCII mode after any file transfer. :-(

With this change, the conn_api.binary_mode will track the actual binary TX
mode whether initiated locally or remotely (by the server), but it'll only be set to true when *both* directions are succesfully set to binary mode. And
this way, if the connection was already in binary mode before any file transfer, it'll remain in binary mode as was apparently desired by the server.

Also with this change, we could probably remove the setting of conn_api.binary_mode to true/false in conn_binary_mode_on()/off() functions, but it shouldn't hurt anything if it's left there I suppose (in case some *other* terminal transport protocols have the concept of binary mode?).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net