XPost: alt.comp.os.windows-11, comp.mobile.android

Warning: If you enable Hyper-V (e.g., WSL, Docker, VMs, etc.) on Windows,
and if you ever want to assign an outgoing port to any process (e.g.,
stunnel, adb, etc.), then you will be a very unhappy person (for years!) if
you don't heed this warning outlined below.

A. Things will work just fine when you set it up
B. But, randomly, after a boot (maybe months later) things fail
C. And yet, another reboot (or two) instantly fixes it again

Over and over... for years...

Hence, this would be the WRONG way to do things (which I apparently did).
a. You use stunnel or adb (or anything else that needs outgoing ports)
b. If you enabled Hyper-V - you will be very sorry with what happens
c. Because available outgoing ports will be randomly yanked from you

It's completely random (AFAICT).
So if it worked today, it could just as well fail next week.
With zero debugging information (other than port binding failed).

Why?

1. Apparently Hyper-V, is enabled by WSL, Docker, VMs, etc.
PS> Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All
2. Hyper-V tells WinNAT to exclude random blocks of ports
3. This happens for IPv4, IPv6, UDP & TCP but we'll focus on TCP only
4. In my case, 13 random blocks of 100 contiguous ports were reserved
5. Each reboot would randomly select another set of 13 random blocks
6. So, for example, if ADB is using port 55555, then you're fine if
the 1300 random blocks don't include 55555 but you're screwed if they do
7. ADB will fail but all ADB knows is that a permission was denied
C:\> adb devices
* daemon not running; starting now at tcp:55555
could not read ok from ADB Server
* failed to start daemon
adb.exe: failed to check server version: cannot connect to daemon
8. There is no debugging ADB can give as it only knows permission denied
9. Even netstat can't help you, nor resmon, nor promon, nor powershell
C:\> netstat -ano | findstr :54555 (returns nothing!)
10. You won't be able to even manually bind to those 1300 random ports
C:\> ncat -l -p 55555 (ADB will fail with "permission denied")
11. Yet, nothing is using those 1300 ports so you can not work backward
C:\> resmon > Network > Listening Ports > Port = 54321 > PID
C:\> procexp.exe > Find > Find Handle or DLL > 54321 > Search
C:\> procmon.exe > Filter (timing is crucial)
12. The only way you know the ports are excluded is to run this command.
C:\> netsh interface ipv4 show excludedportrange protocol=tcp

What's the *PROPER* way to let adb use port 55555 (which is its default)?

1. The proper way is to know ahead of time you need to reserve the port!
C:\> netsh int ipv4 add excludedportrange protocol=tcp startport=55555 numberofports=1
2. Once you reserve the port, then ADB will have no problem using it
3. Better yet, when Hyper-V tells WinNAT to exclude 1300 random ports,
winnat will skip any port you've previously excluded, so you're fine

Notice that the *proper* way to use some tools which need an outgoing port
is to exclude that port first, and then use the tool that needs that port.

In the case of ADB, the port is the default (AFAIK), where I wouldn't know
how to change the default port ADB uses to connect to Android over USB.

However, in the case of Stunnel, you will want most likely to reserve a
block of ports since you can easily set up more than one nntp server.

To reserve a block of 100 ports just for your personal use, use this:
C:\> netsh int ipv4 add excludedportrange protocol=tcp startport=55500 numberofports=101

Now you have, forever, your own block of outgoing ports from 55500
to 55600 that you can use for any program that needs a port set.

I never took a class in networking so I don't really know why you
have to do this - but all I know it not knowing this cost me zillions
of hours over the years of wasted debugging that knowing what is in this
one post would have saved me (and which is why I'm posting this for you).

Let me know if you have any questions. More details are in this thread:
*Port Permission Denied finally resolved after years of debugging*
<https://www.novabbs.com/computers/article-flat.php?id=87044&group=alt.comp.os.windows-10#87044>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, comp.mobile.android

Marion, 2025-05-07 00:24:

Warning: If you enable Hyper-V (e.g., WSL, Docker, VMs, etc.) on Windows,
and if you ever want to assign an outgoing port to any process (e.g., stunnel, adb, etc.), then you will be a very unhappy person (for years!) if you don't heed this warning outlined below.

[...]

I never took a class in networking so I don't really know why you
have to do this - but all I know it not knowing this cost me zillions
of hours over the years of wasted debugging that knowing what is in this
one post would have saved me (and which is why I'm posting this for you).

Well - since WSL2 provides the ability to access ports on the machine
*inside* WSL2 as 127.0.0.1 from the *host*, this is the expected behaviour.

If you don't like this - don't use WSL2 but instead Hyper-V only with a
"real" virtual machine inside Hyper-V and a virtual network setup for
Hyper-V which is shared with your host, for example 10.0.0.1/24 so you
can access the virtual machines at 10.0.0.2 from your host with is
10.0.0.1 (in addition to its regular IP address in your network). Then
the host won't have any blocked ports at all. To let the VM have access
to the outside world, it can then also directly use the network card of
the host as bridge and does not need NAT as well - so your host will
then be visible as two machines, one is your host and the second one is
the VM inside Hyper-V.

--
Arno Welzel
https://arnowelzel.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, comp.mobile.android

On Fri, 9 May 2025 09:05:48 +0200, Arno Welzel wrote :

Marion, 2025-05-07 00:24:

Warning: If you enable Hyper-V (e.g., WSL, Docker, VMs, etc.) on Windows,
and if you ever want to assign an outgoing port to any process (e.g.,
stunnel, adb, etc.), then you will be a very unhappy person (for years!) if >> you don't heed this warning outlined below.

[...]

I never took a class in networking so I don't really know why you
have to do this - but all I know it not knowing this cost me zillions
of hours over the years of wasted debugging that knowing what is in this
one post would have saved me (and which is why I'm posting this for you).

Well - since WSL2 provides the ability to access ports on the machine *inside* WSL2 as 127.0.0.1 from the *host*, this is the expected behaviour.

If you don't like this - don't use WSL2 but instead Hyper-V only with a "real" virtual machine inside Hyper-V and a virtual network setup for
Hyper-V which is shared with your host, for example 10.0.0.1/24 so you
can access the virtual machines at 10.0.0.2 from your host with is
10.0.0.1 (in addition to its regular IP address in your network). Then
the host won't have any blocked ports at all. To let the VM have access
to the outside world, it can then also directly use the network card of
the host as bridge and does not need NAT as well - so your host will
then be visible as two machines, one is your host and the second one is
the VM inside Hyper-V.

Thanks for that information. I turned off Hyper-V (I don't even know what
it does, and I stopped using WSL long ago) which solved some of the issues.

The only ports I mess with are in stunnel and the only reason I do that is
you have to if your newsreader is a bunch of telnet scripts. I guess if I ported the telnet scripts to openssl they might not need stunnel anymore.

Is that correct?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, comp.mobile.android

Marion, 2025-05-09 12:12:

[...]

The only ports I mess with are in stunnel and the only reason I do that is you have to if your newsreader is a bunch of telnet scripts. I guess if I ported the telnet scripts to openssl they might not need stunnel anymore.

Is that correct?

Well - I don't know what you do with "telnet scripts" and why you need
stunnel for them, so I can't answer your question.

But in general there is also SSH which can also tunnel connections from
your client to a server if the server does not allow you to access the
services on a public IP address or if you want to protect your
connection if the server does not support TLS.


--
Arno Welzel
https://arnowelzel.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, comp.mobile.android

On Fri, 16 May 2025 19:03:43 +0200, Arno Welzel wrote :

The only ports I mess with are in stunnel and the only reason I do that is >> you have to if your newsreader is a bunch of telnet scripts. I guess if I
ported the telnet scripts to openssl they might not need stunnel anymore.

Is that correct?

Well - I don't know what you do with "telnet scripts" and why you need stunnel for them, so I can't answer your question.

Well - what I "do" is my "newsreader" was written years ago on Linux
(mostly by Marek Novotny off of Usenet) which I had ported to Windows.

telnet nntp.server.net 119

It's just a bunch of scripts which fetch articles and present them in a
gVim window (since it was originally written for vi editing on Linux).

That's one reason I treat everyone the same, which is I treat them the way
they treat me in the post I'm responding to, since I don't see headers.

The only way I know whom I'm conversing with is by the attribute line.

So people sometimes claim I am "mean" to them; but the reality is that I'm
just reflecting their attitude since I only know what they wrote to me.

That's why Frank, for example, says I'm nice to him sometimes, and not
others; but Frank doesn't realize it's HE who is inconsistent; not me.

When someone says something intelligent, that's all I see (as I don't
generally even look at the attribute line) - so I respond similarly.

If they say something stupid - well - that's all I see; hence that's why I respond to them in the way that I do (I'm a mirror of their attitude).

I only see what THEY write; and I respond to them as they wrote to me.

But in general there is also SSH which can also tunnel connections from
your client to a server if the server does not allow you to access the services on a public IP address or if you want to protect your
connection if the server does not support TLS.

Since the newsreader is just a bunch of telnet scripts, Marek wrote a way
to use encryption, which is where stunnel on Windows came in handy.
telnet localhost 55563

That goes to Stunnel, but you MUST manually define the port ahead of time.
stunnel.conf
[Mixmin]
client = yes
accept = localhost:55563
connect = news.mixmin.net:563
CAfile = ca-certs.pem
verifyChain = yes
checkHost = news.mixmin.net
OCSPaia = yes

I didn't write the scripts so I try to mess with them as little as possible since they're been working for maybe two decades (not counting the years).

But if I had wanted to get rid of stunnel, I suspect I could change them to
use openssl since that doesn't require me to deal with the high ports.
openssl s_client -connect news.mixmin.net:563
200 news.mixmin.net InterNetNews NNRP server INN 2.8.0 (20230826 prerelease) ready (posting ok)
post
340 Ok, recommended Message-ID <[email protected]>
Message-ID: <[email protected]>
From: whoami@whereami
In-Reply-To: <[email protected]>
Newsgroups: alt.comp.os.windows-11,alt.comp.os.windows-10,comp.mobile.android
Subject: Re: Hyper-V locks up 1400 ports!
Date: Fri, 16 May 2025 10:11:12 MST
References: <[email protected]>
<blank>
Message body
<dot>
quit

Anyway, the problem of Hyper-V locking up ports has been happening for a
couple of years, but it was hard to debug because not only did a reboot
always fix it, but nothing was ever using the ports since I wasn't using Hyper-V. Hence the "solution" was to disable Hyper-V in my case.

If people need to use Hyper-V, then they *must* reserve ports they want to
use *ahead* of time since Winnat reservation is essentially random (AFAIK).

This is all very easy to do.
If you know that you need to do it.

Which is the reason for my public service warning to everyone else.
I'm always trying to help people as I'm one in a million that way.
--
It's interesting that the people most unhelpful are the ones who can't understand why someone would strive to always be helpful to others.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, comp.mobile.android

Marion, 2025-05-16 21:58:

[...]

If people need to use Hyper-V, then they *must* reserve ports they want to use *ahead* of time since Winnat reservation is essentially random (AFAIK).

You can also just disable the NAT and only use direct connections in the virtual machines in Hyper-V. This is why I suggested this *instead* of
using WSL2 if you need a Linux VM in Windows - because WSL2 does not
work without NAT.


--
Arno Welzel
https://arnowelzel.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, comp.mobile.android

On Sat, 17 May 2025 08:54:23 +0200, Arno Welzel wrote :

If people need to use Hyper-V, then they *must* reserve ports they want to >> use *ahead* of time since Winnat reservation is essentially random (AFAIK).

You can also just disable the NAT and only use direct connections in the virtual machines in Hyper-V. This is why I suggested this *instead* of
using WSL2 if you need a Linux VM in Windows - because WSL2 does not
work without NAT.

I thank you for that information which will help others.

Personally, I can't even spell Hyper-V as I have no idea what it is.
All I know is I have to enable it whenever a program asks me to do that.

Looking up what you said (which requires more understanding than I own), apparently Hyper-V is Microsoft's name for its virtual machine platform.

For that virtual machine to connect to the Internet, apparently it needs a
port to go through in order to get outside to the Internet. NAT takes care
of the pipe of the virtual machine port on one end and the real machine
port on the other end, apparently.

Apparently your reference to "direct connections" is a bridge of some sort. That bridge has its own IP address, apparently, just like another computer.

So, I guess, the VM traffic goes out that bridge directly to the router. Apparently that bridge isn't a physical device but a software construct.

Apparently that bridge is set up in the "Hyper-V Manager" (which I only
heard of for the first time at this moment in my search).
Hyper-V > Virtual Switch Manager > New virtual network > External >
Create Virtual Switch > {Name,Adapter,Sharing,VLAN ID,etc.}

Get-NetAdapter

New-VMSwitch -Name "<MySwitchName>" -NetAdapterName "<MyPhysicalAdapterName>" -AllowManagementOS $true

To validate:
PS> Get-VMSwitch

Given there isn't a single concept above that I was aware of before you
posted your suggestion, am I correct in assuming the "software bridge" you speak of is this External Virtual Switch I just created in Hyper-V
configured to bind to my physical network adapter?

If so, is my understanding correct that this virtual switch then handles
the task of bridging the network traffic between my VM and the physical network?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, comp.mobile.android

Marion, 2025-05-18 02:25:

On Sat, 17 May 2025 08:54:23 +0200, Arno Welzel wrote :

If people need to use Hyper-V, then they *must* reserve ports they want to >>> use *ahead* of time since Winnat reservation is essentially random (AFAIK). >>

You can also just disable the NAT and only use direct connections in the
virtual machines in Hyper-V. This is why I suggested this *instead* of
using WSL2 if you need a Linux VM in Windows - because WSL2 does not
work without NAT.

I thank you for that information which will help others.

Personally, I can't even spell Hyper-V as I have no idea what it is.
All I know is I have to enable it whenever a program asks me to do that. Looking up what you said (which requires more understanding than I own), apparently Hyper-V is Microsoft's name for its virtual machine platform.

Exactly - Hyper-V is the name of Microsofts virtual machine solution -
similar to VMware, QEMU etc.. You can create a virtual machine inside
Windows and run a second computer inside that - like Linux or another
Windows installation.

Before Hyper-V there was "VirtualPC" which Microsoft acquired many years
ago to provide the "Windows XP mode" in Windows 7 - in fact a virtual PC running Windows XP with a special license inside Windows 7.

For that virtual machine to connect to the Internet, apparently it needs a port to go through in order to get outside to the Internet. NAT takes care
of the pipe of the virtual machine port on one end and the real machine
port on the other end, apparently.

You can also just use the network card directly using a bridge driver.

Apparently your reference to "direct connections" is a bridge of some sort. That bridge has its own IP address, apparently, just like another computer.

Exactly. However WSL2 does not support bridging for security reasons.

So, I guess, the VM traffic goes out that bridge directly to the router. Apparently that bridge isn't a physical device but a software construct.

Exactly. But for the network it makes no difference, where the traffic
comes from - the VM will still be seen as an individual computer.

[...]

If so, is my understanding correct that this virtual switch then handles
the task of bridging the network traffic between my VM and the physical network?

Yes.


--
Arno Welzel
https://arnowelzel.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, comp.mobile.android

On Wed, 21 May 2025 02:16:23 +0800, Mr. Man-wai Chang wrote :

Did you activate Hyper-V in that PC? Or was it someone else? Maybe you
or that person forgot what had done....

Thanks for caring enough to ask for an explanation, which only came to me belatedly once I had finally figured out what was screwing up the boots
over the years.

The problem won't affect most people I think 'cuz most people don't have a
need to reserve specific ports, but I had that need so it affected me.

Every once in a while either adb or stunnel would have its ports locked up. This only happened after a boot. And it went away after a reboot.

What frustrated me is I *hate* when I don't know why something is
happening. I strive to understand what's the reason for such things.

Most people would blame Aliens, God or the (insert desired minority here).

I had blamed Microsoft Update because my machine boots after MS updates,
but it had nothing to do with the Microsoft Update, per se (other than my machine boots after a MS update).

What I didn't know, for years, was each time my machine booted, winnat
reserved 13 random blocks of 100 ports for Hyper-V but these ports were
NEVER used (since I don't use Hyper-V).

The main reason it took me a couple of years to figure this out was simply
that a reboot almost always fixed the problem, and two reboots always did.

Another reason for it having taken years to debug is there is no debugging command you can possibly run that tells you who is "using" those ports -
since nobody is using them - they're only excluded - they're never used.

Looking back, there's no doubt I must have enabled Hyper-V when doing some testing, perhaps of Docker (which I find to be an abomination) or WSL
(where I wrote a couple of tutorials to help people set up WSL on Windows).

Having enabled Hyper-V, I didn't know it at the time but that locks up 1300 random ports, which only sometimes conflict with the ports set for Stunnel.

If you ask why I need to use Stunnel, it's simply because my "newsreader"
is gVIM as a front end, and a bunch of telnet scripts as the back end.

For encryption, it uses Stunnel (but I probably should port it to OpenSSL).
And with Stunnel, you need to explicitly set the port for each server.

telnet localhost 55563

[Mixmin]
client = yes
accept = localhost:55563
connect = news.mixmin.net:563
CAfile = ca-certs.pem
verifyChain = yes
checkHost = news.mixmin.net
OCSPaia = yes
The reason for all this is simply that I want to use gVIM as my editor.

The adb port of 55555 was reserved for a different reason, which I had forgotten about, when I was valiantly trying to work around Android
security.

While ADB used port 5555 for years (and more recently port 5037) over USB, around Android 10 or 11 time frame ADB allowed Wi-Fi using ports in the
35000 to 55000 range (or so - I forget the actual range that it used).

I love using adb with Android (because it enables Windows & Android to be
one filesystem much as dual booting with Ubuntu manages to do the same).

So I was valiantly trying to get around the inconvenience of having to LOOK
at the Android phone to set the port for adb over Wi-Fi - but since that's
a security measure - even I was unable to get around that Android security.

Since I changed the port that adb uses (from 5037 to 55555) and it still
worked after many reboots, I eventually forgot I had changed the adb port.

The only time the problem came up was during these random port assignments.
And that port lockup only happened once every month or so.
And since that port lockup was already happening with Stunnel after
reboots, I didn't think that the adb issue was a separate problem.

And it wasn't.
In the end, the solution for the NEXT PERSON (which is what Usenet is all about), is if you need to use a port, then you probably should reserve it first. Then set it.

If you reserve it first, then winnat will choose a different set of ports.
But if you do not reserve it, and if you ever set Hyper-V, then winnat will eventually clobber the port you wanted to use.

Lesson learned.
Who knew?
Not me.

The moral of the story is if you turn on Hyper-V and if you need to use
select ports, then you will want to reserve those ports ahead of time.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, comp.mobile.android

On Tue, 20 May 2025 20:01:12 -0000 (UTC), Marion wrote :

The moral of the story is if you turn on Hyper-V and if you need to use select ports, then you will want to reserve those ports ahead of time.

So that this final summary contains useful commands for everyone to learn
from, below are the commands you'll likely want to save for future use.

1. This will display ports currently excluded by Winnat.
C:\> netsh int ip show excludedportrange protocol=tcp

2. This will explicitly reserve a range of ports for your personal use:
C:\> netsh int ipv4 add excludedportrange protocol=tcp startport=50000 numberofports=10

3. These commands will enable/disable Hyper-V on Windows.
C:\> dism.exe /Online /Enable-Feature:Microsoft-Hyper-V /All
C:\> dism.exe /Online /Disable-Feature:Microsoft-Hyper-V

4. These commands will stop/start the Windows NAT Driver service.
C:\> net stop winnat
C:\> net start winnat

5. This command shows the current set of dynamic outbound ports.
C:\> netsh int ipv4 show dynamicport tcp

Note TCP & UDP are similarly affected as are IPv4 & IPv6.
But these commands above are only shown for IPv4 TCP ports.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, comp.mobile.android

On Wed, 21 May 2025 04:13:50 -0000 (UTC), Marion wrote :

1. This will display ports currently excluded by Winnat.
C:\> netsh int ip show excludedportrange protocol=tcp

What I had been using before all those commands was this command to figure
out what was using the ports - but nothing was ever using the ports!

netstat -aon | findstr :55555

From that resulting PID you can find the name of the offending program.

tasklist | findstr 1234

That's what everyone does when they have a port conflict.
But that didn't work here because nothing was using those ports.

Hyper-V told WinNAT to reserve the ports.
But Hyper-V never used them.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11, comp.mobile.android

Marion wrote:

What I had been using before all those commands was this command to figure out what was using the ports - but nothing was ever using the ports!
C:\> netstat -aon | findstr :55555

From that resulting PID you can find the name of the offending program.
C:\> tasklist | findstr 1234

netstat can sometimes linewrap (e.g. with the -b flag, perhaps also when
with long FQDNs) so findstr can 'miss' what owned the port.

there's a better method than piping to findstr for tasklist
tasklist /fi "pid eq 1234"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)