Re: [PATCH] udp: Fix breakage of UDP error handling by PKTINFO support

[Stefano Brivio <sbrivio@redhat.com>]

On Mon, 14 Apr 2025 13:58:53 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> We recently enabled the IP_PKTINFO / IPV6_RECVPKTINFO socket options on our
> UDP sockets.  This lets us obtain and properly handle the specific local
> address used when we're "listening" with a socket on 0.0.0.0 or ::.
> 
> However, the PKTINFO cmsgs this option generates appear on error queue
> messages as well as regular datagrams.  udp_sock_recverr() doesn't expect
> this and so flags an unrecoverable error when it can't parse the control
> message.
> 
> Correct this by adding space in udp_sock_recverr()s control buffer for the
> additional PKTINFO data, and scan through all cmsgs for the RECVERR, rather
> than only looking at the first one.
> 
> Link: https://bugs.passt.top/show_bug.cgi?id=99
> Fixes: f4b0dd8b06 ("udp: Use PKTINFO cmsgs to get destination address..")
> Reported-by: Stefano Brivio <sbrivio@redhat.com>
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

The patch looks good to me, but I'm hitting something in my tests (with
my recent DNS fix) that's perhaps not intended.

On the host:

  $ cat /etc/resolv.conf
  nameserver 127.0.0.1

...and nobody is listening on that address. Podman passes
--dns-forward 169.254.1.1 (default) and in the container:

  $ podman run --net=pasta:-d,-l,/tmp/pasta.log --rm -ti alpine sh

I do:

  / # nslookup google.com 169.254.1.1
  ;; connection timed out; no servers could be reached

which is expected. But logs show a warning:

49.5377:          Flow 0 (NEW): FREE -> NEW
49.5377:          Flow 0 (INI): NEW -> INI
49.5377:          Flow 0 (INI): TAP [88.198.0.164]:43458 -> [169.254.1.1]:53 => ?
49.5377:          Flow 0 (TGT): INI -> TGT
49.5377:          Flow 0 (TGT): TAP [88.198.0.164]:43458 -> [169.254.1.1]:53 => HOST [0.0.0.0]:43458 -> [127.0.0.1]:53
49.5377:          Flow 0 (UDP flow): TGT -> TYPED
49.5377:          Flow 0 (UDP flow): TAP [88.198.0.164]:43458 -> [169.254.1.1]:53 => HOST [0.0.0.0]:43458 -> [127.0.0.1]:53
49.5378:          Flow 0 (UDP flow): Side 0 hash table insert: bucket: 148325
49.5378:          Flow 0 (UDP flow): Side 1 hash table insert: bucket: 309967
49.5378:          Flow 0 (UDP flow): TYPED -> ACTIVE
49.5378:          Flow 0 (UDP flow): TAP [88.198.0.164]:43458 -> [169.254.1.1]:53 => HOST [127.0.0.1]:43458 -> [127.0.0.1]:53
49.5378: WARNING: Error peeking at socket address: Connection refused
49.5379:          ICMP error on UDP socket 208: Connection refused
49.5379:          ICMP error on UDP socket 208: Connection refused
52.0404:          ICMP error on UDP socket 208: Connection refused
52.0404:          ICMP error on UDP socket 208: Connection refused

and I'm not sure if that warning is intended. By the way, I have the
feeling that it now takes longer (with the whole IP_PKTINFO thing) for
nslookup to fail, as if those ICMP errors were not relayed anymore, but
I'm not sure about this, and I didn't investigate yet.

-- 
Stefano