Re: [Libguestfs] [nbdkit PATCH 2/2] server/sockets: get rid of AI_ADDRCONFIG

On 01/19/22 14:47, Richard W.M. Jones wrote: > On Wed, Jan 19, 2022 at 01:46:08PM +0000, Richard W.M. Jones wrote: >> On Tue, Jan 18, 2022 at 11:19:18AM -0600, Eric Blake wrote: >>> On Tue, Jan 18, 2022 at 02:48:33PM +0100, Laszlo Ersek wrote: >>>> + case '4': >>>> + tcpip_sock_af = AF_INET; >>>> + break; >>>> + >>>> + case '6': >>>> + tcpip_sock_af = AF_INET6; >>>> + break; >>> >>> Thus, if the user uses nbdkit -46 (or -64), the last one specified >>> silently overrides the earlier one, rather than being diagnosed as >>> conflicting or explicitly permitting both. The override effect >>> matches the long-option naming --ipv4-only, so I can live with it, >>> but I'm also open to the idea of explicitly adding code to diagnose >>> both options at the same time as an error, if we think that's >>> friendlier than silent override. >> >> Is that actually an error? -4 -6 says you want to listen on IPv4 and >> IPv6 which is redundant but not wrong. > > Oh wait, actually it doesn't work like I expected. > > Is it easy to make -4 -6 listen on both IPv4 & IPv6? That's the default; in that case, just don't specify either. -4 and -6 make AF_INET and AF_INET6 (respectively) the exclusive address family within which the argument of option "-i" is resolved. IOW, -4 and -6 are (intentionally) a very thin wrapper around hints.ai_family. Here's some examples (with the "netstat -anp | grep nbdkit" output pasted after the command line): # most generic use: no -i, no -4, no -6: binds the wildcard address for # both IPv4 and IPv6 $ nbdkit -f null -> tcp 0 0 0.0.0.0:10809 0.0.0.0:* LISTEN 219346/nbdkit tcp6 0 0 :::10809 :::* LISTEN 219346/nbdkit # no "-i", so bind the wildcard address, but restricted to IPv4 with # "-4" $ nbdkit -4 -f null -> tcp 0 0 0.0.0.0:10809 0.0.0.0:* LISTEN 219393/nbdkit # no "-i", so bind the wildcard address, but restricted to IPv6 with # "-6" $ nbdkit -6 -f null -> tcp6 0 0 :::10809 :::* LISTEN 219397/nbdkit # "-i localhost" causes getaddrinfo() to find both the IPv4 and IPv6 # addresses (127.0.0.1 and ::1, respectively) in /etc/hosts $ nbdkit -f -i localhost null -> tcp 0 0 127.0.0.1:10809 0.0.0.0:* LISTEN 219386/nbdkit tcp6 0 0 ::1:10809 :::* LISTEN 219386/nbdkit # same as above, but "-4" restricts the resolution to IPv4 $ nbdkit -i localhost -4 -f null -> tcp 0 0 127.0.0.1:10809 0.0.0.0:* LISTEN 219402/nbdkit # same as above, but "-6" restricts the resolution to IPv6 $ nbdkit -i localhost -6 -f null -> tcp6 0 0 ::1:10809 :::* LISTEN 219405/nbdkit # "-i" is passed a numeric address, so the address family is inherent $ nbdkit -i 127.0.0.1 -f null -> tcp 0 0 127.0.0.1:10809 0.0.0.0:* LISTEN 219411/nbdkit # same, but an IPv6 address is used $ nbdkit -i ::1 -f null -> tcp6 0 0 ::1:10809 :::* LISTEN 219414/nbdkit # repeat the above two, with -4 / -6 restrictions, which are no-ops in # this case $ nbdkit -i 127.0.0.1 -4 -f null -> tcp 0 0 127.0.0.1:10809 0.0.0.0:* LISTEN 219421/nbdkit $ nbdkit -i ::1 -6 -f null -> tcp6 0 0 ::1:10809 :::* LISTEN 219424/nbdkit # We can even attempt resolving the numeric addresses for the *wrong* # address family: $ nbdkit -f -i 127.0.0.1 -6 null nbdkit: getaddrinfo: 127.0.0.1: 10809: Address family for hostname not supported $ nbdkit -f -i ::1 -4 null nbdkit: getaddrinfo: ::1: 10809: Address family for hostname not supported These too are correct, because the numeric address 127.0.0.1 is unresolvable in AF_INET6, and the numeric adress ::1 is unresolvable in AF_INET.