Skip to content
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

A stopped TcpListener will NRE during AllowNatTraversal #32551

Closed
eerhardt opened this issue Feb 19, 2020 · 0 comments · Fixed by #32603
Closed

A stopped TcpListener will NRE during AllowNatTraversal #32551

eerhardt opened this issue Feb 19, 2020 · 0 comments · Fixed by #32603
Assignees
Milestone

Comments

@eerhardt
Copy link
Member

Execute the following code on .NET 5:

var listener = new TcpListener(IPAddress.Any, 0);
listener.Start();
listener.Stop();
listener.AllowNatTraversal(true);

It will throw a NRE on line 121:

public void AllowNatTraversal(bool allowed)
{
if (_active)
{
throw new InvalidOperationException(SR.net_tcplistener_mustbestopped);
}
_serverSocket.SetIPProtectionLevel(allowed ? IPProtectionLevel.Unrestricted : IPProtectionLevel.EdgeRestricted);

This appears to be a regression in 5.0 caused by dotnet/corefx#41547. In previous versions, _serverSocket would still be valid after calling .Stop().

Note that AllowNatTraversal can only be called on a stopped listener, so with this bug it means you can only call AllowNatTraversal immediately after creating the listener and before calling Start.

/cc @alnikola

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Feb 19, 2020
@davidsh davidsh added this to the 5.0 milestone Feb 19, 2020
@davidsh davidsh removed the untriaged New issue has not been triaged by the area owner label Feb 19, 2020
@alnikola alnikola self-assigned this Feb 20, 2020
alnikola added a commit that referenced this issue Feb 21, 2020
If AllowNatTraversal is called on a stopped TcpListener when ```_serverSocket``` is null, ```allow``` value gets stored in a field. Subsequently, if a new socket is created on Start call, the saved value is read and the corresponding argument is passed to SetIPProtectionLevel call after which the value is reset to preserve the current IPProtectionLevel propagation logic. The follow-up issue is #32653 
Fixes #32551
@ghost ghost locked as resolved and limited conversation to collaborators Dec 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants