Bug 878717 - Vncserver can't only listen on one kind of protocl (IPV4 or IPv6) at same time
Summary: Vncserver can't only listen on one kind of protocl (IPV4 or IPv6) at same time
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.0
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Gerd Hoffmann
QA Contact: Guo, Zhiyi
URL:
Whiteboard:
Depends On: 796043
Blocks: 880347 790326
TreeView+ depends on / blocked
 
Reported: 2012-11-21 03:46 UTC by Amos Kong
Modified: 2016-11-07 20:08 UTC (History)
27 users (show)

Fixed In Version: qemu-2.4.0
Doc Type: Bug Fix
Doc Text:
Clone Of: 796043
Environment:
Last Closed: 2016-11-07 20:08:41 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2673 normal SHIPPED_LIVE qemu-kvm-rhev bug fix and enhancement update 2016-11-08 01:06:13 UTC

Comment 1 RHEL Program Management 2012-12-14 08:20:40 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 2 Alexandre Oliva 2014-05-27 20:48:34 UTC
From bug 1098659 comment 9, I assume libvirt explicitly uses AI_ADDRCONFIG as a hint.  In this case, discarding IPv4 addresses found, when only IPv6 addresses and IPv4 loopback addresses are configured, is the expected behavior of getaddrinfo per RFC 3493.  It is possible that future releases of glibc revisit this behavior, because it conflicts with POSIX, but I don't envision our making such major changes to getaddrinfo behavior in current releases, so I'm inclined to recommend libvirt to drop AI_ADDRCONFIG for now, if the problem remains, although bug 796043 seems to indicate it was fixed.

Comment 4 Amos Kong 2014-09-26 01:46:39 UTC
In Bug 796043 we THOUGHT it's not a function bug, so we fix it by adding an clear error message.

Until now I still agree with original decision. We can see both IPv4 and IPv6 addresses are configured in 'lo', but we can only indicate to use one of them.

# qemu-kvm -vnc [::1]:0 -> listen IPV6
# qemu-kvm -vnc 127.0.0.1:0 -> listen IPV4

# qemu-kvm -vnc localhost:0 -> listen IPV4
# qemu-kvm -vnc :0 -> listen IPV4

This is the test result in my laptop, localhost is parsed to IPv6 firstly, it depends on the configuration in /etc/hosts

=====================================================

In QEMU (qemu/util/qemu-sockets.c), we set AI_ADDRCONFIG in three parts.

1) TCP listen:
   ai.ai_flags = AI_PASSIVE | AI_ADDRCONFIG;                                                                                                                               

2) TCP client:
   ai.ai_flags = AI_CANONNAME | AI_ADDRCONFIG;                                                                                                                                     

3) UDP:
   ai.ai_flags = AI_CANONNAME | AI_ADDRCONFIG;


What's the expected result after remove this flag?

We need to distinguish internal vs. public, IPv4 vs. IPv6. I don't think we need to change anything here.

Comment 5 Amos Kong 2014-09-26 01:52:01 UTC
Please correct me if the subject fixing is not correct.

I tried to remove AI_ADDRCONFIG from TCP listen.

Result:

# qemu-kvm -vnc localhost:0 -> still only listen IPV4
# qemu-kvm -vnc :0 -> still only listen IPV4

Comment 6 Ján Tomko 2014-09-26 08:09:03 UTC
(In reply to Alexandre Oliva from comment #2)
> From bug 1098659 comment 9, I assume libvirt explicitly uses AI_ADDRCONFIG
> as a hint.  In this case, discarding IPv4 addresses found, when only IPv6
> addresses and IPv4 loopback addresses are configured, is the expected
> behavior of getaddrinfo per RFC 3493.  It is possible that future releases
> of glibc revisit this behavior, because it conflicts with POSIX, but I don't
> envision our making such major changes to getaddrinfo behavior in current
> releases, so I'm inclined to recommend libvirt to drop AI_ADDRCONFIG for
> now, if the problem remains, although bug 796043 seems to indicate it was
> fixed.

Libvirt doesn't create the VNC socket, it only checks for available ports without ADDRCONFIG, so the problem with binding to 127.0.0.1 here is in QEMU.

ADDRCONFIG is still used for listening and connecting in libvirt (but it was dropped for listening to wildcard an localhost addresses in RHEL-7 for bug 1098659). This is used for the daemon listen socket and connecting to the destination QEMU when migrating, which don't seem that useful to do with localhost.

(In reply to Amos Kong from comment #5)
> Please correct me if the subject fixing is not correct.
> 
> I tried to remove AI_ADDRCONFIG from TCP listen.
> 
> Result:
> 
> # qemu-kvm -vnc localhost:0 -> still only listen IPV4
> # qemu-kvm -vnc :0 -> still only listen IPV4

Two sockets are needed to listen on both IPv4 and IPv6 localhost, there is a RFE for qemu: bug 1038963

Comment 7 Pavel Šimerda (pavlix) 2014-09-26 09:16:07 UTC
It is correct to remove AI_ADDRCONFIG from any getaddrinfo queries for listening on sockets even though it may not fix your particular issue. The rest will be covered by Alexander in his new proposal regarding AI_PASSIVE and address ordering.

Comment 8 Gerd Hoffmann 2015-01-15 10:36:13 UTC
(In reply to Pavel Šimerda (pavlix) from comment #7)
> It is correct to remove AI_ADDRCONFIG from any getaddrinfo queries for
> listening on sockets even though it may not fix your particular issue. The
> rest will be covered by Alexander in his new proposal regarding AI_PASSIVE
> and address ordering.

Removing AI_ADDRCONFIG in qemu for listening tcp sockets doesn't change
behavior.  We can do that in upstream qemu if it is the CorrectThing[tm].

I no reason to bother downstream though, picking up with the next rhel7 qemu rebase will do IMO.

Comment 10 Gerd Hoffmann 2015-08-31 08:18:42 UTC
Upstream fix for AI_ADDRCONFIG (in 2.4.0):
3de3d69 util/qemu-sockets: improve ai_flag hints for ipv6 hosts

Let's pick it up with the 7.3 rebase ...

Comment 12 Gerd Hoffmann 2016-04-15 11:07:20 UTC
(In reply to Gerd Hoffmann from comment #10)
> Upstream fix for AI_ADDRCONFIG (in 2.4.0):
> 3de3d69 util/qemu-sockets: improve ai_flag hints for ipv6 hosts
> 
> Let's pick it up with the 7.3 rebase ...

We are at 2.5.0 meanwhile, so it's handled now.

Note: this fixes the issue discussed in comment 7+8, vnc not supporting ipv4 + ipv6 at the same time is tracked in separate bug 1038963.

Comment 14 Guo, Zhiyi 2016-09-12 05:36:24 UTC
Hi Gerd,

Could you tell QE how to verify this bug? Maybe something queried from strace? As the errata will reach the deadline, please help to provide information ASAP, thanks!

BR/
Guo, Zhiyi

Comment 15 Gerd Hoffmann 2016-09-12 06:53:09 UTC
(In reply to Guo, Zhiyi from comment #14)
> Hi Gerd,
> 
> Could you tell QE how to verify this bug? Maybe something queried from
> strace? As the errata will reach the deadline, please help to provide
> information ASAP, thanks!

Easiest is checking the source code I think.

This call goes to the dns resolver in glibc, it wouldn't be directly visible in a system call trace.

Comment 20 errata-xmlrpc 2016-11-07 20:08:41 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2673.html


Note You need to log in before you can comment on or make changes to this bug.