Local server not found error (Mac-OS FGU)

[mattash77]

I'm having a similar issue starting a locally hosted session.

I installed FGU this week and began testing it on my MacBook Pro as well as a PC I have. I noticed on the forums there are several other Mac users that are having issues related to connecting to locally hosted games. I’ve been digging into the issue and found some interesting issues.

If I start with a v4.0.0 FREE client I can start a locally hosted session, but neither my PC or other Mac can connect. The host does start the session though

If I put in my license number for ULTIMATE and my host displays v4.0.0 ULTIMATE and attempt to start a session WITHOUT the firewall on the program hangs. If I have the firewall on, I get the same issue as the others in this thread. I’ve turned on logging within the program and found that a bunch of files are missing from the installation that are attempting to be loaded and may be part of the issue.

I am including a log file that might shed some light on the problematic issues.

I sent this in an email to support as well.

[Moon Wizard]

Thanks for the additional info, and the follow-up to support e-mail as well.

If you remove the license, you can run in free mode which does not try to start a network server, which appears to be the problem right now.

Regards,
JPG

[IdGibbins]

The current FGU provides an error with a stack trace when I attempt to run a local server:

[2/9/2020 8:37:43 AM] [NOTICE] Launcher scene starting.
[2/9/2020 8:38:32 AM] [NOTICE] Daily session backup created.
[2/9/2020 8:38:32 AM] [NOTICE] Starting private server mode. [(192.168.34.211:1802) (fe80::28f4:4b24:7743:700f%11:1802)]
[2/9/2020 8:38:37 AM] [<color="red">ERROR</color>] LAUNCHER START BUTTON: System.Net.Sockets.SocketException (0x80004005): Could not resolve host 'Ids-MacBook.local'
at System.Net.Dns.Error_11001 (System.String hostName) [0x00015] in <ae22a4e8f83c41d69684ae7f557133d9>:0
at System.Net.Dns.GetHostByName (System.String hostName) [0x00021] in <ae22a4e8f83c41d69684ae7f557133d9>:0
at System.Net.Dns.GetHostEntry (System.String hostNameOrAddress) [0x00052] in <ae22a4e8f83c41d69684ae7f557133d9>:0
at NobleConnect.Mirror.NobleNetworkManager.OnStartSer verLANOnly () [0x00005] in <ddabc3e97a80408bb1c027166470a7ad>:0
at NobleConnect.Mirror.NobleNetworkManager.OnStartSer ver () [0x0005f] in <ddabc3e97a80408bb1c027166470a7ad>:0
at FG.NetworkLibrary.OnStartServer () [0x00000] in <ddabc3e97a80408bb1c027166470a7ad>:0
at Mirror.NetworkManager.SetupServer () [0x0006b] in <c426eb1cb8794c66adc84576c050b85e>:0
at Mirror.NetworkManager.StartHost () [0x00007] in <c426eb1cb8794c66adc84576c050b85e>:0
at NobleConnect.Mirror.NobleNetworkManager.StartHostL ANOnly () [0x00007] in <ddabc3e97a80408bb1c027166470a7ad>:0
at FG.NetworkLibrary.StartPersonalServer (System.Int32 BHOPPABLJNL, System.String BJGNJIDEFOF, System.Int32 KFDKFIABKNO, System.String OKMEPDIOKAF, System.Boolean KFPDBBGCDME, System.Boolean CMFJOCMLFOP) [0x00072] in <ddabc3e97a80408bb1c027166470a7ad>:0
at CDMNBKMEIBG.PGFIGJBOEAG (System.String OKMEPDIOKAF, System.String DMNMMAFPGKE, System.Boolean CMFJOCMLFOP, System.Int32 LACFKGCAMMF) [0x000d8] in <ddabc3e97a80408bb1c027166470a7ad>:0
at JECDJEHHEIE.ILNNFDLFCHH (System.String OEKADEOGOOL, System.String EDDLBLODPCM, System.String BOLDJMHMGNJ, System.String DMNMMAFPGKE, System.Boolean CMFJOCMLFOP, System.Boolean JOJMOLKGDPJ, System.Int32 PGGLDPLNGBD, System.Collections.Generic.List`1[T] GOEAJEEMHLH) [0x00089] in <ddabc3e97a80408bb1c027166470a7ad>:0
at FG.LauncherScene.GJBJEPOCJNF () [0x000a7] in <ddabc3e97a80408bb1c027166470a7ad>:0
at FG.LauncherScene.StartButtonClicked () [0x00037] in <ddabc3e97a80408bb1c027166470a7ad>:0

It appears that, despite already knowing the local IP addresses (they're visible on the "Starting private server mode" line before the error), the application is attempting to get local IP addresses by looking up the system's hostname. From a quick poke around Stack Overflow, this does not appear to be a reliable method on macOS. It's likely related to name resolution behavior for the .local domain used on macOS.

[Moon Wizard]

@IdGibbins,

This appears to be working on some Mac machines without issue. We actually tested that internally on a couple Macs before we released.

What version of Mac OS are you running? Anything else that you can think of as unique? (laptop vs. desktop, etc.) Also, do you remember the link on Stack Overflow where you read this?

I'll need to pass this back to network library developer; so the more information I have the better. Plus, if we can determine workaround, we can implement short term fix.

Thanks,
JPG

[IdGibbins]

Finally got some time to dig further into this and figured it out. I run my mac with all sharing services disabled (it provides a reduced attack surface). When macOS starts with all of its sharing services disabled, it doesn't start its mDNS service. mDNS is what resolves name lookups for the .local domain.

A solution to work around this is going to vary by macOS version. For my version (10.14.6 Mojave), a single sharing service that depends on mDNS can be temporarily enabled, for instance the Remote Apple Events service (found in System Preferences -> Sharing; Enable Stealth Mode in System Preferences -> Security & Privacy -> Firewall -> Firewall Options may also need to be unchecked). Once this has been done, mDNS will run for the next 120 seconds (or you could leave a sharing service enabled to leave mDNS on). While mDNS is running a Fantasy Grounds local server can be successfully started.

The error that I get should be replicable in recent versions of macOS by first disabling all services in System Preferences -> Sharing; and then waiting 120 seconds for mDNS to automatically stop (or restarting macOS so it isn't even started). A quick way to see if mDNS is disabled is to ping the system's hostname:

$ ping `hostname`
ping: cannot resolve Ids-MacBook.local: Unknown host

A correct fix for the network library that you're using would be for it to _never_ rely on hostname resolution to determine the local system's own IP addresses. It should instead get a list of network interfaces and work through the list looking for active unicast IP addresses. It's likely already doing this in some parts of the library since the log in my last post showed the correct addresses before the stack dump. Using the hostname to get the system's local IP addresses will work a lot of the time but not all of the time and may, as shown here, prove difficult to root cause why some people have issues and others don't.

[Star Drayke]

I had to add an entry to my hosts file

try this:
MyIP=$(ifconfig | grep 192.16| awk '{print $2}')
echo "$MyIP $(hostname)" | sudo tee -a /etc/hosts (use yr login password)
check:
cat /etc/hosts

[Moon Wizard]

I'll report to the network library creator.

From a quick search, the code setup they are using is fairly commonly used for .Net applications. I'm guessing your situation is uncommon.
https://stackoverflow.com/questions/...cal-ip-address

Regards,
JPG

[zuilin]

@Star Drayke - After adding the hosts entry (which for me is 10.0.0.41 My-MacBook-Pro.local) to hosts, how are you accessing the host? Are you using a second copy of the .app bundle and running it locally? Are you running from another computer? What are you entering in the "Join By IP and Port" field, the host name? (i.e. My-MacBook-Pro.local)

[zuilin]

Finally got some time to dig further into this and figured it out. I run my mac with all sharing services disabled (it provides a reduced attack surface). When macOS starts with all of its sharing services disabled, it doesn't start its mDNS service. mDNS is what resolves name lookups for the .local domain.

A solution to work around this is going to vary by macOS version. For my version (10.14.6 Mojave), a single sharing service that depends on mDNS can be temporarily enabled, for instance the Remote Apple Events service (found in System Preferences -> Sharing; Enable Stealth Mode in System Preferences -> Security & Privacy -> Firewall -> Firewall Options may also need to be unchecked). Once this has been done, mDNS will run for the next 120 seconds (or you could leave a sharing service enabled to leave mDNS on). While mDNS is running a Fantasy Grounds local server can be successfully started.

The error that I get should be replicable in recent versions of macOS by first disabling all services in System Preferences -> Sharing; and then waiting 120 seconds for mDNS to automatically stop (or restarting macOS so it isn't even started). A quick way to see if mDNS is disabled is to ping the system's hostname:



A correct fix for the network library that you're using would be for it to _never_ rely on hostname resolution to determine the local system's own IP addresses. It should instead get a list of network interfaces and work through the list looking for active unicast IP addresses. It's likely already doing this in some parts of the library since the log in my last post showed the correct addresses before the stack dump. Using the hostname to get the system's local IP addresses will work a lot of the time but not all of the time and may, as shown here, prove difficult to root cause why some people have issues and others don't.

I can ping `hostname` and it resolves my hostname to 127.0.0.1 just fine, giving me a good ping. However, the FGU problem persists. I have sharing services enabled and firewall off. I'm testing by running a second copy of the FantasyGrounds.app and connecting to localhost with the default port. I've also tried 127.0.0.1, my actual IP, and localhost.local. Still doesn't work. I wonder if it has anything to do, in my case, with running the second .app bundle. I suspect it doesn't but I don't know enough to figure it out. In the end, I have to be able to run a "client version" on the same laptop as I do in Windows.

[Chris CB]

It's normal that 127.0.0.1 (localhost) is working. Try using the "internal" IP on the server launcher and use it in the client.

I've tried to launch two instances on my mac and it's working in LAN mode as in cloud mode.