Hello there, maybe its the wrong Subforum, please move it to the preferred location.

FYI: This post ignores the DDOS attacks and faulty/shitty internet connections.

I have read through a few technical issue posts concerning disconnects and read through the logs.

A Few things that came to my attention

1. the vast majority are drops of the UDP/RTP Session to a single or a number of players

2. the ICE Client seems to utilize the full range of the High-Port spectrum

3. The ice advanced log is not detailed enough.

Now, I don’t pretend to understand the ICE Client, but as someone handling complex PBX (Telephony / SIP) Systems which also are based on RTP Sessions I can see a lot of similar issues here.

1. Since we can clearly see a successfully established RTP Session, which fails later on, we can assume that the firewall configuration is ok on all involved sides.

At one point or another we all have experienced the issue where we called some hotline, and got kicked out mid-call, or specialy when we are put on hold without waiting music being played.
This is considered inactivity for the RTP Session. Which can result in a timeout. I tend to believe that this is very similar to what happens to the RTP Sessions between players.
RTP Sessions drop by design when there is not enough noise on the line for defined period of time.

The PBX Admin can mitigate this issue by allowing much longer timeout periods or adding waiting music ← No shit.
I think this is something worth looking into from DEV side.

2. RTP-Sessions are a XXX, a nightmare for anyone with a well tuned Firewall.
   To avoid health issues of the security admin, the PBX Admin usualy would limit the port range that RTP is allowed to utilize. 2.5X the factor of active sessions. E.G. lets assume we have a top of 2000 parallel players being active: We would allow 5000 RTP Ports. E.G. a predefined port range from 15000-20000. That's easier to manage and to document.

3. The ICE Log and the advanced ICE log only tell me that sessions are dropped. But I don’t see any reasons/error codes. Might be my eyesight though.

o/

I know this is a common issue, but I also doubt all the affected people use Pi-Hole or similar products in between their host and DNS Server.

However, this made me think that people with this issue reocurring, also could try changing their DNS Server as a step of troubleshooting. Especially those default DNS Servers from ISP's are not very....reliable.

Just a thought.

Hey, i found my issue to be my local DNS settings. I run a pi-hole installation that is connected to 9.9.9.9

I can understand that some players hostnames or parts of it (domain) end up on blocklists, but when turning off the filtering in pi-hole it does not resolve the issue. i have to totally bypass Pihole entirely. clients DNS 9.9.9.9 .

Just to be sure my pihole installation is not messed up, i installed a new one with default settings. Same issue.

So, no issue with FAF-Client, PC-Client, FAF Server or other FAF Players. just the Pi-Hole in the middle.

Hi folks,
it appears I have been the reason for a couple of failed matches recently… from a network perspective.

I am running it on relatively new mashine (7 months) with modern specs connected via 1 Gbit fibre-channel to the internet.
Permanent ping to 8.8.8.8 ranges from 3-6 ms. Zero drops or outliers.

What I have done to narrow down the issue:

ping from a rented internethost to my client (where I play FAF) during the game. Result: perfect
ping from my client (where I play FAF) to said internethost. Result: perfect.
Gone insane and disabled Firewall and AV during a match.
Had someone on my network play CS and observe the ping while I played a FAF match: Wife got killed a 100 times but had perfect ping during my match where I lost connection to all players.

Could someone point me to an other step to narrow down the issue? Maybe a certain logfile?

FAF is unfortunately the only Game that experiences issues on my rig

how did you solve it ? I did not play for weeks, just found this situation. Version 2023.3.0 Fresh installation.