Dashboard page is unable to load app.min.css and/or app.min.js - assymetric traffic in network?

Here is an interesting case which we haven't yet managed to crack fully, but assume we know the issue, so thought of sharing this with all you out there. The Dashboard page fails to load app.min.css or app.min.js.

Setup is like this:

  • Ubuntu 20.04
  • Node LTS (currently v16.14.0)
  • Node-RED installed with the normal npm i -g --unsafe-perm node-red (so currently at version 2.2)
  • Dashboard installed first directly with npm install node-red-dashboard in the /home/[user]/.node-red/ folder, but also tested with doing the same from the Manage palette
  • dashboard set to run at :1880/control via the settings.js file
  • and we view the dashboard over our OpenVPN connection to the ship where this is installed
  • the ship in question uses a hybrid networking system of 3G/LTE, radio link and VSAT satellite

Problem is like this
When we open the dashboard page (in our case over our VPN at http://[vpnip]:1880/control) the app.min.css or app.min.js fails to load and subsequently the page fails (or it takes a veeeeryyyy loooong time to get anything visible - and naturally the styles are all missing and the page shows only text). The Admin page works normally.

Sometimes it works fine
However, once the ship sails out to sea and apparently switches to some other network, the Dashboard page again works. The Dashboard also works fine when using it in the local network.

The reason for this is most likely some type of assymetric network traffic or ACL or similar, which manages to mess up our browsers (here ashore) "talking" with the Node-RED instance onboard the ship.

So if you come across this type of issue, please check the underlying network, especially if the asset (ship, truck, airplane, space rocket) in question uses a hybrid networking system.

We will add to this topic if find our more about the issue.

Thanks for sharing. The "long time" will, of course, be the TCP timeout which is indeed long. You may need to check the various system logs on your infrastructure to see if you can trace where the request is being blocked. One favourite is if you have a filtering proxy, particularly a "smart" (from someone like Sophos, etc) one that does dynamic risk checks, these can sometimes do unexpected things.

1 Like

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