Latest system update kills "--listen"

[Michael_Jinks]

Today I updated the OS on a Linux machine running several cases of “tiddlywiki […] --listen”. It now fails, in an odd way:

The instances of the tiddlywiki script do run, they appear to be waiting for input, but their log suggests IPv6 instead of IPv4.

nginx hasn’t been changed. When we connect from a browser, we get the “bad gateway” message. The nginx log shows that traffic is being passed along, as expected, but failing.

Where the tiddlywiki instance runs, its output has changed. Currently we see, for example:

Serving on http://::1:8083
(press ctrl-C to exit)

…but that “::1:” part is new; what I expect was something like:

Serving on http://127.0.0.1:8083

That makes me think that something, somewhere, is switching from using IPv4 to IPv6, and that’s why traffic is being dropped. It seems like the “something”, here, is on the back end of the tiddlywiki script; some underpinning of NodeJS I’m guessing, but I’m stumped.

For what it’s worth: reading “tiddlywiki --help listen”, I thought I might be able to tweak the script somehow to deal with this, but any change I’ve tried for the “port=” or “host=” options has only caused the script to fall back to listening under “:8080”. I don’t find any way to force the switch to IPv6.

Any hints?

Thanks.

[pmario]

@Michael_Jinks

It seems like the “something”, here, is on the back end of the tiddlywiki script; some underpinning of NodeJS I’m guessing, but I’m stumped.

If you didn’t change the TW source code, why should it change the behaviour after an OS update?

Which version of Node.js do you use node --version ?
Same thing with tiddlywiki --version ?

I’m pretty sure something happened on the OS side of things. …

Which OS do you use?

[jeremyruston]

@Michael_Jinks

Where the tiddlywiki instance runs, its output has changed. Currently we see, for example:

Interesting – I saw this happen when I was experimenting with running TiddlyWiki under GitHub Codespaces, one of the new breed of cloud development environments accessible in the browser (see GitHub Codespaces · GitHub). I didn’t have a chance to investigate but it seems possible that the issue occurs on systems configured to use IPv6.

[Michael_Jinks]

Re-reading what I wrote, I should clarify:

@Michael_Jinks

nginx hasn’t been changed.

I should have said: I haven’t changed anything in the nginx configs, but that process itself is updating, and my only guess right now is that this is being caused by something (a library, or an OS process of some kind, or…). What I can’t find is where the change is really taking place.

nginx is being updated here, from 1.20.1 to 1.21.6, but when I roll that back, 1.21.6 to 1.20.1, the problem doesn’t go away.

@pmario

If you didn’t change the TW source code, why should it change the behaviour after an OS update?

It depends on the OS to run, and something in the output that it’s getting indicates that it’s getting back a change in that.

“tiddlywiki”, here at least, is a call to “/usr/bin/env node”, so I’m guessing that the change is happening somewhere within node.js, but I don’t know it well enough to track that down.

@pmario

Which OS do you use?

Gentoo.

The version of node.js is switching as:

before:

$ node --version
v16.14.2

after:

$ node --version
v18.3.0

…so, as far as I can tell, the real change is happening either in the call to node.js, or somewhere further down the chain, but I don’t know node.js well enough to track that down.

As I write this I’m installing the previous version of that.

[Michael_Jinks]

oh and:

@pmario

Same thing with tiddlywiki --version ?

$ tiddlywiki --version
5.2.1

…both before and after the Issue.

[Michael_Jinks]

Yep: going back to Node.JS version 14.19.3 fixed the problem.

So, apparently, it’s caused by a change there. I’m guessing that there’s a switch to call in the later version.

[Michael_Jinks]

Just to verify, here’s a demo of the issue, nothing new here.

Trouble:

mjinks@lm0:~$ bin/tiddlywiki-lazydm.sh
syncer-server-filesystem: Dispatching ‘save’ task: $:/StoryList
Serving on http://::1:8087
(press ctrl-C to exit)

…then, after the NodeJS package is downgraded:

mjinks@lm0:~$ bin/tiddlywiki-lazydm.sh
syncer-server-filesystem: Dispatching ‘save’ task: $:/StoryList
Serving on http://127.0.0.1:8087
(press ctrl-C to exit)

So, like I said, it’s somewhere between the OS call and the state of the system at run time.

[Michael_Jinks]

Latest here: regardless of the node.js version I call, “node --help” gives:

–dns-result-order=… set default value of verbatim in
dns.lookup. Options are ‘ipv4first’
(IPv4 addresses are placed before IPv6
addresses) ‘verbatim’ (addresses are in
the order the DNS resolver returned)

That suggests the trouble is being caused by a call from the OS during runtime, but the problem switches ONLY with the version of this library. So, I’m guessing, we change NodeOS from one default to the other when the version switches. What to do about that now during runtime, I’m still searching.

[buggyj]

This post says that node, in version 17, switch to choosing ipv6 over ipv4 as a default

r/ipv6 - Node.js finally prefers IPv6 addresses over IPv4 in its latest release

[Michael_Jinks]

Yep. So, to switch back to IPv4 at call time the call to node should include “–dns-result-order=ipv4first”.

My question then is, how should tiddlywiki be adjusted for that? I tried (hey, why not) just changing my script:

tiddlywiki [name] --listen [other stuff] dns-result-order=ipv4first

…thinking, maybe, when ‘tiddlywiki’ sees an option it doesn’t recognize, maybe it’d pass that along…? No dice.

Calling (hey why not) “–dns-result-order…” at the OS level doesn’t have any effect either; in both cases it just gets ignored and doesn’t have any effect.

[Michael_Jinks]

…or: instead of trying to force back to IPv4, is there a way to call the tiddlywiki script to use an IPv6 address? I am pretty IPv6-vague, so basic doc pointers would be great.

[pmario]

@Michael_Jinks

So, apparently, it’s caused by a change there. I’m guessing that there’s a switch to call in the later version.

hmmm, That’s strange, but good to know. … I use LTS 16.x at the moment with windows. → no problems

[pmario]

hmm. I think not many TW users understand http://::1:8090 … or even worse witha real IPv6 address
-m

[Michael_Jinks]

@pmario

I use LTS 16.x at the moment with windows. → no problems

What’s LTS? If that’s a reference to Node.JS, or some part of it, then this would be no surprise. I read (above) that the IPv[46] switch happened in Node.JS at version 17.

[Michael_Jinks]

@pmario

I think not many TW users understand http://::1:8090

That call from the shell has failed for me. I’ve tried a few adjustments from that, but decided that I don’t know the proper syntax, for the “host=” or “port=” part, or something.

[Michael_Jinks]

@Michael_Jinks

That call from the shell has failed for me. I’ve tried a few adjustments from that, but decided that I don’t know the proper syntax, for the “host=” or “port=” part, or something.

Well, hang on… I tried to adjust calls to ‘tiddlywiki’ from the shell script – and got those calls wrong, as I say here – but I hadn’t gotten around to the point of adjusting the web server’s syntax.

Might this be as simple as changing:…

  proxy_pass http://192.168.0.1:8092

…to:

  proxy_pass http://::1::8092 

…? I think I’d still need to adjust the tiddlywiki shell script, right?

Or, since that script is already (by “mistake”) calling an IPv6 setting, is the “port=” setting already good enough, if the web server does the change?

[digitalap3]

@buggyj

https://www.reddit.com/r/ipv6/comments/qbr8jc/nodejs_finally_prefers_ipv6_addresses_over_ipv4/

beggars can’t be choosers but breaking changes like this such a major piece of software kinds sucks.

@Michael_Jinks

Might this be as simple as changing:…

It seem like nginx won’t really care since it’s just a proxy so this seems best and easiest but it breaks things of you’re connecting directly to the server which kinda sucks.

But I guess it’s time I learned more about configuring domains for Ipv6…

[TW_Tones]

This is possibly not the issue but do just check what is available on the computer, if there is no IPV5 being bound on the NIC the new version of node may only provide IPv6.

So thoughts;

Are you invoking TiddlyWiki with the listen IP Address and port? That would be wise rather than relying on the default response which is giving you IPv6 “only”, and the default you reply on has changed with Node release’s.

• Can you navigate to http://::1:8083 which is just IPV6 localhost after all “::1” is localhost ?
• Try the IP address 0.0.0.0 to bind to the LAN IP Address
• Make sure you provide the port if its non-standard.
• If you only want access via local host there is no harm using IPv6 in the host, even if there is no IPv6 on the LAN.

[Edited] The IPv6 equivalent of IPv4’s 0.0. 0.0 is ::/0 .

[Michael_Jinks]

So, on my server:

$ ping ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.038 ms

That’s expected, good to confirm.

But on nginx, if I change…

proxy_pass http://127.0.0.1:8083/;

…to:

proxy_pass http://::1:8083/;

…then I have:

$ sudo /etc/init.d/nginx restart

• Checking nginx’ configuration …
  nginx: [emerg] invalid port in upstream “::1:8083/” in /etc/nginx/nginx.conf:130
  nginx: configuration file /etc/nginx/nginx.conf test failed
  nginx: [emerg] invalid port in upstream “::1:8083/” in /etc/nginx/nginx.conf:130
  nginx: configuration file /etc/nginx/nginx.conf test failed
• failed, please correct errors above [ !! ]
• ERROR: nginx failed to stop

Obviously I’m cargo-culting here but I’m reading this as, no, nginx won’t just accept a switch from one format to the other.

Right? Am I writing the address incorrectly? IPv6 n00bs represent.

[Michael_Jinks]

Minor note: nginx here does, explicitly, support IPv6; I’m just misunderstanding the format for what should go in that config line.

Or something.

Reading.