I think this release should be suspended until a fix is issued, I am regretting updating my 3200acm to . 06
v2.84test2 brings all three errors 
Fri Jan 22 20:32:49 2021 daemon.info dnsmasq[12040]: started, version 2.84test2 cachesize 1000
...
Fri Jan 22 20:32:49 2021 daemon.info dnsmasq[12040]: read /tmp/hosts/dhcp.cfg01411c - 2 addresses
Fri Jan 22 20:32:49 2021 daemon.info dnsmasq-dhcp[12040]: read /etc/ethers - 0 addresses
Fri Jan 22 20:32:50 2021 daemon.err dnsmasq[12040]: failed to send packet: Address family not supported by protocol
Fri Jan 22 20:32:50 2021 daemon.err dnsmasq[12040]: failed to send packet: Not a socket
Fri Jan 22 20:33:08 2021 daemon.err dnsmasq[12040]: failed to send packet: Address family not supported by protocol
Fri Jan 22 20:33:08 2021 daemon.err dnsmasq[12040]: failed to send packet: Not a socket
Fri Jan 22 20:33:08 2021 daemon.err dnsmasq[12040]: failed to send packet: Address family not supported by protocol
Fri Jan 22 20:33:08 2021 daemon.err dnsmasq[12040]: failed to send packet: Not a socket
Fri Jan 22 20:33:08 2021 daemon.err dnsmasq[12040]: failed to send packet: Address family not supported by protocol
Fri Jan 22 20:33:08 2021 daemon.err dnsmasq[12040]: failed to send packet: Not a socket
Fri Jan 22 20:33:08 2021 daemon.err dnsmasq[12040]: failed to send packet: Network unreachable
For the records, I've updated OpenWrt to 19.07.6 r11278-8055e38794 in a TP-LINK Archer C7 v5 (main home router) and I also get these errors.
They showed up at the same time when my Ubuntu 20.04 laptop lost network connectivity.
dnsmask.log:
The only windows machine is currently not at home, so no Windows in the network now.
I reinforce that this is causing network connectivity issues.
Anyway, thanks for the devs for keeping Openwrt up to date ragarding security issues!
EDIT: I'm downgrading to 19.07.4 for now since home has turned into office and it's difficult to cope with these random network outages. (Not 19.07.5 because I got the impression that this issue was already present - unfortunately haven't collected any logs at the time.
I wonder if a temporary workaround is to enable EDNS client subnet to avoid the new logic.
add-subnet=24,96
v2.84test3 has appeared and I think we're there - running ok for 10 mins all ok, will look at the logs in the morning to check nothing nasty happens.
4 Likes
Using your dnsmasq: try v2.84test3 update on two devices (ipq806x/ nbg6817 and lantiq/ bthub5) for the last ~4 hours is looking quite promising so far (no error message or other issues noticed, it's a bit too early to declare victory as the frequency of the error messages wasn't that high, but the logs are still clean).
1 Like
After initial testing, the v.2.84test3 looks ok to me.
(the faulty versions caused errors so rapidly, that the errors were quickly visible)
I applied it straight from the upstream repo:
--- a/package/network/services/dnsmasq/Makefile
+++ b/package/network/services/dnsmasq/Makefile
@@ -8,13 +8,13 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=dnsmasq
-PKG_UPSTREAM_VERSION:=2.83
+PKG_UPSTREAM_VERSION:=2.84test3
PKG_VERSION:=$(subst test,~~test,$(subst rc,~rc,$(PKG_UPSTREAM_VERSION)))
PKG_RELEASE:=1
PKG_SOURCE:=$(PKG_NAME)-$(PKG_UPSTREAM_VERSION).tar.xz
-PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq
-PKG_HASH:=ffc1f7e8b05e22d910b9a71d09f1128197292766dc7c54cb7018a1b2c3af4aea
+PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq/test-releases
+PKG_HASH:=20d1109c991ca08778ea20322b8f3245f2e974688d494b59b2e6ae096ec592b1
PKG_LICENSE:=GPL-2.0
PKG_LICENSE_FILES:=COPYING
1 Like
You're probably not going to spot any resource contention in load values that are averaged over 15 minutes. I would suspect that any excessive CPU usage would be in short bursts at the time of the DNS requests. To spot that I would recommend using the htop package and tweaking the sampling interval with the -d flag.
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?
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.