Tarmslitaren / FrosthavenAssistant

flutter app
GNU Affero General Public License v3.0
184 stars 45 forks source link

Incorrect Host IP Selection (PC) #139

Closed rathe closed 1 year ago

rathe commented 1 year ago

Short version:

  1. What logic does the Windows client use to identify which internal IP to accept connections on? It doesn't appear to be based on IF Index or Metric.
  2. Can options be added to select the internal IP to use, disable external IP usage, and/or intentionally use the 0.0.0.0/0 catch-all?

Long version: As of 1.8.0, "Start Host Server" on my ethernet-connected Windows PC (no wifi) presents my NAT's public IP, and an internal 172.16.0.0/12 address associated with a virtual switch (which is required for the purpose of hosting VMs, but whose IP is unroutable on the network used by my wifi). In versions prior it presented 0.0.0.0 and the NAT public IP, and in those versions I was able to connect via my PC's LAN IP within the 10.0.0.0/8 range, because of that 0.0.0.0 catch-all entry.

Here's my network adapter layout

image

The interface the app should be using is IPv4 Index 3, "vEthernet (iNet1)". The one it IS using is Index 20, "vEthernet (Default Switch)". I have tried explicitly setting a low Metric for the correct interface, as you can see in the screenshot, but did not resolve. I am unsure what process X-Haven Assistant is using to prioritize interfaces.

Of course, I should be able to set up port forwarding from the public IP, and use that way. But there are a few reasons I don't:

  1. My 10.0.0.0/8 range IP is intentionally easy to remember and type, for just such uses as this
  2. Hosting a server open to the internet brings additional network security risks, and my router is not user-friendly enough to toggle this easily
  3. When I tried it before our first game after 1.8.0 hit, it didn't immediately work, and I didn't want to put any time into troubleshooting it because of the impending game, and also the previous two items in this list.

As a workaround, I am hosting from my (older) Galaxy Tab A7, but this comes with the mobile device client disconnections mentioned in Issue #60. I may have resolved this, but even if testing proves that out it is still not my preferred solution.

rathe commented 1 year ago

On reviewing my interface setup, I wonder if 1.8.0 began prioritizing DHCP-disabled interfaces before enabled ones? Perhaps for the increased likelihood of identifying an explicitly-set IP?

I use DHCP on all networking clients, and create reserved addresses in the DHCP server for those I want to have effectively-static IPs.

Tarmslitaren commented 1 year ago

this is the change: https://github.com/Tarmslitaren/FrosthavenAssistant/commit/b7329e2a9c65012b2b67ffa416008f1839c800ac

it used to take the first item it finds in the list with "Ethernet" in the name, but now it's "eth" and not case sensitive.

I'll add a check to not allow "switch" in name, might fix this particular issue. I get that selecting based on name might be quite suboptimal. I do have trouble testing this, since I only have a windows machine with an ethernet port.

Tarmslitaren commented 1 year ago

potential fix in 1.8.2, please tell if it works as intended

rathe commented 1 year ago

Confirmed that Start Server in Settings includes my 10.0.0.0/8 IP address as well as the NAT's Public IP.

rathe commented 1 year ago

1.8.3 broke this again.

image
Tarmslitaren commented 1 year ago

made a new build X-Haven.Assistant.1.8.3.windows.network.fix.zip added to same release. please try if that works. it may show the wrong ip but at least it should connect

rathe commented 1 year ago

On further testing, the error (1.8.3, original version) is display-only, and the error may be because I had to allow Windows Security to re-allow Public networks. Once I do this, and then stop and start the server again, it displays the 0.0.0.0 IP address. and connect from a client on the network using my 10.x.x.x/24 IP.

The network.fix release has the same behaviour: Initially the same error, Windows Security requests permission to Public connections, continues displaying error when allowed, and then switches to showing 0.0.0.0 once I stop and start again. Clients able to connect.

Chahton commented 1 year ago

I just want to confirm that X-Haven.Assistant.1.8.3.windows.zip is working for me. At server, address is shown as 0.0.0.0 but client can connect to correct address (in my case 192.169.1.33). X-Haven.Assistant.1.8.3.windows.network.fix1.zip is NOT working.