Microsoft Releases A Big Update To Windows Subsystem For Linux, New Experimental Options

[elvis]

Quite the disappointment, I have to say. WSL users have been requesting a proper, supported bridged interface forever it feels. We've had the NAT option since day one, which is fine for very basic outbound usage. This new "mirrored" option is designed to alleviate the want for inbound connections, except it has serious limitations. Try and start any listening service inside your WSL VM where the network port is in use inside of your Windows host, and the service fails, as this mirrored mode clones your MAC and IP inside the WSL instance entirely. (I've tested this just now to confirm).

There were some workaround for bridged networking options in Windows 10/11 in the past, but they were troublesome. There was about a 50% hit rate on success based on your specific brand of NIC and driver (and wireless NICs in particular hard a very low success rate). And then any updates to your system generally broke your bridge setup and required you to rebuild it. Compare to other desktop-focussed VM solutions like VirtualBox, where network bridging is very simple, and completely independent of your brand/type of NIC.

The argument remains that bridging is "advanced usage" territory and "nobody wants it", except I call total BS on that. WSL itself is "advanced usage" territory already, so claiming that customers aren't smart enough to understand network bridging is an insult. Additionally, enough people want a fully supported bridged network setup that we got this "mirrored" thing to appease those requests, except it's a half-solution at best. I also don't really accept the argument that putting a bridged interface in will kill off Hyper-V sales to any level that warrants argument. If people want unrestricted $0 virtualisation, that exists across a multitude of simple solutions today (VirtualBox, ProxMox, many more). There are zero valid reasons for not offering this very standard, very banal feature.

I really hope Microsoft just get it together and offer bridged networking like literally every other modern desktop VM solution. It's been long enough.

[dragorth]

I checked literally 3 hours ago to see if they updated their kernel and stuff lately. Missed this by one hour, wouldn't have checked again for weeks if it weren't for this article, cheers for that. Weird they still haven't moved the kernel to 6.1 yet when they've already tagged a release for that months ago. I've run that for a while without any problems, not sure why they haven't gone with it

Could it be the Android subsystem? Don't they use the same kernel for both? They may need more time to test that kernel.

[edxposed]

Quite the disappointment, I have to say. WSL users have been requesting a proper, supported bridged interface forever it feels. We've had the NAT option since day one, which is fine for very basic outbound usage. This new "mirrored" option is designed to alleviate the want for inbound connections, except it has serious limitations. Try and start any listening service inside your WSL VM where the network port is in use inside of your Windows host, and the service fails, as this mirrored mode clones your MAC and IP inside the WSL instance entirely. (I've tested this just now to confirm).

There were some workaround for bridged networking options in Windows 10/11 in the past, but they were troublesome. There was about a 50% hit rate on success based on your specific brand of NIC and driver (and wireless NICs in particular hard a very low success rate). And then any updates to your system generally broke your bridge setup and required you to rebuild it. Compare to other desktop-focussed VM solutions like VirtualBox, where network bridging is very simple, and completely independent of your brand/type of NIC.

The argument remains that bridging is "advanced usage" territory and "nobody wants it", except I call total BS on that. WSL itself is "advanced usage" territory already, so claiming that customers aren't smart enough to understand network bridging is an insult. Additionally, enough people want a fully supported bridged network setup that we got this "mirrored" thing to appease those requests, except it's a half-solution at best. I also don't really accept the argument that putting a bridged interface in will kill off Hyper-V sales to any level that warrants argument. If people want unrestricted $0 virtualisation, that exists across a multitude of simple solutions today (VirtualBox, ProxMox, many more). There are zero valid reasons for not offering this very standard, very banal feature.

I really hope Microsoft just get it together and offer bridged networking like literally every other modern desktop VM solution. It's been long enough.

[wsl2]
networkingMode = bridged
vmSwitch = Bridge

Unrecorded, but is working. 22H2+ only

[edxposed]

Could it be the Android subsystem? Don't they use the same kernel for both? They may need more time to test that kernel.

WSA uses another ACK-based kernel that just shares the HV guest driver with the WSL2 kernel.

[jacob]

I wonder how long before Microsoft releases a full, proper distro.

I also wonder if they did, how long it would be before the Linux faithful would complain that it sucks.

They have had a full distro for quite a while now.

[mdedetrich]

They have had a full distro for quite a while now.

Yup https://github.com/microsoft/CBL-Mariner

[Karmux]

Some of my programmer colleagues were using WSL but soon started to realize that there is little point of Windows around WSL, all of extra hassle and overhead and started switching to Linux.

[slalomsk8er]

You don't understand having working public/private keys in SSH, even if it is a sub-system? It means WSL is not usable past the host system without typing passwords everywhere. This makes WSL non-usable on any serious system that has to talk to other computers.

I use SSH keys in a password manager on windows (it's a managed work machine) and with socat and npiperelay, the SSH agent gets piped though to WSL2.

from my bashrc inside of WLS:

export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock

ss -a | grep -q $SSH_AUTH_SOCK
if [ $? -ne 0 ]; then
rm -f $SSH_AUTH_SOCK
(setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"$HOME/npiperelay/npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork &) >/dev/null 2>&1
fi
export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock

Looks a bit different but definitely a nicer write up then I could provide here: https://stuartleeks.com/posts/wsl-ssh-key-forward-to-windows/

[RAINFIRE]

I use SSH keys in a password manager on windows (it's a managed work machine) and with socat and npiperelay, the SSH agent gets piped though to WSL2.

from the my bashrc inside...

Or you could just download the FIXED OpenSSH from GitHub linked in original post and not have to try all sorts of hacks to get the SSH Agent working in Windows 10, 11, Server, WSL or even by Windows Update. OS Version is borked. I'm not even sure a fixed OS SSH agent will even extend to the WSL? It's all just wrong on so many levels. Cygwin was better than this 15 to 20 years ago . . . again, just my opinion.

[citral]

I wonder how long before Microsoft releases a full, proper distro.

I also wonder if they did, how long it would be before the Linux faithful would complain that it sucks.

Well it would obviously be closed source.
And for having worked in the past with many closed-source unix variants (hp, aix, solaris) I can already tell you it will suck.