Develop Reference

"Resource temporarily unavailable" error from System.Net.Sockets

I am working on a .NET API that runs inside of a docker container. At some point it makes a call to a Python Flask API that is also running in a container.
var response = await httpClient.GetAsync("http://service-name:8000/actual/url")
which then produces the following error:
System.Net.Http.HttpRequestException: Resource temporarily unavailable
---> System.Net.Sockets.SocketException (11): Resource temporarily unavailable
at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken
cancellationToken)
Has anyone had experience with this before and potentially knows a solution? I cant find much on the web about it at all. I have some seen some mentions of the issue potentially being related to the Flask API not using async methods but that doesnt make sense to me.
The Flask API produces the appropriate responses when accessed through a web browser or Postman using localhost:8000/actual/url and the container logs these responses. I have tried using the localhost URL in the .NET API but that does not work either.
If anymore information is needed please leave a comment and I will do my best to update the post quickly.
-- Christie

TLDR
A reason for the "Resource temporarily unavailable" error is when during name resolution the DNS Server responds with RCODE 2 (Server failure).
Long answer
I noticed the same behavior in a dotnet application running in a dotnet runtime alpine docker container. Here are the results of my investigation:
The error message "Resource temporarily unavailable" corresponds to the EAGAIN error code which gets returned by various functions from the C standard library. At first I suspected the connect() function because the C# stack trace indicates the error happening during the ConnectAsync() call of the c# socket. And indeed the EAGAIN error code appears in the man page of connect() with this description: "No more free local ports or insufficient entries in the routing cache".
I simulated a system with depleted local ports and noticed that a different exception gets thrown in that case, which rules out local port availability as a root cause for the original exception. Regarding the other mentioned cause in the man page it turns out that the routing cache was removed from Linux in 2012. commit
I started to look around for EAGAIN in the source of the musl C lib which is used in the dotnet runtime alpine docker container. After a while I finally noticed the gethostbyname2_r function which is used for resolving a domain name to an ip address via DNS. During System.Net.Sockets.Socket.ConnectAsync() the hostname is still a string and the name resolving happens in native code using the gethostbyname2_r function (or one of its variations).
The final question is: When does gethostbyname2_r return the EAGAIN error code? It's when the RCODE field in the header of the DNS Response has the value 2, which stands for "Server failure". source line 166
To verify this result I ran a simple mock DNS server which always returns the RCODE 2 in the DNS response. The resulting c# exception along with the stack trace matched the original exception exactly.

ASP.NET Core disable HTTPS

I have a dockerized ASP.NET Core app that I'm trying to run locally under Linux (Fedora 33). I'd like to disable HTTPS so I don't have to deal with constant certificate errors.
To do this I simply disabled the HTTPS redirect feature which is included by default, however the app then wasn't responding to any HTTP requests at all.
I managed to get the dev version of the app to run on HTTP by explicitly configuring Kestrel in Startup.cs:
webBuilder.UseKestrel(options => {
options.ListenAnyIP(5000);
});
However, it isn't working for the Production version of the app. Whenever I send a request to http://0.0.0.0:5000, I just get a curl: (56) Recv failure: Connection reset by peer error.
Running netstat -ap in the container doesn't show the app as being bound to the port:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 localhost:46825 0.0.0.0:* LISTEN -
udp 0 0 localhost:36022 0.0.0.0:* -
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ACC ] STREAM LISTENING 27739639 1/dotnet /tmp/dotnet-diagnostic-1-3889474-socket
During startup the app also doesn't display the same information that I would normally expect, e.g. the following from another of my dockerized ASP.NET Core apps that does use HTTPS:
web-prod_1 | Hosting environment: Production
web-prod_1 | Content root path: /app
web-prod_1 | Now listening on: https://[::]:443
web-prod_1 | Now listening on: http://[::]:80
web-prod_1 | Application started. Press Ctrl+C to shut down.
The app doesn't print any of this on start, which is a little concerning.
I'd really appreciate any help with this, I've tried just about everything I can think of and I'm pulling my hair out over it.
EDIT
The cause of this was unrelated to HTTPS - a HostedService with a StartAsync that didn't terminate was being added in Startup.cs. Somehow this was stopping the rest of the app from starting, but only in production builds. Moving the AddHostedService call to Program.cs resolved the issue.

But is the container engine actually starting with the flags to bind the container and hosts ports? Conection reset means that the port is closed and actively rejecting connection.
You mention you did a netstat from inside the container, can you run another one from the host while the container is running? I like to use netstat -plnt
If your container is exposing the correct ports to the OS you should see it and be able to reach it at localhost:port, here I have a mysql proxy exposing 3306
❯ sudo netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
1/init
tcp6 0 0 :::3306 :::* LISTEN 300988/containers-r
Which I had to specify the port binding when launching it (depending on your container engine this is done in different flags/options)
docker run -ti -p 3306:3306 eu.gcr.io/xxx-xx/svc-xx-xx-tests

1st cheek by other browser
or
cheek blocking antivirus or firewall of your PC may interrupted it.
then
change the port number before by cheeking the ip and port number by ip scanner.
as you now when you need change http to https need SSL certificate , so set disable option Tools->option->environment->webbrowsers

Unable to anonymously connect to Mosquitto 2.0.5 on Ubuntu

I have the Mosquitto 2.0.5 snap (version 511) running on an Ubuntu Core 18 system. I made no modifications to the configuration, nor pass another configuration to Mosquitto.
On that same system I am running a .NET 5 application, that uses MQTTnet to connect to Mosquitto. I do not pass any credentials to connect to Mosquitto. However, I am unable to connect to Mosquitto 2.0.5, where I was able to connect to Mosquitto 1.6.12 before.
I do know of the increased security of Mosquitto 2.0 (and that is also the reason to upgrade), but the upgrade documentation clearly states that in the default configuration (no listeners) anonymous connections are still possible on localhost:1883. The strange thing is, that it all works when I run Mosquitto 2.0.5 and my application on Windows, but it does not work on Ubuntu Core (the target system).
Mosquitto 2.0.5 is logging the following when I attempt to make the connection:
New connection from 127.0.0.1:57362 on port 1883.
Client <unknown> disconnected, not authorised.
I use the following C# code (using MQTTnet) to make the connection:
var factory = new MqttFactory();
var client = factory.CreateMqttClient();
var builder = new MqttClientOptionsBuilder().
WithTcpServer("localhost", 1883);
client.ConnectAsync(builder.Build(), CancellationToken.None).Wait(MQTTBROKER_TIMEOUT);
Am I not understanding something, am I doing something wrong?
Any help is appreciated.
EDIT: I have been playing around a bit more, and it seems that by default the dynamic security plugin is loaded when using the snap, however I did not find anything in the configuration files about this. I guess that due to this, the authentication fails.
Then the next question arises, how can I find out what the default administrator user and its password are in this situation, as I need those to be able to add groups, clients and roles to the plugin.

So it looks like Mosquitto 2.0.2 and above has had some security changes, just add this to your mosquitto.conf file as it is mentioned here
listener 1883
allow_anonymous true

SSL Error "The message received was unexpected or badly formatted" for a .NET application on one specific machine only

I have a .NET Core 3.1 C# application which is calling an API via HTTPS (and presenting its public key as part of getting the token as that certificate is later used to decrypt information sent back separately). On just about all our machines, it is working, but on one Windows 8.1 machine, we get the following series of exceptions when we try to initially connect for an authentication token:
The SSL connection could not be established, see inner exception.
---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception.
---> System.ComponentModel.Win32Exception (0x80090326): The message received was unexpected or badly formatted.
The exception is thrown from System.Net.Http.HttpClient.FinishSendAsyncBuffered so I suspect it is happening at the HTTPS level and our certificate stuff is not really relevant here anyway.
Our code to get the token looks like this:
The constructor for the auth service:
public XXXXAuthService(IXXDbService dbService, XXXXApiConfig config)
{
_dbService = dbService;
_config = config;
// try forcing TLS1.2 for SSL connection exceptions thrown in some operating environments
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
_httpClient = new HttpClient {BaseAddress = new Uri(config.BaseUrl)};
_httpClient.DefaultRequestHeaders.Accept.Clear();
_httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
}
Code to get the auth token:
private async Task<string> GetXXXXBearerToken(string userId, DateTime creationTime)
{
var token = await GenerateProviderJwtForXXXX(userId, creationTime);
var kvp = new List<KeyValuePair<string, string>>
{
new KeyValuePair<string, string>("grant_type", "urn:ietf:params:oauth:grant-type:token-exchange"),
new KeyValuePair<string, string>("subject_token", token),
new KeyValuePair<string, string>("subject_token_type", "urn:ietf:params:oauth:token-type:jwt")
};
var data = new FormUrlEncodedContent(kvp);
var publicKey = await GetXXXXPublicKey();
_httpClient.DefaultRequestHeaders.Remove("X-XXXX-Public-Cert");
_httpClient.DefaultRequestHeaders.Add("X-XXXX-Public-Cert", publicKey);
var response = await _httpClient.PostAsync("Identity/token", data);
if (!response.IsSuccessStatusCode)
throw new Exception("XXXX Token Server Error: " + response.ReasonPhrase);
var result = await response.Content.ReadAsStringAsync();
var authResponse = JsonConvert.DeserializeObject<OAuthResponse>(result);
if (!string.IsNullOrEmpty(authResponse.access_token))
return authResponse.access_token;
System.Diagnostics.Trace.WriteLine("Token Exchange Result: " + result);
if (!string.IsNullOrEmpty(authResponse.error))
{
var outcome = new XXX.XXXX.Model.OperationOutcome();
outcome.Issue.Add(new XXX.XXXX.Model.OperationOutcome.IssueComponent()
{
//some code to throw an error is here
}
throw new XXX.XXXX.Rest.XXXXOperationException("Bearer Token Exchange failed", response.StatusCode);
}
Unfortunately none of the existing questions/advice anywhere on Stack Overflow, or the rest of the web, for this particular error seems to have helped. They are primarily about version discrepancies between client and server which seems not to be the case here as I am forcing TLS 1.2 (which is active and enabled on the failing machine).
Interestingly, I can visit the server URL in a browser via HTTPS just fine, which suggests there is something about my code that is the problem rather than the machine, but it works everywhere else.
I have confirmed that:
The certificate I am using to authenticate the connection on the machine is valid and has a chain of trust (though as above I don't think we are getting that far as the TLS connection itself is failing)
The server we are calling supports TLS 1.2 (by forcing it)
I can get to the website for the URL independently via the browser
Is there something I need to do either in the code or on the machine to get this call to work everywhere?
Things I have tried to resolve the issue
Installing all Windows 8.1 updates to present day
Forcing TLS 1.2 in the code (see above code sample)
Limiting VM to TLS 1.2 only

I might be able to at least point you in the right direction…
Same Symptoms
I had a .NET Core 3.1 web app running on IIS (Windows Server 2012 R2) that got the exact same error and stacktrace when it tried to connect to another server using TLS 1.2. I also had the symptom where I could connect with the browser (Chrome), but not with the app. (Would have been interesting to see if Internet Explorer browser worked though.)
Root Cause
The TLS handshake was failing because the two servers were unable to agree on a common cipher suite. (Using Wireshark, I discovered that when my app tried to connect it provided a more limited set of cipher suites than when the Chrome browser made the call.)
Solution
In my case, I used IIS Crypto (a small free tool: https://www.nartac.com/Products/IISCrypto/) to enable additional cipher suites on my web app's server. I downloaded and ran IIS Crypto, checkmarked additional cipher suites on its Cipher Suites tab, and then restarted the machine.
One of the new cipher suites worked with my app and the destination server, so the TLS handshake was successful and the error was resolved.
One quick caveat: Some cipher suites are more secure than others, so you'll want to read up on best practices.
Addendum
If you want to further diagnose the failure, I'd recommend installing Wireshark (another free tool: https://www.wireshark.org/#download) on the machine with your .NET Core app. If a TLS Handshake Failure is the issue, you will see a message like: Alert (Level: Fatal, Description: Handshake Failure)
This primer on wireshark output helped me:
https://blog.catchpoint.com/2017/05/12/dissecting-tls-using-wireshark/

I faced a simular issue, and in order to help others here's what I concluded:
Sucessfully executing this code doesn't mean that your application supports the specified protocol version, and the "SSL Error" can still occur later on when trying to establish a connection:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
In my case I was trying to force Tls13 and found out that my app configuration didn't actually support it:
net core 3.0 running on a Windows Server Datacenter 2019, version 1809
So I had to change my configuration to the following which provides support for the protocol version I needed:
Net framework 5.0 on a Windows Server Datacenter 2022, OS build 20348.288
I was trying to connect to an endpoint that suddenly dropped Tls 1.2 support (not sure why) and from then on only accepted Tls 1.3.

IIS8 HTTP Error 500.0 - Internal Server Error

I'm trying to move my website to another host, a shared hosting, and I keep getting this message:
Detailed Error Information: Module
AspNetInitializationExceptionModule Notification BeginRequest
Handler ExtensionlessUrlHandler-Integrated-4.0 Error Code
0x00000000 Requested URL http://1.3144.co.il:80/ Physical Path
h:\root\home\picsize-001\www\3144clubmember Logon Method Not yet
determined Logon User Not yet determined
I've tried many things but nothing seems to work for me.

It looks like either your host doesn't support .net 4.5 or you don't have it enabled.
Things to check in your hosts control panel:
You have enabled .net 4.5
It's running in integrated mode and not classic pipeline