Skip to content
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

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

Open
1 of 2 tasks
nincode opened this issue Dec 7, 2023 · 9 comments
Labels

Comments

@nincode
Copy link

nincode commented Dec 7, 2023

Windows Version

Microsoft Windows [Version 10.0.22631.2792]

WSL Version

2.0.9.0

Are you using WSL 1 or WSL 2?

  • WSL 2
  • WSL 1

Kernel Version

5.15.133.1-1

Distro Version

Ubuntu 22.04

Other Software

No response

Repro Steps

Windows host has two network adapters:

  • Wired (connected)
  • Wifi (disconnected from AP)

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

Copy link

github-actions bot commented Dec 7, 2023

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
Copy link

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
Copy link

0Delta commented May 14, 2024

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

@chanpreetdhanjal
Copy link

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

@0Delta
Copy link

0Delta commented May 15, 2024

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
Copy link
Collaborator

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
Copy link

0Delta commented May 22, 2024

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
  • Connect PC to internet via Wifi
  • Start WSL2
  • ping 8.8.8.8 within WSL2 (works fine)
  • Connect wired to PC, automatically switches from wireless to wired
  • ping starts to fail
  • Exit collect-networking-logs.ps1.
  • Archive generation fails with the following message, so copy the directory created before archive generation
  • Compressed the copied backup with 7zip.
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
Copy link
Collaborator

@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
Copy link

0Delta commented May 23, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants