In fact, what better way to warm my frozen digits up than with some finger-flexing keyboard aerobics? This will give you complete control over the virtual network WSL just won't give that to you.Penguins might love snow, but some bloggers don’t!Īs you may be aware from our gasps of panic, the UK is currently cosseted by thick quilting of snow (and my house without any form of functional heating).īut freezing cold conditions are no excuse for me to slack on the content front. However, I would recommend that the better option for your course would be running several virtual machines with something like VirtualBox (or even Hyper-V if you have Windows Pro or Education). Regardless, at the least you should switch to WSL2 for this. WSL2 has no concept of that WiFi network, since it's NAT'd behind the virtual Hyper-V switch. tshark will run and capture packets originating from and destined to the virtual network, but it won't see (for example) traffic between your phone and your Windows host on the WiFi network. WSL2, on the other hand, is a real Linux kernel running in a virtualized environment. And dang, IMHO, WSL1 does an amazing job of running so much with those limitations, but promiscuous network captures are not one of the things that are translated. ip addr), these are Windows network interfaces, not Linux.Īs such, there's only "so much" that has been translated. While, you really can see the Windows network interfaces with Linux commands (e.g.
There are advantages and disadvantages to this. All Linux syscalls in WSL1 go through a "translation layer" where they are matched to Windows APIs. Network interfaces in WSL1 are not "real" Linux network interfaces. WSL1, in my experience, isn't going to work at all. Neither WSL1 nor WSL2 is "great" for running any packet capturing, for differing reasons: I love WSL, but it probably isn't the right tool for you in this case.
0 kommentar(er)
