XPost: alt.comp.microsoft.windows

UPDATE!

For years, a day or two after a Microsoft Update (I think - but I'm not
sure), about once a month (or so) stunnel and/or adb would fail because
they couldn't bind to the ports that they normally bind to every day.
Privileged ports: Ports 0–1023
Registered Ports: Ports 1024–49151
Dynamic/Private Ports: Ports 49152–65535 (99 of these ports are excluded!)

They'd both fail because a port they normally use, wasn't available.
Binding service [x] to 127.0.0.1:53537: Permission denied (WSAEACCES) (10013)

For years, I tried to find out WHAT was "using" those ports.
It turns out nothing was using them, per se, so netstat returned nothing!

netstat -ano | findstr :53537

So did procmon. So did resmon. So did task manager. As did everything else.

I could bind to any port that was not in a range of 99 ports unavailable.

ncat -l -p 56789

But I could NOT bind to a port that was in the range that was unavailable.

ncat -l -p 56789

Ncat: bind to :::56789: An attempt was made to access a socket
in a way forbidden by its access permissions. . QUITTING.

In desperation, I went to AI and after HOURS with AI, I finally got closer
to the problem, where this command lists 99 ports which are unavailable.

netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp

I still have no idea what is making the 99 ports unavailable after a reboot (often after a Windows Update) but AI thinks it's an underlying Windows
process that has administrator capabilities. We don't know what that is.

But now I at least have a solution without resorting to another reboot!

Instead of rebooting (which was my only solution for years!) all that was needed was to run these stop/start commands to free the 99 excluded ports!

net stop winnat

  The Windows NAT Driver service was stopped successfully.

net start winnat

  The Windows NAT Driver service was started successfully.

netsh interface ipv4 show excludedportrange protocol=tcp

 Protocol tcp Port Exclusion Ranges
  Start Port    End Port
  ----------    --------
      5357        5357
     50000       50059     *
  * - Administered port exclusions.

Voila! (almost)

The only thing left is WHY those 99 ports are sometimes made unavailable.
When you run (as admin) those commands, do you ever get 99 ports locked up?

Anyone have any experience with this problem set for debugging information?
If not, at least others can benefit from the troubleshooting hours today.

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

XPost: alt.comp.microsoft.windows

On Sat, 5/3/2025 1:56 AM, Marion wrote:

UPDATE!

For years, a day or two after a Microsoft Update (I think - but I'm not sure), about once a month (or so) stunnel and/or adb would fail because
they couldn't bind to the ports that they normally bind to every day.
Privileged ports: Ports 0–1023
Registered Ports: Ports 1024–49151
Dynamic/Private Ports: Ports 49152–65535 (99 of these ports are excluded!)

They'd both fail because a port they normally use, wasn't available.
Binding service [x] to 127.0.0.1:53537: Permission denied (WSAEACCES) (10013)

For years, I tried to find out WHAT was "using" those ports.
It turns out nothing was using them, per se, so netstat returned nothing!

netstat -ano | findstr :53537

So did procmon. So did resmon. So did task manager. As did everything else.

I could bind to any port that was not in a range of 99 ports unavailable.

ncat -l -p 56789

But I could NOT bind to a port that was in the range that was unavailable.

ncat -l -p 56789

Ncat: bind to :::56789: An attempt was made to access a socket
in a way forbidden by its access permissions. . QUITTING.

In desperation, I went to AI and after HOURS with AI, I finally got closer
to the problem, where this command lists 99 ports which are unavailable.

netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp

I still have no idea what is making the 99 ports unavailable after a reboot (often after a Windows Update) but AI thinks it's an underlying Windows process that has administrator capabilities. We don't know what that is.

But now I at least have a solution without resorting to another reboot!

Instead of rebooting (which was my only solution for years!) all that was needed was to run these stop/start commands to free the 99 excluded ports!

net stop winnat

  The Windows NAT Driver service was stopped successfully.

net start winnat

  The Windows NAT Driver service was started successfully.

netsh interface ipv4 show excludedportrange protocol=tcp

 Protocol tcp Port Exclusion Ranges
  Start Port    End Port
  ----------    --------
      5357        5357
     50000       50059     *
  * - Administered port exclusions.

Voila! (almost)

The only thing left is WHY those 99 ports are sometimes made unavailable. When you run (as admin) those commands, do you ever get 99 ports locked up?

Anyone have any experience with this problem set for debugging information? If not, at least others can benefit from the troubleshooting hours today.

Use Wireshark.

Fire up a browser, watch what ports are used. Ports in the ephemeral range,
are sending to 443 (encrypted) on mine. Like 61038 ==> 443, which is https. These are ports assigned dynamically from the pool above 49152. A program
doing that, could get EADDRINUSE if it uses a dynamic port currently in
usage by a second browser.

I don't think you are supposed to statically assign such ports to programs needing their own fixed port for some purpose. For example, if I put an XWindows
server on my PC (needed for Bash Shell and WSL1), it uses port 6000 as a
static port. And that is defined in the ports list. That's an officially recognized usage, in the static port range.

https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

6000–6063 Yes X11—used between an X client and server over the network

You can communicate with 64 different Unix computers and put their Windows
on your screen, but people do not typically do that. The DISPLAY variable
:0 or :1 , corresponds to the usage of port 6000 or port 6001.

Those are statically defined ports, and between 1025 and 49151 or so.

At work, we had our own little registrar. She made sure, via phoning her up, that if you invented a new usage for a static port, she would check the list
of experimental usages and make sure there wasn't a conflict. So if some
twirp had used port 12345 for an Ethernet test program, and you decided
to do the same thing, she could tell you it was already in use. And for such
a large company, there was really hardly any usage of static ports in that exact way. There's a reason for that. But she would have penciled in things like popular game engine assignments, because you would not want your
serious business case static port assignment, to suddenly start playing Quake :-)

I'm sure you have your reasons for doing this, but that's not exactly
the intended usage model for those port numbers. Just about any question
I've asked about networking, the answerer starts with "You're not supposed
to do that", and that's the essence of "learn while you earn" as a learning algorithm :-)

To give you some idea how pissy they were about network operations at work,
one day we started a three node flight simulator on a LAN segment, and
the "Nazi" in control, phoned one of the employee phone numbers within 20 seconds
of the game showing up on the LAN. And this was after closing time, too.
You could use the flight sim on one node (no network traffic), and
I routinely used to fly my custom aircraft. A Borg Cube with a
one million pounds of thrust engine. You have to set the trim at +5 degrees
to keep the flight stable. Because, well, it's a brick, not an aircraft.

Paul

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

XPost: alt.comp.microsoft.windows

On Sat, 3 May 2025 22:24:00 -0000 (UTC), Marion wrote:

I need adb for reasons that are so obvious I won't even explain why.
As for stunnel, my newsreader is telnet so I need stunnel for encryption.

You can port your scripts from telnet to openssl which will add the
encryption that stunnel is currently adding for you today.

This is a prolly a good stunnel conf for telnet on the command line.
telnet localhost 12345
[Eternal September]
client = yes
accept = 127.0.0.1:12345
connect = news.eternal-september.org:563
verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.eternal-september.org
OCSPaia = yes

This should accomplish the same thing, but without needing telnet,
which means you won't need stunnel to do the modern encryption.

openssl s_client -connect news.eternal-september.org:563
post
340 Ok
authinfo user username pass password
Message-ID: <whatever>
From: you@isp.com
In-Reply-To: <reply-message-id>
Newsgroups: alt.comp.os.windows-10,alt.comp.os.windows-10,alt.comp.microsoft.windows
Subject: Re: After years of reboots...
Date: Sat, 04 May 2025 10:11:12 GMT
References: <reference-message-ids>

Type your message here using your favorite text editor.
.
quit

I've never tried it but I think it could replace telnet for posting.

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

XPost: alt.comp.microsoft.windows

On Sat, 3 May 2025 13:38:26 -0400, Paul wrote :

Use Wireshark.
Fire up a browser, watch what ports are used. Ports in the ephemeral range, are sending to 443 (encrypted) on mine. Like 61038 ==> 443, which is https. These are ports assigned dynamically from the pool above 49152. A program doing that, could get EADDRINUSE if it uses a dynamic port currently in
usage by a second browser.

I don't disagree with any of your advice above, but I've been there.

The problem here is three fold which makes it a bit unusual in my case.
1. Adb uses port 55555. I have no control over that (AFAIK).
2. Stunnel *needs* ports. I control which ports. I use 49152¡V65535.
3. But once a month (or so) "something" excludes the ports used.

This "something" is apparently a deep system-level application.
But what?

I can run net stumblers galore, yet I haven't found what it is.
Powershell:
$port = 54321
try {
$listener = New-Object System.Net.Sockets.TcpListener ([System.Net.IPAddress]::Loopback, $port)
$listener.Start()
Write-Host "Successfully bound to 127.0.0.1:$port"
$listener.Stop()
} catch {
Write-Warning "Failed to bind to 127.0.0.1:$port: $($_.Exception.Message)"
Write-Host "Attempting to identify the process..."
Get-NetTCPConnection -LocalPort $port | Get-Process -ErrorAction SilentlyContinue
Get-NetUDPEndpoint -LocalPort $port | Get-Process -ErrorAction SilentlyContinue
}

That script will actively try to bind to the port and, if it fails, will immediately try to identify the listening process. It never finds anything.

I don't think you are supposed to statically assign such ports to programs needing their own fixed port for some purpose. For example, if I put an XWindows
server on my PC (needed for Bash Shell and WSL1), it uses port 6000 as a static port. And that is defined in the ports list. That's an officially recognized usage, in the static port range.

https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

6000¡V6063 Yes X11¡Xused between an X client and server over the network

You can communicate with 64 different Unix computers and put their Windows
on your screen, but people do not typically do that. The DISPLAY variable
:0 or :1 , corresponds to the usage of port 6000 or port 6001.

Those are statically defined ports, and between 1025 and 49151 or so.

Again, I don't disagree much with what you said. An example is adb.
ADB needs a port and it always uses 5555 & 55555 (as far as I can tell).
That's what ADB does. I don't control that. But I use adb all day every day.
If "something" deep in the system steals that port at boot, abd will fail.

The error is simply that adb can't bind to that port.
But NOTHING is using that port - which is what took me 2 years to realize. (Mostly because a reboot always instantly resolved the problem.)

As with adb, stunnel *needs* a port. But unlike adb, YOU have to pick it.
The only choice you have is which port. You don't care what port.
So you pick a port, and it works fine. For a while.
Suddenly, at the morning reboot, stunnel fails to bind to that port.
So you change it. Which works fine, but then one day, it happens again.
And again. And again. "Something" is excluding those ports seemingly randomly. Something very deep inside the system since an admin can't release them.

At work, we had our own little registrar. She made sure, via phoning her up, that if you invented a new usage for a static port, she would check the list of experimental usages and make sure there wasn't a conflict. So if some twirp had used port 12345 for an Ethernet test program, and you decided
to do the same thing, she could tell you it was already in use. And for such a large company, there was really hardly any usage of static ports in that exact way. There's a reason for that. But she would have penciled in things like popular game engine assignments, because you would not want your
serious business case static port assignment, to suddenly start playing Quake :-)

I'm sure you have your reasons for doing this, but that's not exactly
the intended usage model for those port numbers. Just about any question
I've asked about networking, the answerer starts with "You're not supposed
to do that", and that's the essence of "learn while you earn" as a learning algorithm :-)

Again, it's adb & stunnel, both of which are required.
I need adb for reasons that are so obvious I won't even explain why.
As for stunnel, my newsreader is telnet so I need stunnel for encryption.

Those are my reasons, and I don't think anyone can say that they're wrong.
The problem isn't stunnel or adb anyway.

The problem is "something" deep inside Windows is excluding ports en masse.
But what?

To give you some idea how pissy they were about network operations at work, one day we started a three node flight simulator on a LAN segment, and
the "Nazi" in control, phoned one of the employee phone numbers within 20 seconds
of the game showing up on the LAN. And this was after closing time, too.
You could use the flight sim on one node (no network traffic), and
I routinely used to fly my custom aircraft. A Borg Cube with a
one million pounds of thrust engine. You have to set the trim at +5 degrees to keep the flight stable. Because, well, it's a brick, not an aircraft.

I love your sardonic humor because there's immense knowledge embedded.

You've helped me in the past, in that you were my AI (or, um, actually, AI
has slowly been replacing Usenet for me in what it does for debugging), so
I appreciate your helpful replies as I need to choose ports from this list.
Privileged ports: Ports 0-1023
Registered Ports: Ports 1024-49151
Dynamic/Private Ports: Ports 49152-65535 (e.g., used by Stunnel & adb)'
ADB typically uses tcp:55555 but you can set stunnel to use many ports.

I'm not sure Wireshark will show anything that isn't already being shown
simply because, as far as I can tell, NOTHING is using the excluded ports.

In the same vein I think would go netmon, TCPView, perfmon, wf.msc, etc., simply because the excluded ports aren't actually being used (AFAICT)

I checked for maybe two years, which doesn't mean I covered all bases, but
as far as I can tell, the ports are simply excluded from use & that's it.
Win+R > cmd {control+shift+enter} for an Administrator prompt

netstat -ano | findstr :54321

@echo off
:loop
echo %date% %time% >> port_usage.log
netstat -ano >> port_usage.log
timeout /t 5 /nobreak > nul
goto :loop

netsh interface ipv4 show tcpconnections
netsh http show urlacl

Win+R > services.msc {control+shift+enter}

Get-NetTCPConnection -LocalPort 54321 -Force

Get-NetUDPEndpoint -LocalPort 54321 -Force

Get-NetTCPListen -LocalPort 54321 | Get-Process -Id {$_.OwningProcess} try {$listener = New-Object System.Net.Sockets.TcpListener ([System.Net.IPAddress]::Loopback, 32565); $listener.Start(); Write-Host "Successfully bound to 127.0.0.1:32565"; $listener.Stop()} catch {Write-Error "Failed to bind to 127.0.0.1:32565: $($

_.Exception.Message)"}

resmon > Network > Listening Ports > Port = 54321 > PID
procexp.exe > Find > Find Handle or DLL > 54321 > Search
procmon.exe > Filter (timing is crucial)

[Local Port] is 54321 then Include
(kill & restart stunnel with the script below & watch with procmon)
[Process Name] [is] [stunnel.exe] then [Include]
[Operation] is [TCP Accept] then [Include]
[Operation] is [TCP Connect] then [Include]
[Operation] is [TCP Disconnect] then [Include]
[Operation] is [TCP Other] then [Include]
[Operation] is [TCP Receive] then [Include]
[Operation] is [TCP Reconnect] then [Include]
[Operation] is [TCP Retransmit] then [Include]
[Operation] is [TCP Send] then [Include]
[Operation] is [TCP TCPcopy] then [Include]
[Operation] is [TCP Unknown] then [Include]
[PID] is [4321] then "Include
[Apply][OK]
@echo off
REM restartstunnel.bat
REM Replaces the following manual commands:
REM tasklist | findstr "stunnel.exe"
REM stunnel.exe 4321 Console 1 21,308 K
REM taskkill /F /PID 9640
echo Terminating stunnel...
taskkill /F /IM stunnel.exe > nul 2>&1
timeout /t 2 /nobreak > nul
echo Starting stunnel...
start "" "stunnel.exe"
echo Done.
(Note some of the commands above have udp/ipv6 variants I've omitted.)

When a port is excluded after the morning boot, nothing can bind to it.

ncat -l -p 54321 (or... ncat -l -k -p 54321 -e exit)

Ncat: bind to :::54321: An attempt was made to access a socket
in a way forbidden by its access permissions. . QUITTING.

It's hard to even get the port unexcluded if you know it's excluded.

netsh interface ipv4 delete excludedportrange protocol=tcp startport=54300 numberofports=100

Access is denied.

When the exclusion includes Stunnel's ports, I get this error:
Binding service [x] to 127.0.0.1:54321:
Permission denied (WSAEACCES) (10013)
When it excludes adb's ports, I get this error after the morning boot:
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

Something is excluding entire blocks of random ports, but what?

Of course, there must be a reason, but even now, some are excluded
as shown by this back-to-back contiguous sequence I just ran for you.

netsh interface ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges
Start Port End Port
---------- --------
5357 5357
20164 20263
50000 50059 *
59914 60013
60014 60113
60214 60313
60314 60413
60414 60513
60514 60613
60614 60713
60714 60813
60814 60913
60914 61013
61014 61113
61114 61213
* - Administered port exclusions.

net stop winnat

The Windows NAT Driver service was stopped successfully.

netsh interface ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges
Start Port End Port
---------- --------
5357 5357
50000 50059 *
* - Administered port exclusions.

net start winnat

The Windows NAT Driver service was started successfully.

netsh interface ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges
Start Port End Port
---------- --------
5357 5357
50000 50059 *
* - Administered port exclusions.

I only found out about those commands yesterday, so I'm actually surprised
that the result change constantly. I have no idea why they're changing.

The reason it matters is that some apps (like adb) have a port which
sometimes is excluded and other apps (like stunnel) require a port.

It's hard to pick an unused port when they're randomly excluded at boot.
I've debugged this many times and failed every time, mainly because
after a few hours of wasted debugging, I decide to punt and reboot.

Anyway, after about two years of these shenanigans, I finally figured
out the "problem" is "something" deep inside of Windows is excluding
a hundred random ports at a time. I "think" it's related to Windows
update, but I'm not sure really. It always happens at a boot though.

I post this mostly to accomplish a few things I always strive for.
1. Let people know what my solution is so they can try it too.
2. Provide the commands, verbatim, as they're extremely useful.
3. Try to push the ball forward to figure out WHAT is excluding ports.

I suspect most of you have the same problem; you just don't notice it.
You can tell, actually, simply by running this command.
If it reports more than two lines, you likely have the same problem.

netsh interface ipv4 show excludedportrange protocol=tcp

How many lines show up for others?

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

XPost: alt.comp.microsoft.windows

On Sat, 3 May 2025 05:56:35 -0000 (UTC), Marion wrote :

The only thing left is WHY those 99 ports are sometimes made unavailable. When you run (as admin) those commands, do you ever get 99 ports locked up?

Since I've been fighting this dynamic port range exclusion for years, I'm
going to continue to try to debug WHY many random ports are excluded.

This experiment run just moments ago seems to indicate that perhaps it's
the Winnat service who is dynamically excluding those extra port ranges.

I'm first going to verify the basics of the port range:
Privileged ports: Ports 0 to 1023
Registered/(TCP) Dynamic Ports: Ports 1024 to 49151
Private/(TCP & UDP) Dynamic Ports: Ports 49152 to 65535

Run this to confirm what the UDP ephemeral outgoing dynamic ports are:

netsh int ipv4 show dynamicport udp

Protocol udp Dynamic Port Range
---------------------------------
Start Port : 49152
Number of Ports : 16384

Run this to confirm what the TCP ephemeral outgoing dynamic ports are:

netsh int ipv4 show dynamicport tcp

Protocol tcp Dynamic Port Range
---------------------------------
Start Port : 1024
Number of Ports : 64511

netsh interface ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges
Start Port End Port
---------- --------
5357 5357
50000 50059 *
* - Administered port exclusions.

This is what the (random?) TCP port exclusion is at the moment.

netsh interface ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges
Start Port End Port
---------- --------
5357 5357
33476 33575
33576 33675
33676 33775
33776 33875
33876 33975
33976 34075
34076 34175
34176 34275
34276 34375
34376 34475
34476 34575
34576 34675
34694 34793
50000 50059 *
* - Administered port exclusions.

Note the regularity of the excluded port counts:
Total excluded ports: 1 + (14 * 100) + 60 = 1461


So that's 1400 random ports which are excluded!

This test below strongly suggests the Windows NAT Driver (Winnat) service
is perhaps responsible for the randomly appearing excluded port ranges.

net stop winnat

The Windows NAT Driver service was stopped successfully.

netsh interface ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges
Start Port End Port
---------- --------
5357 5357
50000 50059 *
* - Administered port exclusions.

Total excluded ports: 1 + 60 = 61

net start winnat
netsh interface ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges
Start Port End Port
---------- --------
5357 5357
50000 50059 *
* - Administered port exclusions.

My assessment, based on the facts, is that the Windows NAT Driver is
excluding about 1400 (random) ports at boot but which are different each
boot, where sometimes they conflict with my static adb & stunnel ports.

The next step is to understand why the Windows NAT Driver is randomly
excluding roughly about 1400 ports upon a reboot, where some of them can conflict with static outgoing ports that stunnel & adb use every day.

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

XPost: alt.comp.microsoft.windows

On Sun, 4 May 2025 22:59:53 -0000 (UTC), Marion wrote :

The next step is to understand why the Windows NAT Driver is randomly excluding roughly about 1400 ports upon a reboot, where some of them can conflict with static outgoing ports that stunnel & adb use every day.

Drat.

After much research, it appears you can't directly control the ports that Winnat will reserve upon booting as Docker Desktop for Windows relies
heavily on Hyper-V for containerization where Winnat is the network address translation component used by Hyper-V for internal networks.

Therefore, it seems that the most reliable method to prevent Winnat from reserving the static ports used by stunnel & by adb is to add your own Administered Port Exclusions which take precedence and prevent Winnat (and other dynamic port allocation mechanisms) from using those ports.

Checking which port adb is using is easy to do with "adb devices".

adb devices

* daemon not running; starting now at tcp:55555
* daemon started successfully
List of devices attached
SMGA325GSMU device

Stunnel uses whatever ports you have configured stunnel.conf to use.
[Mixmin]
client = yes
accept = localhost:55563
connect = news.mixmin.net:563
CAfile = ca-certs.pem
verifyChain = yes
checkHost = news.mixmin.net
OCSPaia = yes

This will exclude just the two ports above (and it will persist across reboots):

netsh int ipv4 add excludedportrange protocol=tcp startport=55555 numberofports=1

netsh int ipv4 add excludedportrange protocol=tcp startport=55563 numberofports=1

But you never know if any app uses adjacent ports so you want a wider range.

This will add a range of 101 TCP ports, starting from port 55500
& ending at port 55600 (inclusive) to the list of administered
outgoing excluded IPv4 ports (which should persists after reboot).

netsh int ipv4 add excludedportrange protocol=tcp startport=55500 numberofports=101

The process cannot access the file because it is being used by another process.

Oops. Something is using (some of) those ports, but what?

netstat -ano | findstr "555"

TCP 127.0.0.1:55555 0.0.0.0:0 LISTENING 11216
TCP 127.0.0.1:55563 0.0.0.0:0 LISTENING 9380
TCP [::1]:55563 [::]:0 LISTENING 9380

adb kill-server
netstat -ano | findstr "555"

TCP 127.0.0.1:55563 0.0.0.0:0 LISTENING 9380
TCP [::1]:55563 [::]:0 LISTENING 9380

tasklist /FI "PID eq 9380"

Image Name PID Session Name Session# Mem Usage
========================= ======== ================ =========== ============
stunnel.exe 9380 Console 1 29,836 K

taskkill /F /IM stunnel.exe

netstat -ano | findstr "555"
netsh int ipv4 add excludedportrange protocol=tcp startport=55500 numberofports=101

Ok.

netsh interface ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges
Start Port End Port
---------- --------
5357 5357
50000 50059 *
55500 55600 *
* - Administered port exclusions.

To check if I need to run that same command for UDP:

netstat -ano | findstr /I "UDP"

(shows no conflicts with the excluded port range of 55500-55600)

To check if I need to do the same command for IPv6:

ipconfig /all

(shows some link-local IPv6 addresses in network interfaces)

This is getting long, but I document it carefully so that others
can make use of the debugging technique as these work on your system.

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

XPost: alt.comp.microsoft.windows

On Sun, 4 May 2025 23:54:58 -0000 (UTC), Marion wrote :

This is getting long, but I document it carefully so that others
can make use of the debugging technique as these work on your system.

Update... doublechecking my assessments of fact are turning out correct.

This was run before rebooting to reserve a block of 101 ports.

netsh int ipv4 add excludedportrange protocol=tcp startport=55500 numberofports=101

I just rebooted and confirmed that 1400 ports (i.e., 14 random sets of 100 ports) are being excluded by "something" (likely Winnat) after every boot.

netsh interface ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges
Start Port End Port
---------- --------
2438 2537 (100 ports)
5357 5357 (1 port)
22110 22209 (100 ports)
48744 48843 (100 ports)
48844 48943 (100 ports)
49044 49143 (100 ports)
49144 49243 (100 ports)
49344 49443 (100 ports)
49444 49543 (100 ports)
49544 49643 (100 ports)
49668 49767 (100 ports)
49768 49867 (100 ports)
49868 49967 (100 ports)
50000 50059 * (60 ports)
50060 50159 (100 ports)
55500 55600 * (101 ports)
* - Administered port exclusions.

net stop winnat

The Windows NAT Driver service was stopped successfully.

netsh interface ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges
Start Port End Port
---------- --------
5357 5357 (1 port)
50000 50059 * (60 ports)
55500 55600 * (101 ports)
* - Administered port exclusions.

I wonder... Do we event need the Winnat functionality?
To find out what happens if I don't restart it, I won't.
How else can I find out what uses Winnat on Windows 10?

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

XPost: alt.comp.microsoft.windows

On Tue, 6 May 2025 15:45:39 -0000 (UTC), Marion wrote :

When people run this command, do they get two lines or more of output?

netsh int ipv4 add excludedportrange protocol=tcp startport=55500 numberofports=101

Oops. Wrong command. That command reserves the ports.
The command to simply see what ports are reserved is this.

netsh interface ipv4 show excludedportrange protocol=tcp

What do other people get when they run that command to list excluded ports?

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

XPost: alt.comp.microsoft.windows

On Mon, 5 May 2025 00:58:39 -0000 (UTC), Marion wrote :

net stop winnat

The Windows NAT Driver service was stopped successfully.
I wonder... Do we event need the Winnat functionality?
To find out what happens if I don't restart it, I won't.

Update...

I went all day yesterday without winnat running.
Nothing bad happened (that I know of).

I killed it today also.
Win+R > cmd {control+shift+return}

net stop winnat

The Windows NAT Driver service was stopped successfully.

I suspect we don't need winnat unless we're doing special stuff like port forwarding or docker or virtual machines or whatever "internet connection sharing" does for us - but I'm not sure yet - so that's just a wild guess.

If nothing bad happens after a while, I'll just put some kind of script in place to kill winnat every day but first I need to test if bad things
happen with winnat dead.

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

XPost: alt.comp.microsoft.windows

On Tue, 6 May 2025 22:06:40 +0800, Mr. Man-wai Chang wrote :

I wonder... Do we event need the Winnat functionality?
To find out what happens if I don't restart it, I won't.
How else can I find out what uses Winnat on Windows 10?

You sure that it had nothing to do with the firewall and/or the free anti-virus scanner??

NAT should be automatic and working by default, I dunno....

Thanks for trying to help as this issue had frustrated me for years.

I'm not sure of anything, but like most people here, I stopped using
antivirus scanners (e.g., Avast) years ago when Windows Defender got
better. Now I just use the Windows default.

While I know Winnat is who is reserving the ports, I'm assuming a Hyper-V related app (like Docker) is commanding Winnat to reserve ports on bootup.

But I don't have Docker.
And I can't even spell Hyper-V.

But "something" is telling Winnat to reserve 1400 ports randomly on boot.

The main reason I never tracked it down was that nothing was using the
ports so I couldn't figure out what the problem was aiming in that manner.

The other reason I never tracked it down before was that a reboot fixed it.
But now I realize a reboot simply moved the 1400 reserved ports to a
different random set. That randomness also explains why sometimes I had to reboot twice.

One reason for posting this information, other than you help anyone with
the same problem, is to see if anyone else has random ports excluded.

When people run this command, do they get two lines or more of output?

netsh int ipv4 add excludedportrange protocol=tcp startport=55500 numberofports=101

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

XPost: alt.comp.microsoft.windows

On Sat, 3 May 2025 22:24:00 -0000 (UTC), Marion wrote:

Anyway, after about two years of these shenanigans, I finally figured
out the "problem" is "something" deep inside of Windows is excluding
a hundred random ports at a time. I "think" it's related to Windows
update, but I'm not sure really. It always happens at a boot though.

You can't query WinNAT because it operates at a low level within the kernel.

To reveal the processes making network-related requests around the time
of port reservation, you might look into using logman to configure Event Tracing for Windows to capture requests to WinNAT for port reservations.

logman create trace -n WinNATPortTrace -p {YOUR_PROVIDER_GUID} -o c:\temp\WinNATTrace.etl -ets
logman update trace -n WinNATPortTrace -p {ANOTHER_RELEVANT_GUID} -ets
logman start -n WinNATPortTrace

After a reboot and observing the port reservations, stop the trace:
logman stop -n WinNATPortTrace


Then analyze the .etl file using tools like Windows Performance Analyzer
which is part of the Windows Assessment and Deployment Kit.

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

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows

On Tue, 6 May 2025 15:45:39 -0000 (UTC), Marion wrote :

While I know Winnat is who is reserving the ports, I'm assuming a Hyper-V related app (like Docker) is commanding Winnat to reserve ports on bootup.

But I don't have Docker.
And I can't even spell Hyper-V.

Woo hoo! I think I finally found the culprit all these years who
was telling winnat to reserve random 1300 ports upon every reboot!

netsh interface ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges
Start Port End Port
---------- --------
5357 5357 (1 port excluded)
33476 33575 (100 ports randomly excluded)
33576 33675 (100 ports randomly excluded)
33676 33775 (100 ports randomly excluded)
33776 33875 (100 ports randomly excluded)
33876 33975 (100 ports randomly excluded)
33976 34075 (100 ports randomly excluded)
34076 34175 (100 ports randomly excluded)
34176 34275 (100 ports randomly excluded)
34276 34375 (100 ports randomly excluded)
34376 34475 (100 ports randomly excluded)
34476 34575 (100 ports randomly excluded)
34576 34675 (100 ports randomly excluded)
34694 34793 (100 ports randomly excluded)
50000 50059 * (60 ports excluded)
* - Administered port exclusions.

I looked up what Hyper-V is, and I don't think I need it.
So I got rid of it.

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

FeatureName : Microsoft-Hyper-V-All
DisplayName : Hyper-V
Description : Provides services and management tools for creating and running virtual
machines and their resources.
RestartRequired : Possible
State : Enabled
CustomProperties :

Disable Hyper-V

Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

Reboot:

shutdown /r /t 0

When the machine came up, I checked that Hyper-V is disabled.

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

FeatureName : Microsoft-Hyper-V-All
DisplayName : Hyper-V
Description : Provides services and management tools for creating and running virtual
machines and their resources.
RestartRequired : Possible
State : Disabled
CustomProperties :

Now, when I check, the 1300 random reservations are finally gone!

netsh interface ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges
Start Port End Port
---------- --------
5357 5357
50000 50059 *
55500 55600 * <== I had reserved these 101
* - Administered port exclusions.

If anyone else has Hyper-V enabled (whatever the heck that is),
can you check to see what ports you have reserved by Winnat?

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

XPost: alt.comp.microsoft.windows, alt.comp.os.windows-11

On Fri, 9 May 2025 20:36:10 -0000 (UTC), Marion wrote :

As I recall (it was years ago) I made some progress in assigning
adb ports both on Android and on Windows that were of my choosing.

Just to put it into the public record so that anyone in the future finds
this, while almost everyone thinks you can't change the port adb uses, you
can, and I did, because I was trying to get around adb Wi-Fi security.

adb devices

* daemon not running; starting now at tcp:55555
* daemon started successfully
List of devices attached
SMGA325GSMU device

But I had forgotten that I had set the adb port in order to try to get
around Android ADB Wi-Fi security implemented way back on Android 10+.

C:\> set | findstr /i adb
ANDROID_ADB_SERVER_PORT=55555

To test if that was why adb was using port 55555, here's what I did...

set ANDROID_ADB_SERVER_PORT=

Bingo!

Now adb on Windows is using the port that everyone else sees it using!

adb devices

* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
SMSGA325GV1 device

OK. So this happens to be the answer to the 3 questions...I think.
Q1: What port does *your* Windows adb use?
A1: TCP:5037

Q2: Where is that port set inside of the adb tool?
A2: That's the default. If you need to change it, you can use:
C:\> setenv ANDROID_ADB_SERVER_PORT 55555
Win+R > sysdm.cpl > Advanced > Environment Variables
System Variables > ANDROID_ADB_SERVER_PORT

Q3: On Windows, what did you do to *reserve* that port?
If it's below 1024, you don't have to do anything.
If it's above 1023, you should reserve the port using:
C:\> netsh int ipv4 add excludedportrange protocol=tcp startport=55555 numberofports=1

If you do not reserve any port above the privileged ports,
for TCP (it's a different set for UDP) then you'll be sorry
if you also turn on Hyper-V (which Docker & WSL might do).

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

XPost: alt.comp.microsoft.windows, alt.comp.os.windows-11

On Fri, 9 May 2025 10:21:08 -0000 (UTC), Marion wrote :

If it's above 1023, you should reserve the port using:
C:\> netsh int ipv4 add excludedportrange protocol=tcp startport=55555 numberofports=1

And presumably you could check the exitcode of the netsh command, and if >>> it fail increment the port number and retry, finally setting the
environment variable to the actual port number?

y'mean some4thing like this?

@echo off
setlocal

set "targetPort=55555"
set "maxRetries=10"
set "retryCount=0"

:reservePort
echo Trying to reserve port %targetPort%...
netsh int ipv4 add excludedportrange protocol=tcp startport=%targetPort% numberofports=1

if errorlevel 1 (
echo Failed to reserve port %targetPort%. Error code: %errorlevel%
set /a retryCount+=1
if %retryCount% lss %maxRetries% (
set /a targetPort+=1
echo Retrying with port %targetPort%...
goto :reservePort
) else (
echo Failed to reserve a port after %maxRetries% retries. Exiting. >> goto :end
)
) else (
echo Successfully reserved port %targetPort%.
echo Setting ANDROID_ADB_SERVER_PORT environment variable to %targetPort%
setx ANDROID_ADB_SERVER_PORT %targetPort% /M
echo Please note that system environment variables changes may require a reboot to fully take effect for all processes.
goto :end
)

:end
endlocal
pause

On Fri, 9 May 2025 11:49:58 +0100, Andy Burns wrote :

y'mean some4thing like this?

I tried co-pilot

"write a script to reserve an tcp port"

it did it in Python

"in cmd.exe"

it wrote a one-liner using netsh

"make it retry until it finds an available port"

it added a loop

"limit to ten retries"

it obeyed

"set resulting port in a variable"

the result, which I haven't tried ...

@echo off
set /a port=8080
set /a retries=0
set /a max_retries=10
set reserved_port=

:retry
if %retries% GEQ %max_retries% (
echo Failed to find an available port after %max_retries% retries.
pause
exit /b 1
)

netsh int ipv4 add excludedportrange tcp %port% 1 >nul 2>&1
if %errorlevel% == 0 (
set reserved_port=%port%
echo Successfully reserved TCP port %reserved_port%
) else (
echo Port %port% is in use. Trying next...
set /a port+=1
set /a retries+=1
goto retry
)

echo The reserved port is: %reserved_port%
pause

Hi Andy,

Thanks for your purposefully helpful advice & understanding of the problem. What I learned, I suspect almost nobody knows who isn't a networking
expert.

It's been finally resolved - after years of seemingly random frustration.
With your kind advice, the final puzzle pieces finally went into place.

I rarely fail, so I tried valiantly years ago to set the port that adb used
on both Android & Windows to get around Android Wi-Fi adb connect security.

And yet, after a noble attempt at getting around that Android security
measure, I forgot that I had set the port that adb uses (until yesterday!).

Before setting the adb port, stunnel would also randomly fail on me
(where I use stunnel to handle the encryption in my newsreader scripts).

Then, at some point in time, randomly, adb would also fail to work.
The reason it was difficult to track was that nothing was using the ports.

And yet, adb (and stunnel) would, at times, fail to bind to their ports.
Yet, a reboot almost always fixed it - where two reboots always fixed it.

Worse, all the normal debugging commands (such as those Frank suggested)
fail to find the culprit because the ports are randomly excluded; not used.

Since few others had the same problem, there was precious little on the Internet about it, which is why I resorted to asking for help on Usenet.

Apparently there is no official documentation, but as you're now likely
aware, huge swathes of ports can be randomly reserved by winnat at boot.
<https://github.com/microsoft/WSL/issues/5306>
<https://forums.docker.com/t/port-already-allocated/10888/6>
<https://stackoverflow.com/questions/61885607/wsl2-port-already-in-use>
<https://dev.to/trademark18/an-attempt-was-made-to-access-a-socket-4nh9>

<https://www.reddit.com/r/HyperV/comments/1bowbai/port_reservation_causes_issues/>

<https://stackoverflow.com/questions/54010365/how-to-see-what-is-reserving-ephemeral-port-ranges-on-windows>

<https://learn.microsoft.com/en-us/answers/questions/651127/hyper-v-and-docker-desktop-preventing-port-bindin>

<https://stackoverflow.com/questions/65272764/ports-are-not-available-listen-tcp-0-0-0-0-50070-bind-an-attempt-was-made-to>

Which you can prove yourself by stopping & restarting winnat, so not only
is it not a mystery, it's widely known to everyone but you, me (& Frank).
:)

netsh interface ipv4 show excludedportrange protocol=tcp
net stop winnat
netsh interface ipv4 show excludedportrange protocol=tcp
net start winnat
netsh interface ipv4 show excludedportrange protocol=tcp

If you've enabled Hyper-V, you'll see excluded ports being random!

Which you can prove yourself by disabling & enabling Hyper-V, so not only
is it not a mystery, it's widely known to everyone but you, me & Frank. :)
PS:\> Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor
PS:\> netsh interface ipv4 show excludedportrange protocol=tcp
PS:\> Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All
PS:\> netsh interface ipv4 show excludedportrange protocol=tcp
PS:\> Enable-WindowsOptionalFeature -Online -FeatureName
Microsoft-Hyper-V-All
PS:\> netsh interface ipv4 show excludedportrange protocol=tcp
You'll likely see a world of difference if you run those commands.

So we've established that Hyper-V affects the available ports.
[Note TCP, UDP, IPv4 & IPv6 are affected, but we're simplifying to TCP.]

If that port happens to be a port you've assigned to adb or stunnel, then netstat/netsh won't show anything & yet you still can't bind to that port.

netstat -ano | findstr :55555
netsh interface ipv4 show tcpconnections

(finds nothing is binding to the port)

ncat -l -p 55555 (or... ncat -l -k -p 55555 -e exit)

Ncat: bind to :::55555: An attempt was made to access a socket
in a way forbidden by its access permissions. . QUITTING.

netsh interface ipv4 show excludedportrange protocol=tcp

(shows the port is excluded)
í° C:\> netsh interface ipv4 delete excludedportrange protocol=tcp startport=55555 numberofports=1
Access is denied.

For Stunnel, you *must* assign a port. You have no choice.
[Mixmin]
client = yes
accept = localhost:55563
connect = news.mixmin.net:563
CAfile = ca-certs.pem
verifyChain = yes
checkHost = news.mixmin.net
OCSPaia = yes

But for adb, you do not need to assign a port; and yet, I did but
I had forgotten that I did that years ago when adb first came out
as working over Wi-Fi (Android 10? Android 11? I don't remember).

When Android came out with adb over Wi-Fi, they added security.
I rarely fail so I tried to get around that Android security.

As I recall (it was years ago) I made some progress in assigning
adb ports both on Android and on Windows that were of my choosing.

However, I was still unable to get around Android security which
requires you to look at the Android phone to use adb over Wi-Fi.

At that time, I gave up but it was an extremely rare failure
since I almost never fail - but what I didn't do was reset the
adb ports back to what they originally were before my quest.

The reason was that everything worked just fine.

It's only at some random boot weeks later, maybe months later,
that adb failed to bind to the port, where, since stunnel had
failed to bind to its ports, I didn't associate with the fact
that I had changed the port that ADB uses on Android & Windows.

And, since a reboot fixed it, I *thought* it was due to some
Microsoft update (since my machine always reboots after updates).

As you know from the reference threads on the Windows ngs, it wasn't
Microsoft after all. Nor was it adb. Nor was it stunnel.

It was Hyper-V.
Sigh.
*After years of reboots - I finally solved random port exclusions*

<https://www.novabbs.com/computers/article-flat.php?id=87044&group=alt.comp.os.windows-10#87044>

*Warning: If you use adb or stunnel & if you enable Hyper-V*

<https://www.novabbs.com/computers/article-flat.php?id=87110&group=alt.comp.os.windows-10#87110>

To prevent this from happening to others, my (now astute) recommendation is that any time you feel you need to assign a port, you should also reserve
that port at the time you assign it (for example, as with your script).

In summary, the problem has been solved where what I learned was
that Hyper-V will exclude random blocks of ports, but I realize
most people won't be affected if they don't have a need to assign ports.

I had a need to assign ports for two reasons most people won't have:
1. I was trying to get around Android adb Wi-Fi security, and,
2. My newsreader was written years ago from scratch with telnet.

To bring things to full circle, I think you and I, long ago, had
discussed the new adb over Wi-Fi security restrictions, which means
what started the adb port permission problem has come full circle
with this thread, years later, which shows possible repercussions
when you try to subvert Android adb Wi-Fi security by changing ports.
*Do you use ADB (or ScreenCopy) with Android & Windows?*

<https://www.novabbs.com/computers/article-flat.php?id=58842&group=comp.mobile.android#58842>

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

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows

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)