Web interface found only on 2nd try

General
1

Hi,

when opening the NodeRED web interface via http://hostname:1880, I often get "this server cannot be reached" on first try, while refreshing/2nd try gets it loading smoothly.

NodeRED: 4.1.4 on Raspberry/Debian 13
Node.JS: v20.20.0

Accessing browser: Firefox 140.7.0esr on Debian 13
Access path: http://pi1:1880 (wherein pi1 is the hostname of the machine with NodeRED in the local network)

Other web interfaces in the local network do answer in first try, therefore i dare to ask: did anyone encounter this too? I fear, have to hunt it with Wireshark otherwise.

1 Like
2

First try after what? Opening the browser? Restarting node red? Rebooting something?

Is it consistent?

3

First try after opening the browser. Yes, it is reproducing.

Couldn't find an issue on the DNS (which is on the locla internet router) yet. First ping from same machine is resolved and answered correctly.

4

... ouff ok, and browser Chromium gets its (apparently) on first try. Think i have to come back to this thread after wiresharking locally and on the (NodeRED-)Raspberry.

5

If you close the browser and re-open it does it happen again? If so then I don't see how it can be a node-red issue.

Is it exactly that error message? Google does not find anything with exactly that message.

What happens if you try a different browser?

What happens if you use the ip address rather than the host name?

6

Exactly, closing the browser and re-opening it is sufficient to reproduce. Why this is particular to NodeRED: such issues were not experienced for any other web page, neither in global internet nor in local network.

The exact firefox display, in german:

"Verbindung fehlgeschlagen

Firefox kann keine Verbindung zu dem Server unter pi1:1880 aufbauen. [...]"

Don't know the exact in English Firefox, should be connection not possible, or connection time-out.

To get it even more weird: with browser Chromium it is not happening. So ... just due to the fact that this is only observed for accessing NodeRed, remains a bit mysterious.

7

If you close both browsers, then reopen Chromium and, leaving it open, re-open FF does it still fail?

8
  1. Closed Chromium and Firefox.
  2. Opened Chromium, entered http://pi1:1880/ in address bar - instantly loaded, left Chromium open
  3. Opened Firefox, entered http://pi1:1880/ in address bar - no connection
  4. "Refresh" in Firefox - Page did load

As a variation, I did load in step 2 a Dashboard 2.0 page coming from same NodeRED in Chromium and did leave that "running" to keep the connection densely alive. But outcome of step 3 (no connection) did stay.

9

IP instead of hostname: the issue is not reproducing. Working instantly in that case.

10

At first: apologies, i should have gone further on my side. Think its understood now, using Wireshark/TShark on the Raspberry.

The DNS of the local network was having local IPv4 and v6 addresses of the Raspberry. Firefox was first trying to connect on the v6, which NodeRED was not configured to answer on. Second try was going (successfully) to the v4 address.

Added uiHost: "::", to the settings.js did fix it, NodeRED now also answering the connection attempts received on the v6 address. Ouff... :slight_smile:

11

@Colin At this opportunity, from my naive view: what about adding IPv6 by default?

12

I don't know why IPv6 is disabled by default. Perhaps one of the developers will explain.

1 Like
13

Continuing on v6, I learned now (from an AI... at least it is claiming the following :wink: ) that IPv6 addresses might be exposed globally in older routers/early IPv6 stacks even without explicit opening of the port to the outside, as the device IPv6 address can anyhow be read as a global address. (Therefore, it is not subject of "port forwarding" as in IPv4.) In that case, the aforementioned v6 acceptance would be a clear security threat.

1 Like