LAN Connection Issues; Internet Works; Logging Issue [SOLVED]

[coffeejoshua]

Support/Dev Team,

First, thank you for making this awesome software!

I know there are many posts like this, but I can connect to games on the internet just fine, but can't connect to each other on the same subnet.
I've attached 6 files, but please let me know if I have configured it incorrectly or if there is something more useful to help you debug this.

Game setup:

Code: Select all

Options > Settings > Game Port
Port set (below) on both computers and "Use UPnP" is unchecked (is disabled on router).


Network setup:

Code: Select all

192.168.168.1 - Router
192.168.1.94 - Emily - Port 5125 - Host
192.168.1.186 - Jade - Port 5724 - Join


Networking notes:

* UPnP disabled on router.
* I used netstat -na | findstr <port> to verify FAF listening on above ports for both endpoints.
* I used wireshark with capture filter "udp port 5125 and port 5724" on both endpoints. Should I have captured more?
* Clear the logs and start the capture on both endpoints, launch the game, host on Emily, join on Jade. Leave at "connecting" on Join for about 100 packets.
* Click cancel button on Join and leave to lobby on host.
* Stop capture, grab logs (both attached)
* Another note: If you need a pcap from the router I can install tcpdump on this ASUS RT-AC66R if needed, but would like to avoid this if possible.

PCAP observations:
I can't read the data, is there any way to decompress/decode/decrypt this? I think they are stuck in an infinite loop.

* Host and join are sending and receiving data both directly to each other on subnet, and to the gateway which is rewritten WAN IP.
* I could be wrong, but this looks like an application issue to me, not a networking issue.

In host side log (emily):

Code: Select all

2017-12-17 12:35:50,360 INFO     client.connection              Outgoing JSON Message: {"command": "game_host", "title": "Pandaman32", "mod": "faf", "visibility": "public", "mapname": "x1ca_coop_002.v0017", "password": "test", "is_rehost": false}
2017-12-17 12:35:50,583 ERROR    client._clientwindow           Not ready for game launch


In join side log (jade):

Code: Select all

2017-12-17 12:36:13,575 INFO     client.connection              Outgoing JSON Message: {"command": "game_join", "uid": 7201862, "gameport": 5724, "password": "test"}
2017-12-17 12:36:13,825 ERROR    client._clientwindow           Not ready for game launch


Edit: logging "bug" removed, this is an enhancement request, not a bug. Details in comments.

Thanks for looking at this issue!

[PhilipJFry]

if you just wanna play a LAN game 1v1 and it doesn't work via FAF then i recommend you start the game offline via the EXE file located in C:\ProgramData\FAForever\bin and use the Multiplayer-LAN mode to connect to each other directly

[coffeejoshua]

@PhilipJFry, thanks for your reply. We did do this successfully, but we would like to play coop campaign and also would like to get a 3rd person from the internet to join in the future. This doesn't have all the same features as the FAF clinet, right?

I saw in other posts on the forums that someone else with this problem used a VPN to connect on one computer. I will try this. Ideally though we could get this bug fixed as i'm sure a lot of people out there would like a LAN + Online play feature.

[PhilipJFry]

the thing is that the netcode that faf uses kinda sucks at connecting several people who are in the same local network - you could try using a VPN to circumvent that
also not sure about your setup locally (do you have a /16 subnet mask or a more complicated network?)

[coffeejoshua]

It is a standard /24 subnet 192.168.168.x. I am reviewing the python now and my above claim that there is a bug in the error logging logic is incorrect (I will edit it if I can). There is still additional logging enhancement request to be desired here, though. It is in the game launch function:

Code: Select all

def handle_game_launch(self, message):
        if not self.game_session or not self.connectivity.is_ready:
            logger.error("Not ready for game launch")


That is the error in the logs, but why is there not self.game_session or self.connectivity.is_ready? Which of the two is the problem? It would be nice on debug to print everything you can so that we might see the exact problem.

I suspect my ASUS router is rewriting the packets all stupidly (I've been meaning to get something better), but I don't know if this is just me because there are lot of posts about this issue (with no real solution other than the VPN workaround). Do you know of a network where scenario does work as expected?

Did you get a chance to look at those pcaps? It seems they are running 2 streams at the same time, one with WAN IP and one with LAN IP. It also looks like they're stuck transmitting the same data over and over, but without being able to decrypt it I don't really know what is happening.

[PhilipJFry]

sorry i don't know enough about networking to actually look at that data and judge it
i was just wondering why you have your router on 192.168.168.x and your machines are in 192.168.1.x which is in a different subnet which makes the network overly complicated imho

[coffeejoshua]

Sorry, that is a typo! It is all in a single subnet 192.168.1.x and no special routes or anything fancy is in use .

I found some things that are interesting, but I don't know enough about how the networking is designed with this to be very useful. I checked the code on git and can follow along with other things, but the netcode is really complicated for me! There is a connectivity relay feature that I haven't figured out yet, too. I'll keep looking at it and scratching my head for a while. On another note I wish it was possible for me to add some logging without having to build it, I will try and get a dev environment setup later.

If you open the pcaps in wireshark you will see that UDP is very easy to understand , and only about 100 packets to deal with.

* The first packet is sent from the Host to the Join computer, which is backwards from most client server models (why doesn't the client send the first packet to the server?).
* Warning: I could be wrong about any of this stuff!
* This means they must have got information about each other on another port from FAF servers, maybe TCP, that is not in the pcaps.
* The actual data they send is not readable!
* Both host and join try to connect on WAN IP initially (seems reasonable to me, this assumes you're on the internet).
* In subsequent comms the router rewrites WAN IP to LAN IP.
* They continue to talk now confused with both LAN and WAN in 2 streams, and even though it's possible to reach each other using either method the application is confused.

Does anyone have an environment using this scenario that works? I'm trying to isolate if the problem is my ASUS router (with NAT and Firewall lumped into one feature), or with the python.

[Sprouto]

Even with complicated port forwarding, I've historically had the same connection issues you've described. I was never able to fully circumvent them other than resorting to a VPN.

I have, and continue to use, both Hamachi and Tuungle with great results. Hamachi in particular is especially stable, seamless and easy to use.

[PhilipJFry]

we hope that we'll finally be able to get rid of these issues with the ICE adapter
unfortunately there are some technical issues present (the adapter likes to crash sometimes) and we need some c++ coders/time to help fixing some last bugs before we can roll it out

[coffeejoshua]

Sorry to bump this thread but I wanted to post a workaround that we discovered that doesn't involve using a VPN.

Simply misconfigure your router/firewall to incorrectly send the traffic nowhere or filter the traffic (by setting the right port to a computer that doesn't exist for example). To do this, we set both computers to use the same port, have use UPNP enabled (although it's disabled on the router), and then configured the router to drop all traffic on that port (if you can't do this, configure it to send it to a nonexistent device).

This way they are unable to communicate on the LAN, and when that fails they will use the online proxy server instead.