I have installed SBBS again and I am getting the same problem that I did last time, but I didn't post it here, like a fool. I have installed SBBS according to the Raspberry Pi instructions on the wiki (although I am running a Banana Pi on Armbian) and it compiles great. If I log in through telnet, everything seems to work fine. When I use the web telnet client, the output looks good, but the username prompt produces garbage with typing and, of course, I can't log in that way.

Any thoughts on why the web telnet doesn't seem to interpret keystrokes correctly?

---
þ Synchronet þ My Brand-New BBS
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: armhf installed web telnet garbles input
By: W5jsn to All on Tue Aug 27 2024 15:40:11

through telnet, everything seems to work fine. When I use the web telnet client, the output looks good, but the username prompt produces garbage with typing and, of course, I can't log in that way.

Haven't heard of this before. If your site is open for visitors I can stop by and have a look. Could be a lot of things depending on which web interface you chose, what browser you're using, etc.

echicken
electronic chicken bbs - bbs.electronicchicken.com
---
þ Synchronet þ electronic chicken bbs - bbs.electronicchicken.com
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

That would be great! It is accessible at http://2cc.us:8080. I have pretty much kept the original install (except for setting the 8080 and 8443 ports for http and https). I am using Windows 10 and firefox when I get the garbled input. Now that I try it with Chrome, I can't get the web telnet to work at all. Yikes! Is this my just deserts for not using x86_64 and debian under the hood? ;)

---
ï¿­ Synchronet ï¿­ My Brand-New BBS
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: armhf installed web telnet garbles input
By: W5jsn to echicken on Wed Aug 28 2024 11:20:01

That would be great! It is accessible at http://2cc.us:8080. I have pretty

Your website loads fine, but I was unable to test further with ftelnet since I can't connect to port 1123 on your system from here. You'll need to open that to the outside world.

echicken
electronic chicken bbs - bbs.electronicchicken.com
---
þ Synchronet þ electronic chicken bbs - bbs.electronicchicken.com
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Can you try connecting via this link:

https://embed-v2.ftelnet.ca/connect/?BareLFtoCRLF=false&BitsPerSecond=57600&Con nectionType=telnet&Emulation=ansi-bbs&Enter=\r&Font=CP437&ForceWss=false&Hostna me=2cc.us&LocalEcho=false&NegotiateLocalEcho=true&Port=23&ProxyHostname=p-us-ce ntral.ftelnet.ca&ProxyPort=80&ProxyPortSecure=443&ScreenColumns=80&ScreenRows=2 5&SendLocation=true

Tiny URL, in case the long link is broken: https://tinyurl.com/5cz6jamb

That'll remove websocketservice.js from the equation. I made changes a couple months ago, and wonder if that's related (is your cpu big endian by any chance?)

Assuming the above link works for you (it does in both Firefox and Chrome for me), and also assuming you're running the latest code from Git, try reverting websocketservice.js to the version prior to my changes:

https://gitlab.synchro.net/main/sbbs/-/raw/6ee49a5dd1baa2cf28fa4ca0903efc4d713a 8dd2/exec/websocketservice.js

---
ï¿­ Synchronet ï¿­ fTelnet Demo Server - ftelnet.synchro.net
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

I had altered port 1123 at the router to point at a different server I have. I changed it to point at the SBBS server again.

---
ï¿­ Synchronet ï¿­ Tucumcari BBS
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

I tried through the ftelent proxy and it works correctly there, so it must be in websocketservice.js! I'll need to roll that back. I found websites that say ARM processors like this (Allwinner A40I-H) are little-endian.

---
ï¿­ Synchronet ï¿­ Tucumcari BBS
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

I tried through the ftelent proxy and it works correctly there, so it must be in websocketservice.js! I'll need to roll that back. I found websites that say ARM processors like this (Allwinner A40I-H) are little-endian.

Reverting to the websocketservice.js that you indicated worked! Sadly, it only allowed the ftelnet login once. Now, I just get when I "connect with telnet" is a blank screen with a greyed underline cursor.

Ack!!

---
ï¿­ Synchronet ï¿­ Tucumcari BBS
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Thanks to everyone for the help. Now that I have done a few reboots and some proxy work, everything seems to be working very well!

---
ï¿­ Synchronet ï¿­ Tucumcari BBS
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Thanks to everyone for the help. Now that I have done a few reboots and some proxy work, everything seems to be working very well!

Are you back on the latest websocketservice.js, or still rolled back?

---
ï¿­ Synchronet ï¿­ fTelnet Demo Server - ftelnet.synchro.net
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Are you back on the latest websocketservice.js, or still rolled back?

---
ï¿­ Synchronet ï¿­ fTelnet Demo Server - ftelnet.synchro.net

I'm still on the rolled-back version.

---
ï¿­ Synchronet ï¿­ Tucumcari BBS
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Can you give this version a shot? I made two commits last year, and this is the first of the two, so based on whether it works or is garbled I'll know which of the two commits introduced the issue.

https://tinyurl.com/ysc38wxv

---
ï¿­ Synchronet ï¿­ fTelnet Demo Server - ftelnet.synchro.net
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Can you give this version a shot? I made two commits last year, and this is the first of the two, so based on whether it works or is garbled I'll know which of the two commits introduced the issue.

https://tinyurl.com/ysc38wxv

I put in the version of websocketservice.js you linked here and it is back to garbled input. Also, it doesn't use the ANSI terminal, only the dumb terminal. I will be rolling back again to get it to work again.

---
ï¿­ Synchronet ï¿­ Tucumcari BBS
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

I put in the version of websocketservice.js you linked here and it is back to garbled input. Also, it doesn't use the ANSI terminal, only the dumb terminal. I will be rolling back again to get it to work again.

Thanks, that helps narrow down to which commit caused the issue.

Can you try downloading this to a NEW file called exec/websocketservice-debug.js, add two new entries to ctrl/services.ini, and allow ports 1124 and 11245 to be forwarded to your BBS? This debug version of websocketservice will echo some websocket metadata back to the user, so once things are setup I'll be able to connect to your system on one of the new ports to see how your system is interpreting the data/keypresses fTelnet is sending.

Download: https://tinyurl.com/3rsv6eww

services.ini entries:

[DebugWS]
Port=1124
Options=NO_HOST_LOOKUP
Command=websocketservice-debug.js

[DebugWSS]
Port=11245
Options=NO_HOST_LOOKUP|TLS
Command=websocketservice-debug.js

---
ï¿­ Synchronet ï¿­ fTelnet Demo Server - ftelnet.synchro.net
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

The debug .js file, services.ini changes, port forwarding for the debug ports are all set up. Have at it!!

---
ï¿­ Synchronet ï¿­ Tucumcari BBS
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

The debug .js file, services.ini changes, port forwarding for the debug ports are all set up. Have at it!!

Just gave it a shot, but it looks like your telnet server is down? Can't connect via the web telnet, or even directly with syncterm.

---
ï¿­ Synchronet ï¿­ fTelnet Demo Server - ftelnet.synchro.net
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

I just got back to reading messages and saw your response. I restarted the lot and it looks like the telnet server is running again.

---
ï¿­ Synchronet ï¿­ Tucumcari BBS
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

The debug .js file, services.ini changes, port forwarding for the debug ports are all set up. Have at it!!

Just tried again and was able to connect, and the extra debug information definitely helped narrow things down, although it's a mystery to me as to why it's not working. I've added a bit more debug output to this version, if you could replace your websocketservice-debug.js with it: https://tinyurl.com/bdfr3enr

If you're a programmer (or other programmers are reading), here's the relevant debug output:

FWebSocketState=WEBSOCKET_NEED_PACKET_START, FFrameOpCode=2

This tells me the incoming packet is a binary frame (2 = binary)

FWebSocketState=WEBSOCKET_NEED_PAYLOAD_LENGTH, InByte=129, FFrameMasked = true, FFramePayloadLength = 1

This tells me the incoming frame is 1 byte long, and is masked.

FWebSocketState=WEBSOCKET_NEED_MASKING_KEY, InByte=2301443968, FFrameMask = 137 45 63 128

This gives us our four masking bytes

FWebSocketState=WEBSOCKET_DATA, InStr=232

This is the raw data. Since the frame is masked, you need to xor each incoming byte with a masking byte. In this case you'd do 232 XOR 137

tempBytes = 232

This is the unmasked bytes, which should be the result of the 232 XOR 137 operation, which should be 97, which would correspond with the "a" that I pressed. But it's not, it's still the original value of 232, which means either the XOR operation didn't run, or it ran as 232 XOR 0 for some reason. The extra debug information will hopefully shed light on what's happening here.

The part that's really confusing me is that the line of code that unmasks the bytes hasn't changed between the commit that works for you and the commit that breaks:

if (FFrameMasked) InByte ^= FFrameMask[FFramePayloadReceived++ % 4];

We know from the debug output above that FFramemasked is true, so the XOR should be happening. And while we don't know what the value of FFramePayloadReceived is (it should be 0, but it's not included in the current debug output), the % 4 means no matter what value it is we'll always be looking at elements 0, 1, 2, or 3 in the FFrameMask array, and we know those elements have values 137, 45, 63, and 128 from the debug output, so it doesn't make sense that a XOR 0 is happening...

---
ï¿­ Synchronet ï¿­ fTelnet Demo Server - ftelnet.synchro.net
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

The revised debug.js is in place. I fear I am more a hack than programmer.

I forget if I am using the most current websocketservice.js on the ws and wss ports, but it has been working fine as far as I can tell.

---
ï¿­ Synchronet ï¿­ Tucumcari BBS
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

The revised debug.js is in place

Things just keep getting weirder...the latest version is working as expected! But there weren't any logic changes at all, just two extra debug outputs, so there's no reason for this version to work and the previous version to be broken.

Can you try running both debug versions side by side? That'll let me see if they're now both working, or if the older version is still broken. And if the older version is still broken, then I'll have to bring in another set of eyes because clearly I'm missing something.

So re-download https://tinyurl.com/3rsv6eww and save it to a new file called exec/websocketservice-debug2.js

Then in services.ini add:

[Debug2WS]
Port=1125
Options=NO_HOST_LOOKUP
Command=websocketservice-debug2.js

[Debug2WSS]
Port=11255
Options=NO_HOST_LOOKUP|TLS
Command=websocketservice-debug2.js

And of course forward ports if necessary. Thanks!

---
ï¿­ Synchronet ï¿­ fTelnet Demo Server - ftelnet.synchro.net
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: armhf installed web telnet garbles input
By: Ree to W5jsn on Fri Sep 06 2024 09:51:19

Things just keep getting weirder...the latest version is working as expected! But there weren't any logic changes at all, just two extra debug outputs, so there's no reason for this version to work and the previous

This reminds me of a problem I ran into sometime last year, though I don't remember the details. I called it Shroedinger's Variable. (Amusingly, the guy who brought the bug to my attention turned out to be a physics teacher.)

Something was seemingly undefined at runtime *except* when I used log, writeln, some other things that required it to be resolved immediately. As if the same wasn't also necessary for math, evaluation, etc.

It would be interesting to play with different compilation options controlling the behavior of the JS runtime, though I don't remember what's available. I don't know if this would be related to eg. JIT or if it's some weird interplay with the Socket object or what.

echicken
electronic chicken bbs - bbs.electronicchicken.com
---
þ Synchronet þ electronic chicken bbs - bbs.electronicchicken.com
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Things just keep getting weirder...the latest version is working as expected! But there weren't any logic changes at all, just two extra debug outputs, so there's no reason for this version to work and the previous version to be broken.

Can you try running both debug versions side by side? That'll let me see if they're now both working, or if the older version is still broken. And if the older version is still broken, then I'll have to bring in another set of eyes because clearly I'm missing something.

debug2.js is in place services.ini is updated as well. My firewall is looking like swiss cheese, but I am glad I can contribute to improving things.

---
ï¿­ Synchronet ï¿­ Tucumcari BBS
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

debug2.js is in place services.ini is updated as well. My firewall is looking like swiss cheese, but I am glad I can contribute to improving things.

lol, yeah it's a lot of open ports now! The second debug version isn't needed anymore, so you can remove websocketservice-debug2.js and the services.ini entries for ports 1125 and 11255.

Then with echicken's help I think the cause has been determined, so I have a new version for you to test that can be saved over websocketservice-debug.js:

https://tinyurl.com/3ucpcuj8

And thanks for all the help testing this issue. Looks like this may be specific to raspi/banana pi installs, so it'll help any other sysops running on those devices once we have a working fix.

---
ï¿­ Synchronet ï¿­ fTelnet Demo Server - ftelnet.synchro.net
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

lol, yeah it's a lot of open ports now! The second debug version isn't needed anymore, so you can remove websocketservice-debug2.js and the services.ini entries for ports 1125 and 11255.

Then with echicken's help I think the cause has been determined, so I have a new version for you to test that can be saved over websocketservice-debug.js:

https://tinyurl.com/3ucpcuj8

And thanks for all the help testing this issue. Looks like this may be specific to raspi/banana pi installs, so it'll help any other sysops running on those devices once we have a working fix.

I have made the changes as above. Let me know how it goes!

---
ï¿­ Synchronet ï¿­ Tucumcari BBS
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

I have made the changes as above. Let me know how it goes!

Still no joy. Here's another version of websocketservice-debug.js that unmasks the data in multiple steps, so hopefully this'll work. If not, it'll log an error on the server side pinpointing exactly where the unmasking is failing.

https://tinyurl.com/yc2c86ys

---
ï¿­ Synchronet ï¿­ fTelnet Demo Server - ftelnet.synchro.net
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Ignore my previous message -- I was able to get a virtual raspi working with qemu, and the version I linked to in the previous message still doesn't work.

But after a bunch more trial-and-error, I think I finally have a fixed version. It works on the virtual instance, hopefully it works on real hardware too!

https://tinyurl.com/2xmvr447

---
ï¿­ Synchronet ï¿­ fTelnet Demo Server - ftelnet.synchro.net
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Ignore my previous message -- I was able to get a virtual raspi working with qemu, and the version I linked to in the previous message still doesn't work.

But after a bunch more trial-and-error, I think I finally have a fixed version. It works on the virtual instance, hopefully it works on real hardware too!

Behold! I put your new websocketservice.js in place (not on the debug port, but the standard port) and it seems to be working well! This is fantastic!

---
ï¿­ Synchronet ï¿­ Tucumcari BBS
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Behold! I put your new websocketservice.js in place (not on the debug port, but the standard port) and it seems to be working well! This is fantastic!

Awesome, glad that finally did the trick! I'm still doing a bit of investigating to see if I can find a better option, because this is more of a workaround than a fix, and the bug we're working around here could crop up elsewhere and need another workaround, so a proper fix would be best. I'll let you know if I have something more to test later, if that's OK with you.

And thanks again for your help testing.

---
ï¿­ Synchronet ï¿­ fTelnet Demo Server - ftelnet.synchro.net
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)