Re: [musl] dns resolution failure in virtio-net guest

[g1pi@libero.it]

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.