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.
Hisends a TELNET_SEND_LOCATION request upon answering, ftelnet sends a
I'm having an issue with fTelnet / websockify and sbbs together. Synchronet
response,get the IP address printed in my login field.
but synchronet doesn't seem to get that response in the correct manner. IE I
I put sbbs in debugging log mode, and tried syncterm, freebsd telnet andtera 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 inanswer.cpp.
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).
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.
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
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.
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).
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.
When is the last time you updated from CVS and rebuilt?
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...
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)
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.
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.
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?
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!
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.
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.
| Sysop: | Zazz |
|---|---|
| Location: | Mesquite, Tx |
| Users: | 7 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 15:09:19 |
| Calls: | 157 |
| Files: | 2,103 |
| Messages: | 144,386 |