Closed niravjprabtani closed 10 months ago
Tagging subscribers to this area: @dotnet/ncl See info in area-owners.md if you want to be subscribed.
Author: | niravjprabtani |
---|---|
Assignees: | - |
Labels: | `area-System.Net.Http`, `untriaged` |
Milestone: | - |
Be aware that .NET Core 3.1 is out of support for almost a year now: https://github.com/dotnet/core/blob/main/releases.md#end-of-life-net-versions
Can you confirm that it reproduces always?
Source code reference: Microsoft.Azure.Devices.Client.HsmAuthentication.Transport.HttpUdsMessageHandler.GetConnectedSocketAsync
Are you using latest version of azure-iot-sdk? (whichever the version is) Are you able to try it with .NET 8.0 RC1?
Are you able to create minimal repro? (i.e. remove as much code as you can to keep it still failing)
Tagging subscribers to this area: @dotnet/ncl See info in area-owners.md if you want to be subscribed.
Author: | niravjprabtani |
---|---|
Assignees: | - |
Labels: | `area-System.Net.Sockets`, `untriaged` |
Milestone: | - |
I would suspect that WSAEFAULT is happening because WSAConnect
doesn't like the sockaddr
buffer passed to it for some reason.
@niravjprabtani do you know if this is running against the NETSTANDARD2_0 build of the Azure SDK?
Their built in UnixDomainSocketEndPoint
seems to have the size of 93 which is wrong on Windows:
It should be 110:
@wfurt any thoughts?
@niravjprabtani what hardware/architecture is this running on? What is the exact OS version? As stated in https://github.com/dotnet/runtime/issues/92464#issuecomment-1731166841, a repro would really help a lot.
Also: did you update the IoT SDK together with the 3.1->6.0 update? We would need to know the SDK versions before/after. (ConnectAsync(EndPoint)
didn't exist on 3.1, there must have been some other code running.)
I think the UDS size would matter only if we are reaching the file length limits. If this is reproducible, it may worth of trying to get coredump And use runtime's build-in type. Even there, there were some more fixes in 8.0 and it may be worth of shoot.
This issue has been marked needs-author-action
and may be missing some important information.
This issue has been automatically marked no-recent-activity
because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity
.
This issue will now be closed since it had been marked no-recent-activity
but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.
Description
I've created an IoTEdge module, which is an application containerized using Docker, and initially, it was built with dotnet core version 3.1. We've been using this module for a considerable amount of time. However, as part of our security team's recommendations, we decided to migrate it to dotnet core version 7.0. After making this migration, we encountered a System.Net.Socket.SocketException when running the modules. We attempted to test it with dotnet core 6.0 as well, but unfortunately, we faced the same issue. Consequently, we reverted the Docker base image back to version 3.1, and the module started functioning correctly.
We uses following docker image for our application FROM mcr.microsoft.com/dotnet/sdk:7.0
I'm sharing the exception details for additional information.
Reproduction Steps
We are not able to upgrade the application to latest dotnet core version although it works fine with dotnet core 3.1, No specific steps for reproduction
Expected behavior
Application should work as is as they works in dotnet core 3.1
Actual behavior
It gives an exceptions
Regression?
No response
Known Workarounds
No workarounds with dotnet core 7.0
Configuration
Dotnet Core 7.0 Docker Windows X64
Other information
We are using iotedge device sdk to initialize the modules. While initializing the modules we are getting this exception.