that's great! thanks to the openwrt team for the quick work from that patch:
"If identical queries from IPv4 and IPv6 sources are combined by the new code added in 15b60ddf935a531269bb8c68198de012a4967156 then replies can end up being sent via the wrong family of socket. The ->fd should be per query, not per-question. In bind-interfaces mode, this could also result in replies being sent via the wrong socket even when IPv4/IPV6 issues are not in play." On Sat, Jan 23, 2021 at 11:29 AM Jonathan Foulkes <j...@jonathanfoulkes.com> wrote: > > Hi Seb, someone did just that and even better, compared two builds with the > dnsmasq being the only variable, and did not see any differences: > https://forum.openwrt.org/t/security-advisory-2021-01-19-1-dnsmasq-multiple-vulnerabilities/85903/85 > > From other comments, looks like they found the bug and are testing the fix. > https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commitdiff;h=9a18346676850646764072ffcfd32ad9396d95c3 > > Jonathan > > > On Jan 22, 2021, at 4:40 PM, Sebastian Moeller <moell...@gmx.de> wrote: > > > > Could you try to run top or htop and look at the CPU load? I could imagine > > that the fixes dnsmasq might have some CPU spikes that simply leave not > > enough cycles for the traffic shaper? > > > > Best Regards > > Sebastian > > > >> On Jan 22, 2021, at 22:25, Jonathan Foulkes <j...@jonathanfoulkes.com> > >> wrote: > >> > >> I figure there should be no inter-dependencies there, but the side-effect > >> of the new dnsmasq is pretty serious. > >> > >> I did not install .6, I only performed an opkg update of the dnamasq > >> package itself. So kernal is the same in my case. > >> > >> But others running a full .6 build report similar QoS issues. > >> > >> I regressed back to .4 and all is good on the QoS front, waiting until a > >> new drop of dnsmasq before trying again. > >> > >> - Jonathan > >> > >>> On Jan 22, 2021, at 4:15 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > >>> > >>> Jonathan Foulkes <j...@jonathanfoulkes.com> writes: > >>> > >>>> I installed the updated package on a 19.07.4 box running cake, and QoS > >>>> performance went down the tubes. > >>>> Last night it locked up completely while attempting to stream. > >>>> > >>>> See the PingPlots others have posted to this forum thread, mine look > >>>> similar, went from constant sub 50ms to very spiky, then some loss, loss > >>>> increasing, and if high traffic, lock-up. > >>>> https://forum.openwrt.org/t/security-advisory-2021-01-19-1-dnsmasq-multiple-vulnerabilities/85903/39 > >>>> > >>>> load is low, sirq is low, so box does not seem stressed. > >>>> > >>>> Any reason Cake would be sensitive to a dnsmasq bug? > >>> > >>> No, not really. I mean, dnsmasq could be sending some traffic that > >>> interferes with stuff? Or it could be a kernel regression - the release > >>> did bump the kernel version as well... > >>> > >>> -Toke > >> > >> _______________________________________________ > >> Bloat mailing list > >> bl...@lists.bufferbloat.net > >> https://lists.bufferbloat.net/listinfo/bloat > > > > _______________________________________________ > Bloat mailing list > bl...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
