9:14 a.m.
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.
Thanks
Laszlo