Skip to content
Snippets Groups Projects
Select Git revision
  • dailybuild_linux-x64
  • dailybuild_win32
  • master default protected
  • sqlite
  • rip_abstraction
  • dailybuild_macos-armv8
  • dd_file_lister_filanem_in_desc_color
  • mode7
  • dd_msg_reader_are_you_there_warning_improvement
  • c23-playing
  • syncterm-1.3
  • syncterm-1.2
  • test-build
  • hide_remote_connection_with_telgate
  • 638-can-t-control-c-during-a-file-search
  • add_body_to_pager_email
  • mingw32-build
  • cryptlib-3.4.7
  • ree/mastermind
  • new_user_dat
  • sbbs320d
  • syncterm-1.6
  • syncterm-1.5
  • syncterm-1.4
  • sbbs320b
  • syncterm-1.3
  • syncterm-1.2
  • syncterm-1.2rc6
  • syncterm-1.2rc5
  • push
  • syncterm-1.2rc4
  • syncterm-1.2rc2
  • syncterm-1.2rc1
  • sbbs319b
  • sbbs318b
  • goodbuild_linux-x64_Sep-01-2020
  • goodbuild_win32_Sep-01-2020
  • goodbuild_linux-x64_Aug-31-2020
  • goodbuild_win32_Aug-31-2020
  • goodbuild_win32_Aug-30-2020
40 results

telnet_io.c

Blame
    • Deucе's avatar
      9a9a81ea
      Fix telnet binary mode tracking. · 9a9a81ea
      Deucе authored
      When SyncTERM started by enabling binary mode in both directions,
      the internal tracking of the binary status wasn't updated, so it
      was incorrectly tracked as being in NVT mode.  After a file
      transfer, it would then revert to the NVT mode it throught it was
      in.
      
      This change updates the binary mode value when sending as well as
      receiving TELNET_BINARY_TX.
      
      This is still technically broken though since binary mode is
      negotiated separately in each direction, and the initial send of
      WILL + DO is actually a pair of requests that need to be confirmed
      by the remote.  Until they are confirmed, the connection is still
      in NVT mode.
      
      Hopefully though this isn't an issue since the remote should reply
      to both, and if it denies there's no effective difference between
      what we should do when already in binary mode and not because we
      don't support any other modes (such as CHARSET option).  Fixing it
      correctly would get very complex and involve blocking the connection
      until we get a response.
      9a9a81ea
      History
      Fix telnet binary mode tracking.
      Deucе authored
      When SyncTERM started by enabling binary mode in both directions,
      the internal tracking of the binary status wasn't updated, so it
      was incorrectly tracked as being in NVT mode.  After a file
      transfer, it would then revert to the NVT mode it throught it was
      in.
      
      This change updates the binary mode value when sending as well as
      receiving TELNET_BINARY_TX.
      
      This is still technically broken though since binary mode is
      negotiated separately in each direction, and the initial send of
      WILL + DO is actually a pair of requests that need to be confirmed
      by the remote.  Until they are confirmed, the connection is still
      in NVT mode.
      
      Hopefully though this isn't an issue since the remote should reply
      to both, and if it denies there's no effective difference between
      what we should do when already in binary mode and not because we
      don't support any other modes (such as CHARSET option).  Fixing it
      correctly would get very complex and involve blocking the connection
      until we get a response.