It is an intermittent symptom. I noticed that already when I authored the wifi support for WNDR3700 in ath79 in August 2018:
https://github.com/openwrt/openwrt/pull/1284
Known issues:
...
phy0 and phy1 may get assigned mixed, so that phy0 may be the 5GHz radio instead of the normal 2.4GHz, and vice versa for phy1. Does not happen always, but may happen.
In build ar71xx-master-r11968-3446702cdb-20200113/WNDR3800 Internet acces does not work because of name resolution not working anymore. Do you have the same problem?
My current WNDR3700 build is in my secondary router, so I haven't really tested full connectivity with DNS.
But I would guess that your troubles are related to recent changes in dnsmasq resolv file location and e.g. a restored config (after the transisition script had already run):
4 days ago Daniel Golle dnsmasq: add uci-defaults script for config migration
6 days ago |Daniel Golle| dnsmasq: switch to /tmp/resolv.conf.d/resolv.conf.auto
6 days ago |Daniel Golle| netifd: move /tmp/resolv.conf.auto to /tmp/resolv.conf.d/
6 days ago |Daniel Golle| base-files: move /tmp/resolv.conf.auto to /tmp/resolv...
That same change may cause me trouble when jumping back to 19.07 from master, but I have not had time to look into possible mitigations (like creating the same dir also in 19.07)
In fact I did keep the settings which worked fine so far. I'll have a look.
owrt1907-r10874-455ba76bf9-20200116
A week ago a change was made in master that changed the default position of resolv.conf.auto file (for DNS).
There is a transition script in master and most users will never see any problem when sysupgrading. (But if you restore an older config to the current master, you might hit trouble.)
The same goes for downgrading from master to 19.07, as the new default is a new directory instead of a plain file. So I added a reverse transition script to my 19.07 build, so that I am still able to seamlessy jump back to 19.07 with my builds.
I don't know what the exact process is when you kepp settings. Are they overridden and restored or do they stay in place?
I could not get dnsmasq running if I keep my settings during update, not even if I create the folder you mentioned. What I was wondering is: why can't dnsmasq create the temp files it uses including it's parent folder? Doesn't have to do this anyway when you restart the router?
If I reset the router to default settings it seems to work, but I am not ready to re-enter the complete configuration again through the webinterface. I even tried to restore the dhcp config file from a default settings backup, but this did not work either.
The transition script does not seem to work in my case. I am currently using the ar71xx-master build.
If you have looked at the commits that I referenced, you may have noticed that it is actually "base-files" that creates the directory that dnsmasq currently uses.
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=fedc5d30ae0a39a7d308adae8ed918dc5b603067
The config files are copied to a temporary file in RAM and flashed after the end of the flashed firmware image. During the first boot, the settings archive is noticed and expanded to overlay. Then a bit later in the boot process the uci-defaults scripts (like the transition script I mentioned) are run, and the restored settings can be manipulated buy them.
Apparently something in your config is strange. But without seeing your settings, it is hard to guess what...
I do not know if something is strange with my config or if the transition script simply isn't in place. Where should I find it?
In live router /etc/uci-defaults/50-dnsmasq-migrate-resolv-conf-auto.sh (befoer the first boot after flashing),
and after that it can only be seen in /rom:
/rom/etc/uci-defaults/50-dnsmasq-migrate-resolv-conf-auto.sh
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt SNAPSHOT, r12040-8df14c229c
-----------------------------------------------------
root@router1:~#
root@router1:~# cat /etc/uci-defaults/50-dnsmasq-migrate-resolv-conf-auto.sh
cat: can't open '/etc/uci-defaults/50-dnsmasq-migrate-resolv-conf-auto.sh': No such file or directory
root@router1:~#
root@router1:~#
root@router1:~# cat /rom/etc/uci-defaults/50-dnsmasq-migrate-resolv-conf-auto.sh
#!/bin/sh
[ "$(uci get dhcp.@dnsmasq[0].resolvfile)" = "/tmp/resolv.conf.auto" ] && {
uci set dhcp.@dnsmasq[0].resolvfile="/tmp/resolv.conf.d/resolv.conf.auto"
uci commit dhcp
}
root@router1:~#
root@router1:~#
The point is that you run into trouble if your dnsmasq settings point to a directory that does not exist.
But as this has nothing specific to do with my build, as if was a generic OpenWrt change, you might open an own thread if your settings need more debugging.
I did play around with dnsmasq again. What was missing is the first line in /etc/init.d/boot, the others I had to modify:
mkdir -p /tmp/resolv.conf.d
touch /tmp/resolv.conf.d/resolv.conf.auto
ln -sf /tmp/resolv.conf.d/resolv.conf.auto /tmp/resolv.conf
and then I had to add in /etc/config/dhcp which was missing completely for some reason:
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
I updated from ar71xx to ath79 and everything seems to work well, but in Chrome (both desktop and mobile) I get "ERR_SSL_KEY_USAGE_INCOMPATIBLE". In Firefox I get a warning about the certificate but I can override it. Chrome usually allows to override the warning (both on mobile and desktop), but not this time.
I repeated the procedure indicated in https://openwrt.org/docs/guide-user/luci/getting_rid_of_luci_https_certificate_warnings after deleting the old one from my desktop, but it doesn't seem to work neither in Firefox nor in Chrome.
Has anything changed in the new build related to openssl and uhttpd? If not and if you have no idea, I'll go to the normal OpenWRT forum to ask for help.
Nothing has changed in OpenWRT, it simply uses a self signed certificate. But web-browsers tend to get more strict every now and then.
I have installed acme which gets you a Let's Encrypt certificate and made an entry to the hosts file pointing to the LAN address of the router: 192.x.x.x my.routers.domain
Of course you need a ddns service too to resolve your external address to a name (my.routers.domain)
I noticed that the ath9 builds limit the internet throughput considerably. While I get up to 244Mbit/s from the ar71 builds (which is close to the theoretical maximum of my internet connection) the ath9 builds limit the throughput to about 150Mbit/s. When opening the webgui it slows down even more (< 100Mbit/s).
Did anybody else notice this too?
Just as a "caution ahead" warning, I just build ath79-master-r12234-7~a2fd92-20200214-2227 with the help of your great buildscripts, I used ath79-master-r12157-a~e0dcbb-20200131-2337 before that.
I had to make a few edits to account for the renaming of wndr3700v2 to wndr3700-v2 (I can understand the attraction of using the ar to ath move to clean up a few inconsistencies, but this is not helping in the long run, as I predict new quirks will creep in anyway, but not my decision to make).
But the bigger issue is that r12234 comes up without wifi (the dmesg output seems to indicate that the kernel does not even see the two radios). I guess I will embark on a git bisect run (which is going to be nasty due to the gratuitous rename... )
Now, if someone has already beaten me to this, please holler 
I am currently debugging why my 6in4 tunnel does not work anymore. I see some lines in the sys log when connecting the interface:
x_tables: ip6_tables: mac match: used from hooks OUTPUT, but only valid from PREROUTING/INPUT/FORWARD
Can anybody point me to the problem
googling that error message reveals e.g. this:
https://sourceforge.net/p/fwbuilder/mailman/message/29414456/
Are you using the standard firewall with 6in4 without any special personal rules?
Or is that with some special rules from you?
E.g. MAC filtering might be problematic based on linked discussion.
Ps. And I highly doubt that this is actually related to my build, as there is nothing special regarding the firewall settings in my build. You might get better information, if you would open a topic-specific clearly named thread in the networking section of the forum...
hnyman, thanks for the quick reply!
The strange thing is: IPv6 has already been working with your builds. I did not change any firewall rules related to IPv6. It simply stopped working some time ago.
If time allows I will try an older build, to see if it is a problem with the current builds only.
Yeah but my point was that it has nothing special to do with my builds.
Either
In both cases, you should reach for the wider OpenWrt audience and firewall specialists, instead of the small population of my build's users.
Ps. that "mac match" makes me to think that you have some MAC filtering which now misbehaves. Something may have changed in iptables or kernel or firewall.
You were right: it was a firewall rule. Thanks again!
Ugh. My last remaining WNDR3800 comes up with OWRT default wifi w/o password (and won't vend anything or respond), but nothing on the network. I've tried tftping it with little luck. I get about 3 seconds of ICMP from 192.168.1.1 when it comes up, so uboot has to be working.
Aside from finding my USBTTL interface, any ways to drop this back to defaults and hope it comes through?