Looking for some help - Connection with a Circle Mud

[dillera]

Trying this and it's not quite connecting to my circle mud. Enabling debug options seems to not do much. Any way I could get a little help on the config to make sure I have it correct? I'll paste what I have on my system.

https://i.imgur.com/agzXH3Z.png

[neverbot]

Hi! This project will only work in a system with certificates installed, I've added some info to the readme to clarify this. Tomorrow I'll try to find a good tutorial of how to install certificates in your sytem, so I can add another link to the readme.

Update your files, as I've edited a pair of things today, and let me know what do you see when you execute your sudo node wsproxy.js.

[dillera]

I installed certs, and it gets past that. It seems to just not be connecting to my telnet on port 4000...

[dillera]

Here is more info:

root@vcf-migration1:~/mud_2021/mud-web-proxy# node ./wsproxy.js
Mon Jun 21 2021 17:47:04 GMT+0000 (Coordinated Universal Time) []: (ws) server listening: port 6200

let srv = {
  path: __dirname,
  ws_port: 6200 /* this websocket proxy port */,
  tn_host: 'localhost' /* default telnet host */,
  tn_port: 4000 /* default telnet/target port */,
  debug: true /* enable additional debugging */,
  compress: true /* use node zlib (different from mccp) - you want this turned off unless your server can't do MCCP and your client can inflate data */,
  open: true /* set to false while server is shutting down */,

  ttype: {
    enabled: 1,
    portal: ['mud.diller.org', 'XTERM-256color', 'MTTS 141'],
  },

  gmcp: {
    enabled: 1,
    portal: ['client mud.diller.org', 'client_version 1.0'],
  },

symlinked to my https certs....

cert.pem -> /etc/letsencrypt/live/mud.diller.org/fullchain.pem
privkey.pem -> /etc/letsencrypt/live/mud.diller.org/privkey.pem

my web-client config:

# cat src/config.js
var Config = {
  debug: param('debug') || 1,
  host: param('host') || 'localhost',
  port: param('port') || '6200',
  name: param('name') || 'Circle 2021',
  profile: param('profile'),
  width: param('width') || 800,
  height: param('height') || j(window).height() - 80,
  top: param('top') || 0,
  left: param('left') || 0,
  clean: window.location.search.has('clean') || 0,
  solo: window.location.search.has('solo') || 0,
  nocenter: window.location.search.has('nocenter') || 0,
  notrack: param('notrack') || 0,
  nodrag: param('nodrag') || 0,
  embed: param('embed') || 0,
  kong: param('kong'),
  collapse: [],
  dev: window.location.search.has('dev') || 0,
  onfirst: param('onfirst') || 0,
  separator: window.location.search.has('separator')
    ? param('separator')
    : ';',

  proxy: 'wss://localhost:6200/',

  ...

[dillera]

I get the same output from your updated version.

Where is the proxy writing debug output? I can't find any!

[neverbot]

Checking with the one I have in maldorne.org (https://maldorne.org/en/play/?port=5010), the only differences I can see are:

• In both projects I have a dns as host, instead of localhost (I have muds.maldorne.org, same in the proxy field in the client: 'wss://play.maldorne.org:6200/'), although I don't think that could be relevant.
• In the client side:
  port: param('port') || '6200', is not 6200, is the port the proxy will redirect to (in your config I think it would be 4000). The 6200 is specified below, in the proxy field.

Try with that and let me know.

About the debug output, I won't be 100% sure about every feature in the original project (MUDPortal-Web-App) working here, I think in some error cases nothing is written, some more work would be useful, but it's working for now. If I run the proxy I can see some info even with debug set to false:

$ sudo /usr/bin/node /var/www/...something.../mud-web-proxy/wsproxy.js
(node:32707) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
Wed Jun 23 2021 00:54:36 GMT+0200 (Central European Summer Time) []: (ws) server listening: port 6200
Wed Jun 23 2021 00:54:46 GMT+0200 (Central European Summer Time) []: (ws) new connection
Wed Jun 23 2021 00:54:46 GMT+0200 (Central European Summer Time) []: (ws) connection count: 1
Wed Jun 23 2021 00:54:46 GMT+0200 (Central European Summer Time) ...some ip...: Target host set to muds.maldorne.org
Wed Jun 23 2021 00:54:46 GMT+0200 (Central European Summer Time) ...some ip...: Target port set to 5010
Wed Jun 23 2021 00:54:46 GMT+0200 (Central European Summer Time) []: new connection to muds.maldorne.org:5010 for undefined
Wed Jun 23 2021 00:54:46 GMT+0200 (Central European Summer Time) []: new telnet socket connected
Wed Jun 23 2021 00:54:46 GMT+0200 (Central European Summer Time) ...some ip...: IAC DO TTYPE <- IAC FIRST TTYPE
Wed Jun 23 2021 00:54:46 GMT+0200 (Central European Summer Time) []: maldorne.org
...
^C
Wed Jun 23 2021 01:01:47 GMT+0200 (Central European Summer Time) []: Got SIGINT.
Wed Jun 23 2021 01:01:47 GMT+0200 (Central European Summer Time) []: Dying gracefully in 3 sec.

[neverbot]

FYI: I did some more updates, now debug: true shows some binary data as it was intended.

[dillera]

Ok, thanks for the info. As for client and the proxy, isn't it that the client (index.html) connects to the proxy, not to the real telnet?

in that case, isn't port: param('port') || the proxy?

Why would the client need to have any idea of the actual telnet- I'm not arguing just wondering.

If I switch that to 4000 then it asks if the Mud is up (which it is: I can $ telnet localhost 4000 and connect right up to the circle mud....

Setting param'port' to 4000 results in the web ui:

Error: maybe the mud server is down?
Remote server has disconnected. Refresh page to reconnect.
WARNING: please connect first.

when you type something...

Circle mud is doing some wierd client detection when you connect, I wonder if that is doing something. I will test with a different mud server to be sure...

[dillera]

I have the mud logging, when I telnet in via localhost it logs:

# Jun 23 02:00:26 2021 :: New connection.  Waking up.

and so far I haven't gotten that to happen at all with the proxy and client. Trying some things, even tried 127.0.0.1. I keep trying and see if I can get it to work.

[dillera]

oh - sorry for all the comments, but just got something.

I changed

host: param('host') || 'mud.diller.org',

from localhost/127.0.0.1 to my hostname- and it connected!

But it now looks like the client detection that is going on by tbamud (circle) messes up the connection and it closes....

From the client index.html page --- I see the "Attempting to Detect Client," !!!!

Attempting to Detect Client, Please Wait...
Error: maybe the mud server is down?
Remote server has disconnected. Refresh page to reconnect.
WARNING: please connect first.

So perhaps it does require actual DNS hostnames?!?!

[neverbot]

in that case, isn't port: param('port') || the proxy?

Why would the client need to have any idea of the actual telnet- I'm not arguing just wondering.

I think it was made that way so with only one instance of the proxy you could handle connections to several muds (the original code was made to be used in mudportal, I think). The client gives the information about what port has to be used by the proxy to find the right mud.

Error: maybe the mud server is down?

I added that message some hours ago, it happens when the socket between proxy and mud receives an error... might happen when the proxy is not able to connect to the mud. If I turn the mud off I can force that message.

So perhaps it does require actual DNS hostnames?!?!

Mind blowing... but it's something! :)

Beyond that, I can't add much more about the negotiation with Circle, I've only used the proxy with MudOS and DGD. If you get it to work, please let me know!

[neverbot]

Closing the issue due to inactivity.

[dillera]

Yeah lack of this ever working for me, I just used FRP (on GH) as a forward proxy to push my mud onto a system on the internet.

[Shea690901]

I haven't tested anything myself, but just ab idea concerning your problem:

What is the CN in your certificate?
Is it your FQDN? If yes, then you most likely won't be able to connect unless you are using this FQDN and 'localhost' surely isn't your FQDN ;)

[neverbot]

Reopen the issue, just in case any other people with similar problems could find it easily.