Open nincode opened 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!
Note: You can give me feedback by thumbs upping or thumbs downing this comment.
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
same problem If I provide information on his behalf, will this progress?
We will prioritize it with other items we have in our queue as soon as we get networking logs.
Thank you for your progress in the investigation. My environment and logs.
Microsoft Windows 11
Version 23H2
OS build 22631.3527
Windows Version (from wsl --version
) 10.0.22631.3527
2.1.5.0
WSL 2
5.15.146.1-2
Ubuntu 22.04
WslLogs-2024-05-15_14-45-20.zip WslNetworkingLogs-2024-05-15_14-44-17.zip
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
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
wsl --shutdown
collect-networking-logs.ps1
ping 8.8.8.8
within WSL2 (works fine)collect-networking-logs.ps1
.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.
@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
@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.
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
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.
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:
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