Test-Connection needs to be revised due to an intentional breaking change in .NET 7

[daxian-dbw]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

Here is the dotnet issue: dotnet/runtime#66746
Here is the breaking change note: dotnet/docs#28720

Basically, System.Net.NetworkInformation.Ping doesn't support specifying payload on Linux:

• it throws PlatformNotSupported exception when custom Ping payload is specified, when the process is not running as root.
• even if running as root (sudo), the custom payload is simply ignored because on Linux it's implemented by interfacing with the ping native utility, which doesn't support specifying custom payload.

So, whatever functionality in Test-Connection that depends on specifying custom payload is broken and should be either fixed or removed.

Attention: Workaround was added to test code in Test-Connection.Tests.ps1 by #16930. Please fix the tests when resolving this bug, or removing the related tests if the affected functionalities will be removed.

Expected behavior

N/A

Actual behavior

N/A

Error details

N/A

Environment data

PowerShell 7.3-preview.3

Visuals

No response

[daxian-dbw]

@iSazonov You may want to take a look at this issue.

[vexx32]

My read of the linked issue and related issues/PRs seems to indicate that the content of a custom payload is ignored, but the size of the payload is still passed to the ping native util if running as root or with proper capabilities (permissions?) set on the calling process.

So I guess the question here is -- is this enough of a feature that we think it worth keeping for that (kinda narrow imo) use case, and wrap the error that comes up to tell the user to run pwsh as root if they want to use the relevant parameter? Or do we just compile this on Unix systems without that parameter entirely / ignore it if it's set?

[JoeSalmeri]

@vexx32

So I guess the question here is -- is this enough of a feature that we think it worth keeping for that (kinda narrow imo) use
case, and wrap the error that comes up to tell the user to run pwsh as root if they want to use the relevant parameter? Or do > we just compile this on Unix systems without that parameter entirely / ignore it if it's set?

Is anything going to be done to address the issue with Test-Connection now requiring root on Linux?

Standard ping command works fine on Linux as a regular user.

At a minimum add an option to Test-Connection that allows it to work for regular users like standard ping command does.

So often I see MS's answer that they won't fix something because it might/could break existing customer code that depends on that behavior and yet this change which actual broke all my code uses of Test-Connection is allowed to stand.

Maybe MS needs to change their answer to "Won't fix something because it might/could break existing customer code that depends on that behavior except for all the exceptions that we make".

Guess I write my own Test-Connection around the built in ping command to get a workable solution as it doesn't sound like this will be addressed.

[mcx808]

+1 - I came to open a new issue on this but found this one. Issue present in 7.3.4
Test-Connection should work for ICMP without sudo/root regardless of what the underlying .Net function is doing. Ping doesn't require sudo, neither does testing a TCP port.
Issue is specific to Linux as macOS also works fine so it's not purely a *nix issue.

[SteveL-MSFT]

Looking at the code and the .NET change, it appears that the problem is that we just need to remove

PowerShell/src/Microsoft.PowerShell.Commands.Management/commands/management/TestConnectionCommand.cs

Lines 872 to 875 in 5595072

	for (int i = 0; i < bufferSize; i++)
	{
	sendBuffer[i] = (byte)((int)'a' + i % 23);
	}

so that the default buffer of 32 works. We also need to document that on Linux, any buffer size that is not the default requires sudo.

[JoeSalmeri]

@SteveL-MSFT

Thanks Steve that would be an appreciated solution.

Is there an ETA as to what pwsh release that change will target ?

Thanks