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

Any ideas?



My doctor said I have the body of a 25 year old ... and the mind of a 10 :-/

---
þ Synchronet þ AlleyCat! BBS - http://alleycat.synchro.net:81
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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.

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

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 :-)




My doctor said I have the body of a 25 year old ... and the mind of a 10 :-/

---
þ Synchronet þ AlleyCat! BBS - http://alleycat.synchro.net:81
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Re: WS Error after Update
By: Mortifis to echicken on Sun Aug 11 2019 00:00:55

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

The "Services" server (under which websocketservice.js runs) already generates log output whenever a
client connects, including their IP address. Where this log output appears depends on how your system is
set up. Could be the console, syslog, Synchronet Control Panel, or Windows Event Viewer. In any case
there's *somewhere* you can look to see who's been connecting to your websocket server.

I'm not sure that I want to introduce parallel logging (and maintain a log file lest it grow
indefinitely).

Correlating logged connections between the WS and terminal server based on timestamp alone is
problematic. In reality maybe not such a problem, but several bots/users connecting within seconds of
each other is a thing that happens and could worsen depending on how many nodes you have.

Knowing the client's real IP address is an inherent problem with how this proxy service works. Depending
on your actual goal, we might be able to come up with a solution.

(I wouldn't use the address from which a user's last connection originated from as the basis for user
account deduplication, FWIW. I think maybe you mentioned this earlier.)

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

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


My doctor said I have the body of a 25 year old ... and the mind of a 10 :-/

---
þ Synchronet þ AlleyCat! BBS - http://alleycat.synchro.net:81
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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.

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

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?

This time it was Error 0 ... I don't have the exact console.log but I did post it in the Synchronet Programming C/C++ and CVS Forum


-----------------------------------------------------------------

What do you have for "Interface" in the [Global] section of sbbs.ini?

[Global]
; Override system address for this instance (optional):
Hostname=
; IP address of network interface to bind to (defaults to ANY/ALL interfaces):
Interface=0.0.0.0,:: -----------------------------------------------------------------

What do you have for "TelnetInterface" and "RLoginInterface" in the [BBS] section of sbbs.ini?

[BBS] Terminal Server
; Set to 'false' to disable Telnet/Rlogin/Event server:
AutoStart=true
; Set to IP address of network interface (or blank for default):
TelnetInterface=0.0.0.0,::
RLoginInterface=0.0.0.0,::
SSHInterface=0.0.0.0,::
; TCP port for Telnet server:
TelnetPort=23
; TCP port for RLogin server:
RLoginPort=513
; TCP port for Secure Shell (SSH) server:
SSHPort=22
; TCP port for 40-column PETSCII connections (any terminal protocol):
Pet40Port=64
; TCP port for 80-column PETSCII connections (any terminal protocol):
Pet80Port=128
; Note on PETSCII support: you must add the same port(s) to one of your
; *Interface= values above to open/listen/accept connections on that port.
; Example:
; TelnetInterface=71.95.196.34,71.95.196.34:64,71.95.196.34:128

; This server handles this range of BBS nodes:
; LastNode should not be higher than the number of nodes configured in SCFG->Nodes
FirstNode=1
LastNode=4

; Set to a non-zero number to limit the number of concurrent connections from the same client/host
MaxConcurrentConnections=0 -----------------------------------------------------------------

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.

---

No mworries, Brah, breakage sucks, but, it is part of the dev process :-) ... trust that everything is automagcially terrific for the most part, but, at the same time, SysOps need to keep getting their hands dirty; especially in a highly customizable environment as a BBS ... make us think about it; otherwise we might as all just bake Betty Crocker Cakes and call them home made :-P ...

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 ...


My doctor said I have the body of a 25 year old ... and the mind of a 10 :-/

---
þ Synchronet þ AlleyCat! BBS - http://alleycat.synchro.net:81
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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.

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

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

This Is Spinal Tap quote #11:
Nigel Tufnel: No. no. That's it, you've seen enough of that one.
Norco, CA WX: 69.5øF, 68.0% humidity, 1 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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





My doctor said I have the body of a 25 year old ... and the mind of a 10 :-/

---
þ Synchronet þ AlleyCat! BBS - http://alleycat.synchro.net:81
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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.

Yes, I updated both files and the issue has been resolved, thank you!


My doctor said I have the body of a 25 year old ... and the mind of a 10 :-/

---
þ Synchronet þ AlleyCat! BBS - http://alleycat.synchro.net:81
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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?

digital man

Synchronet/BBS Terminology Definition #16:
DCD = Data Carrier Detect
Norco, CA WX: 81.0øF, 55.0% humidity, 5 mph N wind, 0.00 inches rain/24hrs
--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Re: WS Error after Update
By: Digital Man to Mortifis on Mon Aug 12 2019 11:30 am

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 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.

digital man

Synchronet/BBS Terminology Definition #73:
TCP = Transmission Control Protocol
Norco, CA WX: 83.0øF, 46.0% humidity, 2 mph NNE wind, 0.00 inches rain/24hrs --- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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.)

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

Re: Re: WS Error after Update
By: echicken to Digital Man on Mon Aug 12 2019 03:29 pm

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.)

The full RLogin terminal string ("type/speed") is stored in the JS bbs.rlogin_terminal property. If fTelnet sent "something/ip-address", for the RLogin terminal string, you should be able to parse the IP address from that.

digital man

Synchronet "Real Fact" #72:
Synchronet CIOXTRN (created by Deuce) is a 32-bit replacement for DOORWAY. Norco, CA WX: 85.5øF, 45.0% humidity, 11 mph ENE wind, 0.00 inches rain/24hrs --- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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.

Ah, very nice, thank you!

My doctor said I have the body of a 25 year old ... and the mind of a 10 :-/

---
þ Synchronet þ AlleyCat! BBS - http://alleycat.synchro.net:81
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Re: WS Error after Update
By: echicken to Digital Man on Mon Aug 12 2019 03:29 pm

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): 71.95.196.34

This'll work for a while, and then stop working. Weird.


digital man

Synchronet/BBS Terminology Definition #9:
BSO = Binkley Style Outbound
Norco, CA WX: 65.9øF, 84.0% humidity, 2 mph SSE wind, 0.00 inches rain/24hrs --- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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




My doctor said I have the body of a 25 year old ... and the mind of a 10 :-/

---
þ Synchronet þ AlleyCat! BBS - http://alleycat.synchro.net:81
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Re: WS Error after Update
By: Mortifis to Digital Man on Tue Aug 13 2019 09:46 am

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

That should be fixed now with today's commit to CVS. Give it a go!

digital man

This Is Spinal Tap quote #18:
Sustain, listen to it. Don't hear anything. You would though were it playing. Norco, CA WX: 90.7øF, 40.0% humidity, 2 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)