[libvirt] [PATCH v3] Loop through all resolved addresses in virNetSocketNewListenTCP

Olaf Hering olaf at aepfle.de
Wed Jul 4 11:48:56 UTC 2018


Am Wed, 4 Jul 2018 11:57:58 +0100
schrieb Daniel P. Berrangé <berrange at redhat.com>:

> On Mon, Jun 04, 2018 at 12:29:37PM +0200, Olaf Hering wrote:
> > In this case the resolver returns not only the IPv4 addresses but also
> > IPv6. Binding the IPv6 address will obviously fail. But this terminates
> > the entire loop, even if binding to IPv4 succeeded.  
> Could you elaborate on this a bit more, as on reflection I'm not sure
> I understand the flaw here. Could you show the 'ip addr' output and
> corresponding hostname resolution results, and say what errno you
> are seeing from bind().

Not sure what is unclear about this statement.
The hostname resolves to ipv4+ipv6. Binding to ipv4 works because this
address is available on the interface. Binding to ipv6 fails because this
address not not available on any interface.
Since bind() already succeeded (or will succeed) for one address, there is
no reason to error out. Anyone who connects to an resolved ipv6 address will
get an error, and moves on to try the resolved ipv4 address.
libvirt is overdoing things here.

> This EDESTADDRREQ feels a bit odd to use - "Destination address required"
> doesn't make much sense for something that has to be a local address.

Maybe that depends on the context. The whole function does not try hard
to preserve all possible errors for the nsocks==0 case. This specific new
case just assumes that bind() was the thing that resulted in nsocks==0.
There are other error paths.

What errno value do you suggest for nsocks=0?

Olaf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180704/3b211b69/attachment-0001.sig>


More information about the libvir-list mailing list