Sure you can, but just wait a few hours until buildbots have built the new package version, and then you can easily opkg install the new dnsmasq version.
No need to flash the whole firmware.
(mass upgrading all packages can lead into trouble, but upgrading just dnsmasq is easy and ok.)
Thanks for your patience.
Just to make sure I understood it, the new dnsmask package should show at some point in time in the following list, correct? (list produced after doing opkg update)
root@OpenWrt:~# opkg list-upgradable
luci-app-opkg - git-21.018.57536-6ba9740-1 - git-21.022.31068-7129723-1
luci-lib-ip - git-21.018.57536-6ba9740-1 - git-21.022.31068-7129723-1
luci-mod-system - git-21.018.57536-6ba9740-1 - git-21.022.31068-7129723-1
luci-theme-bootstrap - git-21.018.57536-6ba9740-1 - git-21.022.31068-7129723-1
netifd - 2019-08-05-5e02f944-1 - 2021-01-09-753c351b-1
luci-mod-status - git-21.018.57536-6ba9740-1 - git-21.022.31068-7129723-1
luci-app-firewall - git-21.018.57536-6ba9740-1 - git-21.022.31068-7129723-1
odhcp6c - 2019-01-11-e199804b-16 - 2021-01-09-64e1b4e7-16
luci-compat - git-21.018.57536-6ba9740-1 - git-21.022.31068-7129723-1
luci-proto-ppp - git-21.018.57536-6ba9740-1 - git-21.022.31068-7129723-1
luci-mod-admin-full - git-21.018.57536-6ba9740-1 - git-21.022.31068-7129723-1
luci-base - git-21.018.57536-6ba9740-1 - git-21.022.31068-7129723-1
luci-proto-ipv6 - git-21.018.57536-6ba9740-1 - git-21.022.31068-7129723-1
luci-lib-nixio - git-21.018.57536-6ba9740-1 - git-21.022.31068-7129723-1
luci-lib-jsonc - git-21.018.57536-6ba9740-1 - git-21.022.31068-7129723-1
luci - git-21.018.57536-6ba9740-1 - git-21.022.31068-7129723-1
luci-mod-network - git-21.018.57536-6ba9740-1 - git-21.022.31068-7129723-1
EDIT: As of now, the package is available, so please disregard this post.
Running a build using 'dnsmasq - 2.84~~test3-1' for 12 hours
No logged error messages, seems to work as before.
Hi all! Also experiencing the issue since moving to 19.07.6.
I have to compile my own images because I need to add a kmod driver that isn't in the releases yet. If I want to complile 19.07.6 from source with dnsmasq_2.80-16.3 included - how do I do that?
Thanks!
Strictly speaking, you can't. 19.07.6 is a historical release with static sources.
But the fix has been backported to the 19.07 branch, so you can checkout the openwrt-19.07 branch, git pull the newest sources, and you are good to go. (And you will also get the other fixes since 19.07.6)
See the commit log
https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=refs/heads/openwrt-19.07
Ps.
It would be also possible to checkout 19.07.6 and then manually apply the dnsmasq patch. But then you would miss the minor kernel update plus the IPv6 security fixes.
dnsmasq doesn't depend on any kernel modules, so even with a custom self-compiled image you can install dnsmasq via opkg. No need to compile in the newer package directly.
DNSSEC checkbox appears to be gone in the 19.07's newer builds, following this fix. Was that intended?
That checkbox is not only with full dnsmasq?
Got one of those messages again, but I didn't feel any network outage:
Let's keep monitoring.
EDIT: dssmasq version:
Looks good to me now, I foward some DNS request to 8.8.8.8, I visit those webpage once, some err syslog everytime.
The new version did not.
Tue Jan 26 01:21:42 2021 daemon.warn dnsmasq[3837]: possible DNS-rebind attack detected: popup.carbonite.com
I do use Carbonite, and it hasn't backed up in 38 hours despite being scheduled to do it every 24. Hope it's just another Carbonite glitch - after all it's a pretty glitchy program.
I believe this is probably not related to the upgrade. This is an actual DNS rebind "attack" which means that dnsmasq is correctly preventing your device from resolving that FQDN to a local address.
For reference, I see popup.carbonite.com resolving to a local IP address (127.0.0.53) on public DNS records.
If it is what you expect (i.e. carbonite is a local service to your device - I'm not familiar with it), you may want to add that entry to your device hosts file. You could also add a rebind exception to your dnsmasq config for that particular IP (if you trust carbonite.com).
I just wanted to thank everyone involved in turning round the latest fix super quick. I've been running dnsmasq_2.80-16.3 since release and works perfectly for me.
Second failed message in 24 hours:
2021-01-25T20:14:29-03:00 OpenWrt dnsmasq[2410]: failed to send packet: Operation not permitted
2021-01-26T16:53:56-03:00 OpenWrt dnsmasq[2410]: failed to send packet: Operation not permitted
(I upgraded the package at 16:00 yesterday)
Is this one normal?
I had upgraded dnsmasq last week, and was seeing 'failed to send packet' errors every couple of minutes. I then upgraded the dnsmasq package again this afternoon. Thus far the error seems to have gone away.
Package version is 2.80-16.3 on 19.07.5.
I wouldn't regard it as 'normal', I suspect it is benign and was occurring on earlier versions of the package. I've seen it occasionally when my ISP wan link drops. The message is in essence 'permission denied'. Once every 24 hours is not something I would worry about.
Investigating further would probably start with running 'strace' on dnsmasq to see how the 'sendmsg' syscall is failing. Then getting a bit more info on the offending socket file descriptor.
strace -Z --trace=sendmsg -p $(pidof dnsmasq)
lines beginning "sendmsg(11, {msg_name={sa_family=AF_INET, sin_port=htons(41774)," would be of interest, taking the file handle (11 in this case) into readlink to get an inode
'readlink /proc/$(pidof dnsmasq)/fd/11' - returns a socket number e.g. socket:[2081468]
Then get some socket details with "grep 2081468 /proc/$(pidof dnsmasq)/net/{tcp,tcp6,udp,udp6}"
But I very much doubt this effort is going to reveal anything particularly magical/dangerous.
So far it seems to be indeed. Haven't felt any network outage as I have before the package upgrade.
As of now, I only have this logged:
2021-01-25T20:14:29-03:00 OpenWrt dnsmasq[2410]: failed to send packet: Operation not permitted
2021-01-26T16:53:56-03:00 OpenWrt dnsmasq[2410]: failed to send packet: Operation not permitted
2021-01-26T20:05:30-03:00 OpenWrt dnsmasq[2410]: failed to send packet: Operation not permitted
Can i do this and let it there waiting for maybe more than 24 hours? Will this harm the router or, at least, its functionality? (I'm guessing that this may require extra resources from the router that may negatively impact its performance)
Thanks for your reply and for the quick answer fixing the bug!
I would run that with GNU screen. And no, it will not harm the router.
Good idea!
I'll try to do this for the next few days, then
root@OpenWrt:~# strace -Z --trace=sendmsg -p $(pidof dnsmasq)
strace: unrecognized option: Z
This is strace 5.0-1.
On Ubuntu (strace version 5.5), the -Z option exists (print only syscalls that returned with an error code), but I'm not sure what would be the alternative in Openwrt's strace.