home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   SYNC_SYSOPS      Synchronet Multinode BBS Software Suppor      33,243 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 30,272 of 33,243   
   Rick Parrish to GitLab issue in main/sbbs   
   Shroedinger's Variable?   
   06 Sep 24 20:27:40   
   
   TZUTC: -0700   
   MSGID: 56249.sync_sys@1:103/705 2b41d9e5   
   PID: Synchronet 3.20a-Linux master/e93b6dfa6 Aug 22 202 GCC 12.2.0   
   TID: SBBSecho 3.20-Linux master/46c603ce3 Aug 26 2024 17:07 GCC 12.2.0   
   BBSID: VERT   
   CHRS: ASCII 1   
   open https://gitlab.synchro.net/main/sbbs/-/issues/782   
      
   The sysop of Tucumcari BBS reported garbage input when trying to log in via   
   fTelnet.  Dove-net post for reference:    
   https://vert.synchro.net/?page=001-forum.ssjs&sub=sync&thread=52391   
      
   - I asked him to roll back websocketservice.js to a previous version, and   
   input worked good with it   
   - I modified the latest version of websocketservice.js to output debug   
   information, which indicated the issue is related to the XORing used to unmask   
   incoming websocket data frames.   
     - For example, if I hit the "a" key, the debug output showed that a masking   
   byte of 212 and a data byte of 181 were received, and when XORed they should   
   have resulted in an input byte of 97 to match the "a" key I pressed, but   
   instead the input byte was still 181 like the raw data byte.  This means   
   either the XOR was skipped, or somehow 181 XOR 0 ran instead of 181 XOR 212.   
   - I made a second modification to output a bit more debug information to   
   determine whether the XOR was being skipped, or the XOR 0 was happening, and   
   unexpectedly input worked good with it!   
   - I asked him to run both of my modified versions on different ports, to see   
   whether the first debug version now works, but it still has garbage input   
   - I took a closer look at the output from the first debug version, and found   
   that it actually starts unmasking correctly, but seems to reliably fail at the   
   same point on repeated connection attempts:   
     - 255 252 1 received OK   
     - 255 251 23 received OK   
     - 255 253 29 not OK (29 should have been 1)   
     - Everything after that is not unmasking   
      
   The difference between the first debug version and the second debug version is   
   the addition of this line, which references several variables but does not   
   modify any of them:   
   `SendToWebSocketClient_RickDebug('    InByte = ' + InByte + ', FFrameMasked =   
   ' + FFrameMasked + ', FFramePayloadReceived = ' + FFramePayloadReceived + ',   
   Mask = ' + FFrameMask[FFramePayloadReceived % 4] + ', OutByte = ' + (InByte ^   
   FFrameMask[FFramePayloadReceived % 4]) + '\r\n');`   
      
   And in case it helps, this is the commit that introduces the garbage input   
   behaviour.  It switches from reading one byte at a time to reading a message   
   at a time, to speed up file transfers.  The line responsible for unmasking the   
   data didn't change though.   
   https://gitlab.synchro.net/main/sbbs/-/commit/fbefb47f10a19a68c5   
   ae0bdd6ef64484ac100cc   
      
   @echicken mentioned he ran into something like this sometime last year, and   
   suggests changing options controlling JS runtime behaviour.  Is this something   
   that can be done via configuration options?  Or only at compile time?  And   
   however it's done, do you have any suggestions on what to change and what to   
   change it to?   
      
   Here's links to connect to the two debug versions of websocketservice.js, if   
   you'd like to see the issue in action (scrollback is limited so you won't be   
   able to see the earliest debug output, but it's all visible in developer tools   
   console)   
      
   [Version 1 (garbage input)](https://embed-v2.ftelnet.ca/connect/   
   BareLFtoCRLF=false&BitsPerSecond=57600&ConnectionType=telnet&Emu   
   ation=ansi-bbs&Enter=\r&Font=CP437&ForceWss=false&Hostname=tucum   
   ar.synchro.net&LocalEcho=false&NegotiateLocalEcho=true&Port=1125   
   &ScreenColumns=80&ScreenRows=25&SendLocation=true#ftelnetdebug=1)   
      
   [Version 2 (works)](https://embed-v2.ftelnet.ca/connect/?BareLFt   
   CRLF=false&BitsPerSecond=57600&ConnectionType=telnet&Emulation=a   
   si-bbs&Enter=\r&Font=CP437&ForceWss=false&Hostname=tucumcar.sync   
   ro.net&LocalEcho=false&NegotiateLocalEcho=true&Port=11245&Screen   
   olumns=80&ScreenRows=25&SendLocation=true#ftelnetdebug=1)   
   --- SBBSecho 3.20-Linux   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 10/0 1 90/1 102/401 103/1 17 705 105/81 106/201 124/5016   
   SEEN-BY: 153/7715 214/22 218/0 1 215 601 700 720 840 860 870 880 930   
   SEEN-BY: 226/30 227/114 229/110 114 206 317 400 426 428 470 550 700   
   SEEN-BY: 229/705 266/512 280/464 282/1038 291/111 301/1 320/219 322/757   
   SEEN-BY: 342/200 396/45 460/58 633/280 712/848 5075/35   
   PATH: 103/705 218/700 229/426   
      

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca