Unit tests are failing if IPv6 is not configured

[wfurt]

I bump to this while running test on FreeBSD, however this issue is not OS specific.
Some tests make silent assumption about IPv6 and they fail if system is not configured to meet that.
This is unpleasant for anybody from community to run tests and get good pass.

The easy repro for Linux is:
sysctl -w net.ipv6.conf.all.disable_ipv6=1
./build-tests.sh

The expected behavior would be that tests needing IPv6 would be skipped.
Right now, some tests even hang for very long time.

[MarcoRossignoli]

The idea to add ConditionalAttribute with OSSupportsIPv6 check on fail tests could be a solution?Is this similar to this PR?

[wfurt]

Genrally, yes @MarcoRossignoli. I would expect tests to be skipped if they cannot execute correctly.
At some point we may consider it also for IPv6 only systems. That is probably more work and less common right now.

[MarcoRossignoli]

At some point we may consider it also for IPv6 only systems

do you mean skip tests with IPv4 "parameters"?

[MarcoRossignoli]

@wfurt i did some tests and OSSupportsIPv6 = true also if ipv6 is disabled.
What do you think about...

       public static bool IPv6Enabled {get;} = IsIPv6Enabled();
       private static bool IsIPv6Enabled()
        {
            try
            {
                using (Socket host = new Socket(AddressFamily.InterNetworkV6, SocketType.Stream, ProtocolType.Tcp))
                {                
                    host.Bind(new IPEndPoint(IPAddress.IPv6Loopback, 0));
                }            
                return true;
            }
            catch(SocketException ex)
            {            
                if(ex.SocketErrorCode == SocketError.AddressNotAvailable)
                    return false;
                    
                throw ex;
            }            
        }

EADDRNOTAVAIL A nonexistent interface was requested or the requested addres was not local

[wfurt]

I don't undersatnd your point @MarcoRossignoli. Are you suggesting that OSSupportsIPv6 value is incorrect? Even if OS can do IPv6, given address family may or may not be configured. For example you can disable IPv6 on 'lo' and leave it on 'eth0'.
I think for tests them selves we would check both OSSupportsIPv6 as well as loopback configured.

[MarcoRossignoli]

@wfurt i get it

as well as loopback configured

Is It correct my way to check "loopback configuration"?

I think for tests them selves we would check both

We can use two condition for ConditionalAttribute for tests failing, or AND OSSupportIPv6 with new check, which would you prefer?

[davidsh]

I bump to this while running test on FreeBSD, however this issue is not OS specific.

I also ran into this. I have a Windows machine running Docker for Windows. In my Linux containers, there is no IPv6 at all. That is a limitation of Docker for Windows. When I run the System.Net.Sockets tests or System.Net.Http tests, for example, I get failures since it assumes IPv6 is there. It would be nice to fix this.

[MarcoRossignoli]

In my Linux containers...

@davidsh Do you use containers for testing/dev?

It would be nice to fix this.

I'm working on other PR right now, if nobody grab this i'll try a PR

[wfurt]

That would be nice @MarcoRossignoli.It would be nice to have it as xunit trait instead of adding check it each test function.

As far as the implementation, Your code would actually test presence of IPv6 loopback address.
I think the OSSupportIPv6 only tries to create IPv6 socket. So from test prospective, I think test for the address is better.
I don't know if we have any tests reaching to public servers via IPv6. If so, it would be nice to have test for reachability e.g. routers & ISP working right. But I think priority on this one is much lower.
Fixing IPv6 loopback tests would be good improvement.

[MarcoRossignoli]

It would be nice to have it as xunit trait instead of adding check it each test function.

Can you clarify?
Is there a way to pass trait to test runner depending on plat?

If so, it would be nice to have test for reachability e.g. routers & ISP working right

Do you mean use a "real ipv6 address"?If so is there some sample on codebase?
(EDIT: Sorry...I don't know if we have any tests reaching to public servers via IPv6...understood, already answered)

[wfurt]

look at PlatformSupportsUnixDomainSockets under src/System.Net.Sockets/tests/FunctionalTests
That adds Xunit condition so we would (not) run the test when appropriate.

As oposite you can take a look at ReceiveMessageFrom.cs and use of Socket.OSSupportsIPv6.
Those test would always pass even if they did not really run.

I did look at properties under src/Common/tests/System/Net/Configuration* and it does not seems like we have explicit IPv6 host. There are DNS names which can possibly resolve to either AF but I would not worry about it now. @rmkerr is working on fast fail path - at least for HTTP dotnet/corefx#29792

[MarcoRossignoli]

it does not seems like we have explicit IPv6 host

@wfurt i did some test with https://developers.google.com/speed/public-dns/docs/using google dns ipv6 2001:4860:4860::8888...with socket UDP Connect on port 53...throws "unreachable" with ipv6 enabled and with IPv6 disabled i get correct exception/return code(like ping in terminal Cannot assign requested address).

look at PlatformSupportsUnixDomainSockets under src/System.Net.Sockets/tests/FunctionalTests
That adds Xunit condition so we would (not) run the test when appropriate.

If i understood well you mean Conditional/Fact,Theory, some methods that fail already use this attributes...and seems(maybe i'm wrong) it's not possible AND conditions es. https://github.com/dotnet/buildtools/blob/master/src/xunit.netcore.extensions/Attributes/ConditionalFactAttribute.cs, so maybe we can

• add if on failing tests
• replicate conditions on new helper type(to share helper in on all tests classes, es. IPv6SupportHelper), but i don't like it.
• replicate new ipv6 check where needed and use [ConditionalX].

We could also fill issue to buildtools(could be useful AND conditions).

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.