Skip to content

HTTP Connection RemotePort and LocalPort values are incorrect for HttpSys #62128

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
1 task done
mconnew opened this issue May 27, 2025 · 0 comments
Open
1 task done
Labels
needs-area-label Used by the dotnet-issue-labeler to label those issues which couldn't be triaged automatically

Comments

@mconnew
Copy link
Member

mconnew commented May 27, 2025

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.

@github-actions github-actions bot added the needs-area-label Used by the dotnet-issue-labeler to label those issues which couldn't be triaged automatically label May 27, 2025
mconnew added a commit to g7ed6e/CoreWCF that referenced this issue May 28, 2025
g7ed6e added a commit to CoreWCF/CoreWCF that referenced this issue May 28, 2025
* Add net10 UT

* Work around for dotnet/aspnetcore#62128

* Update CodeAnalysis.yml

* Update template.json

---------

Co-authored-by: Matt Connew <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-area-label Used by the dotnet-issue-labeler to label those issues which couldn't be triaged automatically
Projects
None yet
Development

No branches or pull requests

1 participant