Issue with WLS listening to TCP ports (again issue #1554 reccurs)

[lefty-kreouzis]

Please use the following bug reporting template to help produce actionable and reproducible issues. Please try to ensure that the reproduction is minimal so that the team can go through more bugs!

• A brief description
  The issue with listening to tcp ports by WSL occured again (discussion on old issue Issue with WSL listening to TCP ports #1554)

• Expected results
  we should be able to create a server in WSL

• Actual results (with terminal output if applicable)
  We cannot create it

• Your Windows build number
  Microsoft Windows [Version 10.0.14986]

• Steps / All commands required to reproduce the error from a brand new installation

in WSL bash shell:
lefty@Turing:~$ nc -v4l 4444
Listening on [0.0.0.0] (family 2, port 4444)

In command

C:\Users\lefty>netstat -an |find "LIST"
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5357 0.0.0.0:0 LISTENING
TCP 0.0.0.0:17500 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49664 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49665 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49666 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49667 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49668 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49669 0.0.0.0:0 LISTENING
TCP 127.0.0.1:843 0.0.0.0:0 LISTENING
TCP 127.0.0.1:17600 0.0.0.0:0 LISTENING
TCP 192.168.1.42:139 0.0.0.0:0 LISTENING
TCP 192.168.1.42:49923 0.0.0.0:0 LISTENING
TCP [::]:135 [::]:0 LISTENING
TCP [::]:445 [::]:0 LISTENING
TCP [::]:5357 [::]:0 LISTENING
TCP [::]:17500 [::]:0 LISTENING
TCP [::]:49664 [::]:0 LISTENING
TCP [::]:49665 [::]:0 LISTENING
TCP [::]:49666 [::]:0 LISTENING
TCP [::]:49667 [::]:0 LISTENING
TCP [::]:49668 [::]:0 LISTENING
TCP [::]:49669 [::]:0 LISTENING

It happened again

It worked yesterday - it doesn't work today
I uninstalled Avast AV to see if it made any difference but it doesn't
I looked through the Event viewer but didn't see anything
I am going crazy

Please help ;-)

Thanks

Lefty

[therealkenc]

There's no repro so not a lot to go on to track it down. But I feel your pain. There's only a couple of possibilities given the data points here. (A) Avast did something between being freshly installed yesterday (when it worked) and that can't be undone with uninstall. (B) Something else completely unrelated to Avast changed between fresh install and today, but we collectively have no idea what.

Given you're probably going to do the reinstall dance again, couple of things. If you can live without Avast for a few days or a week start with that. Smart money says it keeps working for that week, but that's only a guess based on limited information. That covers (A). Then after you reinstall, don't give yourself admin privileges and keep a journal of every time you're prompted for the admin password and why it was needed. Whatever is breaking WSL listen/accept (a registry change, a change to the system files in general) is going to need admin, and at least you'll have a log of everything that changed between points in time. That will help figure out (B). Finally, set up system restore points and use them so at least you don't have to do a full reinstall and can bisect if (when) it breaks again. It's not much, but that's all I got.

[lefty-kreouzis]

Gotcha!!!!!

I logged in to my company VPN that uses the Pulse secure SSL vpn proxy and forwarding stopped working.

I uninstalled the Pulse secure stuff and it started working again

So nothing to do with Avast

At least I don't have to reinstall everything again ;-)

[lefty-kreouzis]

Further info

The culpit is Pulse Secure Application Manager
Install - not working
Uninstall and reboot - works again

[sunilmut]

@therealkenc, thanksf or the help in troubleshooting this.

@lefty-kreouzis - Do you know if install the Pulse Secure Application Manager is also installing a new network interface in Windows with it's own DNS entry? You can see this using ifconfig /all on Windows cmd prompt. If so, this could be related to other known networking issues with VPN such as #1350 or #416

[lefty-kreouzis]

@sunilmut assuming you mean ipconfig /all - no,no extra interfaces are there, I checked

My only guess is some weird hooking up in the kernel that can cause these issues

[sunilmut]

@lefty-kreouzis I am closing this issue given that you have a resolution and it doesn't look like an issue with WSL so far. If that changes in future, please let us know and we can reopen the issue.