On Mon, 14 Apr 2025 13:58:53 +1000 David Gibson <david(a)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(a)redhat.com> Signed-off-by: David Gibson <david(a)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