Description
Is there an existing issue for this?
- I have searched the existing issues
Describe the bug
When retrieving the value HttpContext.Connection.RemotePort, the wrong value is being returned. When running CoreWCF tests, the value that is being returned is a negative value. For example, when debugging before opening this issue, the value returned was -11134. The value is different each time.
As the local port is predictable (we're running the test using port 44300), I was able to look at the local port number and work out what's going on. The value returned for the LocalPort was -21236. Converting 44300 and -21236 to hexadecimal yields the following values:
-21236 -> FFFF AD0C
44300 -> 0000 AD0C
This looks to be a sign extension bug caused by an incorrect representation of a port number. A TCP port number is an unsigned 16 bit value, so should be represented as a ushort. Presumably to avoid shipping a non-CLS compliant assembly, ConnectionInfo.RemotePort and ConnectionInfo.LocalPort are defined as a signed int (as a signed short would overflow). When retrieving the ushort from the native data structure, as the hex value 0xAD0C has the most significant bit set, when casting to an int32, it's sign extended to keep it a negative number and the first 2 bytes of the int32 incorrectly end up being 0xFFFF.
I didn't look at the unit tests, but I presume they aren't failing as this would only be seen for port numbers greater than 32,767.
Expected Behavior
ConnectionInfo.LocalPort and ConnetionInfo.RemotePort to return the correct value for port numbers greater than 32,767.
Steps To Reproduce
Create a service using HttpSys, and have a listening port greater than 32767. Retrieve the LocalPort from the connection info.
Exceptions (if any)
No response
.NET Version
10.0.100-preview.4.25258.110
Anything else?
This is a regression from .NET 9 as this bug doesn't exist there. I suspect the bug was introduced in the change by @GrabYourPitchforks in PR #61006.