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)