On Wed, Feb 17, 2021 at 4:36 PM Simon Kelley <si...@thekelleys.org.uk> wrote: > > On 09/02/2021 04:08, Amit wrote: > > On Wed, Feb 3, 2021 at 12:16 PM Geert Stappers <stapp...@stappers.nl> wrote: > >> > > > > [snip] > > > >> > >> My guess: > >> > >> } } Where is the `ping www.google.com` done? > >> } The ping is done at the end of the chain > >> } } Where and how is IPv6 disabled? > >> } Same machine, magic from Network Manager > >> } > >> } Although disabling IPv6 is probably not the solution this was just an > >> } observation that disabling seems to allow queries to function again > >> > >> The dnsmasq machine has no or a broken IPv6 configuration. > >> Breaking IPv6 on the client at the end of the chain > >> results in a fallback (failback?) to IPv4. > >> > >> > >> The install of version 2.82 probably has some side effects, > >> side effects that cover or undo problems. > >> > >> > >>> If there are more details required, I can provide them. > >> > >> Feedback on the guess is appriciated. > > > > Following up. So about 20-30 devices in our fleet were affected, so a > > rollback to 2.82 was performed. One of our > > devs did an analysis which points to a different theory on why the > > issue is happening: > > > > ``` > > tcpdump shows dnsmasq send the query out both Ethernet and Wi-Fi, but > > only shows the reply coming back on Ethernet. ip link (output below) > > shows my Wi-Fi interface, wlp2s0, is DORMANT, which could be the > > reason we don't get the reply on Wi-Fi? > > > > When building from git://thekelleys.org.uk/dnsmasq.git > > cfcafdd27c74dc187fe96a9cfa88b1aef53540a0 with HAVE_DBUS enabled > > in config.h (to make it work under NetworkManager), dnsmasq sees the > > reply in reply_query, but doesn't get as far as process_reply. > > > > It seems reply_query is returning early here [1] when lookup_frec > > returns NULL? Perhaps the recently-introduced de-duplication isn't > > storing all the correct query hashes? And/or it assumes we will > > eventually get a reply on all configured interfaces? > > > > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/forward.c;h=8fb03273e1744fb2c2a7606213eee7249ab02278;hb=cfcafdd27c74dc187fe96a9cfa88b1aef53540a0#l849 > > > > $ ip l > > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > > mode DEFAULT group default qlen 1000 > > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > > 2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc > > pfifo_fast state DOWN mode DEFAULT group default qlen 1000 > > link/ether 8c:16:45:ac:fe:88 brd ff:ff:ff:ff:ff:ff > > 3: enx70886b8e26e0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > > pfifo_fast state UP mode DEFAULT group default qlen 1000 > > link/ether 70:88:6b:8e:26:e0 brd ff:ff:ff:ff:ff:ff > > 4: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue > > state UP mode DORMANT group default qlen 1000 > > link/ether 7c:2a:31:0c:53:55 brd ff:ff:ff:ff:ff:ff > > ``` > > > > Hope this gives you further clue. > > > > _______________________________________________ > > Thanks for your work on this. I just pushed a commit at > > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=141a26f979b4bc959d8e866a295e24f8cf456920 > > Would it be possible to test that, and see if it sorts the problem. > > mailing list thread at > > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014697.html > > provides some explanation.
Thanks for the patch. Tried it but unfortunately the same issue persists when an IPV6 DNS server is present and configured. Let me know if you need more logs or other tests I can run. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
