DNS doesn't work from the LAN on either rc1 or rc3. Went back to 21.02.3 which continues to work with the same config from LEDE.
RC4 is busted as well.
I know it's effort, but you really should re-do your config from scratch. LEDE is now more than half a decade old, quite a few configuration details have changed in between. Something on 22.03 or 21.02 not working with an old LEDE config is not really all too surprising.
I mean, if DNS generally didn't work from LAN in 22.03 ... someone would probably have noticed. DNS requests from LAN are not exactly edge cases hardly anyone uses.
2 Likes
That's the thing, this is quite likely an issue with firewall4. 21.02 works fine. Going to the internet works without dns, but nslookup for whatever reason returns servfail. Others have reported similar issues.
The firewall will (by default) not intercept DNS requests from LAN, your problems are very likely to be related to using your old configuration (but there have been changes to dnsmasq that will break when importing an old config). takimata's advice is spot on, this is the time to start with a clean configuration.
While I'm not running 22.03~ as such, I'm totally fine with fw4 and its DNS functionality on current master (x86_64).
3 Likes
No, it really isn't. This is exactly to a T what's wrong with the OpenWRT community. Destroying installations when upgrading is completely unacceptable for standalone devices thousands of miles away. Statements like this are actively harmful to not only the image of the project but new users beginning their journey.
How can I help fix this regression before more users encounter issues.
1 Like
RC1 and RC4 both have (different!) interesting dnsmasq bugs.
If you try to disable AAAA records for a specific domain, for example...the following stanza in /etc/config/dhcp:
config dnsmasq
...
list server '/netflix.com/#'
list address '/netflix.com/::'
that should suppress AAAA records for *.netflix.com will:
- be completely ignored on RC1 (i.e. it becomes part of the parsed dnsmasq config but dnsmasq does nothing with it)
- cause dnsmasq on RC4 to crash immediately upon the second AAAA DNS record request for whatever domain is being suppressed
Neither outcome is a good one. =)
1 Like
can you post that lede config?
And it is only hopeful between stable releases in a row.
when that migration failed, shouldn't it try to fail to some reasonable default? (like normal DHCP+ISP dns or not save config at all with notification of failed to preserve the config
Users feeling too entitled? 
As far as I am concerned OpenWrt makes a reasonable effort to maintain backward compatibilty (see the switch from swconfig to DSA) but simply does not have the manpower to test all possible configurations (again, see swconfig to DSA). This is where users like us can help by testing changes and reporting issues. That in turn means the 'my router runs at McMurdo station and I will only be able to physically reach it in southern hemisphere summer' crowd might want to keep a local instance of the remote device to rehearse with before trying to update the remote device...
Sure it would be nice if steps like that would not be necessary, but what do you expect from an all volunteer project that makes no hard promises about configuration forward/backward compatibility in the first place?
9 Likes
I completely agree, that's why you shouldn't upgrade standalone devices thousands of miles away if you are not willing or able to and OpenWrt should state much, much more prominently that
At the moment, this is hidden rather deep in the documentation, and the sidenote in the release notes
As opposed to snide remarks, you should be aware that this is the default behaviour in LuCI which 95% of users interface with.
Which area do you think would be useful? I was using extradns but it was wiped on upgrade. Based on the feedback from rhester72 it sounds like the regression may be in dnsmasq where I am indeed running ipv6.
I also have a couple forwardings. They look like /svc.k8s.local/10.0.0.7#530.
I was using extradns but it was wiped on upgrade
that sounds like such dns package ran a dns server instance itself (like https-dns-proxy) and make itself as dnsmasqs upstream (ex:127.0.0.1#6666), when upgrade dnsmasq is left unchanged - now upstream is nonexsitant so resolve fails
No - because the downgrade back to 21.02.3 works out of the box (along with other versions). It's not package related unless if there's additional packages that have been added to the 22 series.
I'm interpreting that "Keep settings" as keep it within a line, so you don't have to build things from scratch if you switch eg. from 21.02.1 to 21.02.2 or 21.2.3 - not to keep 'em switching between main lines as 21.02 and 22.03. That may function and if, you're lucky, but don't need to. Perhaps we need a detection to untick that box by default if you try to switch between main lines, it happened already in the past that we have to modify some config files to let the devices function again, for that there was already some sort of warning implemented. The second pit read carefully, there is not mentioned something like keeping all the necessary packages or just updating 'em, I've already fallen into that pit myself... The switch between iptables and nftables breaks a whole lot. If OpenWrt runs in default settings on all devices as expected that'll be a huge work done, personally I need ip sets, but that'd be left for dnsmasq-2.87, which isn't released yet, just as an example. Maybe there are unresolved dependencies between nftables and your config that 're for what reason ever didn't show up with iptables.
1 Like
See this note up-thread: OpenWrt 22.03.0-rc1 first release candidate - #28 by atownlede
I tripped on this while doing something similar to keep netflix working when an IPv6 tunnel was available.
Shall we ask the OpenWrt dnsmasq maintainer to pull in the upstream fix?
In the meantime, I've been using a BIND server with AAAA-record filtering. see https://openwrt.org/docs/guide-user/services/dns/bind-server-filter-aaaa
By the way, is there a thread regarding Snapshot? There gcc bumped up to gcc-11.3.0 but in the according Makefile the sha256sum is missing.
An other "funny Thing" I stumbled across 22.03-RCx: If you change in LuCI the static ipv4-address to dhcp it gets a dhcp-assigned address, runs down the timeout even if you log in on the new address, and then changes back to the static address. If you repeat your changes all goes as expected and after a login on the new address it'l be confirmed and taken permanently.
I believe 2.87 is being tested (I see it in at least one of the dev's personal branches) and I think it is necessary anyway for the nftables equivalent to ipsets to be supported by dnsmasq.
Then you are the bigger moron for changing to a version that says in the release notes this requires clean install. Both the DSA and ntf tables changes are major updates. Also any IT person knows that you test locally before deploying remotely and ALWAYS with someone on hand to help recover otherwise its a long drive to fix what broke.
Detail what changes you make with your default OpenWrt install.
Then use scripts like this to auto install or re-setup back to your desired configuration. https://github.com/richb-hanover/OpenWrtScripts/blob/main/config-openwrt.sh
Keep in mind his script requires editing for your changes, configs and installs but it provides you with a framework to build on.
i can blow away my install. SSH back on it. drop the script on and reboot and i'm back to my setup.
8 Likes
I think I used that example as a start when I made my setup script about two years ago.
It is a big one time job at start (based on how complex setup you have) and then maybe some minor adjustments when new functions gets released like DSA.
But once the admin job is done then I always have new fresh configs and only the right information in the configs when upgrading.
It is actually a pretty common reoccurring issue in this forum, users that have copied over and over and over the same configs for ages and they probably gradually build up minor issues over the years until it stops working and they come here to the forum. But this copy-paste tactic seems to always fail if you only try it enough times.
2 Likes
This is fixed when the platform is upgraded to DSA. 