FGU Showing Incorrect Internal IP Address

[wndrngdru]

(Ver 2020-08-13)

When preparing to create or load a campaign, the internal IP Address shown on the screen is not accurate.
It's showing 192.168.56.1.
My actual internal IP is 10.10.10.10. (yes, I have an unconventional network setup :))

The shown external IP is correct.
I don't know if this has an impact on being able to connect or not, though connecting with a second session via localhost works fine. I don't have a separate machine handy to test a LAN connection with.

FGC reports the IP accurately.

[Imagix]

That would suggest to me that you have multiple network interfaces, and FGU is choosing to show you a different interface's IP. (Got something like VirtualBox or VMware installed?)

[LordEntrails]

FG will use the internal IP of the first network adapter/interface. You can change the order of this in your registry so that FG uses a different internal IP.

[wndrngdru]

I do have VirtualBox installed, so that's what FG is reporting.

Would it not be better to simply test which interface actually has network access and use that one? A fallback to the first one would seem okay if none currently do.
A user should not have to muck about in the registry to get FG to work.

[LordEntrails]

Better? Sure, but FGC is not particularly current and changing something like this is effort that would be pulled off of FGU. Besides, if you don't like the registry solution, all you have to do is to disable the VM adapter before starting FG.

[Imagix]

And, as I recall, FGU listens to all interfaces anyway. So this isn't a functional problem, but more cosmetic.

[damned]

Applications listen on all adapters
it can only display one IP address and that is the one that the Operating System returns to the application first

open a CMD prompt as Administrator and type

netstat -p UDPv6 -b -a

and look for fantasygrounds.exe - it may appear more than once
most likely it will be listening on 127.0.0.1 which means it is listening on all adapters

[wndrngdru]

Better? Sure, but FGC is not particularly current and changing something like this is effort that would be pulled off of FGU.

As I stated in my initial post, FGC reports the IP correctly, it is only FGU that has this problem.

Scenario:
I have 3 people sitting around a table in front of me, each with their own laptop running FGU.
I have 2 more people at remote locations around the world.
Let's also assume I'm ignorant of how networks work (which I'm not).
Now, because my remote people are connecting via the lobby, they can connect fine through my router. However, the 3 people that SHOULDN'T have problems can't connect to me because I gave them the address that FG is showing me and that IP address doesn't exist on my network. Much frustration ensues, there's time wasted trying to figure out why things won't work, etc.

All I'm saying is if the program is going to provide information for people to use, it should at least be correct information. Otherwise, it's better to not have it there in the first place. (and, yes, that info is technically correct as that interface does exist, it's just not one that anything outside my own computer can connect to.)
FG has a steep enough learning curve as it is. Networking 101 really shouldn't have to be part of it.

[LordEntrails]

As I stated in my initial post, FGC reports the IP correctly, it is only FGU that has this problem.
Yea, sorry, I got confused on the issue.

[damned]

As I stated in my initial post, FGC reports the IP correctly, it is only FGU that has this problem.

Scenario:
I have 3 people sitting around a table in front of me, each with their own laptop running FGU.
I have 2 more people at remote locations around the world.
Let's also assume I'm ignorant of how networks work (which I'm not).
Now, because my remote people are connecting via the lobby, they can connect fine through my router. However, the 3 people that SHOULDN'T have problems can't connect to me because I gave them the address that FG is showing me and that IP address doesn't exist on my network. Much frustration ensues, there's time wasted trying to figure out why things won't work, etc.

All I'm saying is if the program is going to provide information for people to use, it should at least be correct information. Otherwise, it's better to not have it there in the first place. (and, yes, that info is technically correct as that interface does exist, it's just not one that anything outside my own computer can connect to.)
FG has a steep enough learning curve as it is. Networking 101 really shouldn't have to be part of it.

FGU reports the interface that windows presents to it.
Network Architecture says let the networking stack handle networking and let the application handle the application data.
Applications hand off the data to the operating system so they dont know and dont care what route or interface the operating system uses.

[wndrngdru]

FGU reports the interface that windows presents to it.
Applications hand off the data to the operating system so they dont know and dont care what route or interface the operating system uses.

I'm not out to argue anything here except that, in my opinion, the Internal IP display feature in FGU is not working as intended and, therefore, a bug. (I'm a little taken aback that I'm even having to argue that.)
If MW wants to come on and tell me it's doing exactly what they expect it to do, or that they know there are certain cases where it doesn't but they're not going to do anything about it, I'll bite my tongue.
Though, I still might argue that it's confusing and could be better than it is. ;) I just want this to be the best and easiest it can be for new users.

[Trenloe]

You’re asking FGU to verify network access to present a valid Internal IP address in the FGU interface so you know what Internal IP address to use for local connectivity. Your operating system is presenting the first valid Internal IP address. It’s a valid IP address, and you just need it for local FGU connectivity. I don’t know how FGU is going to decide this isn’t a valid network interface in your instance.

As damned says, leave the networking config to your operating system. If FGU tries to make guesses as to what is the best Internal IP address within the thousands of different possible network architectures, there’s going to be a lot more issues than just displaying the "wrong" internal IP address.

[Trenloe]

Scenario:
I have 3 people sitting around a table in front of me, each with their own laptop running FGU.
I have 2 more people at remote locations around the world.
Let's also assume I'm ignorant of how networks work (which I'm not).
Now, because my remote people are connecting via the lobby, they can connect fine through my router. However, the 3 people that SHOULDN'T have problems can't connect to me because I gave them the address that FG is showing me and that IP address doesn't exist on my network. Much frustration ensues, there's time wasted trying to figure out why things won't work, etc.
This won't work whatever internal IP address is used, as a Cloud campaign can only use cloud connections.

Confirmation that this is by design from Moon Wizard here: https://www.fantasygrounds.com/forums/showthread.php?58707-Connection-issue-again-with-LAN&p=523399&viewfull=1#post523399

[Trenloe]

If MW wants to come on and tell me it's doing exactly what they expect it to do, or that they know there are certain cases where it doesn't but they're not going to do anything about it, I'll bite my tongue.
From Moon Wizard regarding IP address selection: https://www.fantasygrounds.com/forums/showthread.php?59273-Trouble-with-FGU-opening-port-but-not-FGC&p=522017&viewfull=1#post522017 "it's not a trivial "just pick one" scenario"

[wndrngdru]

You’re asking FGU to verify network access to present a valid Internal IP address in the FGU interface so you know what Internal IP address to use for local connectivity. Your operating system is presenting the first valid Internal IP address. It’s a valid IP address, and you just need it for local FGU connectivity. I don’t know how FGU is going to decide this isn’t a valid network interface in your instance.


99.9% of the time, it's going to be the interface that is on the same network as the Default Gateway.

Windows IP Configuration

Ethernet adapter Ethernet:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::7c9d:b4e7:68bd:4ae3%10
IPv4 Address. . . . . . . . . . . : 10.10.10.10
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.10.10.1

Ethernet adapter VirtualBox Host-Only Network:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::8454:339f:34b6:129%9
IPv4 Address. . . . . . . . . . . : 192.168.56.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

FGU MIGHT be able to successfully route outbound traffic through either one of these, but there's only one that will work when given to the players to connect to.


This won't work whatever internal IP address is used, as a Cloud campaign can only use cloud connections.
Ah, good to know. So, in my scenario, it would need to be set up as a LAN game with the router properly forwarded for the external traffic. It doesn't quite nullify the issue, although the host would presumably realize the local IP as shown won't work and adjust accordingly.


From Moon Wizard regarding IP address selection: https://www.fantasygrounds.com/forums/showthread.php?59273-Trouble-with-FGU-opening-port-but-not-FGC&p=522017&viewfull=1#post522017 "it's not a trivial "just pick one" scenario"
This is different issue. It's on a Mac using IPv6 and has to do with the host communicating on a different address than it used to open the router port.
I'm talking about the IPv4 internal address. The addition of IPv6 compatibility may be muddying the issue, however. I don't know.
FGC does not and never has had this problem for me, only FGU.

I don't have any answers here. It may or may not be possible for FGU to actually do what I'm expecting it to.
What I do know, at least for now, is I can't trust that the IP info provided on that screen will get things up and running and I need to get/confirm it elsewhere.

[Trenloe]

This is different issue. It's on a Mac using IPv6 and has to do with the host communicating on a different address than it used to open the router port.
The section I'm referring to is about trying to identify which network adaptor to use to get a specific IP address. All of this is completely relevant here. Like I quoted "it's not a trivial "just pick one" scenario".