Windows: Binding on low port blocked by firewall

[moomoohk]

Default behavior is to bind server on random port, which might be lower than 49152.
On Windows, this will result in the unindicative error:

_socket.error: [Errno 100] Address already in use

To address this the random port must be higher than 49152.

The issue is cause by the Windows firewall reserving all the lower ports.

More information: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements

[justfoxing]

Uh, the default behaviour is not to use a random port - the server port is defined as 4768 (see https://github.com/justfoxing/ghidra_bridge/blob/master/ghidra_bridge/server/ghidra_bridge_port.py#L1).

The article you linked to explains that ports over 49152 are used by Windows as it's default dynamic port range - this is used for outgoing TCP connections. The ghidra_bridge client will randomly be assigned one of these ports when it tries to establish the connection to the server, but Windows will assign it one that's free, so it won't get that error message. The default dynamic port range has no relevance to the ghidra_bridge server.

I think the most likely issue here is not that the firewall has "reserved" the lower ports, but that, as the error message says, something is already using that port on your computer. The most likely culprit is ghidra_bridge itself - once you start a ghidra_bridge server, you either need to close Ghidra completely (all the windows, including the project window), or run the ghidra_bridge_shutdown.py script before you can start a new ghidra_bridge server. Try running the following command in an elevated powershell session to see what's got 4768 open: netstat -abnp tcp |Select-String -Context 0,1 4768. If you see something like > TCP 127.0.0.1:4768 0.0.0.0:0 LISTENING [javaw.exe] that's probably ghidra_bridge (or it could be some other java program listening on the same port, I guess)

If it's not ghidra_bridge that's got 4768, or if you're trying to run the ghidra_bridge server in multiple separate Ghidra sessions at once, you'll need to modify the server to specify a different listen port. I'd suggest taking a copy of ghidra_bridge_server_background.py and changing the last line to GhidraBridgeServer.run_server(background=True, server_port=<insert your favourite port here>). Naturally if you do this, you'll need to change the client to connect to that port - you do this by invoking the client as ghidra_bridge.GhidraBridge(connect_to_port=<your port>, <whatever other arguments>.

[moomoohk]

Hi,
Not sure why I mentioned the default port being random :)

You're also right about the link not covering the issue (I'm not really on top of my game ATM), however I can confirm Windows firewall blocks low ports from binding. This has affected me in other applications as well!

I confirmed before originally posting this issue that the port was indeed unbound using netstat. Hard coding a higher default port locally solved the issue.

Here are some discussions covering issues binding due to reserved port ranges, for example:

• https://stackoverflow.com/questions/48478869/cannot-bind-to-some-ports-due-to-permission-denied
• https://superuser.com/questions/1579346/many-excludedportranges-how-to-delete-hyper-v-is-disabled
• Unable to bind ports: Docker-for-Windows & Hyper-V excluding but not using important port ranges docker/for-win#3171

Most of these solutions recommend stopping the Windows firewall service, binding the port and then restarting it. Some others recommend adding a firewall exception. I believe both of these solutions aren't robust - I've had these settings reset after OS updates (which led to things breaking inexplicably).

The reserved ranges are quite unintuitive (not just well-known low ports), coupled with obscure error message - makes for a hard diagnosis.

I believe this issue will affect all Windows users with these reserved port ranges and would recommend upping the default port, just to be safe.

[justfoxing]

All of those discussions are about reserved port ranges for Hyper-V, nothing to do with the firewall (for reference, I dev and run ghidra_bridge on my Windows box, without firewall issues).

The discussions describe a wide and changing range of port reservations - since Hyper-V isn't enabled by default, and there appears to be no safe range to change ports to, and nobody else has reported this issue, I'm not going to do anything about it. Since you're enough of a power-user to enable Hyper-V, I'm sure you'll be able to sort out your configuration. If more people report the same problem in future, I might get around to documenting it as an edge-case to be aware of.