.NET app outbound connection times out on dev machine only

Your ConsoleApp1 runs for me without any timeouts or other errors. So it is definitely not a Garuda bug :slight_smile:
(Tested in a garuda-vm on a garuda-test-machine.)

3 Likes

Your issue appears to be related to DNS resolution. If this is caused by a network misconfiguration, there is nothing the live environment provides which will have any impact on the problem.

Using your live environment test method, a simple way to confirm the issue is not related to Garuda Linux would be to test the live environment of another distro as well.

How do you have DNS configured on your network? Verify that your development machine can resolve https://perdu.com correctly.

dig perdu.com

If you are able to resolve the domain, this is what I would investigate next:

The log indicates that the assembly System.Net.NameResolution.dll could not be located. This assembly is responsible for name resolution in .NET applications. It seems possible that this missing assembly could be related to your issue.

I agree with the others who have mentioned that it seems very unlikely your issue is related to Garuda Linux, but rather you either have a network issue or have misconfigured your development environment.

I think this has been explained to you several times, but perhaps it bears repeating:

Legitimate bug reports are appreciated and are considered a valuable way to contribute to the project. However, this is not what you are doing.

You have a propensity to raise issues in an accusatory way, as if something is wrong with Garuda Linux, or Linux in general, or the software you are using, or whatever, and someone else owes it to you to fix the issue, when invariably there is some misconfiguration on your end which has caused the problem.

I agree you can probably find a more appropriate distro if your goal is to avoid troubleshooting or general system administration. However, it is important to appreciate that even OS’s like Windows or MacOS can have configuration issues which require advanced troubleshooting to solve.

This specific issue seems like it would most likely persist on any distro or OS.

3 Likes

I tested on Manjaro Live Boot. It times out.

Fedora Live Boot. Wow surprise, times out also!??

From Fedora

dig https://perdu.com

; <<>> DiG 9.18.24 <<>> https://perdu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35131
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;https://perdu.com.             IN      A

;; AUTHORITY SECTION:
com.                    800     IN      SOA     a.gtld-servers.net. nstld.verisign-grs.com. 1717438359 1800 900 604800 86400

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Jun 03 14:14:24 EDT 2024
;; MSG SIZE  rcvd: 119

I also tried querying by IP address and that resulted in the same problem.

Btw Manjaro on Live Boot doesn’t have the issue of being unable to switch between internal/extral displays and being locked with “expand internal into external”.

My mistake, when using dig you should not include the https:// prefix, it should just be the domain name like this:

dig perdu.com

I corrected the command in my initial response as well.

; <<>> DiG 9.18.24 <<>> perdu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50849
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;perdu.com.                     IN      A

;; ANSWER SECTION:
perdu.com.              300     IN      A       104.21.5.178
perdu.com.              300     IN      A       172.67.133.176

;; Query time: 74 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Jun 03 18:21:45 EDT 2024
;; MSG SIZE  rcvd: 70

That looks good, most likely DNS is not related to the issue.

I would investigate that issue with the System.Net.NameResolution.dll assembly not being found. Double-check the .NET Core runtime and SDK are installed correctly on your development machine. It may be worth re-installing those, or confirming whatever method you are using to install them is correct/complete.

If you are proxying off the Debian server, make sure that the HttpClient is configured to use the correct proxy settings. You can do this by setting the HttpClientHandler.Proxy property.

var handler = new HttpClientHandler
{
    Proxy = new WebProxy("http://your-proxy-server:port"),
    UseProxy = true
};
using var client = new HttpClient(handler);

If you don’t need a proxy, double-check you don’t have proxy settings configured inadvertently.

It’s a self-contained executable with .NET framework embedded. Should have no external dependency; and works for other people.

There’s no proxy in the app; and Live Boot doesn’t configure any proxy either.

I’m curious who this affects or not. I shouldn’t be the only one seeing that behavior.

Try rebuilding the application, then inspect the build output to ensure that the System.Net.NameResolution.dll assembly is present in the output directory alongside the executable. If it’s missing, there may be an issue with the build process or project configuration.

Maybe it would be worth double-checking the project configuration you have in Rider (for example, check the correct .NET framework version is targeted).

On Fedora, updated to latest version, the issue persists.

Downgraded .NET to v6 and ran in standard debug mode, it persists.

So we discarded the distro and .NET. Great. Awesome.

This is starting to look like a Linux package that got pushed into most distros that causes issues… Both Fedora and Arch are quick to push new packages. I’d expect Ubuntu or Debian desktop to work? Let me try Ubuntu. Why is their image so F big??

Ubuntu Live Boot: timeout.

Windows Live Boot: timeout !??

Something is definitely not right.

I think it’s time to escalate the issue.

Sending it to the .NET team.

I recently had an hardware issue, internal webcam cable was loose, so the webcam didn’t work, and the computer jammed on boot and needed 10 minutes to get to the OS and then worked fine. Now both the boot and the webcam work.

Could there be a very specific hardware issue or condition that could cause an issue only with .NET? Such a rare condition that it never would have been diagnosed or fixed ever before? Can’t think of anything else.

This is specifically not a Computing for Dummies forum, yet you continue to treat it as such. Why?

It’s a IPv6-related issue.

DOTNET_SYSTEM_NET_DISABLEIPV6=1 ./ConsoleApp1 
Querying http://www.perdu.com...
<html><head><title>Vous Etes Perdu ?</title></head><body><h1>Perdu sur l'Internet ?</h1><h2>Pas de panique, on va vous aider</h2><strong><pre>    * <----- vous &ecirc;tes ici</pre></strong></body></html>

@Hanuman, please post your terminal outputs formatted in the English language. It only takes one simple command to ensure your terminal outputs are in English. Unless you are posting in one of the Garuda sub-forums dedicated to alternate languages, support here is supposed to be conducted in English. If you are unfamiliar with how to ensure your terminal outputs are converted to English please perform an Internet search to locate the correct command.

Terminal outputs are English. The specific website is French. Translates to

Lost on the internet? No problem, we’ll help you

  • <= you are here

The .NET team will look into it, as it’s a .NET-related issue. Just thought you guys could be interested in resolving the mystery so I’ll update once the mystery is resolved to close this.

My apologies.

I’d seen you post outputs in alternate languages before and I thought it was time to mention this to you as assistants here work in English for standardization of support.

Sometimes IPv6 looks like it’s supported (at least what we check for in the OS), but doesn’t actually work. So there’s nothing we can do about it.

There’s been a lot of outages in the area lately btw; both electric and also ISP outages. That’s when it might have broken IPv6 support.

The sun is to blame, with its record solar storms.

It’s not often you get to blame your programming issues on the sun.

Who would have thought that this topic would ever end… :sweat_smile:

1 Like

I always say that if the cause isn’t apparent then it’s sun spots to blame. :rofl: Well either that, or your pets chewing up your computers external cabling. :stuck_out_tongue_winking_eye:

Well either that, or your pets chewing up your computers external cabling.

well there’s that but I didn’t think it relevant to mention