Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Test-Connect/Ping Tests forcing IPv4 is unreliable - assumes GetHostEntry address list is in a specific order #7576

Copy link
Copy link
@dantraMSFT

Description

@dantraMSFT
Issue body actions

The two tests that verify Test-Connection with IPv4 implicit/explicit options assume that GetHostEntry() returns the AddressList with the IPv4 address as the first entry.

I'm seeing, on Ubuntu 18.04, that the order is reversed, the IPv6 address is reported first.

The test should be updated by searching the IPHostEntry.AddressList for the entry with AddressFamily -eq InterNetwork.

The failure also occurs on Cent0S 7

Actually, this test has a number of issues:

1: It assumes the address list returned by GetHostEntry and GetHostAddresses have a predictable order.
This means that $var->AddressList[0] is not consistent across OS installations and is not guaranteed to be consistent across runs; at least the API doesn't indicate such.

Likely the best solution for this is to query both API's in BeforeAll, build a lookup table and chagne the Should statements to verify the IP address(es) Test-Connection reports are in the the associated table.

2: It assumes that localhost has an IPV6 address (::1).
Ubuntu 18.04, not domain joined, does not.

The test 'Force IPv6' should be skipped for this case. Querying in BeforeAll and checking the IP address list is sufficient.

3: It assumes that GetHostByName('localhost') returns the FQDN name.
On the same, clean Ubuntu 18.04 system, the return value is 'localhost'

The test 'ResolveDestination for address' is a NOP for this case.

4: $targetName is used as the starting name in a number of tests; it is localhost
This is a minor note but it makes the tests that reference it misleading. Using 'localhost' directly would clarify this.

Reactions are currently unavailable

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-BugIssue has been identified as a bug in the productIssue has been identified as a bug in the productResolution-FixedThe issue is fixed.The issue is fixed.WG-Quality-Testissues in a test or in test infrastructureissues in a test or in test infrastructure

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Morty Proxy This is a proxified and sanitized view of the page, visit original site.