runtime
runtime copied to clipboard
dotnet
[macOS] SendTo_.*.Datagram_UDP_AccessDenied_Throws_DoesNotBind cannot reach host
Build Information
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1009757
Build error leg or test failing: System.Net.Sockets.Tests
Affected CI: maccatalyst-x64 Release AllSubsets_Mono and osx-arm64 Release Libraries_Release_CoreCLR
During migration to newer macOS queues (from 12 to 15 or 26, https://github.com/dotnet/runtime/pull/113313), we encountered issues in System.Net.Sockets.Tests.SendTo_.*.Datagram_UDP_AccessDenied_Throws_DoesNotBind tests running on MacCatalyst and macOS where host is unreachable.
Error message:
[06:43:43] dbug: Assert.Equal() Failure: Values differ
[06:43:43] dbug: Expected: AccessDenied
[06:43:43] dbug: Actual: HostUnreachable
Error Message
Fill the error message using step by step known issues guidance.
{
"ErrorPattern": "\\[FAIL\\] System\\.Net\\.Sockets\\.Tests\\.SendTo_.+\\.Datagram_UDP_AccessDenied_Throws_DoesNotBind",
"BuildRetry": false,
"ExcludeConsoleLog": false
}
Known issue validation
Build: :mag_right: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1009757
Error message validated: [\[FAIL\] System\.Net\.Sockets\.Tests\.SendTo_.+\.Datagram_UDP_AccessDenied_Throws_DoesNotBind]
Result validation: :white_check_mark: Known issue matched with the provided build.
Validation performed at: 4/9/2025 5:09:04 PM UTC
Report
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 7 | 33 | 55 |
Report
| Build | Definition | Test | Pull Request |
|---|---|---|---|
| 1214558 | dotnet/runtime | System.Net.Sockets.Tests.WorkItemExecution | |
| 1208373 | dotnet/runtime | System.Net.Sockets.Tests.WorkItemExecution | |
| 1204863 | dotnet/runtime | System.Net.Sockets.Tests.WorkItemExecution |
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 0 | 0 | 3 |
Tagging subscribers to 'os-maccatalyst': @vitek-karas, @kotlarmilos, @ivanpovazan, @steveisok, @akoeplinger See info in area-owners.md if you want to be subscribed.
![dotnet-policy-service[bot] avatar](https://avatars.githubusercontent.com/in/285228?v=4 "Published by a pub.dev verified publisher"){kind=small}
Tagging subscribers to this area: @dotnet/ncl See info in area-owners.md if you want to be subscribed.
@kotlarmilos hey, are you working on this? despite the disabled-test tag, we still see this failure in main on OSX.26.Arm64.Open
cc @liveans
I’m not working on this right now. The test is disabled only on x64, which might explain why it’s failing on arm64. Could you share the pipeline where it is failing?
@kotlarmilos see the table in the issue, e.g. https://dev.azure.com/dnceng-public/public/_build/results?buildId=1146290&view=ms.vss-test-web.build-test-results-tab&runId=31632538&resultId=223760&paneView=debug
Since the tests are failing or ARM64 as well, should we include that in the issue description?
@kotlarmilos Did you test this issue on macOS 14 and macOS 13? It seems like with macOS 15, they have added new Privacy&Security option "Local Network" and unless you allow it explicitly on the system it returns EHOSTUNREACH, and this might be the root cause of this issue.
EHOSTUNREACH … is misleading, because the destination is pingable on my setup at the time of execution.
Right. Our hands are tied here because of the limitations of the available errno error codes. In Apple APIs, like Network framework, we can yield more specific errors. See FAQ-10 in the Local Network Privacy FAQ (which I haven’t yet updated for macOS, but is generally applicable here).
Reference: DTS answer from https://developer.apple.com/forums/thread/765285
This issue initially tracked only the MacCatalyst failure, but it is now also failing on macOS 26. The Privacy & Security option looks like a possible cause, especially since other tests are failing with the same error.
I see two options:
- Verify that this is the cause (disable it locally and confirm the failure). After that, ask the Helix team to update the local network option
- Disable the tests
@liveans Could you try disabling this option locally and confirm the failure? I can follow up with a ticket for the Helix team.
Sorry that I forgot to update here, I already reproduced it locally and privacy setting is the root cause.