EAI_AGAIN, expected, but can a workaround be suggested?

I'm very, very new to Node-RED. I have some simple flows that call the USA's NOAA website. They work fine.

But my Raspberry Pi has the ability to switch it's internet connection from a Wifi Access point, to a phone hot spot, to Starlink -- without rebooting.

When the Pi switches from a Wifi AP to the phone hotspot, for example, the HTTP Request nodes start throwing EAI_AGAIN errors. Ok, I get it - switching the config has confused Node-RED's internet data. My question is, is there a way to tell Node-RED to reload, or re-init it's configs around DNS, etc.?

If I reboot the Pi, things work - but I'd rather not reboot or even restart Node-RED if the internet access changes. I'm hoping there's a nice way to tell Node-RED that network info has changed.

thanks

That is a DNS timeout error. In theory at least, it should be temporary so you might get away with putting in a catch node, delaying a followup for a second and then trying again.

Again theoretically, Node-RED - since it is based on Node.js - shouldn't care which network is being used. And Node.js doesn't cache DNS lookups but relies on the OS instead.

Can't say that this will fix the issue but it is worth trying and certainly beats restarting Node-RED each time.

If Julian's suggestion does not help, does it recover if you restart node-red without rebooting? You did not actually say that.

Thank you both - I have not tried restarting Node RED; I'll try that when I'm back on this project. I've been reading about EAI_AGAIN and you're right in that I need to dig into how node handles DNS.

Changing providers, like from T-Mobile to my Wi-Fi to Starlink, surely changes name servers, gateways, etc. The wlan1 IP address changes too, obviously. Catching the exception and seeing if there are some dns.() functions to call is something I'll try. Clear cache, etc.

Waiting, I'll try to see if that fixes it too. Right now, I make the NOAA calls every 15 minutes. So it's no problem to see if the call resolves itself after 14 minutes.
Thanks again!

Actually, that's a good point. I would recommend fixing your servers DNS provision. I never use my ISP's DNS - it is often pretty rubbish. I have monitors on multiple open DNS services and occasionally will check to see if my current settings are still the best. On so many different services, you might have to compromise a little.

Currently, I have these 4 fixed DNS endpoints defined on my router:
image

In order: AdGuard, Quad9, OpenDNS, Google

Node red should not need to do anything, it should be handled by the OS. For example, if you have the browser open on a laptop and change from Ethernet to WiFi the browser just keeps going. Or if your phone switches from WiFi to Mobile Network again the browser just keeps going.

Yep - I get that. I was just wondering if the HTTP Request Node implementation was ever in this.

My browsers typically throw a Network Changed error, first before clearing up. But I understand that this is an OS/node thing - not Node RED.

Interesting. Perhaps I am wrong.

Apply a fixed DNS service as suggested and those issues should all go away.

It might also be worthwhile running your own DNS server - eg PiHole on your Raspberry Pi.
I don't know if it would resolve the EAI_AGAIN problem but it would certainly eliminate frequent DNS calls, since it has it's own cache.
As a bonus it can save bandwidth by blocking adverts.

Indeed and I should have said that my router is the DNS endpoint for my LAN. It actually enforces this transparently such that calls to other DNS servers are silently redirected to the router. This also helps with security.

I've never been sure whether a PiHole would be performant enough for my network but I think if you have a Pi4 it should be good. But I've never tested performance vs my router.

I fret a bit about calls to other DNS servers. Does Edge or Chrome always use the preferred DNS server or eg for telemetry do they specify MS or Google servers?
What about WIndows 11 phoning home?
I'm sure you can make firewall rules to redirect these but I'm not sure how to go about it.

Pihole is reported to be very fast. I run it on a Pi 4 along with Mosquitto, Node-red, Mariadb and other services but it's fine on any Pi with ethernet.

(Away from original topic.)
I use 3 pi-holes here. 2 RPI Zero W's and 1 RPi Model 1B (not even sure it's a plus).
All work well, but I can sometimes detect delays with the one on the 'Entertainment' Isolated network.

It doesn't always load the base menu quickly on an LG TV, but I have a feeling that several alternative connections are tried to find a non-blocked address before it does load the menu (sometimes a 10 sec delay), but I can live with that for no adverts.

All traffic on the 3 networks use PiHole, I have found them very reliable.

1 Like

No, as per spec, DNS lookups happen at the network level not at the application level. So all the browsers do the right thing in general.

Of course, they are mostly loaded with telemetry too. You can see this if you want to by putting in a network sniffer.

But the point is that they do obey the OS and its network layer.

You get it for "free", so of course it phones home! It is possible to stop it if you try hard enough but it really isn't worth it unless you have some very "specialist" needs. For most people, Windows phoning home really isn't an issue - can you even begin to understand the scale of the telemetry data that Microsoft gets every second? There are an estimated 2.3 billion PC's then there are the Office apps, Edge and other apps. The scale of the telemetry is quite breathtaking.

Genuinely, I wouldn't bother. I'm pretty paranoid and even I don't go to those lengths. But if you really want to, set up a sniffer and you will soon spot the telemetry signals.

I didn't doubt the app, but anything below a Pi4 has very limited bus bandwidth and it is shared.

I really should do it one day. But while I'm running a Ubiquiti EdgeRouter Lite, there really isn't that much benefit.

Oh, and by the way, there is a reason (several actually) why I stopped using Google Chrome and we are eliminating it from work PC's. Here is an example:

1 Like

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