[Qemu-devel] [Bug 1837909] [NEW] test-char fails if host has no network interfaces

[Qemu-devel] [Bug 1837909] [NEW] test-char fails if host has no network interfaces

[Cole Robinson]

Public bug reported:

# ./tests/test-char 
# random seed: R02S8602535bf831a74bca571d8c416d8161
1..34
# Start of char tests
...
ok 12 /char/websocket
# Start of stdio tests
# End of stdio tests
# Start of socket tests
# Start of server tests
# Start of mainloop tests
Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421:
# 
# address resolution failed for 127.0.0.1:42275: Name or service not known
# 

Aborted (core dumped)


# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever


This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or ipv6 address available

This host setup may seem niche, but it is what the 'mock' RPM build tool
has by default. In Fedora we run the test suite during the RPM build, so
the failing test causes a bit of pain for certain workflows

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1837909

Title:
  test-char fails if host has no network interfaces

Status in QEMU:
  New

Bug description:
  # ./tests/test-char 
  # random seed: R02S8602535bf831a74bca571d8c416d8161
  1..34
  # Start of char tests
  ...
  ok 12 /char/websocket
  # Start of stdio tests
  # End of stdio tests
  # Start of socket tests
  # Start of server tests
  # Start of mainloop tests
  Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421:
  # 
  # address resolution failed for 127.0.0.1:42275: Name or service not known
  # 

  Aborted (core dumped)

  
  # ip a
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      inet 127.0.0.1/8 scope host lo
         valid_lft forever preferred_lft forever
      inet6 ::1/128 scope host 
         valid_lft forever preferred_lft forever

  
  This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or ipv6 address available

  This host setup may seem niche, but it is what the 'mock' RPM build
  tool has by default. In Fedora we run the test suite during the RPM
  build, so the failing test causes a bit of pain for certain workflows

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1837909/+subscriptions

[Qemu-devel] [Bug 1837909] Re: test-char fails if host has no network interfaces

[elmarco]

This should be addressed by:
https://patchew.org/QEMU/20190713143311.17620-1-marcandre.lureau@redhat.com/

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1837909

Title:
  test-char fails if host has no network interfaces

Status in QEMU:
  New

Bug description:
  # ./tests/test-char 
  # random seed: R02S8602535bf831a74bca571d8c416d8161
  1..34
  # Start of char tests
  ...
  ok 12 /char/websocket
  # Start of stdio tests
  # End of stdio tests
  # Start of socket tests
  # Start of server tests
  # Start of mainloop tests
  Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421:
  # 
  # address resolution failed for 127.0.0.1:42275: Name or service not known
  # 

  Aborted (core dumped)

  
  # ip a
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      inet 127.0.0.1/8 scope host lo
         valid_lft forever preferred_lft forever
      inet6 ::1/128 scope host 
         valid_lft forever preferred_lft forever

  
  This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or ipv6 address available

  This host setup may seem niche, but it is what the 'mock' RPM build
  tool has by default. In Fedora we run the test suite during the RPM
  build, so the failing test causes a bit of pain for certain workflows

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1837909/+subscriptions

Re: [Qemu-devel] [Bug 1837909] [NEW] test-char fails if host has no network interfaces

[Philippe Mathieu-Daudé]

On 7/25/19 4:20 PM, Cole Robinson wrote:
> Public bug reported:
> 
> # ./tests/test-char 
> # random seed: R02S8602535bf831a74bca571d8c416d8161
> 1..34
> # Start of char tests
> ...
> ok 12 /char/websocket
> # Start of stdio tests
> # End of stdio tests
> # Start of socket tests
> # Start of server tests
> # Start of mainloop tests
> Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421:
> # 
> # address resolution failed for 127.0.0.1:42275: Name or service not known
> # 
> 
> Aborted (core dumped)
> 
> 
> # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>        valid_lft forever preferred_lft forever
>     inet6 ::1/128 scope host 
>        valid_lft forever preferred_lft forever
> 
> 
> This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or ipv6 address available

GETADDRINFO(3)

  If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4
  addresses are returned in the list pointed to by res only if
  the local system has at least one IPv4 address configured, and
  IPv6 addresses are returned only if the local system has at
  least one IPv6 address configured.  The loopback address is not
  considered for this case as valid as a configured address.
  This flag is useful on, for example, IPv4-only systems, to
  ensure  that  getaddrinfo() does not return IPv6 socket addresses
  that would always fail in connect(2) or bind(2).

I'm a little confused, and I don't feel fluent enough with English to be
sure that "only if A and only if B" is equivalent to "requires (A or
B)". Maybe the man page should use 'or' instead of 'and' here...

> This host setup may seem niche, but it is what the 'mock' RPM build tool
> has by default. In Fedora we run the test suite during the RPM build, so
> the failing test causes a bit of pain for certain workflows

Would this diff snippet help?

-- >8 --
diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c
index a5092dbd12..9ad775270d 100644
--- a/util/qemu-sockets.c
+++ b/util/qemu-sockets.c
@@ -417,7 +417,7 @@ static struct addrinfo
*inet_parse_connect_saddr(InetSocketAddress *saddr,
         ai.ai_flags &= ~AI_V4MAPPED;
         rc = getaddrinfo(saddr->host, saddr->port, &ai, &res);
     }
-    if (rc != 0) {
+    if (rc and rc != EAI_NONAME) {
         error_setg(errp, "address resolution failed for %s:%s: %s",
                    saddr->host, saddr->port, gai_strerror(rc));
         return NULL;
---

> 
> ** Affects: qemu
>      Importance: Undecided
>          Status: New
> 

Re: [Qemu-devel] [Bug 1837909] [NEW] test-char fails if host has no network interfaces

[Philippe Mathieu-Daudé]

On 7/25/19 4:20 PM, Cole Robinson wrote:
> Public bug reported:
> 
> # ./tests/test-char 
> # random seed: R02S8602535bf831a74bca571d8c416d8161
> 1..34
> # Start of char tests
> ...
> ok 12 /char/websocket
> # Start of stdio tests
> # End of stdio tests
> # Start of socket tests
> # Start of server tests
> # Start of mainloop tests
> Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421:
> # 
> # address resolution failed for 127.0.0.1:42275: Name or service not known
> # 
> 
> Aborted (core dumped)
> 
> 
> # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>        valid_lft forever preferred_lft forever
>     inet6 ::1/128 scope host 
>        valid_lft forever preferred_lft forever
> 
> 
> This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or ipv6 address available

GETADDRINFO(3)

  If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4
  addresses are returned in the list pointed to by res only if
  the local system has at least one IPv4 address configured, and
  IPv6 addresses are returned only if the local system has at
  least one IPv6 address configured.  The loopback address is not
  considered for this case as valid as a configured address.
  This flag is useful on, for example, IPv4-only systems, to
  ensure  that  getaddrinfo() does not return IPv6 socket addresses
  that would always fail in connect(2) or bind(2).

I'm a little confused, and I don't feel fluent enough with English to be
sure that "only if A and only if B" is equivalent to "requires (A or
B)". Maybe the man page should use 'or' instead of 'and' here...

> This host setup may seem niche, but it is what the 'mock' RPM build tool
> has by default. In Fedora we run the test suite during the RPM build, so
> the failing test causes a bit of pain for certain workflows

Would this diff snippet help?

-- >8 --
diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c
index a5092dbd12..9ad775270d 100644
--- a/util/qemu-sockets.c
+++ b/util/qemu-sockets.c
@@ -417,7 +417,7 @@ static struct addrinfo
*inet_parse_connect_saddr(InetSocketAddress *saddr,
         ai.ai_flags &= ~AI_V4MAPPED;
         rc = getaddrinfo(saddr->host, saddr->port, &ai, &res);
     }
-    if (rc != 0) {
+    if (rc and rc != EAI_NONAME) {
         error_setg(errp, "address resolution failed for %s:%s: %s",
                    saddr->host, saddr->port, gai_strerror(rc));
         return NULL;
---

> 
> ** Affects: qemu
>      Importance: Undecided
>          Status: New
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1837909

Title:
  test-char fails if host has no network interfaces

Status in QEMU:
  New

Bug description:
  # ./tests/test-char 
  # random seed: R02S8602535bf831a74bca571d8c416d8161
  1..34
  # Start of char tests
  ...
  ok 12 /char/websocket
  # Start of stdio tests
  # End of stdio tests
  # Start of socket tests
  # Start of server tests
  # Start of mainloop tests
  Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421:
  # 
  # address resolution failed for 127.0.0.1:42275: Name or service not known
  # 

  Aborted (core dumped)

  
  # ip a
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      inet 127.0.0.1/8 scope host lo
         valid_lft forever preferred_lft forever
      inet6 ::1/128 scope host 
         valid_lft forever preferred_lft forever

  
  This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or ipv6 address available

  This host setup may seem niche, but it is what the 'mock' RPM build
  tool has by default. In Fedora we run the test suite during the RPM
  build, so the failing test causes a bit of pain for certain workflows

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1837909/+subscriptions

[Bug 1837909] Re: test-char fails if host has no network interfaces

[Thomas Huth]

The QEMU project is currently considering to move its bug tracking to
another system. For this we need to know which bugs are still valid
and which could be closed already. Thus we are setting older bugs to
"Incomplete" now.

If you still think this bug report here is valid, then please switch
the state back to "New" within the next 60 days, otherwise this report
will be marked as "Expired". Or please mark it as "Fix Released" if
the problem has been solved with a newer version of QEMU already.

Thank you and sorry for the inconvenience.


** Changed in: qemu
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1837909

Title:
  test-char fails if host has no network interfaces

Status in QEMU:
  Incomplete

Bug description:
  # ./tests/test-char 
  # random seed: R02S8602535bf831a74bca571d8c416d8161
  1..34
  # Start of char tests
  ...
  ok 12 /char/websocket
  # Start of stdio tests
  # End of stdio tests
  # Start of socket tests
  # Start of server tests
  # Start of mainloop tests
  Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421:
  # 
  # address resolution failed for 127.0.0.1:42275: Name or service not known
  # 

  Aborted (core dumped)

  
  # ip a
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      inet 127.0.0.1/8 scope host lo
         valid_lft forever preferred_lft forever
      inet6 ::1/128 scope host 
         valid_lft forever preferred_lft forever

  
  This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or ipv6 address available

  This host setup may seem niche, but it is what the 'mock' RPM build
  tool has by default. In Fedora we run the test suite during the RPM
  build, so the failing test causes a bit of pain for certain workflows

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1837909/+subscriptions

[Bug 1837909] Re: test-char fails if host has no network interfaces

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1837909

Title:
  test-char fails if host has no network interfaces

Status in QEMU:
  Expired

Bug description:
  # ./tests/test-char 
  # random seed: R02S8602535bf831a74bca571d8c416d8161
  1..34
  # Start of char tests
  ...
  ok 12 /char/websocket
  # Start of stdio tests
  # End of stdio tests
  # Start of socket tests
  # Start of server tests
  # Start of mainloop tests
  Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421:
  # 
  # address resolution failed for 127.0.0.1:42275: Name or service not known
  # 

  Aborted (core dumped)

  
  # ip a
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      inet 127.0.0.1/8 scope host lo
         valid_lft forever preferred_lft forever
      inet6 ::1/128 scope host 
         valid_lft forever preferred_lft forever

  
  This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or ipv6 address available

  This host setup may seem niche, but it is what the 'mock' RPM build
  tool has by default. In Fedora we run the test suite during the RPM
  build, so the failing test causes a bit of pain for certain workflows

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1837909/+subscriptions