microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.42k stars 823 forks source link

Mirrored mode - WSL chooses to mirror the disconnected host wifi adapter instead of the connected host ethernet adapter #10884

Open nincode opened 11 months ago

nincode commented 11 months ago

Windows Version

Microsoft Windows [Version 10.0.22631.2792]

WSL Version

2.0.9.0

Are you using WSL 1 or WSL 2?

Kernel Version

5.15.133.1-1

Distro Version

Ubuntu 22.04

Other Software

No response

Repro Steps

Windows host has two network adapters:

Launch WSL2 with mirrored mode on

I expect eth0 to be mapped to the host's ethernet adapter. However, eth0 is down. Alternatively, eth1 might be mapped to the host's ethernet adapter, however, eth1 is also down. There's no network connectivity from the WSL2 instance.

When I connect wifi to the AP on the host (keep in mind that ethernet was connected all along), I get:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether f0:2f:74:17:fb:9b brd ff:ff:ff:ff:ff:ff
3: loopback0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:94:14:45 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 3c:9c:0f:8c:67:e3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.86.244/24 brd 192.168.86.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever
    inet6 fde2:e410:ef31:ba1b:918f:4cbd:b0aa:e961/64 scope global nodad deprecated noprefixroute
       valid_lft forever preferred_lft 0sec
    inet6 fde2:e410:ef31:ba1b:ed0d:5578:aa63:9ee5/128 scope global nodad noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::9a4e:1657:ce6e:4077/64 scope link nodad noprefixroute
       valid_lft forever preferred_lft forever

Notice that eth1 is now mapped to the now connected wifi adapter (fine, I guess), but the connected ethernet adapter is not mapped within the WSL instance (eth0 is down).

Expected Behavior

I expect the ethernet adapter to be always connected in WSL2 as eth0. This is the behavior I get if I change networking back to NAT.

Actual Behavior

❯ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether f0:2f:74:17:fb:9b brd ff:ff:ff:ff:ff:ff 3: loopback0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:15:5d:94:14:45 brd ff:ff:ff:ff:ff:ff 4: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 3c:9c:0f:8c:67:e3 brd ff:ff:ff:ff:ff:ff

Diagnostic Logs

No response

github-actions[bot] commented 11 months ago

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

Closed similar issues:

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

chanpreetdhanjal commented 10 months ago

Hi. Can you please collect networking logs by following the instructions below? https://github.com/microsoft/WSL/blob/master/CONTRIBUTING.md#collect-wsl-logs-for-networking-issues

0Delta commented 5 months ago

same problem If I provide information on his behalf, will this progress?

chanpreetdhanjal commented 5 months ago

We will prioritize it with other items we have in our queue as soon as we get networking logs.

0Delta commented 5 months ago

Thank you for your progress in the investigation. My environment and logs.

Windows Version

Microsoft Windows 11 Version 23H2 OS build 22631.3527 Windows Version (from wsl --version ) 10.0.22631.3527

WSL Version

2.1.5.0

Are you using WSL 1 or WSL 2?

WSL 2

Kernel Version

5.15.146.1-2

Distro Version

Ubuntu 22.04

Logs

WslLogs-2024-05-15_14-45-20.zip WslNetworkingLogs-2024-05-15_14-44-17.zip

CatalinFetoiu commented 5 months ago

hello @0Delta. thanks for attaching the logs

it looks like the interfaces mirrored in Linux (eth0 and eth1) are in a bad state, they are down and don't have IP addresses assigned. this is already the case before the tracing was started.

in order to see what caused the interfaces to be in this state, can you please collect new logs by doing the following?

start the networking logs script run "wsl --shutdown" start wsl and reproduce the issue stop the networking logs script

thanks

0Delta commented 5 months ago

Hi @CatalinFetoiu .

I tried to follow your instructions but ran into some problems. I managed to get the logs by swapping steps and using tricks and I am attaching them.

I did the following steps

PS C:\Users\zdelta> .\collect-networking-logs.ps1

    ディレクトリ: C:\Users\zdelta

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        2024/05/22     23:40                WslNetworkingLogs-2024-05-22_23-40-27
wsl_networking.wprp not found in the current directory. Downloading it from GitHub.
networking.sh not found in the current directory. Downloading it from GitHub.

データ収集を初期化しています。お待ちください。
初期化が完了しました。シナリオを再現し、次に 'capture stop' を実行します。

Log collection is running. Please reproduce the problem and press any key to save the logs.
Saving logs...
データ収集が正常に行われました。出力 = WslNetworkingLogs-2024-05-22_23-40-27/wfpdiag.cab

100%  [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]

"3" 個の引数を指定して "Write" を呼び出し中に例外が発生しました: "ストリームが長すぎます。"
発生場所 C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Archive\Microsoft.PowerShell.Archive.psm1:820 文字:29
+ ...                     $destStream.Write($buffer, 0, $numberOfBytesRead)
+                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : IOException

Logs saved in: C:\Users\zdelta\WslNetworkingLogs-2024-05-22_23-40-27.zip. Please attach that file to the GitHub issue.

The final log is here. WslNetworkingLogs-2024-05-22_23-40-27_bak.zip

Thanks for the research.

CatalinFetoiu commented 5 months ago

@0Delta sorry about the issues with the script. unfortunately the zip you shared does not contain a logs.etl file, which is needed for investigating the issue.

can you try restarting the Windows machine, then running the script again? It's possible some cleanup of the script did not succeed and it's interfering with reruns of the script.

please run collect-networking-logs.ps1 first, then run "wsl --shutdown". WSL autorestarts, so if we start the script after running "wsl --shutdown", it's possible some parts of the WSL initialization are not captured in the logs.

thanks

0Delta commented 5 months ago

@CatalinFetoiu I have good news and bad news.

I rebooted my PC and WSL2 is still online and communicating even after switching between wired and wireless and I am no longer able to log. Is there an update or something wrong ......

Anyway, I am currently unable to proceed with this ticket. If it reoccurs, I will attach the log.

0Delta commented 5 months ago

Hello.

Unfortunately, the problem has recurred again. The log was generated, but there was a problem that the compressed file was not generated as before. As in the previous time, we took a backup before compression of the file and compressed it. This time, Logs.etl also exists, but it has become a huge of 7GB. (It is 230MB even if compressed)

So i couldn't attach it here, so I put it in Google Cloud Storage.

https://storage.googleapis.com/wsl_issues_10884/WslNetworkingLogs-2024-05-31_23-50-14_bak.zip sha256 hash : b18c2804cf66fdd5a60d634b5e7cfc4ffb2b735114f55aa759c1030bb555aa97

cveld commented 4 months ago

Can we enforce WSL to mirror a specific eth adapter? I have three in wsl, and not sure if it tries to mirror the right one. At least in mirrored mode I am not able to connect from Windows to a wsl service. eth0 is the working one; I would expect it defaults to this anyways. So maybe my issue is somewhere else.