Support multi-connect on non-dual-mode IPv6#129892
Conversation
dotnet-policy-service
Bot
added
the
community-contribution
|
Tagging subscribers to this area: @karelz, @dotnet/ncl |
|
cc @rzikm, I tested it on OpenBSD box, it fixed the HttpRequestException mentioned above. |
| // If that instance doesn't support this address, move on to the next. | ||
| if (!_currentSocket.CanTryAddressFamily(address.AddressFamily)) | ||
| // If that instance doesn't support this address, move on to the next. The exception | ||
| // is platforms without IPv6 dual-mode (e.g. OpenBSD), where a single socket can't |
There was a problem hiding this comment.
I'm wondering if we could hide it inside of the CanTryAddressFamily. But I'm fine with this as well. It looks reasonable to me and it should not impact the major platforms.
There was a problem hiding this comment.
The new helper mutates state (reassigns _addressFamily + recreates the handle), whereas CanTryAddressFamily is a pure predicate used by ~12 call sites. The re-create is only valid in the multi-connect still-unconnected path, so I'd rather keep it at the call site. This unblocks dotnet restore etc. which connect to IPv6 endpoint on OpenBSD.
2 participants
On operating systems like OpenBSD and WASI where IPv6 dual-mode isn't supported, a single socket can't reach both address families, so we re-create the still-unconnected handle for the current address' family to let the connect proceed. Since WASI doesn't use this handler, the gap never surfaced until OpenBSD end-to-end testing with TLS endpoints (
dotnet restorefailed withHttpRequestException hr=0x80004005; workaroundDOTNET_SYSTEM_NET_DISABLEIPV6=1 dotnet restoredid the trick and led to this fix)