KleiAccount / KleiMetrics disabled due to "An address incompatible with the requested protocol was used"

Anything unusual with your network, e.g. being IPv6-only? Unfortunately the error is lacking in detail but it seems to suggest unity's not able to make an outbound HTTPS connection to Klei's servers. Are you able to connect to our servers directly with curl from the command line? 

curl https://login.kleientertainment.com/HealthCheck  ; echo  # echo because otherwise you'll be lacking a newline and your shell will be ugly

should return the hostname of the specific login server you happen to be talking to at that moment. Anything other than a hostname ending in klei.ca and you've got a more fundamental problem on your network because even curl can't talk to our servers.

Let us know, hope this helps!

8 hours ago, nome said:

Anything unusual with your network, e.g. being IPv6-only? Unfortunately the error is lacking in detail but it seems to suggest unity's not able to make an outbound HTTPS connection to Klei's servers. Are you able to connect to our servers directly with curl from the command line? 

curl https://login.kleientertainment.com/HealthCheck  ; echo  # echo because otherwise you'll be lacking a newline and your shell will be ugly

should return the hostname of the specific login server you happen to be talking to at that moment. Anything other than a hostname ending in klei.ca and you've got a more fundamental problem on your network because even curl can't talk to our servers.

Let us know, hope this helps!

Re: "Anything unusual with your network, e.g. being IPv6-only?" It is actually IPv4 only. IPv6 is disabled. Perhaps unity it attempting outbound https on an IPv6 address first without falling back to IPv4?

 

```

$ curl https://login.kleientertainment.com/HealthCheck ; echo
login-standalone-alb-prod-crisp-ostrich.us-east-1b.klei.ca

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 4c:cc:6a:f5:31:38 brd ff:ff:ff:ff:ff:ff
    altname enp33s0
    inet 10.26.1.108/24 brd 10.26.1.255 scope global dynamic eno1
       valid_lft 36003sec preferred_lft 36003sec
3: wlp36s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a0:f3:c1:32:43:05 brd ff:ff:ff:ff:ff:ff
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 7a:39:f6:b2:df:1f brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
5: vmnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 00:50:56:c0:00:01 brd ff:ff:ff:ff:ff:ff
    inet 172.16.18.1/24 brd 172.16.18.255 scope global vmnet1
       valid_lft forever preferred_lft forever
6: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 00:50:56:c0:00:08 brd ff:ff:ff:ff:ff:ff
    inet 172.16.104.1/24 brd 172.16.104.255 scope global vmnet8
       valid_lft forever preferred_lft forever

```

Happy Eyeballs dictates that making the IPv6 connection first is the "right" thing to do, so maybe they have a naive implementation that errors out if IPv6 is disabled instead of falling back to IPv4 properly? It's funny, back in the day it was certainly the case that disabling IPv6 could cover up bugs but these days it actually seems to make things worse more often than not. I was just helping a coworker a few weeks ago with a case of a non-Klei game that only worked on machines that had IPv6 enabled.