Project

General

Profile

Bug #4700

'socket' C test fails when there is no IPv6

Added by neels 2 months ago. Updated about 2 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
08/09/2020
Due date:
% Done:

0%

Spec Reference:

Description

When building libosmocore (I did inside the ttcn3-tests docker container 'nonjenkins-bsc'), make check may fail the socket.c test;
when I revert this patch, the error no longer happens:

osmo_sock_init2: improve support for AF_UNSPEC
2c962f5de1eeea119cfac7d9d92db31c570353b9
I397c633931fd00d4f083955a3c49a40fb002d766

This is the test failure output:

49: socket                                          FAILED (testsuite.at:313)
#                             -*- compilation -*-
49. testsuite.at:308: testing socket ...
../../../src/libosmocore/tests/testsuite.at:313: $abs_top_builddir/tests/socket/socket_test
--- experr      2020-08-09 17:51:39.081588010 +0000
+++ /src/make/libosmocore/tests/testsuite.dir/at-groups/49/stderr       2020-08-09 17:51:39.093588179 +0000
@@ -2,3 +2,7 @@
 invalid: you have to specify either BIND or CONNECT flags
 Unable to find a common protocol (IPv4 or IPv6) for local host: 127.0.0.1 and remote host: ::1.
 Unable to find a common protocol (IPv4 or IPv6) for local host: ::1 and remote host: 127.0.0.1.
+unable to bind socket: ::1:0: Cannot assign requested address
+no suitable local addr found for: ::1:0
+Assert failed fd >= 0 ../../../src/libosmocore/tests/socket/socket_test.c:142
+/src/make/libosmocore/tests/testsuite.dir/at-groups/49/test-source: line 27: 20251 Aborted                 $abs_top_builddir/tests/socket/socket_test
--- expout      2020-08-09 17:51:39.081588010 +0000
+++ /src/make/libosmocore/tests/testsuite.dir/at-groups/49/stdout       2020-08-09 17:51:39.089588123 +0000
@@ -9,3 +9,9 @@
 Checking osmo_sock_init2(AF_UNSPEC) must fail on mixed IPv6 & IPv4
 Checking osmo_sock_init2(AF_UNSPEC) BIND + CONNECT on IPv4
 Checking osmo_sock_init2(AF_UNSPEC) BIND + CONNECT on IPv6
+backtrace() returned 6 addresses
+/src/make/libosmocore/src/.libs/libosmocore.so.12(+0xdda0b) [0x7f89ded74a0b]
+/src/make/libosmocore/src/.libs/libosmocore.so.12(osmo_panic+0x14b) [0x7f89ded7491b]
+/src/make/libosmocore/tests/socket/socket_test(+0x1cc8) [0x558ed77eccc8]
+/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f89dd7d02e1]
+/src/make/libosmocore/tests/socket/socket_test(+0x1eda) [0x558ed77eceda]
../../../src/libosmocore/tests/testsuite.at:313: exit code was 134, expected 0
49. testsuite.at:308: 49. socket (testsuite.at:308): FAILED (testsuite.at:313)

History

#1 Updated by fixeria 2 months ago

Hmm,

Aug 03 13:58

The unit test should probably be disabled for systems without IPv6 support.

I kind of expected this to happen ;)

#2 Updated by lynxis 2 months ago

  • Status changed from New to Feedback
  • Assignee changed from lynxis to neels

I kind of expected this to happen ;)

Yes, but I don't see how we can handle this is.
The problem lies deeper in our test infrastructure. If we're skipping this test cases it would still fail because it's checking if stdout and stderr are the same.

Second, how do you test if IPv6 is working correctly? The test case does in fact open a socket with IPv6. So how do we know if this is working on the system or not?
So if IPv6 isn't available (it just need the localhost ::1 interface) it will fail here.

I would see the same problem if I remove the IPv4 localhost interface. The test cases would fail.
Sorry to say, I don't know a better solution than adding IPv6 support to your local docker instance to fix this.

#3 Updated by lynxis 2 months ago

/etc/docker/daemon.json

{
  "ipv6": true,
  "fixed-cidr-v6": "fd02:db8:1::/64" 
}

restart the docker daemon. From my test cases it needs a fixed-cidr-v6 in order to add the lo ::1 interface. ipv6: true is not enought. fd02:: ... is a local address which isn't routed similiar to the 192.168.x.x addresses.

#4 Updated by laforge 2 months ago

It is 2020. IMHO, if you don't have IPv6 support at least for a
loopback network device, you're doing something wrong.

As we right now are adding IPv6 capabilities to various interfaces, I think it is only
fair to assume that a system executing the unit tests will have IPv6 socket support
and a loopback device.

#5 Updated by neels 2 months ago

lynxis wrote:

/etc/docker/daemon.json
[...]

restart the docker daemon. From my test cases it needs a fixed-cidr-v6 in order to add the lo ::1 interface. ipv6: true is not enought. fd02:: ... is a local address which isn't routed similiar to the 192.168.x.x addresses.

Thanks, that seems to work.

However, there seems :

When I launch the osmo-bsc-master docker trivially and manually, I do get inet6 on lo.

▶ docker run --rm -ti neels/osmo-bsc-master bash
root@7c2eb538dc8b:/# 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
[...]

But when I launch the osmo-bsc-master docker with a --network, like jenkins.sh does, I don't see any inet6 on lo

▶ docker network create --internal --subnet 172.18.2.0/24 ttcn3-bsc-test
▶ docker run --rm --network ttcn3-bsc-test --ip 172.18.2.20 -ti neels/osmo-bsc-master bash
root@5e92481bf1da:/# 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
21: eth0@if22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
[...]

So then I try to add --ipv6 to 'docker network create':

▶ docker network create --internal --subnet 172.18.2.0/24 --ipv6 ttcn3-bsc-test
Error response from daemon: could not find an available, non-overlapping IPv6 address pool among the defaults to assign to the network

If I read the docker docs right, then the daemon.json does enable IPv6 when running dockerd,
but when using 'docker network create', the daemon.json doesn't apply.
AFAICT there is no 'network.json'.
And "network creation will fail if --ipv6 is passed but no IPv6 --subnet is specified" (according to https://github.com/moby/moby/issues/29443 )

So I try

▶ docker network create --internal --subnet 172.18.2.0/24 --ipv6 --subnet "fd02:db8:2::/64" ttcn3-bsc-test

and then I get inet6 on lo!
Note that I need to increment the v6 to "..:2" or I get:

▶ docker network create --internal --subnet 172.18.2.0/24 --ipv6 --subnet "fd02:db8:1::/64" ttcn3-bsc-test
Error response from daemon: Pool overlaps with other one on this address space

(probably because dockerd is using the :1 pool now??)

It is 2020. IMHO, if you don't have IPv6 support at least for a
loopback network device, you're doing something wrong.

So it seems our docker-playground/jenkins-common.sh is "doing something wrong" in its 'docker network create', and we should add IPv6 there?
Currently, since no build job actually builds libosmocore in a container started with --network, our ttcn3 test suite doesn't really need IPv6 to work.
But if we are going to add IPv6 tests, then each network also needs an IPv6 subnet added, I guess in every separate jenkins.sh across docker-playground.

For my use case, I will just add --ipv6 with a fixed v6 range to my wip branch of docker-playground.

diff --git a/jenkins-common.sh b/jenkins-common.sh
index a29720c..067d71c 100644
--- a/jenkins-common.sh
+++ b/jenkins-common.sh
@@ -88,7 +88,7 @@ network_create() {
                network_remove
        fi
        echo Creating network $NET_NAME
-       docker network create --internal --subnet $NET $NET_NAME
+       docker network create --internal --subnet $NET --ipv6 --subnet fd02:db8:2::/64 $NET_NAME
 }

 network_remove() {

Doing it properly for parallel tests would require a different v6 pool for each network, IIUC,
and that means adding a second argument (NET6) to network_create() in jenkins-common.sh and adjusting each separate jenkins.sh to indicate its own v6 pool.

#6 Updated by laforge 2 months ago

Thanks for your analysis.

On Tue, Aug 11, 2020 at 11:33:43PM +0000, neels [REDMINE] wrote:

But if we are going to add IPv6 tests, then each network also needs an IPv6 subnet added, I guess in every separate jenkins.sh across docker-playground.

correct. I suggest we simply use one 'unique number' per test suite, and then patch that into
the address (so that for e.g. ttcn3-bsc-test we use '2' that becomes 172.18.2.0/24 and fd02:db8:2::/64.

#7 Updated by laforge 2 months ago

gerrit https://gerrit.osmocom.org/c/docker-playground/+/19572 should enable IPv6 support
in all the docker networks our TTCN3 test suites create.

What is still missing is explicit static IPv6 addresses for every individual container we
start; they currently get allocated addresses dynamically instead.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)