NetworkInformationException when querying network interfaces in WSL 1

[f-markus]

Description

A customer reported the following exception. The code was executed inside WSL 1, the assembly was compiled with .NET 7.0 RC1. Recompiling everything with .NET6.0 resolves the issue.

System.Net.NetworkInformation.NetworkInformationException (2): An error was encountered while querying information from the operating system. ---> System.IO.DirectoryNotFoundException: Could not find a part of the path '/proc/sys/net/ipv4/conf/eth0/forwarding'.
   at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirError)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode, Func'4 createOpenException)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, UnixFileMode openPermissions, Int64& fileLength, UnixFileMode& filePermissions, Func'4 createOpenException)
   at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable'1 unixCreateMode)
   at System.IO.StreamReader.ValidateArgsAndOpenPath(String path, Encoding encoding, Int32 bufferSize)
   at System.IO.File.ReadAllText(String path, Encoding encoding)
   at System.Net.NetworkInformation.StringParsingHelpers.ReadAllText(String filePath)
   at System.Net.NetworkInformation.StringParsingHelpers.ReadAllText(String filePath)
   at System.Net.NetworkInformation.StringParsingHelpers.ParseRawetFile(String filePath)
   at System.Net.NetworkInformation.LinuxIPv4InterfaceProperties.GetIsForwardingEnabled()
   at System.Net.NetworkInformation.LinuxIPInterfaceProperties..ctor(LinuxNetworkInterface lni, LinuxNetworkInterfaceSystemProperties systemProperties)
   at System.Net.NetworkInformation.LinuxNetworkInterface.GetLinuxNetworkInterfaces()
   at V4pCore.Common.Utils.Utilities.GetMacAddresses(Boolean addDetail) in E:\git-data\v3s_new\V4pCore\Common\Utils\Utilities.cs:line 22
   at V4pServer.Server.UpdateWorkspace(String reason)
   at V4pServer.Server.Initialized()
   at LanguageServer.Reflector.<>c__DisplayClass13_0'1.<ForNotification1>b__0(Object n, Connection c)

Reproduction Steps

I don't use WSL, but from the code it should be fairly easy to reproduce:
Just call
NetworkInterface.GetAllNetworkInterfaces()
from an app in WSL

Expected behavior

No exception, but a list of valid networkinterfaces

Actual behavior

Exception instead of list of network interfaces

Regression?

The very same code works with .NET6.0 as TargetPlatform

Known Workarounds

No response

Configuration

No response

Other information

No response

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

A customer reported the following exception. The code was executed inside WSL 1, the assembly was compiled with .NET 7.0 RC1. Recompiling everything with .NET6.0 resolves the issue.

System.Net.NetworkInformation.NetworkInformationException (2): An error was encountered while querying information from the operating system. ---> System.IO.DirectoryNotFoundException: Could not find a part of the path '/proc/sys/net/ipv4/conf/eth0/forwarding'.
at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirError)
at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode, Func'4 createOpenException)
at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, UnixFileMode openPermissions, Int64& fileLength, UnixFileMode& filePermissions, Func'4 createOpenException)
at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable'1 unixCreateMode)
at System.IO.StreamReader.ValidateArgsAndOpenPath(String path, Encoding encoding, Int32 bufferSize)
at System.IO.File.ReadAllText(String path, Encoding encoding)
at System.Net.NetworkInformation.StringParsingHelpers.ReadAllText(String filePath)
at System.Net.NetworkInformation.StringParsingHelpers.ReadAllText(String filePath)
at System.Net.NetworkInformation.StringParsingHelpers.ParseRawetFile(String filePath)
at System.Net.NetworkInformation.LinuxIPv4InterfaceProperties.GetIsForwardingEnabled()
at System.Net.NetworkInformation.LinuxIPInterfaceProperties..ctor(LinuxNetworkInterface lni, LinuxNetworkInterfaceSystemProperties systemProperties)
at System.Net.NetworkInformation.LinuxNetworkInterface.GetLinuxNetworkInterfaces()
at V4pCore.Common.Utils.Utilities.GetMacAddresses(Boolean addDetail) in E:\git-data\v3s_new\V4pCore\Common\Utils\Utilities.cs:line 22
at V4pServer.Server.UpdateWorkspace(String reason)
at V4pServer.Server.Initialized()
at LanguageServer.Reflector.<>c__DisplayClass13_0'1.b__0(Object n, Connection c)

Reproduction Steps

I don't use WSL, but from the code it should be fairly easy to reproduce:
Just call
NetworkInterface.GetAllNetworkInterfaces()
from an app in WSL

Expected behavior

No exception, but a list of valid networkinterfaces

Actual behavior

Exception instead of list of network interfaces

Regression?

The very same code works with .NET6.0 as TargetPlatform

Known Workarounds

No response

Configuration

No response

Other information

No response

Author:	f-markus
Assignees:	-
Labels:	area-System.Net
Milestone:	-

[wfurt]

regression from #63696?
cc: @rzikm

[karelz]

Triage: Looks like regression.
WSL 1 wasn't officially supported to our best knowledge, however, we should fix it if it is easy. Not critical for 7.0 though (unless larger number of customers is impacted).

[rzikm]

Looks like indeed this is a regression from #63696. I can fix this specific exception for .NET 8 (the PR that broke this changed an exception type which is no longer caught on the problematic code path), but as far as I can see, the NetworkInformation tests could not pass on WSL in the past. For example, calling IPGlobalProperties.GetIPGlobalProperties().GetIPv4GlobalStatistics() fails on my distro because /proc/net/snmp file does not exist in WSL 1.

[danmoseley]

@richlander is WSL1 entirely unsupported? I don't believe we test on it, and hit problems in the past.

[wfurt]

I'm not sure @danmoseley. I would hope we don't break things on old releases. Do you think this can meet servicing bar? (as regression)

[danmoseley]

We have taken fixes for releases we don't support, and even serviced for them - although generally where there is another group doing the maintenance, providing the fix, and doing the testing. I'd imagine if there was a change here for servicing they would ask -- how commonly do customers use WSL1? does this compromise non WSL1 behavior? are we confident that the rest of the product is useful on WSL1 - did you eg run all the unit tests on WSL1? (I'm betting there will be a fair number of failures). If there are other failures that emerge, would we bring fixes for those?

@f-markus can you say more about your customer's usage of WSL1? why do they use it?

@jamshedd @richlander my assumption has been that we broadly support WSL2 in development scenarios, but don't regularly test it off our own dev machines; and we don't support WSL1. Is that correct? Whatever is the case, perhaps it should be clear on https://github.com/dotnet/core/blob/main/release-notes/7.0/supported-os.md.

[karelz]

Triage: Let's fix what we can easily fix in 8.0.
Based on above answers we can consider backporting to 7.0 if it is supported.

[danmoseley]

On my spare box I created a WSL1 Ubuntu, built main and ran tests (incl outerloop). I got 235 failures, most in networking. About 37 hit this bug, the others various things many timeouts, protocol not available... There were other due to other parts of the /proc filesystem being missing or having zeros. Some filesystem failures, a couple where Roslyn code fails in an odd way, a peculiar string parsing one.

It seems it broadly does work (the build worked, for example, and almost all tests are passing) and fixing this issue would fix some, but there are some significant failures too so I'm not sure it's useful for running real apps reliably.

[f-markus]

I don't actually know WHY the customer uses WSL1, but I think it's no special reason. Maybe he doesn't know about V2, or is too lazy to upgrade (same situation I am in :-) ) Anyway, just to give my personal view, I think that since WSL2 exists, and .NET7 supports it, WSL1 is obsolete. If I have to tell my customers to upgrade to WSL2 it's good enough for me, esp. as I don't actually promote or officially support WSL. Thanks for your efforts! Am Do., 29. Sept. 2022 um 22:58 Uhr schrieb Dan Moseley < ***@***.***>:

…

On my spare box I created a WSL1 Ubuntu, built main and ran tests (incl outerloop). I got 235 failures, most in networking. About 37 hit this bug, the others various things many timeouts, protocol not available... There were other due to other parts of the /proc filesystem being missing or having zeros. Some filesystem failures, a couple where Roslyn code fails in an odd way, a peculiar string parsing one. It seems it broadly does work (the build worked, for example, and almost all tests are passing) and fixing this issue would fix some, but there are some significant failures too so I'm not sure it's useful for running real apps reliably. — Reply to this email directly, view it on GitHub <#75883 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN4YZHK7UH3MMGOV5PIQHDTWAX7INANCNFSM6AAAAAAQQ56XGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rzikm]

Looks like backporting is not necessary, so I will keep the issue closed (it is now fixed in main). If something changes let us know.

[danmoseley]

For what it's worth I reran the tests with this fix. Now there are 198 failures - so it's fixed. But still unclear how useful it is to run code in WSL1. Possibly for some dev scenario, but WSL2 is much preferred.

[rzikm]

Reopening for backporting to 7.0 because the regression was hit in other environments, such as gVisor #81061

[karelz]

Fixed in main (8.0) in PR #76383 and in 7.0.4 in PR #81157.