[Dnsmasq-discuss] dnsmasq v2.86?

Andre Heider a.heider at gmail.com
Wed Aug 11 14:19:32 UTC 2021


Hi there,

it seems I can trigger this semi-reliably while powering up 2 KVM 
windows instances in parallel.

This is the tail of log-queries:
dnsmasq[6591]: query[A] foo.internal from 192.168.0.foo
dnsmasq[6591]: DHCP foo.internal is 192.168.0.foo
dnsmasq[6591]: query[AAAA] foo.internal from 192.168.0.foo
dnsmasq[6591]: config foo.internal is NODATA-IPv6
dnsmasq[6591]: query[A] ipv4only.arpa from 192.168.0.foo

And this is where dnsmasq stop replying altogether and hogs the cpu.
Note that foo.internal is the kvm host with the ip 192.168.0.foo.

Using gdbserver doesn't yield too much info, looks like because of lto 
maybe (which OpenWrt does for dnsmasq)?
(gdb) info threads
   Id   Target Id                  Frame
* 1    Thread 6591.6591 "dnsmasq" 0x555715f1 in forward_query.lto_priv ()
(gdb) bt full
#0  0x555715f1 in forward_query.lto_priv ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Does that help, maybe?

Regards,
Andre

On 11/08/2021 08:36, Andre Heider wrote:
> On 10/08/2021 23:11, Simon Kelley wrote:
>> On 10/08/2021 14:53, Dominik wrote:
>>> Hey Simon,
>>>
>>> various dnsmasq-2.86 test tags are around and it doesn't look like
>>> there are any intermediate bugs around. The Pi-hole beta seems to have
>>> attracted at least a few couple of dozen additional testers and nothing
>>> seems to have come up here, either.
>>>
>>> How do you feel about tagging a v2.86 release?
>>>
>>> Best regards,
>>> Dominik
>>>
>>>
>>
>> I've been accumulating patches for a couple of weeks, and started
>> working through those tonight. None are very intrusive or controversial.
>> Once those are done, I'll tag rc1.
> 
> I'm using 2.86test6 on OpenWrt, and I think I've found a bug. Detail's 
> are vague so far but ever since I've started DoT with stubby as upstream 
> server, dnsmasq every now and then gets into a mode where it stops 
> responding to request completely and just sits there using 100% cpu 
> power on one core.
> I haven't found a way yet to trigger that reliably, but it feels like 
> timing/parallel requests.
> 
> Does that ring any bells?
> 
> Any hints on how to get more relevant info on the situation? Sometimes 
> it takes over a day, so verbose logs seem to be out of the question 
> (since it's a small router). How to I get a backtrace without gdb?
> 
> config created by OpenWrt:
> conf-file=/etc/dnsmasq.conf
> dhcp-authoritative
> domain-needed
> no-resolv
> localise-queries
> enable-ubus=dnsmasq
> expand-hosts
> bind-dynamic
> local-service
> quiet-dhcp
> edns-packet-max=1280
> domain=internal
> local=/internal/
> server=127.0.0.1#5453
> addn-hosts=/tmp/hosts
> dhcp-leasefile=/tmp/dhcp.leases
> stop-dns-rebind
> conf-file=/usr/share/dnsmasq/trust-anchors.conf
> dnssec
> dhcp-broadcast=tag:needs-broadcast
> conf-dir=/tmp/dnsmasq.d
> user=dnsmasq
> group=dnsmasq
> dhcp-ignore-names=tag:dhcp_bogus_hostname
> conf-file=/usr/share/dnsmasq/dhcpbogushostname.conf
> bogus-priv
> conf-file=/usr/share/dnsmasq/rfc6761.conf
> no-dhcp-interface=pppoe-wan
> dhcp-range=set:lan,192.168.0.200,192.168.0.254,255.255.255.0,12h
> 
> stubby config created by OpenWrt:
> resolution_type: GETDNS_RESOLUTION_STUB
> round_robin_upstreams: 1
> appdata_dir: "/var/lib/stubby"
> trust_anchors_backoff_time: 2500
> tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
> tls_query_padding_blocksize: 128
> edns_client_subnet_private: 1
> idle_timeout: 10000
> listen_addresses:
>    - 127.0.0.1 at 5453
> dns_transport_list:
>    - GETDNS_TRANSPORT_TLS
> upstream_recursive_servers:
>    - address_data: 5.1.66.255
>      tls_auth_name: "dot.ffmuc.net"
>    - address_data: 185.150.99.255
>      tls_auth_name: "dot.ffmuc.net"
>    - address_data: 185.95.218.42
>      tls_auth_name: "dns.digitale-gesellschaft.ch"
>    - address_data: 185.95.218.43
>      tls_auth_name: "dns.digitale-gesellschaft.ch"
> 




More information about the Dnsmasq-discuss mailing list