Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can't install new nodes in Node-Red due to no connection of node-red container with internet #249

Open
bogus105 opened this issue Oct 24, 2022 · 1 comment

Comments

@bogus105
Copy link

bogus105 commented Oct 24, 2022

Hi guys!
after so many trials i'm forced to ask here: please guide me how to make my node-red container to connect to host network. I'm running OITstack on RB Pi4. I need to add nodes to NodeRed but i found it can't connect internet.
When i go to Portainer -> Containers -> nodered -> and connect to its console and check the content of /etc/resolv.conf by typing:
cat /etc/resolv.conf
i'm getting:

nameserver 127.0.0.11
options ndots:0

My RP Pi is connected to the router via ethernet cable and in the router in the LAN parameters the preffered DNS is 192.168.0.1
Should the /etc/resolv.conf point to this address?

How, why?
Thank you

@Paraphraser
Copy link
Contributor

The first thing you should do is read this project is dormant and then, assuming you didn't open the issue here on gcgarner by mistake, migrate to SensorsIot/IOTstack.

The SensorsIot documentation for Node-RED has a whole section on component management which you might find helpful.

If you need to migrate, please make sure you carefully compare/contrast your existing service definitions in your docker-compose.yml with those in ~/IOTstack/.templates. There have been many many changes. Your existing unmodified docker-compose.yml will probably work "as is" but you won't get the benefit of any improvements.


What you are seeing in /etc/resolv.conf inside the container is correct. 127.0.0.11 is a special Docker IP address which basically means "use the host system's DNS configuration" (ie what you see in the Pi's /etc/resolv.conf).

From inside the container, you should be able to resolve the following:

$ docker exec nodered getent hosts mosquitto
172.30.0.6        mosquitto  mosquitto
$ docker exec nodered getent hosts www.google.com
2404:6800:4006:80f::2004  www.google.com  www.google.com

The first one is asking for the IP address of the Mosquitto container in container-space (the iotstack_default network).

If you aren't running Mosquitto then substitute the name of another container

The second one is, obviously, querying outside container-space.

If both work then DNS is working. If the first works but the second does not, it implies that DNS is working but you have a configuration or reachability problem for your Pi getting DNS.

If neither work (which I've never seen) I would guess you might be better off nuking everything and starting over.

If you decide to do that, perhaps take a look at PiBuilder. If you've got a lot of existing data you want to preserve, perhaps also take a look at IOTstackBackup.

Now, when it comes to 192.168.0.1, here's what usually happens. Your router boots. It connects to your ISP. As part of the PPP setup, your ISP allocates an IP address to the WAN side of your router and also provides (typically) two IP addresses of DNS servers that the ISP maintains.

When a client on your LAN boots and issues a DHCP request, your router (which will usually be running as a DHCP server) answers and allocates an IP address to the client. As part of the DHCP lease, the DHCP server tells the client to use the router's IP address for DNS.

When the client issues a DNS query, it's directed to 192.168.0.1 and a DNS resolver running in the router forwards the query to the DNS servers operated by the ISP.

DNS servers run by ISPs are not always the best choice. Quite a few ISPs seem to configure their DNS servers to not operate recursively. I have no idea why they do that but it can often lead to stuff-ups of the type you seem to be having with Node-RED. ISPs also sometimes try to reduce their DNS traffic overheads by deliberately ignoring time-to-live settings on domain names. That can lead to serious stuff-ups with things like DuckDNS and WireGuard.

Some ISPs even try to get into the advertising game by trapping DNS mistakes (eg when you type "microsof" without the "t") and serving you ads instead. All best avoided.

The best thing you can do is to get into your router and ferret around until you find the controls that tell DHCP which DNS servers to hand out in leases. I don't know which router you're using so take this with a grain of salt but many routers have two fields for DNS servers. Yours is probably either defaulting to 192.168.0.1 with the second field left empty, or both are empty which the the DHCP server is intepreting as "use 192.168.0.1". Set the DNS server fields to some combination of 8.8.8.8, 8.8.4.4 and 1.1.1.1. The 8.8s are Google, the 1.1.1.1 is Cloudflare. You lose nothing by avoiding your ISP's DNS servers. You gain reliable DNS by using Google and/or Cloudflare.

Alternatively, tell the Pi which DNS servers to use by sticking this line towards the end of /etc/resolvconf.conf:

name_servers="8.8.8.8 8.8.4.4 1.1.1.1"

followed by:

$ sudo resolvconf -u

You should see the changes come through into /etc/resolv.conf and then getent queries run inside the container via 127.0.0.11 should start using those servers too.

Hope this helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants