Open nnathan opened 3 months ago
If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'. Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.
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!
Note: You can give me feedback by thumbs upping or thumbs downing this comment.
Attached wsl logs to appease bot.
The log file doesn't contain any WSL traces. Please make sure that you reproduced the issue while the log collection was running.
Just attaching logs to appease bot: WslLogs-2024-07-22_04-02-27.zip
(These are the incorrect logs; but the logs don't even matter for this issue)
@nnathan in case you missed the release notes, emphasis on the custom kernel:
We are very excited kernel module support is now available in WSL2! With this latest kernel update, a large set of loadable modules has been introduced, accompanied by an overall config file update. However, please be aware that when using a custom kernel, the default module support is disabled for now. If you’re using a custom kernel, we recommend you edit your kernel config file to build-in all of the modules that you need.
Also, after cloning the repository delete .git
to get rid of the +
at the end of kernel name string.
First try loading manually the required modules or build a kernel with the modules included.
@zcobol
I did actually heed that warning but I couldn't get the kernel to boot when everything is not a module.
I did this:
$ git clean -d -f -x
$ mv .git .git.bak # to get rid of + at end of kernel name
$ cp Microsoft/config-wsl .config
$ sed -i'' -e 's#=m$#=y#g' .config
$ make -j`nproc` KCONFIG_CONFIG=.config
$ cp arch/x86_64/boot/bzImage /mnt/c/Users/naveen/bzImage-linux-msft-wsl-6.6.36.3
Then I set the kernel in .wslconfig
.
I get the following:
Specifically the bottom part is the issue:
[ 1.713731] Run /init as init process
[ 1.713903] with arguments:
[ 1.714072] /init
[ 1.714192] with environment:
[ 1.714360] HOME=/
[ 1.714463] TERM=linux
[ 1.714582] WSL_ROOT_INIT=1
[ 1.715144] WSL (1) ERROR: UtilConnectVsock:587: connect port 50000 failed 19
[ 1.715549] WSL (1) ERROR: No such file or directory @C:/__w/1/s/src/shared/inc\stringshared.h:247 (ReadFile)
[ 1.716069] WSL (1) ERROR: filesystem error: in directory_iterator::directory_iterator(...): No such file or directory ["/sys/bus/scsi/devices"]
[ 1.716283] sd 1:0:0:0: [sda] Synchronizing SCSI cache
I'm not sure what to do - any suggestions?
The latest WSL kernel (6.6.36.3-microsoft-standard-WSL2) already supports masquerading:
elsaco@PORTLAND:~$ modinfo xt_MASQUERADE
filename: /lib/modules/6.6.36.3-microsoft-standard-WSL2/kernel/net/netfilter/xt_MASQUERADE.ko
alias: ipt_MASQUERADE
alias: ip6t_MASQUERADE
description: Xtables: automatic-address SNAT
author: Netfilter Core Team <coreteam@netfilter.org>
license: GPL
depends:
retpoline: Y
intree: Y
name: xt_MASQUERADE
vermagic: 6.6.36.3-microsoft-standard-WSL2 SMP preempt mod_unload modversions
After running your iptables commands this is the output of the nat
table:
elsaco@PORTLAND:~$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 172.22.0.0/24 anywhere
MASQUERADE all -- anywhere anywhere
List of all modules in the netfilter included in the default WSL2 kernel:
elsaco@PORTLAND:~$ ls /lib/modules/6.6.36.3-microsoft-standard-WSL2/kernel/net/netfilter/
ipset nf_synproxy_core.ko xt_CHECKSUM.ko xt_cgroup.ko xt_mark.ko
ipvs nfnetlink_acct.ko xt_CLASSIFY.ko xt_cluster.ko xt_multiport.ko
nf_conncount.ko nfnetlink_cttimeout.ko xt_CONNSECMARK.ko xt_comment.ko xt_nat.ko
nf_conntrack_amanda.ko nfnetlink_osf.ko xt_CT.ko xt_connbytes.ko xt_nfacct.ko
nf_conntrack_broadcast.ko nfnetlink_queue.ko xt_DSCP.ko xt_connlabel.ko xt_osf.ko
nf_conntrack_ftp.ko nft_compat.ko xt_HL.ko xt_connlimit.ko xt_owner.ko
nf_conntrack_h323.ko nft_connlimit.ko xt_HMARK.ko xt_connmark.ko xt_physdev.ko
nf_conntrack_irc.ko nft_ct.ko xt_IDLETIMER.ko xt_conntrack.ko xt_pkttype.ko
nf_conntrack_netbios_ns.ko nft_fib.ko xt_LOG.ko xt_cpu.ko xt_policy.ko
nf_conntrack_netlink.ko nft_hash.ko xt_MASQUERADE.ko xt_dccp.ko xt_quota.ko
nf_conntrack_pptp.ko nft_limit.ko xt_NETMAP.ko xt_devgroup.ko xt_realm.ko
nf_conntrack_sane.ko nft_log.ko xt_NFLOG.ko xt_ecn.ko xt_recent.ko
nf_conntrack_sip.ko nft_numgen.ko xt_NFQUEUE.ko xt_esp.ko xt_sctp.ko
nf_conntrack_snmp.ko nft_queue.ko xt_REDIRECT.ko xt_hashlimit.ko xt_set.ko
nf_conntrack_tftp.ko nft_quota.ko xt_SECMARK.ko xt_helper.ko xt_socket.ko
nf_log_syslog.ko nft_redir.ko xt_TCPOPTSTRIP.ko xt_ipcomp.ko xt_state.ko
nf_nat_amanda.ko nft_reject.ko xt_TEE.ko xt_iprange.ko xt_statistic.ko
nf_nat_ftp.ko nft_reject_inet.ko xt_TPROXY.ko xt_ipvs.ko xt_string.ko
nf_nat_irc.ko nft_tproxy.ko xt_TRACE.ko xt_length.ko xt_tcpmss.ko
nf_nat_sip.ko nft_tunnel.ko xt_addrtype.ko xt_limit.ko xt_time.ko
nf_nat_tftp.ko xt_AUDIT.ko xt_bpf.ko xt_mac.ko xt_u32.ko
However, if you want to experiment with custom kernels, please do!
Actually I noticed the default kernel is now 6.6.36.3-microsoft-standard-WSL2
. Did this change recently? I'm happy to use that as the standard kernel. I was on 5.15 before.
wsl-2.3.17
was just released and we're back to kernel-5.15.153.1
. See the release log at https://github.com/microsoft/WSL/releases/tag/2.3.17
I am wondering what issues made the Kernel to be reverted to version 5.15.x ?
same question here. why revert and not upgrade to 6.10.4? (or 6.6.45 lts)
greetings
Just my 2ct... I don't think that upgrading to a new version in the 6.6 or 6.10 will make any difference for Microsoft. I barely think that the problem is the upstream Kernel, I guess it's a problem with the patch set from Microsoft which they didn't figure out yet. Also it seems that this is an fundamental problem because the first try to get away from the 5.15 Kernel was with release 1.1.7 (Apr 4, 2023) to 6.1.21 this was reverted on the same day with 1.2.0. The new try more than a year later to upgrade to 6.6.36 leasts also not long an was reverted with nearly the same reason (debug some issues). I don't expect an upgrade soon but that's not a problem I would say as long as the 5.15 is not EOL (Dec. 2026).
Hi @MorphBonehunter
Note that the EOL of versions 5.15 and 6.6 are very similar (Oct. 2026 vs Dec. 2026). Upgrading takes a lot of work, and upgrading to 6.6 will have little benefit.
I believe it would be better for Microsoft to wait and update to a future Kernel version (maybe 7.x ?) that has a longer support time.
Waiting won't be a problem as the current version 5.15 has security and bug fix support until 2026.
Windows Version
Microsoft Windows [Version 10.0.22631.3880]
WSL Version
2.3.13.0
Are you using WSL 1 or WSL 2?
Kernel Version
6.6.36.3-microsoft-standard-WSL2+
Distro Version
Ubuntu 24.04 LTS
Other Software
iptables v1.8.10 (nf_tables)
Repro Steps
Build the kernel first:
Edit
~/.wslconfig
:Shutdown WSL2
Start WSL2
Verify kernel:
Now run iptables command:
Expected Behavior
This should work as it does in the 5.15 kernel.
Actual Behavior
iptables doesn't work with MASQUERADE target which pretty much also means Docker is unusable.
Diagnostic Logs