[dotnet-sdk-9.0.100-preview.4.24253.11] IPInterfaceProperties.GatewayAddresses. FirstOrDefault() returns Null

[Junjun-zhao]

Description

when we run OpenNetMeter app with 9.0.100-preview.5.24227.1 or higher version. It will show error: GatewayAddresses is NULL.

Application Name: OpenNetMeter
OS:Windows 10 21H2
CPU:AMD64
.NET Build Number: dotnet-sdk-9.0.100-preview.5.24227.1

App or source Location checking at: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2049203

Github Link: https://github.com/Ashfaaq18/OpenNetMeter

Reproduction Steps

Test Steps for the Application:

1.Launch app from folder “OpenNetMeter.exe".

Expected Result: Show detailed data service successfully.
Actual Result: App is in Disconnected State, nothing appears.

Minimal Repro steps:(Demo AttachedConsoleApp12.zip)
1)Create .NET Console App
2) Add this code

 NetworkInterface[] adapters = NetworkInterface.GetAllNetworkInterfaces();
 foreach (NetworkInterface n in adapters)
 {
     IPInterfaceProperties adapterProperties = n.GetIPProperties();
     try
     {
       
         Console.WriteLine($"{n.Id} {n.Name} {n.Description} GatewayAddresses is {adapterProperties.GatewayAddresses.FirstOrDefault().Address}");
     }
     catch (System.NullReferenceException)
     {
         //in .NET 9.0.100-preview.5.24227.1, it always come to this line because GatewayAddresses is always NULL
         Console.WriteLine($"{n.Id} {n.Name} {n.Description} GatewayAddresses is NULLL");
     }
 }

3. Build the app and change the runtime to .NET 9.0:

"framework": {
     "name": "Microsoft.NETCore.App",
           "version": "9.0.0-preview.4.24225.8"
   }

4. Run the app .

Expected behavior

App run successfully without error.

Actual behavior

Show error: GatewayAddresses returns NULL

Regression?

Yes

Verify Scenarios:

1). Windows 10 21H2 AMD64 + dotnet-sdk-9.0.100-preview.5.24227.1: Fail
2). Windows 10 21H2 AMD64 + dotnet-sdk-9.0.100-preview.4.24223.3: Pass
3). Windows 10 21H2 AMD64 + dotnet-sdk-8.0.300-win-x64: Pass
4). Windows 10 21H2 AMD64 + dotnet-sdk- 7.0.306-win-x64: Pass
5). Windows 10 21H2 AMD64 + dotnet-sdk-6.0.422-win-x64: Pass
6). Windows 10 21H2 AMD64 + dotnet-sdk-9.0.100-preview.4.24253.11: Fail

Did it work in .NET Framework?
Yes

Known Workarounds

No response

Configuration

dotnet info:

dotnet --info
.NET SDK:
 Version:           9.0.100-preview.5.24227.1
 Commit:            0f7644da23
 Workload version:  9.0.100-manifests.f3024191
 MSBuild version:   17.11.0-preview-24223-07+d542f3a80

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19044
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.100-preview.5.24227.1\

.NET workloads installed:
There are no installed workloads to display.

Host:
  Version:      9.0.0-preview.4.24225.8
  Architecture: x64
  Commit:       74d927967d

.NET SDKs installed:
  9.0.100-preview.5.24227.1 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 9.0.0-preview.4.24223.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 9.0.0-preview.4.24225.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 9.0.0-preview.5.24226.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Other information

Finding:
After debugging the app, we find out that IPInterfaceProperties.GatewayAddresses Property returns NULL, app stays in Disconneted State , in earlier Runtimes, we get value of GatewayAddresses

@dotnet-actwx-bot @dotnet/compat

[stephentoub]

in .NET 9.0.100-preview.5.24227.1, it always come to this line because GatewayAddresses is always NULL

Is it null, or is it empty? With your use of adapterProperties.GatewayAddresses.FirstOrDefault().Address, that will fail with a null reference exception if GatewayAddresses returns null, but it will also fail with a null reference exception if GatewayAddresses returns an empty collection, because the FirstOrDefault() will then return null and you'll dereference that null as part of accessing its Address. And based on a quick look at the implementation, it doesn't look like GatewayAddresses ever returns null.

[wfurt]

This is likely outcome of #100824 cc: @MojtabaTajik
The list will now include more interfaces .... some of them may not have address or gateway.

[Junjun-zhao]

in .NET 9.0.100-preview.5.24227.1, it always come to this line because GatewayAddresses is always NULL

Is it null, or is it empty? With your use of adapterProperties.GatewayAddresses.FirstOrDefault().Address, that will fail with a null reference exception if GatewayAddresses returns null, but it will also fail with a null reference exception if GatewayAddresses returns an empty collection, because the FirstOrDefault() will then return null and you'll dereference that null as part of accessing its Address. And based on a quick look at the implementation, it doesn't look like GatewayAddresses ever returns null.

From .NET 9.0 preview 5 build, adapterProperties.GatewayAddresses.FirstOrDefault() returns null, it is a way that used to return address from App Code. After investigation, we found that adapterProperties.GatewayAddresses is empty.

With dotnet-sdk-9.0.100-preview.4.24223.3 or previous build, it could return the address well.

[Junjun-zhao]

We verified this issue with the latest Preview 4 validation build #dotnet-sdk-9.0.100-preview.4.24253.11, this issue also reproduced.

@stephentoub @wfurt Could you please help confirm if this issue is a blocker for Preview 4? Thanks you.

[wfurt]

From the picture it seems like it is returning empty collection, right? And are both pictures on the same interface? What is corresponding ipconfig /all @Junjun-zhao?

[wfurt]

The code above is problematic IMHO even on 8.0

foreach (NetworkInterface n in NetworkInterface.GetAllNetworkInterfaces())
{
    var ipp = n.GetIPProperties();
    Console.WriteLine("{0}: {1} {2} {3}", n.Name, ipp.GatewayAddresses.Count, ipp.GatewayAddresses.FirstOrDefault(), ipp.GatewayAddresses.FirstOrDefault() == null);
      
}

will produce this output for me

Ethernet 2: 0  True
vEthernet (PUBLIC): 3 System.Net.NetworkInformation.SystemGatewayIPAddressInformation False
Loopback Pseudo-Interface 1: 0  True
Teredo Tunneling Pseudo-Interface: 0  True
vEthernet (Default Switch): 0  True

attempt to dereference GatewayAddresses.FirstOrDefault().Address with produce NRE @Junjun-zhao.
And I think the claim from subject is wrong, it is FirstOrDefault() what return NULL IMHO, not GatewayAddresses

same code on 9.0 (9.0.0-preview.5.24256.1)

Ethernet 2: 0  True
vEthernet (PUBLIC): 0  True
Loopback Pseudo-Interface 1: 0  True
Teredo Tunneling Pseudo-Interface: 0  True
vEthernet (Default Switch): 0  True
vSwitch (Default Switch)-Hyper-V Virtual Switch Extension Filter-0000: 0  True
vEthernet (Default Switch)-WFP Native MAC Layer LightWeight Filter-0000: 0  True
vEthernet (Default Switch)-Npcap Packet Driver (NPCAP)-0000: 0  True
vEthernet (Default Switch)-QoS Packet Scheduler-0000: 0  True
Local Area Connection* 6-WFP Native MAC Layer LightWeight Filter-0000: 0  True
vSwitch (PUBLIC)-Hyper-V Virtual Switch Extension Filter-0000: 0  True
vSwitch (PUBLIC)-Virtual Filtering Platform VMSwitch Extension-0000: 0  True
Ethernet-WFP Native MAC Layer LightWeight Filter-0000: 0  True
Ethernet-Npcap Packet Driver (NPCAP)-0000: 0  True
Ethernet 2-WFP Native MAC Layer LightWeight Filter-0000: 0  True
Ethernet 2-Npcap Packet Driver (NPCAP)-0000: 0  True
Ethernet 2-QoS Packet Scheduler-0000: 0  True
vEthernet (PUBLIC)-WFP Native MAC Layer LightWeight Filter-0000: 0  True
vEthernet (PUBLIC)-Npcap Packet Driver (NPCAP)-0000: 0  True
vEthernet (PUBLIC)-QoS Packet Scheduler-0000: 0  True
vEthernet (PUBLIC)-WFP 802.3 MAC Layer LightWeight Filter-0000: 0  True
Ethernet 2-WFP 802.3 MAC Layer LightWeight Filter-0000: 0  True
Local Area Connection* 6-Npcap Packet Driver (NPCAP)-0000: 0  True
Local Area Connection* 6-QoS Packet Scheduler-0000: 0  True
Local Area Connection* 7-WFP Native MAC Layer LightWeight Filter-0000: 0  True
Local Area Connection* 7-Npcap Packet Driver (NPCAP)-0000: 0  True
Local Area Connection* 7-QoS Packet Scheduler-0000: 0  True
Local Area Connection* 8-WFP Native MAC Layer LightWeight Filter-0000: 0  True
Local Area Connection* 8-Npcap Packet Driver (NPCAP)-0000: 0  True
Local Area Connection* 8-QoS Packet Scheduler-0000: 0  True
vEthernet (Default Switch)-WFP 802.3 MAC Layer LightWeight Filter-0000: 0  True
Ethernet (Kernel Debugger): 0  True
Ethernet: 0  True
vSwitch (Default Switch): 0  True
Local Area Connection* 6: 0  True
Local Area Connection* 7: 0  True
Npcap Loopback Adapter: 0  True
Ethernet 3: 0  True
Local Area Connection* 8: 0  True
vSwitch (PUBLIC): 0  True
Ethernet 4: 0  True
Local Area Connection* 5: 0  True
Microsoft IP-HTTPS Platform Interface: 0  True
6to4 Adapter: 0  True
Local Area Connection* 1: 0  True
Local Area Connection* 2: 0  True
Local Area Connection* 3: 0  True
Local Area Connection* 4: 0  True

That is LOT of interfaces. And some will throw when attempting IPv6 properties (and perhaps more)
While that is not necessarily wrong, I feel that can certainly surprise any app that just leisurely iterate through interfaces and dumps info.

It seems like we made it more difficult to use it (showing all Windows internals) for supporting corner case (e.g. disabled interfaces)

any thoughts on this @stephentoub and @dotnet/ncl ?
I'm also wondering if we can somehow hide at least the internal(?) interfaces @MojtabaTajik.
I tried to eyeball it but I don't see obvious pattern. On the original #89990, do we know if 'ipconfig /all` shows them?