Closed rathe closed 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.
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.
potential fix in 1.8.2, please tell if it works as intended
Confirmed that Start Server in Settings includes my 10.0.0.0/8 IP address as well as the NAT's Public IP.
1.8.3 broke this again.
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
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.
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.
Short version:
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
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:
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.