[SOLVED] WAN+DHCP DNS server not being used

There's a complicated backstory I'll get to in a sec (a custom build), but the essence of my problem is that my router's WAN interface is using DHCP to get its config, but the upstream DNS is not used to resolve names. The IP address and routing is set ok (ping 8.8.8.8 works) and the file /tmp/resolv.conf.d/resolv.conf.auto contains the upstream router's DNS server address in the nameserver property. That address can be explicitly used in an nslookup ${target-address} ${upstream-server} query (So the upstream server works, it's not used by default).

I've gone round in circles looking at the DHCPand dnsmasq settings and I can't see what the difference is between this and a VM router that does have working DNS lookup.

The "complicated backstory":
This is running on a Dell Wyse 3040 thin client with an Atom CPU. Because of the Atom CPU, pre-compiled OpenWRT builds won't work (yes, I tried). So I'm following Paul Robson's guide for building from source for this platform. I'm based off the 22.03.5 tag in Git (Latest stable as I write this).

I've got the build working, but by default the thin client's single eth0 port is used for the LAN network. I'd rather use this for WAN and use a USB3 WiFi dongle for a LAN network. I can take the unmodified image, boot to console and edit the /etc/config/network to put eth0 into the WAN network, and restart to get the updated config into operation. However I've tried to make the WAN and LAN network configs into the files/etc/config/network and files/etc/config/wireless files in the build environment.

This is now almost working except that I just noticed that DNS isn't working for clients on the LAN network (Nor the router's OS itself).

Anyone got any clues about how to go about fixing the DNS?

Edit: SOLUTION
So I was trying to make minimalist pre-configured files under files/etc/config for the build environment so I could get eth0 in the WAN network from first boot. Unfortunately I hand-wrote the network config and made an error in the loopback interface definition. I wrote option name 'lo', when this should have been option device 'lo'. As a consequence, the loopback interface did not have an address bound and DNSMasq could not bind to it, so simply didn't work on any interface.

Changing name to device and rebooting resulted in DNS working by default.

Not used by who ?

So which DNS server is being used instead, and, if you grep the router's filesystem for that DNS server's IP address, does it appear in any results?

Not used by who ?

Not used as default by the Router's OS, or DNSMasq presumably and thus not used as the back-end for LAN-side clients. Doing an nslookup google.com times-out.

So which DNS server is being used instead, and, if you grep the router's filesystem for that DNS server's IP address, does it appear in any results?

No DNS server is used. DNS queries time-out unless you explicitly name a server to resolve with. e.g.:

nslookup google.com times-out

nslookup google.com 1.1.1.1 works.

grep -r server-address /etc gets no hits, but it is in /tmp/resolv.conf.d/resolv.conf.auto (Which I believe is correct config) - It just seems that DNSMasq is not using that config file for some reason.

Possibly a dim question, but do you know which Atom? Some are 64-bit, some are 32. I've successfully run OpenWRT on an Atom in the past.

Gaaaah! I've spent hours looking at this and finally gave-up to post to this forum for help.

Then 20 seconds later I notice I'd hand-mangled the loopback interface config and that is what was breaking it.

1 Like

Answering my own question: it's apparently the x5-8350 which is 64-bit, according to https://qubitsandbytes.co.uk/dell-wyse-3040-vs-raspberry-pi-4/

Often the way. Step away from a problem, spot the solution. Congratulations on finding and fixing the cause.

Possibly a dim question, but do you know which Atom? Some are 64-bit, some are 32. I've successfully run OpenWRT on an Atom in the past.

Not a dim question. It's a 64-bit Atom x5-Z8350 in the "Z" series (Intended for mobile devices). You need to build OpenWRT with the Atom target in the kernel config, otherwise it just hangs on boot.

2 Likes

Thanks to @iplaywithtoys and @frollic for being rubber duck debuggers for me. Sorry to waste your time.

1 Like

No apology needed. Anyone who knows the expression "rubber duck debugging" gets a free pass.