Hi

I'm having an issue with fTelnet / websockify and sbbs together. Synchronet sends a TELNET_SEND_LOCATION request upon answering, ftelnet sends a response, but synchronet doesn't seem to get that response in the correct manner. IE I get the IP address printed in my login field.

I put sbbs in debugging log mode, and tried syncterm, freebsd telnet and tera term, and none of them seemed to send a SEND_LOCATION response.

I've worked around it by commenting out the TELNET_SEND_LOCATION request in answer.cpp.

I've tried both websockify and ftelnetproxy between synchronet and ftelnet, but both do the same thing.

I need to use websockify as I can't figure out how to turn my letsencrypt cert into something I can use with the synchronet websocketsomething.js

Andrew

---
þ Synchronet þ Nocturnal - nocturnal.hopto.org:2023

Re: fTelnet, websockify and SBBS
By: Apam to All on Sat Aug 03 2019 08:59 pm

I'm having an issue with fTelnet / websockify and sbbs together. Synchronet sends a TELNET_SEND_LOCATION request upon answering, ftelnet sends a response, but synchronet doesn't seem to get that response in the correct manner. IE I get the IP address printed in my login field.

Sorry, I'm now not sure what's causing it. My work around worked once for some reason, but now it's gone back to putting the ip address in the login field.


I'm stumped.

Andrew

---
þ Synchronet þ Nocturnal - nocturnal.hopto.org:2023

Re: fTelnet, websockify and SBBS
By: Apam to All on Sat Aug 03 2019 08:59 pm

Hi

I'm having an issue with fTelnet / websockify and sbbs together. Synchronet sends a TELNET_SEND_LOCATION request upon answering, ftelnet sends a
response,
but synchronet doesn't seem to get that response in the correct manner. IE I get the IP address printed in my login field.

I put sbbs in debugging log mode, and tried syncterm, freebsd telnet and tera term, and none of them seemed to send a SEND_LOCATION response.

I'll see if I can find a supporting client to test with.

I've worked around it by commenting out the TELNET_SEND_LOCATION request in answer.cpp.

That seems like the simpliest solution. Synchronet doesn't really need/use the telnet location for anything (just logging).

digital man

This Is Spinal Tap quote #31:
Viv Savage: Quite exciting, this computer magic!
Norco, CA WX: 93.0øF, 27.0% humidity, 7 mph E wind, 0.00 inches rain/24hrs

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

Re: fTelnet, websockify and SBBS
By: Digital Man to Apam on Sat Aug 03 2019 01:51 pm

Re: fTelnet, websockify and SBBS
By: Apam to All on Sat Aug 03 2019 08:59 pm

Hi

I'm having an issue with fTelnet / websockify and sbbs together. Synchronet sends a TELNET_SEND_LOCATION request upon answering, ftelnet sends a response,
but synchronet doesn't seem to get that response in the correct manner. IE I get the IP address printed in my login field.

I put sbbs in debugging log mode, and tried syncterm, freebsd telnet and tera term, and none of them seemed to send a SEND_LOCATION response.

I'll see if I can find a supporting client to test with.

I've worked around it by commenting out the TELNET_SEND_LOCATION request in answer.cpp.

That seems like the simpliest solution. Synchronet doesn't really need/use the telnet location for anything (just logging).

SEXPOTS uses the Telnet SEND_LOCATION sub-neg option to pass Caller-ID information (received from the modem) to the BBS. And that works.

I could add an option to disable the SEND_LOCATION *request* during answer, but completely disabling it doesn't really see like a good option. Fixing the client(s) - assuming that's where the problem with the option lies, would be better.

digital man

Synchronet "Real Fact" #17:
"Vertrauen" (ver-trow-en) translates to "trust" in German, and was a band name. Norco, CA WX: 93.6øF, 27.0% humidity, 6 mph E wind, 0.00 inches rain/24hrs

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

Re: fTelnet, websockify and SBBS
By: Digital Man to Apam on Sat Aug 03 2019 02:45 pm

I could add an option to disable the SEND_LOCATION *request* during answer, but completely disabling it doesn't really see like a good option. Fixing the client(s) - assuming that's where the problem with the option lies, would be better.

Yeah, I'm not sure what's going on, I re-enabled it, and sometimes it works sometimes it doesn't.

When it doesn't work, the debugging log lists that it received a telnet set location but the location is empty and turns up on the login prompt. When it does work, the logging lists the location.

I wondered if it's something like the response is sent over two packets occasionally and synchronet is expecting it all at once? I don't know, my assumption would be that synchronet can handle that situation.

It doesn't matter too much, I might try and set it up to use rlogin instead, otherwise people can press backspace a few times before entering their login name ;P

Andrew

---
þ Synchronet þ Nocturnal - nocturnal.hopto.org:2023

Re: fTelnet, websockify and SBBS
By: Apam to Digital Man on Sun Aug 04 2019 02:52 pm

Re: fTelnet, websockify and SBBS
By: Digital Man to Apam on Sat Aug 03 2019 02:45 pm

I could add an option to disable the SEND_LOCATION *request* during answer, but completely disabling it doesn't really see like a good option. Fixing the client(s) - assuming that's where the problem with the option lies, would be better.

Yeah, I'm not sure what's going on, I re-enabled it, and sometimes it works sometimes it doesn't.

When it doesn't work, the debugging log lists that it received a telnet set location but the location is empty and turns up on the login prompt. When it does work, the logging lists the location.

I wondered if it's something like the response is sent over two packets occasionally and synchronet is expecting it all at once? I don't know, my assumption would be that synchronet can handle that situation.

Yeah, it should work even if every byte were a separate packet.

It doesn't matter too much, I might try and set it up to use rlogin instead, otherwise people can press backspace a few times before entering their login name ;P

Since you don't need it, an option to disable the location request would be a good thing to have. In the mean-time, just commenting out that one line in answer.cpp should work fine for ya too.

digital man

This Is Spinal Tap quote #10:
Dozens of people spontaneously combust each year... just not widely reported. Norco, CA WX: 71.5øF, 64.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs

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

Re: fTelnet, websockify and SBBS
By: Apam to All on Sat Aug 03 2019 08:59 pm

Hey DM

I'm having an issue with fTelnet / websockify and sbbs together. Synchronet sends a TELNET_SEND_LOCATION request upon answering, ftelnet sends a response, but synchronet doesn't seem to get that response in the correct manner. IE I get the IP address printed in my login field.

Not sure if this is related, but I've noticed an odd issue with SyncTerm.

I have SyncTerm on my MAC set to 80x50.

Sometimes when I connect, SBBS detects me as 80x25 - if I disconnect and reconnect (ie: no changes anywhere), the second time it will detect me as 80x50.

So, when it thinks I'm 80x25, my pause prompt is half way up the screen.

Its almost like it is remembering my "last" session (cause sometimes I do connect from my laptop configured for 80x25).

...ëîå*

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: fTelnet, websockify and SBBS
By: Alterego to Digital Man on Mon Aug 05 2019 11:42 am

Re: fTelnet, websockify and SBBS
By: Apam to All on Sat Aug 03 2019 08:59 pm

Hey DM

I'm having an issue with fTelnet / websockify and sbbs together. Synchronet sends a TELNET_SEND_LOCATION request upon answering, ftelnet sends a response, but synchronet doesn't seem to get that response in the correct manner. IE I get the IP address printed in my login field.

Not sure if this is related, but I've noticed an odd issue with SyncTerm.

I have SyncTerm on my MAC set to 80x50.

Sometimes when I connect, SBBS detects me as 80x25 - if I disconnect and reconnect (ie: no changes anywhere), the second time it will detect me as 80x50.

So, when it thinks I'm 80x25, my pause prompt is half way up the screen.

Its almost like it is remembering my "last" session (cause sometimes I do connect from my laptop configured for 80x25).

When is the last time you updated from CVS and rebuilt?

digital man

This Is Spinal Tap quote #16:
David St. Hubbins: I believe virtually everything I read...
Norco, CA WX: 76.2øF, 60.0% humidity, 4 mph ESE wind, 0.00 inches rain/24hrs

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

Re: fTelnet, websockify and SBBS
By: Digital Man to Apam on Sun Aug 04 2019 12:37 am

Since you don't need it, an option to disable the location request would be a good thing to have. In the mean-time, just commenting out that one line in answer.cpp should work fine for ya too.

I commented out that one line, and it still does it.. so looking through the ftelnet code I see that on connection it sends will send location and will send terminal location number. So I think those lines are going to have to go too.

So, yeah an option to disable the location request won't completely solve the problem with ftelnet.

The thing that confuses me, is why it works for people using the synchronet websocketservice.js and not with websockify (or ftelnetproxy).

Thanks for the help with this :) I'll report back later if my modified ftelnet works (it should I think, seems no one will be requesting locations :P)

Andrew

---
þ Synchronet þ Nocturnal - nocturnal.hopto.org:2023

Re: fTelnet, websockify and SBBS
By: Digital Man to Alterego on Sun Aug 04 2019 09:00 pm

When is the last time you updated from CVS and rebuilt?

10 days ago...

...ëîå*

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: fTelnet, websockify and SBBS
By: Alterego to Digital Man on Mon Aug 05 2019 06:34 pm

Re: fTelnet, websockify and SBBS
By: Digital Man to Alterego on Sun Aug 04 2019 09:00 pm

When is the last time you updated from CVS and rebuilt?

10 days ago...

Okay, I asked because I saw that same regression recently but I thought it was fixed.

digital man

Synchronet "Real Fact" #52:
Answers to Frequently Asked Questions: http://wiki.synchro.net/faq:index
Norco, CA WX: 67.4øF, 75.0% humidity, 0 mph S wind, 0.00 inches rain/24hrs

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

Re: fTelnet, websockify and SBBS
By: Apam to Digital Man on Mon Aug 05 2019 02:41 pm

Thanks for the help with this :) I'll report back later if my modified ftelnet works (it should I think, seems no one will be requesting locations :P)

Just letting you know, I removed the on connection WILL SEND LOCATION from ftelnet, it works now. Also, uncommented the line from answer.cpp and it still works.

Have no idea really why it wasn't working, but happy it works :)

Thanks,
Andrew

---
þ Synchronet þ Nocturnal - nocturnal.hopto.org:2023

I wondered if it's something like the response is sent over two packets occasionally and synchronet is expecting it all at once? I don't know, my assumption would be that synchronet can handle that situation.

Yeah, it should work even if every byte were a separate packet.

Hey Rob, actually it looks like this might be related.

I fired up Wireshark and after a couple dozen reconnect attempts I finally saw the behaviour Andrew described, and the only difference on that attempt was that the SendLocation subnegotiation was sent in two packets (0xff, 0xfa, 0x17 in the first packet, the rest in the second packet).

To test further I created a page with 3 buttons to have one simulate the 1-packet scenario, and the other two simulate the 2-packet scenario. They have a 100% success rate in working (1-packet) or not working (2-packet).

1-packet logs this in sbbsctrl: "received telnet location: 99.98.97.96", whereas 2-packet logs this: "received telnet location: " and "99.98.97.96" gets stuffed into the login prompt.

For one final test I modified the 2-packet scenario to send 0xff, 0xfa, 0x17, 0x39, 0x39, 0x2e in the first packet, and the rest in the second packet. This results in sbbsctrl logging "received telnet location: 99." and only "98.97.96" gets stuffed into the login prompt.

Hope that helps narrow things down.

Thanks,
Rick

---
þ Synchronet þ Rick's Dev Server

Re: Re: fTelnet, websockify and SBBS
By: Ree to Digital Man on Sat Aug 31 2019 10:29 pm

I wondered if it's something like the response is sent over two packets occasionally and synchronet is expecting it all at once? I don't know, my assumption would be that synchronet can handle that situation.

Yeah, it should work even if every byte were a separate packet.

Hey Rob, actually it looks like this might be related.

I fired up Wireshark and after a couple dozen reconnect attempts I finally saw the behaviour Andrew described, and the only difference on that attempt was that the SendLocation subnegotiation was sent in two packets (0xff, 0xfa, 0x17 in the first packet, the rest in the second packet).

What exactly was the "rest"?

Synchronet (even v3.16c, the version it appears you're running) only parses a Telnet sub-negotiation message once it receives the final IAC/SE pair (0xff, 0xf0). Is it possible that the websocket proxy or ftelnet is sending a premature SE sequence?

To test further I created a page with 3 buttons to have one simulate the 1-packet scenario, and the other two simulate the 2-packet scenario. They have a 100% success rate in working (1-packet) or not working (2-packet).

1-packet logs this in sbbsctrl: "received telnet location: 99.98.97.96", whereas 2-packet logs this: "received telnet location: " and "99.98.97.96" gets stuffed into the login prompt.

For one final test I modified the 2-packet scenario to send 0xff, 0xfa, 0x17, 0x39, 0x39, 0x2e in the first packet, and the rest in the second packet. This results in sbbsctrl logging "received telnet location: 99." and only "98.97.96" gets stuffed into the login prompt.

Hope that helps narrow things down.

It's great we have a 100% repro scenario. I'll see if I can trigger it with netcat or something, but looking at the code, I don't see how it could try to parse an incomplete Telnet sub-neg message.

If you update to the lastest dev code and enable Telnet debugging (add DEBUG_TELNET to the Options: value of the [bbs] section of your ctrl/sbbs.ini file), it should also log the *length* (in bytes) of every received sub-neg command. If you can reproduce with that log output and paste here, *that* could be helpful. Also, a complete hex dump of the payload of each packet would help.
Thanks for your help!

digital man

This Is Spinal Tap quote #38:
Artie Fufkin: I'm not asking, I'm telling with this. Kick my ass.
Norco, CA WX: 79.5øF, 61.0% humidity, 7 mph E wind, 0.00 inches rain/24hrs

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

What exactly was the "rest"?

My IP followed by IAC SE

Synchronet (even v3.16c, the version it appears you're running) only parses a Telnet sub-negotiation message once it receives the final IAC/SE pair (0xff, 0xf0). Is it possible that the websocket proxy or ftelnet is sending a premature SE sequence?

I was testing locally with 3.17b, and yes my first thought was it was proxy related, but it's happening with multiple proxy packages.

It definitely looks like Synchronet doesn't parse the message until after it gets the final IAC+SE, because when I click "send packet 1" sbbsctrl doesn't update at all, but then when I click the "send packet 2" button it updates with the messages provided below.

If you update to the lastest dev code and enable Telnet debugging (add DEBUG_TELNET to the Options: value of the [bbs] section of your ctrl/sbbs.ini file), it should also log the *length* (in bytes) of every received sub-neg command. If you can reproduce with that log output and paste here, *that* could be helpful. Also, a complete hex dump of the payload of each packet would help.

1-packet scenario:
Wireshark:
0000 ff fa 17 31 2e 32 2e 33 2e 34 ff f0
sbbsctrl:
Node 1 received telnet sub-negotiation command: Send Location (12 bytes)
Node 1 received telnet location: 1.2.3.4

2-packet scenario (1/2):
Wireshark:
0000 ff fa 17 31 2e
sbbsctrl:
No change in display

2-packet scenario (2/2):
Wireshark:
0000 32 2e 33 2e 34 ff f0
sbbsctrl:
Node 1 received telnet sub-negotiation command: Send Location (7 bytes)
Node 1 received telnet location: 1.
Login prompt:
Enter User Name or Number or 'New'
Login: 2.3.4

Doesn't seem to matter if I click the 2-packet buttons in quick succession or with a several second delay between them, same result either way. Here's the relevant functions just to double-check that the tests are setup correctly:

function SendLocationFull() {
Client.Connection.Send([0xff , 0xfa , 0x17 , 0x31 , 0x2e , 0x32 , 0x2e , 0x33 , 0x2e , 0x34 , 0xff , 0xf0]);
}

function SendLocation1() {
Client.Connection.Send([0xff , 0xfa , 0x17 , 0x31 , 0x2e]);
}

function SendLocation2() {
Client.Connection.Send([0x32 , 0x2e , 0x33 , 0x2e , 0x34 , 0xff , 0xf0]);
}

Thanks for your help!

No problem. I'm off for the night and will be out all day tomorrow, but I'll check in again Monday in case you need me to test anything else.

Rick

---
þ Synchronet þ Rick's Dev Server

Re: Re: fTelnet, websockify and SBBS
By: Ree to Digital Man on Sun Sep 01 2019 12:41 am

What exactly was the "rest"?

My IP followed by IAC SE

Synchronet (even v3.16c, the version it appears you're running) only parses a Telnet sub-negotiation message once it receives the final IAC/SE pair (0xff, 0xf0). Is it possible that the websocket proxy or ftelnet is sending a premature SE sequence?

I was testing locally with 3.17b, and yes my first thought was it was proxy related, but it's happening with multiple proxy packages.

It definitely looks like Synchronet doesn't parse the message until after it gets the final IAC+SE, because when I click "send packet 1" sbbsctrl doesn't update at all, but then when I click the "send packet 2" button it updates with the messages provided below.

If you update to the lastest dev code and enable Telnet debugging (add DEBUG_TELNET to the Options: value of the [bbs] section of your ctrl/sbbs.ini file), it should also log the *length* (in bytes) of every received sub-neg command. If you can reproduce with that log output and paste here, *that* could be helpful. Also, a complete hex dump of the payload of each packet would help.

1-packet scenario:
Wireshark:
0000 ff fa 17 31 2e 32 2e 33 2e 34 ff f0
sbbsctrl:
Node 1 received telnet sub-negotiation command: Send Location (12 bytes)
Node 1 received telnet location: 1.2.3.4

2-packet scenario (1/2):
Wireshark:
0000 ff fa 17 31 2e
sbbsctrl:
No change in display

2-packet scenario (2/2):
Wireshark:
0000 32 2e 33 2e 34 ff f0
sbbsctrl:
Node 1 received telnet sub-negotiation command: Send Location (7 bytes)
Node 1 received telnet location: 1.
Login prompt:
Enter User Name or Number or 'New'
Login: 2.3.4

Doesn't seem to matter if I click the 2-packet buttons in quick succession or with a several second delay between them, same result either way. Here's the relevant functions just to double-check that the tests are setup correctly:

function SendLocationFull() {
Client.Connection.Send([0xff , 0xfa , 0x17 , 0x31 , 0x2e , 0x32 , 0x2e , 0x33 , 0x2e , 0x34 , 0xff , 0xf0]);
}

function SendLocation1() {
Client.Connection.Send([0xff , 0xfa , 0x17 , 0x31 , 0x2e]);
}

function SendLocation2() {
Client.Connection.Send([0x32 , 0x2e , 0x33 , 0x2e , 0x34 , 0xff , 0xf0]); }

Thanks for your help!

No problem. I'm off for the night and will be out all day tomorrow, but I'll check in again Monday in case you need me to test anything else.

Thanks for the detailed info. I see where the received telnet command buffer length is being reset if the SE is not found when expected. Testing a fix now.

digital man

This Is Spinal Tap quote #27:
As long as there's, y'know, sex and drugs, I can do without the rock and roll. Norco, CA WX: 73.9øF, 68.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs

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

Thanks for the detailed info. I see where the received telnet command buffer length is being reset if the SE is not found when expected. Testing a fix now.

Just updated to the latest sbbs_dev binaries, and both the 1- and 2-packet scenarios are reporting the same thing now:

Node 1 received telnet sub-negotiation command: Send Location (12 bytes)
Node 1 received telnet location: 1.2.3.4

So looks like the fix did the trick.

---
þ Synchronet þ Rick's Dev Server

Re: Re: fTelnet, websockify and SBBS
By: Ree to Digital Man on Mon Sep 02 2019 06:17 pm

Thanks for the detailed info. I see where the received telnet command buffer length is being reset if the SE is not found when expected. Testing a fix now.

Just updated to the latest sbbs_dev binaries, and both the 1- and 2-packet scenarios are reporting the same thing now:

Node 1 received telnet sub-negotiation command: Send Location (12 bytes) Node 1 received telnet location: 1.2.3.4

So looks like the fix did the trick.

Cool. Thanks for the feedback and the detailed testing.

While I have you, you want to try some YMODEM-G transfers with fTelnet (e.g. with Vertrauen)?

I've made some changes lately to how all Telnet/RLogin data goes to/from external socket-IO programs (e.g. sexyz) and while testing with SyncTERM, all the issues seem resolved, but I never got reliable uploads and downloads working with fTelnet. I'm not sure when/how that got broke. :-(

digital man

Synchronet/BBS Terminology Definition #77:
TTY = Teletype (dumb terminal)
Norco, CA WX: 80.8øF, 50.0% humidity, 9 mph ESE wind, 0.00 inches rain/24hrs

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