I did a full dev update today, and now when someone tries fTelnet (not sure about other WS/WSS services) I get similar to this:
8/10 08:40:52p 1848 WS Error 1004 connecting to server at 0.0.0.0,:::23
Re: WS Error after Update
By: Mortifis to All on Sat Aug 10 2019 20:44:09
I did a full dev update today, and now when someone tries fTelnet (not sure about other WS/WSS services) I get similar to this:
8/10 08:40:52p 1848 WS Error 1004 connecting to server at 0.0.0.0,:::23
Something I'll try to fix tonight.
implement this, but, if someone were to connect via fTelnet on *any* web ui (stock or web*) could an ftelnet-socket.log be written to, or a
After updating the ftelnethelper.js from the cvs I was still getting an error, so for shits n giggles I copied the websocketservice.js from my 07-19-2019 backup and overwrote the one from 08-10-2019 and there are no longer any WS/WSS errors
Re: Re: WS Error after Update
By: Mortifis to echicken on Sun Aug 11 2019 14:48:27
After updating the ftelnethelper.js from the cvs I was still getting an error, so for shits n giggles I copied the websocketservice.js from my 07-19-2019 backup and overwrote the one from 08-10-2019 and there are no longer any WS/WSS errors
What was the error this time?
What do you have for "Interface" in the [Global] section of sbbs.ini?
What do you have for "TelnetInterface" and "RLoginInterface" in the [BBS] section of sbbs.ini?
Sorry for the breakage, but I'd really like to make this as automagic as possible. Getting websockets
and fTelnet configured is a massive source of confusion for many sysops and I'd be happier if they just
didn't need to think about it.
---
Interface=0.0.0.0,::
TelnetInterface=0.0.0.0,::
RLoginInterface=0.0.0.0,::
Was there an update to the websocketservice.js? ; reverting to the one I had on July 19th, but, keeping all of the other updates I did on Aug 10th, plus the ftelnethelper.js you submitted on the 11th, seemed to 'cure' the issue ...
Re: WS Error after Update
By: Mortifis to All on Sat Aug 10 2019 20:44:09
I did a full dev update today, and now when someone tries fTelnet (not sure about other WS/WSS services) I get similar to this:
8/10 08:40:52p 1848 WS Error 1004 connecting to server at 0.0.0.0,:::23
Something I'll try to fix tonight.
I just figured it was something I overlooked during the update; I appreciate the updates!
If I may put in a little request: I am not sure what is the best way to implement this, but, if someone were to connect via fTelnet on *any* web ui (stock or web*) could an ftelnet-socket.log be written to, or a js.object be added that stores the originating ip address type thing so that the hard-to-trace local re-addressing (127.0.0.1) or local-machine-name not update the user.computer; user.host_name; user.ip_address? a log file would suffice :-)
Re: Re: WS Error after Update
By: Mortifis to echicken on Sun Aug 11 2019 12:00 am
Re: WS Error after Update
By: Mortifis to All on Sat Aug 10 2019 20:44:09
I did a full dev update today, and now when someone tries fTelnet (not sure about other WS/WSS services) I get similar to this:
8/10 08:40:52p 1848 WS Error 1004 connecting to server at 0.0.0.0,:::23
Something I'll try to fix tonight.
I just figured it was something I overlooked during the update; I appreciate the updates!
If I may put in a little request: I am not sure what is the best way to implement this, but, if someone were to connect via fTelnet on *any* web ui (stock or web*) could an ftelnet-socket.log be written to, or a js.object be added that stores the originating ip address type thing so that the hard-to-trace local re-addressing (127.0.0.1) or local-machine-name not update the user.computer; user.host_name; user.ip_address? a log file would suffice :-)
I thought someone said fTelnet sends the IP address as the Telnet "location". If that's the case, then it would be stored in the Synchronet caller-ID string, which is available in JS via a call to bbs.atcode("CID").
digital man
Re: Re: WS Error after Update
By: Mortifis to echicken on Sun Aug 11 2019 19:16:26
Interface=0.0.0.0,::
TelnetInterface=0.0.0.0,::
RLoginInterface=0.0.0.0,::
Was there an update to the websocketservice.js? ; reverting to the one I had on July 19th, but, keeping all of the other updates I did on Aug 10th, plus the ftelnethelper.js you submitted on the 11th, seemed to 'cure' the issue ...
There are a few more changes I should make, but I would expect your settings (above) to work with the
current versions of both websocketservice.js and ftelnethelper.js.
Re: Re: WS Error after Update
By: Mortifis to echicken on Sun Aug 11 2019 12:00 am
Re: WS Error after Update
By: Mortifis to All on Sat Aug 10 2019 20:44:09
I did a full dev update today, and now when someone tries fTelnet (not sure about other WS/WSS services) I get similar to this:
8/10 08:40:52p 1848 WS Error 1004 connecting to server at 0.0.0.0,:::23
Something I'll try to fix tonight.
I just figured it was something I overlooked during the update; I appreciate the updates!
If I may put in a little request: I am not sure what is the best way to implement this, but, if someone were to connect via fTelnet on *any* web ui (stock or web*) could an ftelnet-socket.log be written to, or a js.object be added that stores the originating ip address type thing so that the hard-to-trace local re-addressing (127.0.0.1) or local-machine-name not update the user.computer; user.host_name; user.ip_address? a log file would suffice :-)
I thought someone said fTelnet sends the IP address as the Telnet "location". If that's the case, then it would be stored in the Synchronet caller-ID string, which is available in JS via a call to bbs.atcode("CID").
digital man
Yes, bbs.atcode("CID") has the same value as user.ip_address, which, when someone connect via fTelnet (I haven't checked other WS services,) both are using the 127.0.0.1 IP Address. It is not an issue, really, I was just curious if a js property could be added somewhere that stores the actual world readable IP address ... for instance if an http(s) connection is made to the web ui then a person connects to the board via ftelnet their ip address is passed as 127.0.0.1 and not say 24.138.28.115 (my IP address) then that ip address can be stored in user.ip_address and not the 127.0.0.1? perhaps the same for user.host_name/user.computer could store their actual values instead of the system.local_host_name which seems the current behavior
Re: Re: WS Error after Update
By: Mortifis to Digital Man on Mon Aug 12 2019 08:54 am
Re: Re: WS Error after Update
By: Mortifis to echicken on Sun Aug 11 2019 12:00 am
Re: WS Error after Update
By: Mortifis to All on Sat Aug 10 2019 20:44:09
I did a full dev update today, and now when someone tries fTelnet (not sure about other WS/WSS services) I get similar to this:
8/10 08:40:52p 1848 WS Error 1004 connecting to server at 0.0.0.0,:::23
Something I'll try to fix tonight.
I just figured it was something I overlooked during the update; I appreciate the updates!
If I may put in a little request: I am not sure what is the best way to implement this, but, if someone were to connect via fTelnet on *any* web ui (stock or web*) could an ftelnet-socket.log be written to, or a js.object be added that stores the originating ip address type thing so that the hard-to-trace local re-addressing (127.0.0.1) or local-machine-name not update the user.computer; user.host_name; user.ip_address? a log file would suffice :-)
I thought someone said fTelnet sends the IP address as the Telnet "location". If that's the case, then it would be stored in the Synchronet caller-ID string, which is available in JS via a call to bbs.atcode("CID").
digital man
Yes, bbs.atcode("CID") has the same value as user.ip_address, which, when someone connect via fTelnet (I haven't checked other WS services,) both are using the 127.0.0.1 IP Address. It is not an issue, really, I was just curious if a js property could be added somewhere that stores the actual world readable IP address ... for instance if an http(s) connection is made to the web ui then a person connects to the board via ftelnet their ip address is passed as 127.0.0.1 and not say 24.138.28.115 (my IP address) then that ip address can be stored in user.ip_address and not the 127.0.0.1? perhaps the same for user.host_name/user.computer could store their actual values instead of the system.local_host_name which seems the current behavior
I understand. What I heard was that fTelnet was using the TELNET "SEND LOCATION" command to pass the real IP address to the BBS. If you enable debug-level log output and the "DEBUG_TELNET" option in the [bbs] section of your sbbs.ini file, do you see evidence of fTelnet passing the "LOCATION" to the BBS?
I understand. What I heard was that fTelnet was using the TELNET "SEND LOCATION" command to pass the real IP address to the BBS. If you enable debug-level log output and the "DEBUG_TELNET" option in the [bbs] section of your sbbs.ini file, do you see evidence of fTelnet passing the "LOCATION" to the BBS?
Re: Re: WS Error after Update
By: Digital Man to Mortifis on Mon Aug 12 2019 11:30:15
I understand. What I heard was that fTelnet was using the TELNET "SEND LOCATION" command to pass the real IP address to the BBS. If you enable debug-level log output and the "DEBUG_TELNET" option in the [bbs] section of your sbbs.ini file, do you see evidence of fTelnet passing the "LOCATION" to the BBS?
A look at fTelnet's source suggests it'll send the IP address (as returned by myip.randm.ca) if the remote server says DO SEND-LOCATION or DO TTYLOC. (Confirmation that it's actually doing that would be good though.)
This is only helpful for telnet sessions of course. I wonder if we could repurpose the "speed" portion of "terminal-type/speed" of RLogin sessions for this. (As terminal-type is often repurposed for launching specific external programs.)
I understand. What I heard was that fTelnet was using the TELNET "SEND LOCATION" command to pass the real IP address to the BBS. If you enable debug-level log output and the "DEBUG_TELNET" option in the [bbs] section of your sbbs.ini file, do you see evidence of fTelnet passing the "LOCATION" to the BBS?
I noticed that some versions of fTelnet offer to send the Telnet "TERMINAL LOCATION NUMBER" (which contains the an IPv4 address) instead of the "SEND LOCATION" (a string). I just added support for Telnet TERMINAL LOCATION NUMBER (RFC 946), and it'll store that IPv4 address in the same place where bbs.atcode("CID") would represent it.
So... if your version of fTelnet is supporting TERMINAL LOCATION NUMBER instead of SEND LOCATION, that should now work as well.
Re: Re: WS Error after Update
By: Digital Man to Mortifis on Mon Aug 12 2019 11:30:15
I understand. What I heard was that fTelnet was using the TELNET "SEND LOCATION" command to pass the real IP address to the BBS. If you enable debug-level log output and the "DEBUG_TELNET" option in the [bbs] section of your sbbs.ini file, do you see evidence of fTelnet passing the "LOCATION" to the BBS?
A look at fTelnet's source suggests it'll send the IP address (as returned by myip.randm.ca) if the remote server says DO SEND-LOCATION or DO TTYLOC. (Confirmation that it's actually doing that would be good though.)
This is only helpful for telnet sessions of course. I wonder if we could repurpose the "speed" portion of "terminal-type/speed" of RLogin sessions for this. (As terminal-type is often repurposed for launching specific external programs.)
I find that fTelnet only *sometimes* sends the SEND-LOCATION or TERM-LOC-NUMBER commands:
8/12 11:45:33p Node 2 received telnet sub-negotiation command: Send Location (17 bytes)
8/12 11:45:33p Node 2 received telnet location: 71.95.196.34
8/12 11:45:34p Node 2 received telnet sub-negotiation command: Terminal Location Number (16 bytes)
8/12 11:45:34p Node 2 received telnet location number (IP address):
I find that fTelnet only *sometimes* sends the SEND-LOCATION or TERM-LOC-NUMBER commands:
8/12 11:45:33p Node 2 received telnet sub-negotiation command: Send Location (17 bytes)
8/12 11:45:33p Node 2 received telnet location: 71.95.196.34
8/12 11:45:34p Node 2 received telnet sub-negotiation command: Terminal Location Number (16 bytes)
8/12 11:45:34p Node 2 received telnet location number (IP address):
I also see a similar terminal console log: I used the Connect by Telnet link on my Web UI (currently using fTelnet that comes with the stock web interface/nightshade and custom css)
8/13 09:29:47a 2328 Telnet connection accepted from: 127.0.0.1 port 4358
8/13 09:29:47a 2328 Telnet Hostname: AlleyCat [127.0.0.1]
8/13 09:29:47a Node 1 socket 2328 attached to local interface 127.0.0.1 port 23
8/13 09:29:47a Node 1 09:29a Tue Aug 13 2019 Node 1
8/13 09:29:47a Node 1 Telnet AlleyCat [127.0.0.1]
8/13 09:29:48a Node 1 Telnet Location: 24.138.28.115 <----------------
8/13 09:29:48a Node 1 terminal type: 80x25 ansi-bbs
It is showing the world IP address Telnet Location: but when accessing user.ip_address; bbs.atcode["CID"]; or client.ip_address all values are 127.0.0.1
| Sysop: | Zazz |
|---|---|
| Location: | Mesquite, Tx |
| Users: | 7 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 78:09:43 |
| Calls: | 157 |
| Files: | 2,110 |
| Messages: | 145,577 |