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

Renable SocketOptionName.ReuseUnicastPort test #15888

Closed
davidsh opened this issue Dec 8, 2015 · 9 comments · Fixed by dotnet/corefx#36864
Closed

Renable SocketOptionName.ReuseUnicastPort test #15888

davidsh opened this issue Dec 8, 2015 · 9 comments · Fixed by dotnet/corefx#36864
Assignees
Labels
area-System.Net.Sockets disabled-test The test is disabled in source code against the issue test-enhancement Improvements of test source code
Milestone

Comments

@davidsh
Copy link
Contributor

davidsh commented Dec 8, 2015

Some Windows CoreFx features like System.Net.Sockets socket option SocketOptionName.ReuseUnicastPort require a specific version of Windows (10) and customized networking configuration using Powershell scripts. And changing these settings requires a machine reboot. This is difficult to test in the current CI environment.

Need to find a way to create 'disposable' test machines/VM's with these customized settings so that these kinds of specific tests can be automated.

@davidsh davidsh self-assigned this Dec 8, 2015
@mellinoe
Copy link
Contributor

@davidsh Is this something that can be solved by just creating a new VM image, with the appropriate configuration, and setting up a new CI job to use that image?

@davidsh
Copy link
Contributor Author

davidsh commented Nov 12, 2016

this something that can be solved by just creating a new VM image, with the appropriate configuration, and setting up a new CI job to use that image?

Yes. And in particular it would be good to be able to have various Windows 10 images with RTM versus other versions of Windows 10, i.e. Windows 10 RTM (build 10240) vs. TH2 (build 10586) vs. RS1 (build 14393) etc. This will enable us to do positive testing of expected features/behaviors from each release.

@davidsh davidsh removed their assignment Nov 18, 2016
@CIPop
Copy link
Member

CIPop commented Dec 12, 2016

@karelz, @davidsh we should consider this for netstandard2.0 work and decide if we want to have an automated test for this case or not.

@karelz
Copy link
Member

karelz commented Feb 2, 2017

Closing. We will see if we need it for more tests in future - then we can reconsider. We have a way to express it in the test code.

If the tests are disabled now, we will enable them in the networking test push which is in progress cc @steveharter @Priya91 @ianhays

@karelz karelz closed this as completed Feb 2, 2017
@KristinXie1
Copy link

Disabled test, reopen it.

@KristinXie1 KristinXie1 reopened this Feb 24, 2017
@Priya91
Copy link
Contributor

Priya91 commented Feb 24, 2017

This test is not tracked in networking push, as it requires special CI infrastructure to run the test, so out of scope of stabilization effort. The test is already there, what's missing is the right version of windows, and setup scripts. One way is to write the powershell script that's required to set the setting, and ensure to execute the script before running the test.

cc @davidsh Can you provide more info on which specific Windows version/build number is required for the test, and also the powershell scripts required for configuration.

@KristinXie1
Copy link

KristinXie1 commented Feb 27, 2017

@karelz
Copy link
Member

karelz commented Feb 28, 2017

This should be Future - it is not blocking 2.0 release

@davidsh
Copy link
Contributor Author

davidsh commented Mar 15, 2019

Ref: https://support.microsoft.com/en-us/help/3014399/various-network-and-computer-issues-occur-when-tcp-ephemeral-ports-are

For an application to use these new socket parameters, the auto-reuse port range must be defined as in the following example:

Set-NetTCPSetting –SettingName Custom -AutoReusePortRangeStartPort 40000  -AutoReusePortRangeNumberOfPorts 1000
Note Restart requirement: You have to restart the computer after you change the AutoReusePortRange settings for the setting to take effect.

After the reboot you can verify your defined settings using the PowerShell command:

Get-NetTCPSetting

@davidsh davidsh self-assigned this Mar 15, 2019
@davidsh davidsh changed the title Allow test infrastructure to work for specialized Windows 10 tests Renable SocketOptionName.ReuseUnicastPort test Mar 18, 2019
davidsh referenced this issue in davidsh/corefx Apr 14, 2019
One of the oldest issues #4887 was about the Windows socket option, ReuseUnicastPort.
This test was disabled several years ago because it was very difficult to test in CI since it
required not only a newer version of Windows but also specific network settings on the machine.

At this point, there is not any way to reliably test this. And the end-to-end test isn't really
of high value for .NET Core since we would really be mostly testing an OS feature.

As part of cleaning that issue up, I cleaned up the rest of the tests, some of which were marked
as Outerloop but didn't need to be.

Closes #29929
Closes #21327
Closes #4887
stephentoub referenced this issue in dotnet/corefx Apr 15, 2019
One of the oldest issues #4887 was about the Windows socket option, ReuseUnicastPort.
This test was disabled several years ago because it was very difficult to test in CI since it
required not only a newer version of Windows but also specific network settings on the machine.

At this point, there is not any way to reliably test this. And the end-to-end test isn't really
of high value for .NET Core since we would really be mostly testing an OS feature.

As part of cleaning that issue up, I cleaned up the rest of the tests, some of which were marked
as Outerloop but didn't need to be.

Closes #29929
Closes #21327
Closes #4887
@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 3.0 milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Jan 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Net.Sockets disabled-test The test is disabled in source code against the issue test-enhancement Improvements of test source code
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants