Being bombarded with Server Errors, yet everything is fine

[FAAtheguy]

It happens everytime I’m not playing a mission. So, that means it occurs while I’m in the Keep, while connecting to the mission, while looking at post-game stats. A message suddenly pops up saying “There was a problem while connecting to the game servers. Please verify your internet connectivity or try again later”. Then the game sends me back to the Keep. Nothing happens afterwards. I can still play the game normally, well, until the next error.

What do I do? Playing on PC if that somehow helps.

[Fatshark_Hedge]

Steam Community :: Guide :: Исправление проблем с игрой. Запуск, краши,...

[FAAtheguy]

Damn, that did it. I even forgot there was this problem with Russia, thats really my bad. Thanks fro helping.

[EmpIzza]

@Fatshark_Hedge

A bit off-topic, but have you been in touch with PlayFab with regards to this issue? I.e. so they can actively ask for new instances if they get instances in the (Russia) banned IP-range.

Or is there something you can do at your side? AFAIK (by just looking at code, not testing, assuming you use the Lua SDK provided by PlayFab), the implementation of IPlayFabHttps.MakePlayFabApiCall seems to be responsible for the actual API-call. (see https://github.com/PlayFab/LuaSdk/blob/master/PlayFabClientSDK/PlayFab/IPlayFabHttps.lua for interface, which I’m assuming that you are using)

Should it not be possible to catch SSL-errors and force a try on all IP-addresses related to the FQDN? This would get a bit technical though, since you would have to separate the TCP connection, the TLS-handshake, and the HTTP-requests (remember that HTTP + TLS == HTTPS, they can be separated). And since you would ideally force a TCP-connection on an IP-address base rather than a FQDN, you would have to manually trust the CA (in this case the Amazon CA which the *.playfabapi.com certificate is anchored by).

This approach would get rid of the problem of trusting the naming and routing provision of the access-provider (i.e. ISP in most cases), which sometimes is necessary, without tunnelling or similar overhead or static setup of hosts files (i.e. forcing 5107.playfabapi.com to resolve to a specific non-blocked IP).

See http://notebook.kulchenko.com/programming/https-ssl-calls-with-lua-and-luasec for a basic example on how to separate IP-host from URL-host (Internet knowledge 101, the FQDN of the url in the http-request need not resolve to the IP-address of the server for a HTTP over TLS over TCP over IP connection to work…).

I.e.

• Write custom http(s) client capable of separating host and url
• Resolve all A-records for FQDN (ex by resty.dns.client)
• Trust amazon CA for IP-based TLS-connections (see https://www.amazontrust.com/repository/)
• Loop through all IPs.
• Use above as fallback when the first IP returned by the OS DNS resolved is not routable (i.e. using built-in LuaSec https-client).
• (ideally it would be possible to route everywhere, but for now that is not possible)