Weird LAN networking connectivity issue

[kasin]

In LAN mode I am unable to connect to the server locally via WiFi, but can remotely via ethernet, or externally via port forwarding. This is very confusing! I can send UDP packets to the server, and even to fantasy grounds on the server when on the wifi, but the client doesn't connect and hangs at "Attempting direct connection to server".

Both machines are macs.

Attached is my compiled logs from the server. Of note in console.log is a null reference exception:
[11/26/2024 2:27:41 PM] [WARNING] URL: System.TypeInitializationException: The type initializer for 'System.Net.ServicePointManager' threw an exception.

On the client, console.log just says:
[11/26/2024 3:55:44 PM] FGU: v4.6.0 FREE (2024-11-24)
[11/26/2024 3:55:44 PM] OS: Mac OS X 15.1.1
[11/26/2024 3:55:44 PM] GRAPHICS: Apple M1 Pro : 10922
[11/26/2024 3:55:44 PM] UI SCALE: 1
[11/26/2024 3:55:44 PM] USER: kasin
[11/26/2024 3:55:44 PM] Launcher scene starting.
[11/26/2024 3:55:54 PM] Attempting direct connection to server. [192.168.2.2:1802]

Client network.log says:
[11/26/2024 3:55:44 PM] FGU: v4.6.0 FREE (2024-11-24)
[11/26/2024 3:55:44 PM] USER: kasin

The server has 192.168.2.2 on the ethernet interface and 192.168.2.72 on the wifi interface

Tests tried:
0. Ping the server (192.168.2.2 and 192.168.2.72) from the client (192.168.2.186) on the LAN via IPv4 and IPv6 (both passed)
1. Tried connecting FG via LAN IPv4 address (192.168.2.2) and IPv6 (both failed)
2. Updated both server and client to latest release (still failed)
3. Rebooted both client and server machine (still failed)
4. Disabled firewalls (anti-virus not installed on either) (still failed)
5. Launched the 5e tutorial campaign with no extensions loaded (still failed)
6. tested network connectivity
6a. Test UDP connectivity between client and server by running netcat on a different port (1803) on server to see if UDP packets arrive from client (passed)
6b. Testing UDP connectivity from client to FG server by running netcat on client to connect to fantasy grounds running on port 1802 (connection not dropped, so looks like something was running on that port to receive the packets, but no response from server. The lack of response is unsurprising given I don't know the syntax to send.). (passed)
7. Checked fantasy grounds on the server is running and listening on port 1802 for UDP with lsof (passed)
7. Disabled VPN on both client and server machines (still failed)
8. Tested client and server software works by connecting to server from outside the LAN using port forwarding (passed, so it is just the LAN)
9. Completely clean install of both client and server by deleting all config and plists, deleting the application folder, downloading FG, and re-installing. (still failed)
10. Checked the MAC address in the routing tables of both client and server correctly reflected the right routes and show they are directly connected at layer 2 (passed, I am getting desperate).
11. Connect the client via ethernet to the same switch as the server (passed). This one is blowing my mind!!!
12. Disable the WiFi interface on the server. (Still failed).

I cannot work out how this is happening. Why can I get network connectivity, but FG won't connect except via ethernet?

Any ideas?

[damned]

Do you have Wifi isolation enabled on your router or access point?

[TVDinner]

Are you bridging/connecting the ethernet and wifi with the Mac, or is there some sort of "router" involved?

I don't do Macs and haven't done Berkeley in a long time, but I'd focus at the packet filtering on the server wifi. I'd make sure when packet filtering is off on the mac that the default is to accept packets. When it's running, look at the rule list for the default and 1802.

For testing, you can try to swap the server and client, and try a brokered connection (cloud server).

[kasin]

Nope, just checked. Although why can I send UDP packets but FG won’t connect?

[kasin]

No, it’s all layer 2. The wifi access point is connected via Ethernet to a switch which the server is so connected via Ethernet. I just did a manual arp on the client which returns the server’s MAC address, and vice versa, so they are definitely layer 2.

Your idea of switching client and server made we realise I was only testing UDP packets one way, from client to server. I just tried and I can send UDP packets from server to client on port 1802. Using the same port (1802) with nc would seem to rule out a port filter.

I tried running FG on the client and connecting from the server and no joy (good idea though).

With a packet capture I can see zero traffic between the hosts when using FG but I can see UDP packets being exchanged when using nc. It’s like it even isn’t trying to connect via FG.

[Trenloe]

I'd try test #12 again, but reboot both the client and server machines after disabling the WiFi interface on the server.

[TVDinner]

With a packet capture I can see zero traffic between the hosts when using FG but I can see UDP packets being exchanged when using nc.
This really sounds like the Mac has a per-app firewall with nc authorized while FGU isn't. I'd expect the installer to configure this and it needs to be there on both ends.

[Trenloe]

Additionally, if you still can't get it to work, please provide the whole logs from both the GM and Player side when the player is trying to connect. Details on how to compile the logs can be found in the FG Wiki here: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/1242136781/How+to+Compile+Logs After recreating the issue, use Method #3 on the GM side and Method #1 on the Player side.

[TVDinner]

8. Tested client and server software works by connecting to server from outside the LAN using port forwarding (passed, so it is just the LAN)
11. Connect the client via ethernet to the same switch as the server (passed). This one is blowing my mind!!!
Was the software that worked in these two tests FGU? Can the two machines connect with the brokered "cloud" connection?

If so, that points the evil finger at the "access point" that's bridging the wifi and the ethernet. Maybe it only does standard ports. You could try moving one of the networks to 192.168.3 and setting up routes by hand on the end machines (assuming that works on the AP).

You should be able to get this to work. I use a more complicated setup. The server and one client runs on one ethernet to a opnsense machine port forwarding 1802 from a second ethernet. The junk AT&T "router" sits on the second ethernet, with connections to the WAN, a "guest" 2.8ghz wifi, a second "home" 2.8 ghz wifi with two more clients, and the disabled 5ghz wifi. All the networks are on different addresses, one is even a class A for grins. Any problems are usually caused by the "router," although Windows has been known to mess up the firewall rule for FGU. The "guest" wifi is not allowed to talk with anything but the WAN.

You mentioned VPN, I suppose the packets could be sent there with no where to go, but you tested that.

I have this vague memory that I was able to set up a cloud connection on my server, get things working that way, then grab the port number the server was using and reconnect the client with the local option.

[damned]

You can run /info on a cloud game to get the local udp port number (it will be a random port not 1802) and you can connect a LAN client to that port but it is unlikely to solve the issue in this case

Do you have any UDP flood protection in place on either client or server?

[kasin]

Ok, just to recap.

I am currently trying connections from server to laptop, having previously tried laptop to server.

For the complete setup picture, I have multiple wifi AP, each of which has 4 VLANs;
Vlan 1: 192.168.1.0/24
Vlan 2: 192.168.2.0/24
Vlan 3: 192.168.3.0/24
vlan 4: 192.168.4.0/24
(each also has IPv6, but I am using IPv4 for simplicity in testing).

I have a core switch. The Wifi AP's are connected via ethernet into the vlan-aware switch. The AP's broadcast all of the above vlans onn separate SSID's. The server is connected via ethernet into the switch on vlan 2. The laptop is connected to vlan 1 or 2. Vlan 1 and 2 can freely talk to each other.

The router is connected to the switch and routes inter-VLAN traffic, and also traffic out to the Internet. It has port forwarding rules set on port 1802. I have tried running FG on non-port 1802 to test that.

I have found that it works if I either:
1. Plug it into ethernet. I didn't check with vlan it was on.
1. FG works vlan 2 -> vlan 1, but not vlan 2 -> vlan 2, or vlan 1 -> vlan 2. So there is something funky happening about vlan 2.

My investigation continues into the network.


I have attached console and network log when working and not working. Note the licence key conflict is fine as that means it actually connected.



Troubleshooting info so far:
Laptop-side, FG is listening:

glenn@MacBookPro ~ % sudo lsof -nP -i4UDP:1803
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
Fantasy 34415 glenn 56u IPv4 0x5bb7d5d43a893e61 0t0 UDP *:1803
Fantasy 34415 glenn 57u IPv6 0x3e7b89f32c4b5bfe 0t0 UDP *:1803

and my IP is correct:

glenn@MacBookPro ~ % ifconfig -a | grep 192
inet 192.168.2.189 netmask 0xffffff00 broadcast 192.168.2.255

However, connecting FG to 192.168.2.189 port 1803 just hangs. laptop-side console.log shows:


[11/27/2024 9:57:20 AM] FGU: v4.6.0 FREE (2024-11-26)
[11/27/2024 9:57:20 AM] OS: Mac OS X 15.1.1
[11/27/2024 9:57:20 AM] GRAPHICS: Apple M2 : 5461
[11/27/2024 9:57:20 AM] UI SCALE: 1
[11/27/2024 9:57:20 AM] USER: kasin
[11/27/2024 9:57:20 AM] Launcher scene starting.
[11/27/2024 9:57:21 AM] [WARNING] URL: UPDATE 1
[11/27/2024 9:57:21 AM] [WARNING] URL: DICE PACKS
11/27/2024 9:57:21 AM] [WARNING] URL: System.TypeInitializationException: The type initializer for 'System.Net.ServicePointManager' threw an exception. ---> System.NullReferenceException: Object reference not set to an instance of an object
[snip]
[11/27/2024 9:57:43 AM] Attempting direct connection to server. [192.168.2.189:1803]
[11/27/2024 9:58:10 AM] Network setup cancelled by user.


Ruling out network issues:

laptop-side, I can send UDP packets on port 1802 on the server:
g
lenn@MacBookPro ~ % sudo nc -n -4 -v -u 192.168.2.2 1802
Connection to 192.168.2.2 port 1802 [udp/*] succeeded!
blah blah blah
c^C
glenn@MacBookPro ~ %

Server-side, I can receive those UDP packets on port 1802
glennbutcher@server ~/SmiteWorks/Fantasy Grounds % sudo nc -n -v -4 -u -l 1802
XXXXblah blah blah
^C
glennbutcher@server ~/SmiteWorks/Fantasy Grounds %


Laptop side packet capture, showing the above packets:

glenn@MacBookPro Fantasy Grounds % sudo tcpdump -nn -vv udp and host 192.168.2.2
Password:
tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Apple DLT_PKTAP), snapshot length 524288 bytes
09:28:18.381918 IP (tos 0x0, ttl 255, id 54396, offset 0, flags [none], proto UDP (17), length 428)
192.168.2.2.5353 > 224.0.0.251.5353: [udp sum ok] 0*- [0q] 2/0/7 GlennM-bM-^@M-^Ys Mac mini._device-info._tcp.local. TXT "model=Mac14,3" "osxvers=24" "icolor=0", _companion-link._tcp.local. PTR GlennM-bM-^@M-^Ys Mac mini._companion-link._tcp.local. ar: FundWA-mini.local. (Cache flush) AAAA fe80::8e1:9f99:31b:c82a, FundWA-mini.local. (Cache flush) AAAA 2403:580e:80d2:20:18cd:5648:e5eb:d92e, FundWA-mini.local. (Cache flush) A 192.168.2.2, GlennM-bM-^@M-^Ys Mac mini._companion-link._tcp.local. (Cache flush) TXT "rpBA=A6:C7:2E:09:61:FD" "rpAD=6ec5f22b7d89" "rpFl=0x20000" "rpHN=334b36e5f9c2" "rpMac=0" "rpVr=610.71.1", GlennM-bM-^@M-^Ys Mac mini._companion-link._tcp.local. (Cache flush) SRV FundWA-mini.local.:49192 0 0, FundWA-mini.local. (Cache flush) NSEC, GlennM-bM-^@M-^Ys Mac mini._companion-link._tcp.local. (Cache flush) NSEC (400)
09:28:18.751709 IP (tos 0x0, ttl 64, id 50763, offset 0, flags [none], proto UDP (17), length 43)
192.168.2.189.56040 > 192.168.2.2.1802: [udp sum ok] UDP, length 15
09:28:19.547283 IP (tos 0x0, ttl 64, id 57621, offset 0, flags [none], proto UDP (17), length 29)
192.168.2.189.56040 > 192.168.2.2.1802: [udp sum ok] UDP, length 1
^C
3 packets captured
2350 packets received by filter
0 packets dropped by kernel


Server side packet capture:

glennbutcher@server ~/SmiteWorks/Fantasy Grounds % sudo tcpdump -nn udp and host 192.168.2.189
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), snapshot length 524288 bytes
09:28:16.759832 IP 192.168.2.189.56712 > 233.89.188.1.10001: UDP, length 4
09:28:16.760013 IP 192.168.2.189.56712 > 233.89.188.1.10001: UDP, length 4
09:28:16.760112 IP 192.168.2.189.59593 > 255.255.255.255.10001: UDP, length 4
09:28:16.760160 IP 192.168.2.189.59593 > 255.255.255.255.10001: UDP, length 4
09:28:16.871907 IP 192.168.2.189.59593 > 255.255.255.255.10001: UDP, length 4
09:28:16.872014 IP 192.168.2.189.59593 > 255.255.255.255.10001: UDP, length 4
09:28:18.576758 IP 192.168.2.189.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/7 PTR MacBook Pro 2022._companion-link._tcp.local., TXT "model=MacBookPro18,3" "osxvers=24" "icolor=2" (444)
09:28:18.721035 IP 192.168.2.189.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/7 PTR MacBook Pro 2022._companion-link._tcp.local., TXT "model=MacBookPro18,3" "osxvers=24" "icolor=2" (444)
09:28:18.770779 IP 192.168.2.189.56040 > 192.168.2.2.1802: UDP, length 15
09:28:19.564598 IP 192.168.2.189.56040 > 192.168.2.2.1802: UDP, length 1
09:28:21.760239 IP 192.168.2.189.56712 > 233.89.188.1.10001: UDP, length 4
09:28:21.760846 IP 192.168.2.189.56712 > 233.89.188.1.10001: UDP, length 4
09:28:21.760989 IP 192.168.2.189.59593 > 255.255.255.255.10001: UDP, length 4
09:28:21.761687 IP 192.168.2.189.59593 > 255.255.255.255.10001: UDP, length 4
09:28:21.787289 IP 192.168.2.189.59593 > 255.255.255.255.10001: UDP, length 4
09:28:21.787294 IP 192.168.2.189.59593 > 255.255.255.255.10001: UDP, length 4
09:28:22.551545 IP 192.168.2.189.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/1 (Cache flush) TXT "rpMac=0" "rpHN=70153d169370" "rpFl=0x20000" "rpHA=2237e3c5a93c" "rpVr=610.71.1" "rpAD=cb1f998d9221" "rpHI=c7128af1067c" "rpBA=12:E6:40:E2:3E:83" (218)
^C
17 packets captured
690 packets received by filter
0 packets dropped by kernel
glennbutcher@server ~/SmiteWorks/Fantasy Grounds %

So, I can send UDP packets to port 1802 and receive them, so nothing is filtering on the network layer. However, previous experimentation showed that using Ethernet on the laptop works, so there is _some_ network involvement. it could be application or network stack on the devices though, rather than something in the middle.

Checking for application firewalls
On each host the firewall is disabled and Fantasy Grounds is set as allowed anyway.


glenn@MacBookPro Fantasy Grounds % sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps
Total number of apps = 16
[snip]
14 : unity.SmiteWorks.Fantasy Grounds
(Allow incoming connections)
glenn@MacBookPro Fantasy Grounds % sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
Firewall is disabled. (State = 0)

It wasn't permitted on the server, but the firewall was off, so I added it just in case. No joy.

glennbutcher@server ~/SmiteWorks/Fantasy Grounds % sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
Firewall is disabled. (State = 0)

glennbutcher@server ~/SmiteWorks/Fantasy Grounds glennbutcher@FundWA-mini Fantasy Grounds % sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getappblocked /Applications/SmiteWorks/Fantasy\ Grounds/FantasyGrounds.app/Contents/MacOS/Fantasy\ Grounds
Incoming connection to /Applications/SmiteWorks/Fantasy Grounds/FantasyGrounds.app/Contents/MacOS/Fantasy Grounds is permitted.

[Trenloe]

Thanks for the logs, but I can't make sense of them. server-working-console.log appears to be the same as server-notworking-console.log (except for the last two lines). And all of the network logs aren't showing anything - there should be a lot more in these logs. Some of these logs also show connections on port 1803 - I can see you've used 1803 at some point in your previous post, but I can't work out which server/client log ties together. The server logs also show attempted client connections. So, I'm very confused and I don't think I can make head-nor-tail of these, sorry. Can you provide the full logs (console and network) for one successful connection attempt and one failed attempt. Close down FG completely after each so that the logs don't show multiple attempts as the logs are only newly created after a restart of FG.

[kasin]

I've attached clean logs:
* FG-server-notworking-console.log
* FG-client-notworking-network.log
* FG-server-betterworking-console.log
* FG-client-betterworking-network.log
* FG-server-working-console.log
* FG-client-working-network.log

I called it "betterworking" because it still wasn't working but showed an unable to authorise error.

It works if I put them on different subnets. I can see no reason why so I must be missing something.

[damned]

If you run a simple web server on the server computer can you successfully browse to it when the server is in VLAN2?
this is to try and work out if its likely to be application or network related.

is it possible that you have duplicate IP addresses on the network?

[kasin]

Yes, I can run a simple server and see it between VLANS. I can even send UDP packets on port 1802 and see the contents of those packets arriving at the other end. That is what makes it so puzzling. it only affects FG and nothing else. Not even other UDP packets on the same port.

Here is an example of a simple web connection between the two machines.

On the same subnet

glenn@MacBookPro % python3 -m http.server 8000
Serving HTTP on :: port 8000 (http://[::]:8000/) ...
::ffff:192.168.2.2 - - [27/Nov/2024 19:14:09] "GET / HTTP/1.1" 200 -

glennbutcher@-mini % curl 192.168.2.194:8000
<body>
it works
</body>

On different subnets
glenn@MacBookPro html % python3 -m http.server 8000
Serving HTTP on :: port 8000 (http://[::]:8000/) ...
::ffff:192.168.2.2 - - [27/Nov/2024 19:15:57] "GET / HTTP/1.1" 200 -

glennbutcher@mini % curl 192.168.1.226:8000
<body>
it works
</body>


No sign of duplicate IPs, and the mac address in the routing table matches the mac address of the other adapter, and vice versa, so it should be working.

At this point I have a workable solution - run FG on a machine on a different subnet - but it is doing my head in why it isn't working.

[Trenloe]

I called it "betterworking" because it still wasn't working but showed an unable to authorize error.
When an unlicensed (free) copy of FG connects to an ultimate license, the free copy connects to the FG servers to verify the ultimate license key is valid. As you're getting an "Authorization failed: The host is running an unauthorized copy, or authorization server is down." message, this means that the client can't connect to the FG servers over the Internet. EDIT: At least this shows that the client has connected to the GM server, but then couldn't connect to the Internet to verify the license.

I'm also seeing warnings in the console log files:


[11/27/2024 5:41:31 PM] [WARNING] URL: System.TypeInitializationException: The type initializer for 'System.Net.ServicePointManager' threw an exception. ---> System.InvalidOperationException: ConfigurationSectionGroup cannot be edited until it is added to a Configuration instance as its descendant
at System.Configuration.ConfigurationSectionGroup.get _Config () [0x00008] in <0dcc25d41af0447f9006c56a874ad635>:0
at System.Configuration.ConfigurationSectionGroup.get _SectionGroups () [0x00008] in <0dcc25d41af0447f9006c56a874ad635>:0
at System.Configuration.Configuration.get_SectionGrou ps () [0x00006] in <0dcc25d41af0447f9006c56a874ad635>:0
at System.Configuration.Configuration.GetSection (System.String sectionName) [0x0001f] in <0dcc25d41af0447f9006c56a874ad635>:0
at System.Configuration.ClientConfigurationSystem.Sys tem.Configuration.Internal.IInternalConfigSystem.G etSection (System.String configKey) [0x00006] in <0dcc25d41af0447f9006c56a874ad635>:0
at System.Configuration.ConfigurationManager.GetSecti on (System.String sectionName) [0x00005] in <0dcc25d41af0447f9006c56a874ad635>:0
at System.Net.ServicePointManager..cctor () [0x0003c] in <9be5d760d8204c7dbc66320fdd824250>:0
--- End of inner exception stack trace ---
at DNKANPKCFCP.POJNOGLMBNK (System.String CPIBLICGLPL, System.String OFGEABBADGD) [0x0000e] in <cccd955d11354130ba3623f8eb7618cc>:0
at DNKANPKCFCP.POJNOGLMBNK (System.String CPIBLICGLPL, System.String OFGEABBADGD) [0x0000e] in <cccd955d11354130ba3623f8eb7618cc>:0

I don't know if this is causing your issues, as I'm not familiar with this error related to FG, but it's a .NET library. You could try uninstalling and reinstalling the .NET libraries on this MAC. Information on that here: https://learn.microsoft.com/en-us/dotnet/core/install/macos

[TVDinner]

Some snips:


Vlan 1: 192.168.1.0/24
Vlan 2: 192.168.2.0/24
Vlan 3: 192.168.3.0/24
vlan 4: 192.168.4.0/24

I have found that it works if I either:
1. Plug it into ethernet. I didn't check with vlan it was on.
1. FG works vlan 2 -> vlan 1, but not vlan 2 -> vlan 2, or vlan 1 -> vlan 2. So there is something funky happening about vlan 2.


and



The server has 192.168.2.2 on the ethernet interface and 192.168.2.72 on the wifi interface


I'm a bit out of my league with vlans, but something about this setup bothers me. If I'm a server with two network interfaces both bound to 192.168.2 host addresses trying to send a UDP packet to another host on the 192.168.2 network, which interface should I use to send the packet? Unless I'm way out of date (which wouldn't surprise me), the server is going to pick the first interface in the routing table. I'd expect vlan 2 -> vlan 1 to work since that'll get the default route which presumably is the AP which is the correct gateway. For any case with vlan 2 as the destination, the packet may not get sent on the right interface. Any third party machine which gets a UDP packet from a host on a given network to another host on that same network is allowed to drop the packet, since the origin host should have sent it correctly in the first place. There should be an ICMP redirect sent back, but that-a-way lies network storms and I'm not sure what that would mean with vlans anyway besides I'm out of my depth. That redirect may never be sent.

This sort of problem is solved by host routes, but I'd never try to bridge an ethernet with wifi. It should work with vlans, but I'm on pretty good terms with my buddy Murphy.

And there's going to be two sets of firewall rules that FGU would need to configure, one for each interface, and that's probably not happening, unless there's a separate rule set for each vlan....

Okay, I'll shut up about vlans now. The theory does fit the observed behavior though.

[TVDinner]

The not working server console log shows:

[11/27/2024 5:41:22 PM] Starting private server mode. [(100.71.138.64:1802) (fe80::60ff:34ba:8df1:2202%22:1802)]

The better working server console log shows:

[11/27/2024 5:47:42 PM] Starting private server mode. [(100.71.138.64:1802) (fe80::60ff:34ba:8df1:2202%22:1802)]

The working server console log shows:

[11/27/2024 5:58:40 PM] Starting private server mode. [(192.168.1.226:1802) (fe80::ce81:b1c:bd2c:69e%21:1802)]

------

Yeah, the 100.71.138.X addresses won't work from pretty much anywhere except inside your ISP.

[damned]

The 100. IP Addresses are not useable on the Internet they are a special range of IPs for ISP use only.
However the 192. IP addresses are also not useable on the internet...

I would still eliminate that range - it is intended for ISPs and their Upstream provider use only.

[damned]

In regards to TVDinners other post about 2 interfaces on the same network I dont know how it works on a Mac but on Windows if two interfaces otherwise share same routes and priority the most recently connected interface will get higher priority. I normally would not stress over this as TCP traffic is connection oriented so it should continue to back and forth on the correct interfaces. As UDP is connectionless maybe this can cause some conflict?

In regards to the web server test it is a small amount of data only that you are testing Can you do it with more data (web page with multiple images or includes) because the small amount you have there would not trigger any sort of UDP flooding if that is what is happening. I think the network setup is a better focus of your time though.

[kasin]

The 100.X could be the clue. That 100.X range is a private VPN. Possibly the return UDP packets are being sent out a different route than the input UDP packets. Why this is only happening to FG and not other applications isn't clear. lsof shows FG is binding to the wildcard and not binding to a specific IP address.

UDP 192.168.2.226 -> 192.168.2.2 with netcat works
UDP 192.168.2.2 -> 192.168.2.226 with netcat works
UDP 192.168.2.226 <-> 192.168.2.2 with FG doesn't work, possibly because it is trying to send it down the 100.X route.

The system route table doesn't reflect this, so I am not sure why it is trying to route those packets down that interface, but it does fit the observed data. Possibly it is related to the .et crash. I'll try it without the VPN running while on the same VLAN to confirm.

That .net crash is also interesting and I'll try updating the .net libraries, as per the suggestion.

I'll also try sending larger amounts of data via UDP to check for UDP flood protection.

[TVDinner]

When you hit the "Load Campaign" button the address FGU is binding to is in the box on the lower right, along with the external address. If the bound address is anything other than 192.168.2.x, things probably won't work. Binding to the 100.71.x.x address should not work.

Once you fix the binding address problem, I'd still get rid of the loop in the 192.168.2 network. I presume FG licensed a network library that handles the connections over UDP, and who knows exactly how that works.

[TVDinner]

I'm not sure the "other applications" are trying to establish a connection over UDP. I think netcat just blasts packets out and you count them on the other end. You really want something that sends packets, and then listens for the other end to send the packets back.

[kasin]

After a long absence I am posting as I believe I found the issue.

Mac OS sequoia introduced a new permission called local network access. Applications using certain API's trigger an OS prompt to give the application permission to access resources on the same subnet. However, it seems somewhat buggy. In particular it can mistake which is the correct application and trigger the prompt for the wrong application. For me, I had "humankind" pop up when fantasy grounds launched which was a critical clue.

This was so difficult to troubleshoot as packet captures showed everything was fine, because it was an issue at a layer of abstraction above the level of the packet capture. All of my manual testing was from the terminal which is automatucally granted this perission, so it always works. This drove me nuts for month!

Steps to troubleshoot:
1. On the Mac check system settings -> privacy and security. Fantay grounds should be listed. If it is listed, turn on local network access. If it is alredy turned on, try turning the permission off and on again. For me it is not listed as it has either not asked for the permission correctly, or Mac OS has it confused with another piece of software such as other unity based software.

Workarounds:
1. Connect from a different network. If you are network savvy, create a different subnet.
For me, I have a guest WIFI network which is on a different subnet (192.168.3.0/24 vs the server which was on 192.168.1.0/24) and that was sufficient.

2. Alternatively, launch fantasy grounds from the terminal. Launch the terminal and launch FG with: /Applications/SmiteWorks/Fantasy\ Grounds/FantasyGrounds.app/Contents/MacOS/Fantasy\ Grounds
I can't check this because I did the below step, but it should work as applications launched from the terminal inherit the terminal's permissions.

3. Resetting the entire privacy and seceutiy subsystem.
WARNING: I haven't tried to do this myself, but the docs reference doing so. It will delete your otehr privacy and security settings.
Alternatively, if you don’t want to delete your app for some reason, reset the entire privacy subsystem using Settings > General > Transfer or Reset > Reset > Reset Location & Privacy.
https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy

4. Reinstall OS. I ended up doing this. It was pretty painless on my M1 pro laptop and I barely noticed any difference after reinstalling. This seems to have permanently fixed the problem.

5. I did try looking into how Mac OS stores this permissiom, but there is limited documentation on it and no API access, whie the raw databases are protected (system integrity protected) so I just gave up and reinstalled.

[TVDinner]

Thank you for making the solution that worked for you available to the search engines and the various humans who try to help out. I'm sure someone else will find this helpful in the future.

[jkusters]

Amazing work. Assuming this is the actual issue, Smiteworks will need to add the appropriate entitlement to the app and send out updates.


4. Reinstall OS. I ended up doing this. It was pretty painless on my M1 pro laptop and I barely noticed any difference after reinstalling. This seems to have permanently fixed the problem.

How did you do this? Non-destructively from the macOS Recovery boot up option? Or did you wipe the machine and reinstall from there? I'm hoping the former.

[Morenu]

Mac is one of the easiest reinstalls I have done... been a few years, but plenty of YT videos on it

[jkusters]

Believe me, I’m very familiar with reinstalling macOS in many ways, some pretty benign, some very destructive. I tried the most benign way, and unfortunately it didn’t work for me. I’m not up for a full wipe and restore at this time, so I’m investigating alternative VTTs until the actual issue is addressed.

[kasin]

Amazing work. Assuming this is the actual issue, Smiteworks will need to add the appropriate entitlement to the app and send out updates.

How did you do this? Non-destructively from the macOS Recovery boot up option? Or did you wipe the machine and reinstall from there? I'm hoping the former.

I suspect they do as fantasy grounds works fine on a different Mac.

Non-destructively from the recovery boot up option.
https://www.lifewire.com/restart-a-mac-into-recovery-mode-5184142

[shellbackrob]

That worked out perfectly...just needed to set the correct accessibility and things were good to go! Thank you for the post/guidance - very helpful!