runtime: [Ping] Unix - some problems in ping API
Related https://github.com/dotnet/corefx/issues/9350
In PowerShell repo we port TestConnection cmdlet and catch some problems in the ping API.
The problems documented in the cmdlet tests - see comments and if (!isWindows) blocks.
Below short list:
- Dontfragment doesn’t work on Unixes This definitely should work on Linux and on MacOs too
PingReply.Bufferis empty on Unix. Expected - a buffer we send.- Ping unreachable host returns ErrorCode 6 (Handle is invalid) on Unix. Expected (as on Windows) - 11001 (Host not found).
- API always returns Options based on default PingOptions() constructor (Ttl=128, DontFragment = false). PingReply.Options.DontFragment:
- on Windows always returns false. Expected - real value from ping request.
- on Unix always returns null. Expected - real value from ping request (or false if not implemented).
PingReply.Options.Ttl - always 128. Expected - real value from ping request. PingReply.Options.Status - always Success (if we expect ‘TtlExpired’). Expected - real status.
- PingReply doesn’t return ScopeId in IPAddress
About this issue
- Original URL
- State: open
- Created 6 years ago
- Reactions: 8
- Comments: 30 (19 by maintainers)
It is very amazing that the API is broken on Unix-s for years. If no plans exist to fix the API in 5.0/6.0 please indicates this and we will use an alternative library in PowerShell that is highly undesirable and will lead to inevitable breaking changes in the future.
It definitely looks like this won’t have sufficient priority to actually get fixed, judging by this issue at least. I understand there are probably other big ticket items to deal with, but having -some- amount of communication on this would be very much appreciated.
Do we have any idea when this will get sorted?
I can take a look next week. It should be easy enough to run fragment of the code above on windows and check actual packet going out as well as reply coming in.
I’ll have to see if I can get this project to build for me. I’ve taken several stabs at it, but it always comes up short, giving me errors about MSBuild or Arcade, and no amount of finagling has thus far let me actually build coreFX as yet. 😅
I’ll have to see about giving it another go, I suppose 🙂
Just to set expectations: 3.0 is locking down and the bar is high already. Change like this would not meet the bar. Master branch is opened for 5.0 though.
@vexx32 - I didn’t want to put a PR in for this back at the time because I didn’t get any confirmation as to whether the PR would be considered or not. I’m just a contributor and my understanding of the general process with this project is to get approval before starting work and then submit a PR.
Even if approval was given now for work to start I’m afraid I don’t have any spare time to dedicate to this in the short term.
@tdinucci looks like dotnet/corefx#30000 is all merged and sorted. Any chance we can revisit this one at some point soonish? 🙂
@tdinucci I don’t work on this. This fix is required for PowerShell Core to work properly on Unix.
@tdinucci I’ll happy to get this! I left a comment about the breaking change in the related issue.
I’d be happy to take this one but would prefer to wait until https://github.com/dotnet/corefx/pull/30000 is closed to avoid any conflicts.
There was some debate in dotnet/corefx#9350 about whether it would be better to introduce a breaking change and throw an exception if options are provided and the operation is executed as a non-root user - as opposed to having subtly different behavior depending on the user. I just want to confirm that the answer in this debate is to just ignore the options when running as non-root?