22.03.4 breaks resolv.conf in AP

[lwarshawsky]

When I upgraded one of my access points from 22.03.3 to 22.03.4, /etc/resolv.conf on the AP forgot the configured DNS server.

The AP's /etc/config/network contains

config interface 'lan'
        ...
        list dns '192.168.1.1'
        list dns_search 'lan'         

After the upgrade, /etc/resolv.conf looked like the one on the main router:

search lan
nameserver 127.0.0.1
nameserver ::1

I edited /etc/resolv.conf manually to put it right:

nameserver 192.168.1.1
search lan

So far, so good. No other problems have surfaced.

The AP in question is a TP-Link Archer C7 v5. I haven't yet upgraded the other APs, another Archer C7 v5 and a D-Link DIR-878.

[eduperez]

That file is a symbolic link to a file in the (volatile) /tmp folder; it will revert again, when you reboot the device.

You should probably review your configuration, so everything works after a reboot.

[psherman]

I agree with @eduperez

Typically, the dns configuration options (beyond the basic upstream dns configured within the relevant network interface) are specified in the dnsmasq section of the etc/config/dhcp file.

[lwarshawsky]

Thanks for pointing out the symbolic link and ephemeral nature of resolv.conf.

I have re-disabled dnsmasq, firewall and odpcpd on the AP, and resolv.conf now gets built correctly on reboot.

When upgrading the other APs I should visit System > Startup.

[psherman]

@lwarshawsky

I have re-disabled dnsmasq, firewall and odpcpd on the AP

The preferred method of handling this is to disable the specific features explicitly in the configuration files -- disabling them in init.d (startup items) is not the best method because the services will usually be re-enabled when a sysupgrade is performed.

For example, in most situations, a dumb AP will not be the DHCP server on a network. Therefore, the DHCP server must be disabled in the dumb AP. While disabling dnsmasq as service will achieve the goal, a sysupgrade will re-enable the service and the DHCP server will turn back on, even when settings are kept during the upgrade, Instead, the DHCP server on lan should be explicitly disabled in the /etc/config/dhcp file by setting the option to ignore the interface. This will be persistent and deterministic across upgrades.

This same principle applies to other config options, too... so your DNS server settings and such -- if you have specific settings, make them explicit in the /etc/config/dhcp config file (instead of manually entering it into your /etc/resolv file and disabling dnsmasq).

[ed8]

Also the advise is to append option ignore '1' in /etc/config/dhcp like this, right?

config dnsmasq
		[...]
		option ignore '1'

config odhcpd 'odhcpd'
		[...]
		option ignore '1'	

[lwarshawsky]

Thanks for insisting that the changes be made permanent. I had originally followed the instructions in Wireless Access Point for configuring APs with LuCI. That included disabling the DHCP server on the lan interface. Indeed, /etc/config/dhcp contains

config dhcp 'lan'
        option ignore '1'

I had not, however, scrolled down to Disable Daemons Persistently. I have now added to /etc/rc.local:

# these services do not run on dumb APs
for i in firewall dnsmasq odhcpd; do
  if /etc/init.d/"$i" enabled; then
    /etc/init.d/"$i" disable
    /etc/init.d/"$i" stop
  fi
done

rm -f /usr/sbin/wpa_supplicant

My APs don't need wpa_supplicant since each one has a wired Ethernet connection to the main router. (I added the -f to avoid error messages in later reboots.) I have reflashed the upgrade and all is well.

I will make this addition to the other APs before I upgrade them.

I believe wpa_supplicant is superfluous on the main router, too.

[psherman]

@lwarshawsky

Thanks for insisting that the changes be made permanent.

Yeah... this will make things much easier for you moving forward.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks!