[Found work-around] Cannot connect to Archipelago host under Arch Linux x64

[ChargedNeon]

Tried to connect to the Archipelago server using Poptracker with correct port information (archipelago.gg:00000, zeroes as placeholders for room port number).

Running Arch Linux, x64-bit only, with latest updates. Desktop environment is GNOME Wayland. Additionally installed dependencies as per BUILD.md (in the event installation would resolve problems).

This is reproducible using Poptracker v0.30.4, either as an AppImage or extracted and executed from the Ubuntu tar file. This was tested using both A Short Hike's pack, and Pokemon Emerald's pack.

Using A Short Hike's tracker, attempted to connect to Archipelago server. After entering host and port, messages in console show:

APClient: Connect timed out. Retrying.
wswrap: exception during close: invalid state
FPS:  78 (max 2025ms)
[2025-03-15 11:07:39] [error] handle_connect error: Timer Expired
APClient: Reconnecting to server
[2025-03-15 11:07:45] [error] handle_connect error: Timer Expired
APClient: Reconnecting to server

The client never reconnects to the server.

[ChargedNeon]

I believe this issue has happened before 0.30.4. From memory, I originally found this issue ~0.29, but I didn't create a GitHub account at that point.

Please let me know if you would like me to perform any testing of builds.

[black-sliver]

Are you sure the room is up? (I.e. press F5 on the room page, wait a few seconds and double-check the port number hasn't changed)

Can you try to prepend wss://, so wss://archipelago.gg:00000, which should make the log/stdout cleaner, and repost that stdout?

[ChargedNeon]

To test, I tried setting up a new room. I also appended wss://, but I'm not sure that changed any output. Here is the entire stdout of the program:

New room: https://archipelago.gg/room/sb3gOwY5SsmBRgN2mz3aHw (doesn't use any password)

[~/Downloads/Archipelago/PopTracker/poptracker]$ ./poptracker 
PopTracker 0.30.4
Ui: Init SDL 2.32.52...
Ui: Available renderers: opengl (hw), opengles2 (hw), vulkan (hw), gpu (hw), software
Creating renderer ... opengl
Loading font ...
Loading small font ...
First render(957,592)
Loading Tracker /home/cn/PopTracker/packs/shorthike-archipelago-poptracker-1.1.1.zip:tall!
Cleaning up...
Loading Pack...
Target PopTracker version: 0.30.4 (undefined/latest)
Selecting Variant...
Creating Lua State...
Loading Lua libs...
Loading Tracker...
Registering in Lua...
Creating Script Host...
Registering in Lua...
Creating Archipelago Interface...
Registering in Lua...
Registering classes in Lua...
Hooking Lua globals...
Restoring window size 957x592
Resizing... (957,592)
Updating UI
update state of : ""
Running init...
Loading "scripts/init.lua" ...
Debug logging is enabled!
Loading "scripts/utils.lua" ...
Loading "scripts/layouts.lua" ...
Loading layouts from "layouts/settings_popup.json"...
Loading maps from "maps/maps_tall.json"...
Loading locations from "locations/locations_tall.json"...
Loading layouts from "layouts/broadcast.json"...
Loading layouts from "layouts/tracker.json"...
Loading "scripts/logic/logic.lua" ...
Loading "scripts/custom_items/class.lua" ...
Loading "scripts/custom_items/progressiveTogglePlus.lua" ...
Loading "scripts/custom_items/progressiveTogglePlusWrapper.lua" ...
Loading items from "items/items.json"...
Loading layouts from "layouts/items_standard.json"...
Loading "scripts/autotracking.lua" ...

Active Auto-Tracker Configuration
---------------------------------------------------------------------
Enable Item Tracking:        	true
Enable Location Tracking:    	true
Enable Debug Logging:        	true
Enable AP Debug Logging:        	true
Enable SNES Debug Logging:        	true
---------------------------------------------------------------------

Loading "scripts/autotracking/archipelago.lua" ...
Loading "scripts/autotracking/item_mapping.lua" ...
Loading "scripts/autotracking/location_mapping.lua" ...
Saving state "reset" to RAM...
Loading state "autosave" from file /home/cn/Downloads/Archipelago/PopTracker/poptracker/.portable-config/PopTracker/saves/shorthike_chandler/1.1.1/tall/autosave.json...
ok
PackManager: Checking for update for shorthike_chandler
HTTP: connecting via https to raw.githubusercontent.com  for /black-sliver/PopTracker/packlist/community-packs.json
Tracker loaded!
adding label #0 "AP"
FPS:   0 (max 5072ms)
0
0
0
5
2
3
1
3
1
2
1
7
First render(957,592)
Resizing... (957,592)
Added 10 packs from https://raw.githubusercontent.com/black-sliver/PopTracker/packlist/community-packs.json
Nowhere to check for updates of shorthike_chandler
FPS:  17 (max 7997ms)
APClient: Connect timed out. Retrying.
wswrap: exception during close: invalid state
FPS:  79 (max 2032ms)
[2025-03-15 13:38:51] [error] handle_connect error: Timer Expired
APClient: Reconnecting to server
[2025-03-15 13:38:57] [error] handle_connect error: Timer Expired
APClient: Reconnecting to server
[2025-03-15 13:39:09] [error] handle_connect error: Timer Expired

[black-sliver]

Adding wss:// just makes sure that each connection attempt is encrypted (removes failed attempts that won't work anyway).

[2025-03-15 13:38:51] [error] handle_connect error: Timer Expired this points to the websocket handshake timing out, which is odd.
I can definitely connect to rooms on archipelago.gg on Arch Linux using the 0.30.4 AppImage.

Do you see any connection attempt in the room log?
Do you have any special network setup?
Have you tried connecting to the room with a different local client on the same machine and/or an in-browser client (such as evermizer.com/textclient )?
Have you tried hosting locally and connecting to that? (i.e. starting Archipelago Launcher on the PC, Generating a game and then running "Host" for the generated game and connecting to "localhost" in Poptracker)

[black-sliver]

I do see one concerning thing in the log. It looks like the first attempt is timing out "correctly" and then the following attempts fail too quickly - probably because the shutdown was not clean.
I don't think fixing that would solve the problem though since the first attempt should already work.

[ChargedNeon]

I've managed to resolve the problem.

Turns out, I had configured my local network's DNS routing to go to Google's DNS servers (8.8.8.8, 8.8.4.4). At some point, my ISP's DNS servers went down, so I switched it to Google's DNS servers. Changing the DNS server settings back to the ISPs fixed the issue. I guess it may be down to IPv6 being used, but I'm not 100% sure.

Thank you for the assistance, and apologies for time-wasting. I will close this issue, unless it is valuable to keep this issue open?

If the wait timeouts are still a problem, I guess raising a separate issue would be better than tracking it here.

[black-sliver]

I think the biggest problem is that the actual error is not visible (whatever it is).

I think we should probably add more error logging. Currently the DNS resolution is a black box in the code, so could be that.

I'll leave this open for now as a reminder and close this if/when I created a new issue (or PR) with a concrete idea/plan.