On the topic of performance, does anybody know of a good way to generate a lot of DNS requests to reliably test the load dnsmasq causes? I know very little about DNS in general, but it seems like there's some sort of cache that causes requests to previously visited domains to not generate any noteworthy load. Is there any way to get around this in a testing scenario?
https://www.dns-oarc.net/tools/dnsperf might contain what you need.
Thanks for the tip!
I compiled two master shapshots where one had the dnsmasq update reverted (i.e. running version v2.82) and the other had the newest test build (v.2.84test3). There doesn't really seem like there's much difference in load between the two, but I admit that my testing had been fairly naive, so feel free to poke holes in it. What I did was:
-
ssh into the router and run:
htop -p <pid of dnsmasq> -d 0.2 -
Disable the DNS cache on my Fedora 33 laptop by uncommenting
#Cache=noin/etc/systemd/resolved.confand restarting systemd-resolved withsudo systemctl restart systemd-resolved -
Run
dnsperf -s 192.168.1.1 -d address_file -n 10on the laptop -
Compare the load in the two builds
I used the addresses of a few large newspapers in Norway and the Norwegian google page:
$ cat address_file
www.vg.no AAAA
www.vg.no A
www.ap.no AAAA
www.ap.no A
www.google.no AAAA
www.google.no A
The resulting CPU load was more or less the same at short bursts of 10% when the request went through. Sometimes it reached 20%, but this happened on both builds.
Maybe you saw posts with those on 19.07.5 who had applied the workaround? In that case, the issue would be present, but other than that it doesn't make sense that it would be in .5. There would have been huge threads on it for the last month.
1 Like
Package upgrade doesn't work for me.
Could I simply put these lines in "Startup" under web UI, and consider the problem fixed?
Tried those settings but it didn't help me that much. But it did lessen the logs a little bit.
1 Like
Not really.. because once you do the uci commit dhcp it's already saved in the config.. so in the sense of putting it as part of the Startup, your just keep on setting and saving the same config everytime you reboot which is redundant and doesn't really help.
1 Like
Another question - is dnsmasq too deeply embedded in OpenWRT to simply remove it? AFAIK it was initially meant as a DNS lookup performance enhancer. But if removing it removes an unknown number of future attack vectors, isn't it worth it the slight decrease in performance?
It also acts as a DHCP server, and a DNS server for the local names.
I also use dnsmasq-full "ipset" to work with iptabls, and work with banip to protect SSH 22 port
@ldir
Will you push the dnsmasq fix 2.84test3 to master soon?
So far it still looks good.
The upstream version can be directly used in master, but 19.07 likely requires individual patches to be backported to 2.80.
(Although I am not quite sure why exactly we still use a patched 2.80 in 19.07. Yeah, in theory it may be good for stability to stick with 2.80 with selected patches, but as the faulty 2.83 patches were backported quickly to 19.07, the stability is questionable in any case.)
Why is that?
under web UI
I've just updated the instructions for LuCI web based mitigation.
Does this mean the fix is already in master?
And if so, how can I upgrade? I used
opkg update; opkg upgrade $(opkg list-installed dnsmasq* | cut -d' ' -f1)
but dnsmask still shows
No.
The fix is in the upstream dnsmasq source repository, but the local Makefile in OpenWrt has not yet been updated by ldir
The Makefile fixes for master and 19.07 are also already in ldir's testing/staging tree, but they have not yet been pushed to the main OpenWrt
https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=summary
(see the "mine" and "openwrt-19.07" branches)
3 Likes
I pushed dnsmasq 2.84test3 to openwrt master. Still discussing what to do with 19.07.
1 Like
Thank you!
Now a noob question: having 19.07.6 installed, how would I upgrade this single package from master?
You could by changing the package feeds so that your router will be pulling packages from the master branch instead of the 19.07 branch package repository. Having said that, while it's possible, it's strongly recommended NOT to do it. These packages are compiled and tested on master snapshot images. There are no guarantees that they will also work on images of the 19.07 branch. I would recommend to wait until an updated package will appear in the 19.07 branch.
Also, changing the feeds in this way will make ALL future package installs from the master branch package repository, with all the same pitfalls and downsides.
1 Like
You wait until the corresponding fix is implemented to 19.07
(it is already implemented for testing in ldir's staging repo, like I said above)
You can't use master packages binaries in 19.07
Note that currently 19.07 uses 2.80+patches, while master uses 2.84test3
1 Like
If someone could build & test https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=aea07294d78dcc8214f858007d144d02860f6443 to make sure a) it doesn't blow up and b) actually solves the problem I would be very grateful
Well, looks like @hauke has applied the 19.07 fixes in the meanwhile...
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=11f4918ebb32f658e419225ef218f82d66b482cc
Looks like he backported the three main fixes, but not the "Optimise-sort_rrset-for-the-case-where-the-RR-type-n.patch"