OpenWrt 22.03.0-rc1 first release candidate

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? :wink:
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.

image

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. :slight_smile:

This coming from someone who hasn't contributed a single original post since joining, really tells everything about his understanding of the term "community".

7 Likes

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 20
Keep in mind his script requires editing for your changes, configs and installs but it provides you with a framework to build on.

Well... What OpenWRT currently lacks is a documented way to upload a similar script together with a sysupgrade image that requires not keeping the settings. This functionality is required for fully remote upgrades to versions with too-major changes - because after the upgrade, the router will be inaccessible from the outside, so one cannot "telnet in" as documented in the script.

Of course the to-be-uploaded script needs to be tested on an identical router locally.

It has that. The image builder. And with that you can include custom scripts to deploy in the image. Thus you can actually do what is required fairly cleanly. But that's a custom install. What OpenWrt provides is good defaults to build on for customisation. Think of it like Lego. You get the base and house. Now add in the extras you require like VPN or Adblocking/filtering etc. Throw in your tweaks like SQM and other settings and deploy it.

2 Likes

OpenWrt 22.03.0-rc4 was just announced: OpenWrt 22.03.0-rc4 fourth release candidate

5 Likes