-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NetworkInformationException when querying network interfaces in WSL 1 #75883
Comments
Tagging subscribers to this area: @dotnet/ncl Issue DetailsDescriptionA 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'. Reproduction StepsI don't use WSL, but from the code it should be fairly easy to reproduce: Expected behaviorNo exception, but a list of valid networkinterfaces Actual behaviorException instead of list of network interfaces Regression?The very same code works with .NET6.0 as TargetPlatform Known WorkaroundsNo response ConfigurationNo response Other informationNo response
|
Triage: Looks like regression. |
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 |
@richlander is WSL1 entirely unsupported? I don't believe we test on it, and hit problems in the past. |
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) |
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. |
Triage: Let's fix what we can easily fix in 8.0. |
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. |
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:
***@***.***>
|
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. |
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. |
Reopening for backporting to 7.0 because the regression was hit in other environments, such as gVisor #81061 |
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.
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
The text was updated successfully, but these errors were encountered: