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:
I edited /etc/resolv.conf manually to put it right:
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.
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.
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
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.
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).
Also the advise is to append
option ignore '1' in /etc/config/dhcp like this, right?
option ignore '1'
config odhcpd 'odhcpd'
option ignore '1'
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,
config dhcp 'lan'
option ignore '1'
I had not, however, scrolled down to Disable Daemons Persistently. I have now added to
# these services do not run on dumb APs
for i in firewall dnsmasq odhcpd; do
if /etc/init.d/"$i" enabled; then
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.
wpa_supplicant is superfluous on the main router, too.
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.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.