[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZdG3AX1yiXRoohrY@moon>
Date: Sun, 18 Feb 2024 08:51:29 +0100
From: g1pi@...ero.it
To: musl@...ts.openwall.com
Cc: g1pi@...ero.it
Subject: Re: dns resolution failure in virtio-net guest
On Sat, Feb 17, 2024 at 01:45:34PM -0500, Rich Felker wrote:
> [...]
>
> UDP is "allowed" to drop packets any time for any reason, but that
> doesn't mean it's okay to do so in the absence of a good reason, or
> that musl should work around bugs where that happens, especially when
> they're not a fundamental part of Linux but a particular
> virtualization configuration.
I expected the network to drop a UDP packet anywhere, just not at the
boundary between kernel-space and user-space: it's gratuitously rude.
I agree a workaround is not worth the effort, although I suspect such
a configuration to be more common than not.
>
> I suggest you run tcpdump on the host and watch what's happening, and
> I suspect you'll find this is qemu's virtio network being... qemu. It
> probably does not do any real NAT, but directly rewrites source and
> destination addresses so that your local caching DNS sees *two
> identical queries* (same source/dest host/port combination, same query
> id) and treats the second as a duplicated packet and ignores it. Or it
> may be something different, but at least inspecting the actual network
> traffic coming out of the qemu process will tell you what's going on.
>
On the host side all is fine: the cache log shows that it receives the
request and replies correctly, and tcpdump agrees. I had already
checked that.
But tcpdump on the guest side surprised me:
Good case -- 16 msec delay before second sendto()
7:32:44.332 IP 10.0.2.15.43276 > 10.0.2.2.53: 33452+ A? example.com. (29)
7:32:44.333 IP 10.0.2.2.53 > 10.0.2.15.43276: 33452 1/0/0 A 93.184.216.34 (45)
7:32:44.349 IP 10.0.2.15.43276 > 192.168.1.123.53: 33452+ A? example.com. (29)
Bad case -- rushing the sendto()s
7:32:55.358 IP 10.0.2.15.46537 > 10.0.2.2.53: 33452+ A? example.com. (29)
7:32:55.358 IP 10.0.2.15.46537 > 192.168.1.123.53: 33452+ A? example.com. (29)
7:32:55.358 IP *127.0.0.1*.53 > 10.0.2.15.46537: 33452 1/0/0 A 93.184.216.34 (45)
The response packet does arrive, but has wrong src host. Same behaviour
in linux and bsd guests.
I believe you guessed correctly that this is a bug in qemu, just more
interesting than I initially thought. Most likely it's in the
virtio-net driver, which was ported also to the BSDs. Any suggestion
about how to report it?
g.b.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
