XOA Failing on Check-in

olivierlambert

So it could be a peering issue in IPv6. On my side, no problem, where are you based?

acomav

@olivierlambert

I am in Australia.

Danp

Isn't this the same issue caused by the Node upgrade? https://github.com/nodejs/node/issues/54359

notr1ch created this issue in nodejs/node

closed Happy eyeballs implementation times out prematurely #54359

acomav

@Danp Interesting. That will be it. Thanks for linking this.
In the mean time, I've put in a request with the Australian government to move us closer to Europe.

HamiltonWDS

I can concur that I have had the same issue described above and have a fix for it as well.
XOA did work after deploying. But then after updating to the latest version "5.101.0 - XOA build: 20241004" and rebooted, Updates were no longer possible, along with some other minor things.

I applied the fix from the "Happy eyeballs implementation times out prematurely" link above by editing the "/etc/systemd/system/env" file.
Commands:

sudo nano /etc/systemd/system/env

Added in the NODE_OPTIONS line after the HOME line as shown below:

HOME=/tmp
NODE_OPTIONS='--network-family-autoselection-attempt-timeout=500'

WRITE (CTRL-C) and EXIT (CRTL-X)
Reboot XOA

olivierlambert

So it's the case in an IPv6 context I assume, right?

DustinB

@olivierlambert in my case I found an errant DNS setting that was configured before I worked here that was causing some issues, but this issue became obvious after some XOA update and was likely exacerbated.

After I fixed up my DNS issue, performance network wide has greatly improved, and XOA hasn't been reporting this specific issue.

olivierlambert

@julien-f what do you think?

HamiltonWDS

@olivierlambert said in XOA Failing on Check-in:

So it's the case in an IPv6 context I assume, right?

I think it is only the time out setting as the primary cause of the problem with IPv6 as a secondary cause.
I am also in Australia, and just using IPv4 to Ping the address that I am seeing XOA Updater use, takes about on average 320ms.
As from that "Happy eyeballs" link the initial message has, "Node tries to connect to the A address with only 250ms timeout, insufficient for many real-world cases (cellular/satellite links, poorly connected ISPs, far away servers, packet loss, etc). This times out, so node proceed to the last candidate which is supposed to have a longer timeout, however the last candidate is an AAAA address and the host has no IPv6 connectivity so it immediately fails"

So it seems that when timeout occurs for those networks outside of the 250ms range, Node then uses an IPv6 address. And for those using only IPv4 networks, well, the connection never occurs.

The resolution, but looks to not be implemented (by Node.js), would be for Node to have the last address to be IPv4, or at least have the last IPv4 address with the longer timeout.

olivierlambert

Thank you very much for the clear explanation @HamiltonWDS ! This will be really helpful so we find a solution for that. We might default to IPv4 for a lot higher latency, and in the future maybe having closer location mirrors. Let me discuss this internally and schedule an action for that.