[Report // Linux] Dotnet 8+ httpClient times out in IPV6

[ForeverExe]

Mine here is more of a report, since the issue was originally made on Godot Engine's Repo, which uses C# as an alternative programming language over their internal GDScript.

So, what happened:

On Nobara Linux (custom Fedora 42), building the project with Dotnet 8 (it's the minimum requirement for the engine version that I'm using) would result in a long hang.
Building the project via terminal, instead shows an error after 10 minutes, which corresponds to a timeout regarding network connections (and since it had to fetch the dependencies).

I got suggested to make a new .NET project with this content:

var httpClient = new HttpClient();
var response = await httpClient.GetAsync("https://your.chosen.URL");
Console.WriteLine("Response statuc code: " + response.StatusCode);

And, either be Package or Scripted userspace install, it would still timeout.

In the end, the workaround I'm actually using is to make an additional Application Launcher which prepends DOTNET_SYSTEM_NET_DISABLEIPV6 to the engine executable / dotnet executable or directly launch it from terminal.

Now since I'm here, other than this method, is there a way to say to dotnet to fall back to IPV4 globally, instead of having to disable IPV6 entirely with an environment variable? (I've already tried disabling IPV6 in the OS's network settings, doesn't change anything)

[antonfirsov]

This is likely a networking configuration problem that prevents dual stack (IPv6) sockets from functioning (it could be a misconfigured machine, firewall, router etc.). Any chance you can try to diagnose it before fully disabling IPv6? Have you tried reproducing it on another machine with the same OS?

is there a way to say to dotnet to fall back to IPV4 globally

There is also a runtime configuration setting (AppContext switch) System.Net.DisableIPv6. Note that it does exactly the same as the environment variable.

[wfurt]

.NET does fallback to IPv4. ForeverExe. However, depending on the con figuration and DNS entries that can take a while. Do you have situation when IPv6 is advertised in DNS but not actually reachable? That on its own seems like problematic setup. You may want to get some packet captures to see what is actually happening at the network layer.

[ForeverExe]

There is also a runtime configuration setting (AppContext switch) System.Net.DisableIPv6.

@antonfirsov Thanks, I'll try to add it to the Godot Project manually, since it doesn't generate a runtimeconfig.json automatically.

Do you have situation when IPv6 is advertised in DNS but not actually reachable?

@wfurt To be completely honest, this type of issue is new to me so I don't know the proper way to diagnose that.
So, while trying to make an adequate response, I searched a little and on https://test-ipv6.com/ and I've found out that I don't have any IPv6 capabilities whatsoever.

Now, I'm using a Fritz!Box Router, so I can customize it a bit.
For now I've always had set Use DNSv6 servers assigned by your provider, but I imagine my ISP had none or was not included in the contract.

I'll change it and set to Google's DNS to test this and try again. I'll let you know as soon as I have news, whether they'll be good or bad.

Still, I don't know how or when .NET falls back to IPv4, I don't have much experience of the inner workings unfortunately.

Here is a screenshot of the result:

[ForeverExe]

Ok, after some tries and changes and then re-running the test a couple of times, I still get fails on the IPv6 tests.

Now, I don't think it's because of the Router, nor the Computer, I think it's an ISP-dependent issue. I'll have to check my contract and hear them what they can do about it.

In the meantime I'll use the method @antonfirsov told me, and find some information regarding how and when dotnet falls back to IPv6 in human times, and not after a timeout which kills my compilation.