• WS Error after Update

    From Mortifis@1:103/705 to All on Saturday, August 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

    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)
  • From echicken@1:103/705 to Mortifis on Saturday, August 10, 2019 21:38:45
    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)
  • From Mortifis@1:103/705 to echicken on Sunday, August 11, 2019 00:00:55
    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)
  • From echicken@1:103/705 to Mortifis on Sunday, August 11, 2019 00:44:40
    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)
  • From Mortifis@1:103/705 to echicken on Sunday, August 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


    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)
  • From echicken@1:103/705 to Mortifis on Sunday, August 11, 2019 15:03:34
    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)
  • From Mortifis@1:103/705 to echicken on Sunday, August 11, 2019 19:16:26
    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 :-) ... I 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)
  • From echicken@1:103/705 to Mortifis on Sunday, August 11, 2019 18:43:37
    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)
  • From Digital Man@1:103/705 to Mortifis on Sunday, August 11, 2019 21:54:37
    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.5F, 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)
  • From Mortifis@1:103/705 to Digital Man on Monday, August 12, 2019 08:54:02
    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)
  • From Mortifis@1:103/705 to echicken on Monday, August 12, 2019 08:57:19
    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)
  • From Digital Man@1:103/705 to Mortifis on Monday, August 12, 2019 11:30:15
    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.0F, 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)
  • From Digital Man@1:103/705 to Mortifis on Monday, August 12, 2019 12:09:02
    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.0F, 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)
  • From echicken@1:103/705 to Digital Man on Monday, August 12, 2019 15:29:32
    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)
  • From Digital Man@1:103/705 to echicken on Monday, August 12, 2019 12:50:17
    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.5F, 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)
  • From Mortifis@1:103/705 to Digital Man on Monday, August 12, 2019 21:08:40

    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)
  • From Digital Man@1:103/705 to echicken on Monday, August 12, 2019 23:50:55
    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.9F, 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)
  • From Mortifis@1:103/705 to Digital Man on Tuesday, August 13, 2019 09:46:03
    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)
  • From Digital Man@1:103/705 to Mortifis on Tuesday, August 13, 2019 13:23:56
    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.7F, 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)