• After years of reboots - I finally today solved a 99-port lockup after

    From Marion@21:1/5 to All on Sat May 3 05:56:35 2025
    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)
  • From Paul@21:1/5 to Marion on Sat May 3 13:38:26 2025
    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)
  • From Uncle Bob@21:1/5 to Marion on Sat May 3 18:58:32 2025
    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)
  • From Marion@21:1/5 to Paul on Sat May 3 22:24:00 2025
    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)
  • From Marion@21:1/5 to Marion on Sun May 4 22:59:53 2025
    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)
  • From Marion@21:1/5 to Marion on Sun May 4 23:54:58 2025
    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)
  • From Marion@21:1/5 to Marion on Mon May 5 00:58:39 2025
    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)
  • From Marion@21:1/5 to Marion on Tue May 6 15:50:11 2025
    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)
  • From Marion@21:1/5 to Marion on Tue May 6 15:58:03 2025
    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)
  • From Marion@21:1/5 to Mr. Man-wai Chang on Tue May 6 15:45:39 2025
    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)
  • From Victor@21:1/5 to Marion on Tue May 6 11:32:27 2025
    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)
  • From Marion@21:1/5 to Marion on Tue May 6 17:25:02 2025
    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)
  • From Marion@21:1/5 to Marion on Fri May 9 20:56:43 2025
    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)
  • From Marion@21:1/5 to Andy Burns on Fri May 9 20:36:10 2025
    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)
  • From Marion@21:1/5 to Mr. Man-wai Chang on Tue May 20 19:51:14 2025
    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)