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.
So with dnsmasq 2.80-16.3 out, is the first post still valid?
The advice given in message 1 to upgrade to at least these version is still quite valid.
If you already are using 2.80-16.3, you have the required fixes (and also the fixes for new bugs in introduced 2.80-16.2).
I can confirm the issue with dnsmasq 2.83 spamming syslog with "DNSMASQ failed to send packet: Address family not supported by protocol" or similar. The network both has IPv6 enabled and has Windows machines as clients... I was running a snapshot versions from last month. Upgrading dnsmasq with opkg fixed the issue for me.
I tried this weekend to update from 19.07.5 to 19.07.6 (delivered with DNSmasq 2.80-16.2). That didn't work with system log.
Tried to update DNSmasq with LuCi to version 2.80-16.3 (and used my old DHCP config file). Now the system log seems fine again.
uci set dhcp.@dnsmasq[0].cachesize='0'
uci set dhcp.@dnsmasq[0].dnsforwardmax='50'
Are these settings supposed to be set with the updated DNSmasq also? OpenWRT 19.07.6 had the old values preset?
I am having the 19.07.6 with the dnsmasq 2.80-16.2. I get a lot of syslog spamming with the "dnsmasq failed to send packet".
In the luci-interface I can see that the dnsmasq package is upgradeable to 2.80-16.3.
However, when I select to "upgrade" it fails with the following error:
Upgrading dnsmasq on root from 2.80-16.2 to 2.80-16.3... Downloading http://downloads.openwrt.org/releases/19.07.6/packages/mips_24kc/base/dnsmasq_2.80-16.3_mips_24kc.ipk
Errors
Collected errors: * opkg_install_pkg: Package size mismatch: dnsmasq is 103242 bytes, expecting 103238 bytes * opkg_install_cmd: Cannot install package dnsmasq.
The opkg install command failed with code
255.
OK I shot the question too quickly. I should have updated the package list before the upgrade.
Maybe someone else avoids same issue, and scratching his head, by reading my post 
However, I discovered now also a message telling that that there is new config file (now saved on the name dhcp-opkg). I have edited by dhcp preferences + did change the dnsmasq cache to 0. I will study the differences in config files but it could be helpful if someone notified potential real changes in the config i.e. do I need to care about the dhcp-opkg at all.
Did you clicked on Update Lists before trying to upgrade?
Thanks for a quick help.
I did realize, indeed, that I should have updated the package list before the upgrade.
Now I did, and successfully upgraded the dnsmasq.
Hopefully my experience helps other people from doing the same trivial mistake.
Thanks.
Hi, just to verify, I ran the upgrade commands in the first post. I'm on david's build (pretty old but pretty darn good I must say).
Now it says 2.81-2, am I safe and upgraded? Thanks!
# opkg list-installed dnsmasq*
dnsmasq - 2.81-2
No, you are using some old OpenWrt version and have an old version of dnsmasq.
Based on 2,81, you likely have an old master build, which tries to upgrade from old mvebu packages. The mvebu package arch was changed a few months ago from arm_cortex-a9_vfpv3 to arm_cortex-a9_vfpv3-d16.
Sysupgrade to a current build.
Thanks hnyman, appreciate it a lot.
My david build's quite old and I'm not looking into upgrading it at the moment (it just works so well).
Could I "use" a newer package to upgrade only dnsmasq and not do a full sysupgrade?
I'm looking into other builds but at the moment I'm not sure what to do..