Node.js - Node-RED v3.0.2 MQTT Configuration Windows Quirk

dceejay · 9 April 2023 21:48

It’s probably related to this change in nodejs behaviour from v17 onwards

"localhost" favours IPv6 in node v17, used to favour IPv4

opened 09:12PM - 20 Oct 21 UTC

closed 09:36PM - 20 Oct 21 UTC

### Version v17.0.0 ### Platform Darwin pink.local 20.6.0 Darwin Kernel Versi…on 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64 ### Subsystem _No response_ ### What steps will reproduce the bug? ```js var http = require('http') var server = http.createServer(function (req, res) { /* ... */ }) server.listen(3000, 'localhost', function (_err) { console.log('server listening: %s', server.address()) }) ``` I'm not sure what the underlying mechanism is, but it looks to me like the resolution of "localhost" for `server.listen(PORT, HOST, ...)` and for `http.request('http://localhost/...', ...)` changed from favouring IPv4 in node v16 and earlier, to favouring IPv6. The result is some possibly confusing breakages when using IPv4 values such as `127.0.0.1` and `0.0.0.0`. For example, the following script errors with node v17, but succeeds with node v16: ```js // example-localhost-means-which-ipv.js var http = require('http') var server = http.createServer(function (req, res) { req.on('data', function (chunk) { console.log('server req data: %s', chunk) }) req.on('end', function () { console.log('server req end') res.end('pong') }) }) // Listen on IPv4 address. var theHost = '127.0.0.1' server.listen(3000, theHost, function (_err) { console.log('server listening: %s', server.address()) // GET from localhost. var theUrl = 'http://localhost:3000/ping' console.log('client req: GET %s', theUrl) http.get(theUrl, function (res) { console.log('client res:', res.statusCode, res.headers) res.on('data', (chunk) => { console.log('client data: %s', chunk) }) res.on('end', () => { console.log('client end') server.close() }) }) }) ``` ``` % node --version v17.0.0 % node example-localhost-means-which-ipv.js server listening: { address: '127.0.0.1', family: 'IPv4', port: 3000 } client req: GET http://localhost:3000/ping node:events:368 throw er; // Unhandled 'error' event ^ Error: connect ECONNREFUSED ::1:3000 at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1161:16) Emitted 'error' event on ClientRequest instance at: at Socket.socketErrorListener (node:_http_client:447:9) at Socket.emit (node:events:390:28) at emitErrorNT (node:internal/streams/destroy:164:8) at emitErrorCloseNT (node:internal/streams/destroy:129:3) at processTicksAndRejections (node:internal/process/task_queues:83:21) { errno: -61, code: 'ECONNREFUSED', syscall: 'connect', address: '::1', port: 3000 } Node.js v17.0.0 % nvm use 16 Now using node v16.11.1 (npm v8.0.0) % node example-localhost-means-which-ipv.js server listening: { address: '127.0.0.1', family: 'IPv4', port: 3000 } client req: GET http://localhost:3000/ping server req end client res: 200 { date: 'Wed, 20 Oct 2021 21:01:56 GMT', connection: 'close', 'content-length': '4' } client data: pong client end ``` Similarly, if we reverse things to listen on `'localhost'` and GET from `'http://[::1]:3000/ping'` (IPv6), then it fails on node v16 and passes on node v17. As I said above, I don't know the mechanism for selecting IPv4 or IPv6. I suspect this isn't a "bug", except perhaps a lack of documentation? I don't see any mention of localhost of IPv6 in the changelog. Thanks. ### How often does it reproduce? Is there a required condition? Everytime. While I tested mostly on macOS, I believe I was seeing this in GitHub Action tests running on linux containers. ### What is the expected behavior? _No response_ ### What do you see instead? _No response_ ### Additional information _No response_

tree-frog · 10 April 2023 02:46

Mosquitto Broker. That version has not been updated either. At this time I would need to get the version number.

tree-frog · 10 April 2023 03:23

Why does the MQTT node need different syntax for the address and does not allow "localhost" ? That's the "op's" "oq".

Steve, Sorry for not answering your question about Mosquitto. I guess I just did not see it.
op = Original Post
oq = Original Question

TotallyInformation · 10 April 2023 10:15

What I was trying to say is that while localhost is certainly accepted as valid by the node, there are several factors as to why "localhost" the concept may have several different actual values depending on use, host file, DNS, DHCP and such settings. Doesn't really help you get an answer but helps understand the context.

Indeed, I think I left 0.0.0.0 off the list as well which may also be valid (representing all of the possible IPv4 addresses across all local interfaces).

If you wanted to, you could probably adjust C:\Windows\System32\drivers\etc\hosts to deal with the issue. Though Windows tells you that localhost resolution is handled by DNS. But on my desktop, I have 127.0.0.1 kubernetes.docker.internal as a line in my hosts file which was added by Docker Desktop for Windows.

Colin · 10 April 2023 10:36

@TotallyInformation, I believe the fundamental problem here is that the connection to mosquitto fails if ipv6 is used. Do you know whether the default mosquitto install on Windows prevents IPv6? Looking at the docs it appears that, to disable ipv6, the mosquitto conf file would have to contain socket_domain ipv4. If there is no socket_domain setting in the config file then mosquitto will listen on both.

@tree-frog how did you install mosquitto, and have you made any changes to the config files?

TotallyInformation · 10 April 2023 11:01

Honestly, I've not tried. I don't run Mosquitto on Windows because I only use it for work, development, entertainment, .... Like most people, I have a small server that runs ... well, servers.

Did you say how you have your listener configured in Mosquitto?

socket_domain [ ipv4 | ipv6 ]

By default, a listener will attempt to listen on all supported IP protocol versions. If you do not have an IPv4 or IPv6 interface you may wish to disable support for either of those protocol versions. In particular, note that due to the limitations of the websockets library, it will only ever attempt to open IPv6 sockets if IPv6 support is compiled in, and so will fail if IPv6 is not available.

Set to ipv4 to force the listener to only use IPv4, or set to ipv6 to force the listener to only use IPv6. If you want support for both IPv4 and IPv6, then do not use the socket_domain option.

Not reloaded on reload signal.

Note the comment about the websockets library. Not sure if that applies here. However, I note that the mosquitto log should say which interfaces were activated and will say whether the ip4/ip6 versions were used.

Colin · 10 April 2023 12:20

Sorry, I thought that you did run such things on Windows.

it isn't me that has the problem, I don't run windows at all (except for Fusion 360 in a VM). I am trying to understand why the OP has the problem, so that we will know the answer next time it comes up.

TotallyInformation · 10 April 2023 13:37

Not a problem. I have run Mosquitto and InfluxDB/Grafana on Windows but honestly, I think we can all agree that Windows is much better as a desktop OS than a server! I'm too used to the Windows way of doing things to be comfortable switching even though I do have both MacOS and Linux to hand if needed. Having started in the IBM world >40yrs ago and coming up through OS/2 and every version of LAN Manager and Windows, it is a hard habit to break.

But even so, I only use Windows for my daily-driver workstation and laptops. For servers, I use Linux and have done for many years. Debian is my server OS of choice.

Wasn't aimed at you, I probably selected the wrong previous post.

tree-frog · 12 April 2023 21:01

Colin,

It appears to me that this is in concert with Node.js, Mosquitto MQTT and Windows as it is configured as well. I "usually" have IPv6 disabled on these machines. But not always. I realize there are things at play on my settings and configuration side that I'll need to verify. Thank you very much for looking into this. I'll have more time next week to look at the details on my configuration on Mosquitto and then the IPv6 configuration on that Windows 10 PC.

I have a path forward at present to rename the localhost tag to 127.0.0.1 which is acceptable for now. Please note that this caused issues on upgrade and porting code which I did have to puzzle through how to get it working. I believe this should be understood and I will certainly assist you as much as possible and time permitting.

Kind Regards,

system · 26 April 2023 21:01

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
MQTT not connecting over LAN General	15	1901	22 June 2020
Verbindung zum mqtt Broker nicht möglich General mqtt	3	1593	17 December 2021
MQTT-In Not Connecting General	69	8412	7 November 2019
MQTT mosquitto connection problem General	13	974	9 August 2021
Two separate instances of MQTT and Node Red General	8	293	19 November 2022

Node.js - Node-RED v3.0.2 MQTT Configuration Windows Quirk

Related Topics