XPost: alt.comp.microsoft.windows, comp.mobile.android

Ever see this screencopy error?
<https://i.postimg.cc/Dz1rcpDX/scrcpy26.jpg>

This error pops up every once in a while. Then goes away.
When it's gone, screencopy works for days, weeks & months.
Then it happens again.
Dunno why.
Do you?

This time it has lasted for two days (multiple reboots).
Any debugging ideas?

adb connect 192.168.1.4:44285
adb devices

List of devices attached
192.168.1.4:44285 device

scrcpy.exe -s 192.168.1.4

scrcpy 1.24 <https://github.com/Genymobile/scrcpy>

scrcpy-server: 1 file pushed, 0 skipped. 28.9 MB/s (41159 bytes in 0.001s)

ERROR: bind: [10013] An attempt was made to access a socket in a way forbidden by its access permissions.

I also tried this, which also used to work - but now it just flashes.

powershell.exe -executionpolicy bypass -command "start-process -filepath 'scrcpy' -argumentlist '--always-on-top --tcpip-192.168.1.4:44285' -windowstyle 'hidden'"

or

powershell.exe -executionpolicy bypass -command "start-process -filepath 'scrcpy' -argumentlist '--always-on-top --tcpip-192.168.1.4:44285'"

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

XPost: alt.comp.microsoft.windows, comp.mobile.android

On 10/4/2023 7:50 PM, Wally J wrote:

Ever see this screencopy error?
<https://i.postimg.cc/Dz1rcpDX/scrcpy26.jpg>

This error pops up every once in a while. Then goes away.
When it's gone, screencopy works for days, weeks & months.
Then it happens again.
Dunno why.
Do you?

This time it has lasted for two days (multiple reboots).
Any debugging ideas?

adb connect 192.168.1.4:44285
adb devices

List of devices attached
192.168.1.4:44285 device

scrcpy.exe -s 192.168.1.4

scrcpy 1.24 <https://github.com/Genymobile/scrcpy>

scrcpy-server: 1 file pushed, 0 skipped. 28.9 MB/s (41159 bytes in 0.001s)

ERROR: bind: [10013] An attempt was made to access a socket in a way forbidden by its access permissions.

I also tried this, which also used to work - but now it just flashes.

powershell.exe -executionpolicy bypass -command "start-process -filepath 'scrcpy' -argumentlist '--always-on-top --tcpip-192.168.1.4:44285' -windowstyle 'hidden'"

or

powershell.exe -executionpolicy bypass -command "start-process -filepath 'scrcpy' -argumentlist '--always-on-top --tcpip-192.168.1.4:44285'"

Try the last comment here ???

https://github.com/Genymobile/scrcpy/issues/2468

netsh interface ipv4 show excludedportrange protocol=tcp

# There seems to be a control for the port numbers

scrcpy --tcpip -p 27206:27220

Paul

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

XPost: alt.comp.microsoft.windows, comp.mobile.android

Paul <nospam@needed.invalid> wrote

Try the last comment here ???

https://github.com/Genymobile/scrcpy/issues/2468

netsh interface ipv4 show excludedportrange protocol=tcp

# There seems to be a control for the port numbers

scrcpy --tcpip -p 27206:27220

Thanks for the advice Paul, because I lack debugging skills.
<https://i.postimg.cc/25XrGW9R/scrcpy27.jpg>

Win+R -> cmd -> control+shift+enter (for an admin window)

netsh interface ipv4 show excludedportrange protocol=tcp

Protocol tcp Port Exclusion Ranges
Start Port End Port
---------- --------
1526 1625
1709 1808
1829 1928
2281 2380
2381 2480
2545 2644
2645 2744
2987 3086
5357 5357
50000 50059 *
* - Administered port exclusions.

What the heck is an "administered port exclusion"?

Looking at your reference you kindly cited...
<https://github.com/Genymobile/scrcpy/issues/2468>
It says "I've been using scrcpy via USB for some time with no issues, but
at some point it's no longer working. I believe that's because I recently upgraded from Android 10 to 11, but I'm not sure."

This is kind of what happened, although I migrated to Android 13 a few
weeks ago (without any mishaps as I use scrcpy every day to make my
phone two feet tall and a foot wide on my PC monitor with mouse & keyboard
and clipboard sharing between Android and Windows - that's why).

Like that long-term scrcpy user, I have the normal Windows firewall
stuff - which worked fine with scrcpy up until now so I woudn't expect it
to be acting up all of a sudden (unless Windows Patch Tuesday did it).

The fundamental problem, it says is...
"You have a permission problem to listen on a port".

Hmmmmm..... the user then says "Nevermind. After applying latest windows updates and restarting both the phone and the laptop, the issue was fixed."

This has been my experience that it "fixes itself" somehow, over time.
Let me try the command that they suggested, which I guess is this:
"scrcpy --tcpip -p 27206:27220"

But it might not be that because there are two ways to connect Android
to Windows for adb - one way is the Wi-Fi (which I'm using); the other
is the USB cable (which I think they're using because they need tcpip).

I just found some other similar threads using the keywords from your
helpful reference so allow me to run a few tests in the interim. Thanks!

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

XPost: alt.comp.microsoft.windows, comp.mobile.android

On Wed, 4 Oct 2023 19:50:16 -0400, Wally J wrote:

ERROR: bind: [10013]
An attempt was made to access a socket in a way forbidden by its access permissions.

Did it happen after patch Tuesday perchance?

The reason is most likely due to a Windows Update that
restricted access to certain ports without telling anyone. https://ardalis.com/attempt-made-to-access-socket/

After Windows 10 updates, some ports are reserved by Windows
with the result that applications cannot bind to these ports. https://superuser.com/questions/1486417/unable-to-start-kestrel-getting-an-attempt-was-made-to-access-a-socket-in-a-way

This Microsoft-caused problem has been around for more than a dozen years. https://stackoverflow.com/questions/10461257/an-attempt-was-made-to-access-a-socket-in-a-way-forbidden-by-its-access-permissi

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

XPost: alt.comp.microsoft.windows, comp.mobile.android

On 10/4/23 21:04, Wally J wrote:

Win+R -> cmd -> control+shift+enter (for an admin window)

Huh, that's something new I learned about Windows. Thanks!

The fundamental problem, it says is...
"You have a permission problem to listen on a port".

I know in Linux/UNIX systems, certain port ranges require admin perms to
bind to.

Exact port ranges are listed here: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

Something to look at?
--
user <candycane> is generated from /dev/urandom

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

XPost: alt.comp.microsoft.windows, comp.mobile.android

On 10/4/23 21:44, Wolf Greenblatt wrote:

The reason is most likely due to a Windows Update that
restricted access to certain ports without telling anyone. https://ardalis.com/attempt-made-to-access-socket/

Seems like bad planning on Windows' part. Also, it's kinda hilarious
they didn't just take one or two big blocks out of the upper port range.
--
user <candycane> is generated from /dev/urandom

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

XPost: alt.comp.microsoft.windows, comp.mobile.android

On Wed, 4 Oct 2023 21:52:36 -0500, candycanearter07 wrote:

Seems like bad planning on Windows' part.

Almost every instance of this long but distinct error message appears to be related to Windows update locking up ports - but why does it do that? https://appuals.com/fix-an-attempt-was-made-to-access-a-socket-in-a-way-forbidden-by-its-access-permissions/
"Almost all affected users report that the issue started occurring
after a Windows automatic update has been installed. Microsoft has
implemented a new security feature that will prevent users from
grabbing a random port and giving it away to some service.
This could occur if you're using a script or a home brewed application."

The problem with articles like that one is they're shooting in the dark.
They suggest all sorts of "fixes" without having any rhyme or reason.
It's clear they are just guessing. There's no organized approach.
Eventually 'something' works.

And you know when they start blaming the firewall and the AV programs
that they're completely shooting at shadows flickering by the fire. https://stackoverflow.com/questions/20779336/an-attempt-was-made-to-access-a-socket-in-a-way-forbidden-by-its-access-permiss

But at least they gave a debugging command to check things out better.
netstat -ano | findstr <your port number>

You can change the port that Android uses only by trying to connect
or pair over Wi-Fi on your LAN but you don't control the port.

It will change. Arbitrarily. Within a range. But that's the only
control you have (the port range seems in the 30,000's to 40,000s).

I'm not sure how (or if) it works, but some sites suggest restarting your
IIS services but that's probably only when they have a web server affected. iisreset

This seems to have the longest set of continuous advice for a decade. https://stackoverflow.com/questions/10461257/an-attempt-was-made-to-access-a-socket-in-a-way-forbidden-by-its-access-permissi

What they suggest which seems to have worked for lots of people is
stopping and starting the Host Network Service service.
net stop hns && net start hns

But it seems nobody is debugging to figure out what the problem is.
Everyone is just testing out commands until finally one of them works.

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

XPost: alt.comp.microsoft.windows, comp.mobile.android

Wally J wrote:

ERROR: bind: [10013] An attempt was made to access a socket in a way forbidden by its access permissions.

I'd be looking in Windows Defender Firewall settings, temporarily add
an allow rule to see if that stops the error, if it works replace it
with as narrow a rule as possible to leave in place.

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

XPost: alt.comp.microsoft.windows, comp.mobile.android

On 05/10/2023 06:47, Andy Burns wrote:

I only have two TCP ports that are reserved
2869 which is for Internet Connection Sharing
5357 which is for Web Sharing for Devices.

Or possibly Web Services Discovery.

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

XPost: alt.comp.microsoft.windows, comp.mobile.android

Wolf Greenblatt wrote:

After Windows 10 updates, some ports are reserved by Windows with the
result that applications cannot bind to these ports.

I only have two TCP ports that are reserved
2869 which is for Internet Connection Sharing
5357 which is for Web Sharing for Devices.

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

XPost: alt.comp.microsoft.windows, comp.mobile.android

On 10/5/2023 12:58 AM, Wolf Greenblatt wrote:

But it seems nobody is debugging to figure out what the problem is.
Everyone is just testing out commands until finally one of them works.

But you know, in the end, there is a proper way to do this.

(You must use a modern browser, to view the simple text content on these pages :-/ )

https://github.com/Genymobile/scrcpy/blob/master/doc/connection.md

scrcpy --tcpip=192.168.1.1 # default port is 5555
scrcpy --tcpip=192.168.1.1:5555

If adb TCP/IP mode is disabled on the device (or if you don't know the IP address),
connect the device over USB, then run:

scrcpy --tcpip # without arguments

It will automatically find the device IP address and adb port,
enable TCP/IP mode if necessary, then connect to the device before starting.

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

5555 Unofficial Wireless adb (Android Debug Bridge) control of an Android device over the network.

And that port is actually used by more than one service.

*******

"Documentation for control protocol #673"

https://github.com/Genymobile/scrcpy/issues/673

"The protocol between the client and the server is internal
and private, and may (and will) change at any time.

Recently, as you noticed, the communication has changed
to use 2 sockets in order to support copy-paste (ec71a3f).
"

https://github.com/Genymobile/scrcpy/commit/ec71a3f66ab48c2fdd1728753acc09edbd4db570

"Use two sockets for video and control

The socket used the device-to-computer direction to stream the video and
the computer-to-device direction to send control events.

Some features, like copy-paste from device to computer, require to send
non-video data from the device to the computer.

To make them possible, use two sockets:
- one for streaming the video from the device to the client;
- one for control/events in both directions.
"

In this thread, without explanation, their firewall has 5555,7007 open.

https://stackoverflow.com/questions/66611227/afwall-firewall-unblock-adb-wireless

And 7007 isn't in the Wiki port list.

Paul

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

XPost: alt.comp.microsoft.windows, comp.mobile.android

Paul <nospam@needed.invalid> wrote

But you know, in the end, there is a proper way to do this.

SOLVED!
<https://i.postimg.cc/Dz1rcpDX/scrcpy26.jpg> The port is locked up
<https://i.postimg.cc/25XrGW9R/scrcpy27.jpg> But it's not in the list
<https://i.postimg.cc/pdyTjwnT/scrcpy28.jpg> Android assigns the port
<https://i.postimg.cc/Hs1ZZ5H0/scrcpy29.jpg> Apparently HNS solved it

I'm confused.
So all I can tell you is what happened.

The problem solved itself immediately after I ran the HNS commands cited
in one of the references (I think it was the 12 year old stackexchange).
<https://i.postimg.cc/pdyTjwnT/scrcpy28.jpg>

Thanks for your help - in the end - the problem "went away" the moment I
ran this command - but I do not know why the problem "was there" in the
first place - but now - when it comes back - and it will - I'll run this command again. :)

net stop hns && net start hns
adb connect 192.168.1.4:44285
netstat -ano | findstr 44285

TCP 192.168.1.198:1708 192.168.1.4:44285 ESTABLISHED 8172

(You must use a modern browser, to view the simple text content on these pages.)
https://github.com/Genymobile/scrcpy/blob/master/doc/connection.md

scrcpy --tcpip=192.168.1.1 # default port is 5555
scrcpy --tcpip=192.168.1.1:5555

This is confusing to me - even though I use this stuff every day.

I used to use these terms "--tcpip" many years ago - but no longer.
After Android+adb+scrcpy went to Wi-Fi, I no longer use the USB cable.

However...

I don't profess to understand all this tcp port stuff so I have to be
careful what I say as I don't know how much of that "tcpip" stuff matters.

Suffice to say Android adb on Windows can connect to the phone via
either USB or Wi-Fi but we used to _also_ use those tcpip options after initially connecting via USB and _then_ pulling the cable out to go Wi-Fi.

Andy Burns will know more about this than I do, but that's how we did it.
a. Either we stayed on USB
b. Or we _started_ on USB (and then went Wi-Fi using tcpip port 5555)
<https://i.postimg.cc/5NrK7jtg/scrcpy16.jpg>
c. Or we stayed on Wi-Fi (and used the port that Android tells us to use)

As you can see from the screenshot, the port is assigned to us.
I don't get to pick the port and it changes on every Wi-Fi connection.
<https://i.postimg.cc/pdyTjwnT/scrcpy28.jpg>

Those randomly assigned ports are usually from 3xxxx to 4xxxx (not 5555).

If adb TCP/IP mode is disabled on the device (or if you don't know the IP address),
connect the device over USB, then run:

scrcpy --tcpip # without arguments

It will automatically find the device IP address and adb port,
enable TCP/IP mode if necessary, then connect to the device before starting.

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

5555 Unofficial Wireless adb (Android Debug Bridge) control of an Android device over the network.

And that port is actually used by more than one service.

*******

"Documentation for control protocol #673"

https://github.com/Genymobile/scrcpy/issues/673

"The protocol between the client and the server is internal
and private, and may (and will) change at any time.

Recently, as you noticed, the communication has changed
to use 2 sockets in order to support copy-paste (ec71a3f).
"

https://github.com/Genymobile/scrcpy/commit/ec71a3f66ab48c2fdd1728753acc09edbd4db570

"Use two sockets for video and control

The socket used the device-to-computer direction to stream the video and
the computer-to-device direction to send control events.

Some features, like copy-paste from device to computer, require to send
non-video data from the device to the computer.

To make them possible, use two sockets:
- one for streaming the video from the device to the client;
- one for control/events in both directions.
"

In this thread, without explanation, their firewall has 5555,7007 open.

https://stackoverflow.com/questions/66611227/afwall-firewall-unblock-adb-wireless

And 7007 isn't in the Wiki port list.

All this is what we _used_ to do years ago _before_ Android had the
capability of connected to Windows adb _without_ using the USB cable.

You can tell because of the "5555" port number.

Nowadays, we use a port number assigned to us from 30000 to 40000
(note the extra digit!) which the phone randomly provides us.

When it's all working, here's how we do the connection nowadays:

On the phone we connect to Wi-Fi & the LAN & get our random port.
1. We make sure our Android Wi-Fi is on & connected to the LAN
2. We longpress the handy "Wireless Debugging" swipe-down tile
3. This tells us the random port that we are assigned today
(today that random port is 44285)

On the PC we open up a command window & start adb & connect to Android
1. C:\> adb devices
2. C:\> adb connect 192.186.1.4:44285
3. C:\> scrcpy -s 192.168.1.4

I admit I'm confused for a couple of reasons though.
a. First off, this works 99% of the time; but 1% of the time I get
the error which started this thread in the first place. Dunno why.
b. I sometimes do see port 55555 (note the extra digit) showing up!
<https://i.postimg.cc/Hs1ZZ5H0/scrcpy29.jpg>
b. I usually do NOT see port 55555; I see the random port instead.
(see the same screenshot, different session).
Note: I had just killed the second session so that's why it's closed.

The good news?
This single Windows command solved the connection problem!

net stop hns && net start hns

Running that single command _instantly_ solved the connection problem!

The bad news?
I don't know why it happened & I don't even know why it worked.

I'm confused.
But... it's working again.

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

XPost: alt.comp.microsoft.windows, comp.mobile.android

Andy Burns <usenet@andyburns.uk> wrote

ERROR: bind: [10013] An attempt was made to access a socket in a way
forbidden by its access permissions.

I'd be looking in Windows Defender Firewall settings, temporarily add
an allow rule to see if that stops the error, if it works replace it
with as narrow a rule as possible to leave in place.

Thanks for the help as this happens every once in a while to me, and, from
the looks of what the search engines found, to everyone who is on Windows.

While I'm completely dumbfounded as to why it happened and how HHN fixed
it, what I do know is most people who have this blame Windows update.

In addition, most people who have this problem get it solved by using this.
Win+R cmd <control+shift+enter> (to get an admin window)

net stop hns

The Host Network Service service is stopping.
The Host Network Service service was stopped successfully.

net start hns

The Host Network Service service is starting.
The Host Network Service service was started successfully.

I repeat that this error is common and that there were _many_ suggestions
to fix firewalls and to check ports - but this is the command that worked!

The instant I ran those HNS commands, everything worked fine again.
<https://i.postimg.cc/WbpYsfqg/scrcpy30.jpg> It's all working again

What happened?
I do not know.

Do you?

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

XPost: alt.comp.microsoft.windows, comp.mobile.android

Wally J wrote:

The problem solved itself immediately after I ran the HNS commands

I didn't catch whichever message you mentioned HNS in, if you mean Host
Network Service, are you running windows within a container (docker etc)
if so I didn't notice that either ... but could see how one container
would need to protect its ports against other containers ...

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

XPost: alt.comp.microsoft.windows, comp.mobile.android

Andy Burns <usenet@andyburns.uk> wrote

The problem solved itself immediately after I ran the HNS commands

I didn't catch whichever message you mentioned HNS in, if you mean Host Network Service, are you running windows within a container (docker etc)
if so I didn't notice that either ... but could see how one container
would need to protect its ports against other containers ...

Everyone talks about Docker - but I hate Docker (it's a dumbly written
program, that's why) so I don't have it. Everyone also talks about IIS
"iisreset -stop"
But I'm not running any web servers.
I'm not running anything in a container, no VM, nothing.

I'm just running these two commands (which I run every single day):
1. adb connect IP:port <=== this connects Windows to Android over Wi-Fi
2. scrcpy -s IP <=== this mirrors Android onto Windows over Wi-Fi

I do it because my phone suddenly becomes two feet tall and a foot wide
when I do that, and it works with my keyboard, mouse & clipboard to boot.

Every once in a while (who knew then that I now know it's the Windows
Update that probably did it!) it just stops working. Just like that.

The error message is the one in the subject line of this thread:
"An attempt was made to access a socket in a way forbidden by its access permissions"

But now it's finally solved!

It isn't a straight path for the ant to find the food, but once the ant
found the tasty crumbs, the path to the solution is dead-arrow straight.

This is a long dozen-year history of everyone having the same problem.
<https://stackoverflow.com/questions/10461257/an-attempt-was-made-to-access-a-socket-in-a-way-forbidden-by-its-access-permissi>

The four key statements in that long dozen-year problem history are...
"Restarting the Host Network Service on Windows solved the problem."
"net stop hns && net start hns"
"netstat -ano | find <portnumber>"
"netsh interface ipv4 show excludedportrange protocol=tcp"
etc.

Now... I've never heard of "HNS" in my life... so certainly I didn't
mess with it... but apparently most people say Windows Update did it.

Whatever Windows Update did, that is.
All I know is that it instantly started working again the moment I ran

Win+R cmd <control+shift+enter> (to get an admin window)

net stop hns

The Host Network Service service is stopping.
The Host Network Service service was stopped successfully.

net start hns

The Host Network Service service is starting.
The Host Network Service service was started successfully.

Here are my screenshots since I am all about proving what I say...
<https://i.postimg.cc/Dz1rcpDX/scrcpy26.jpg> The port is locked up
<https://i.postimg.cc/25XrGW9R/scrcpy27.jpg> But it's not in the list
<https://i.postimg.cc/pdyTjwnT/scrcpy28.jpg> Android assigns the port
<https://i.postimg.cc/Hs1ZZ5H0/scrcpy29.jpg> Apparently HNS solved it
<https://i.postimg.cc/WbpYsfqg/scrcpy30.jpg> It's all working again

What happened?
Damned if I know.

I "think" Windows Update locked up some ports.
At least that's what many of the solutions seem to say it did.

How did HNS unlock those locked ports?
Damned if I know.

I never even heard of Windows HNS until today.

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