Hello Samuel, I found the explanation for why ::1 was timing out on this system.
During unrelated troubleshooting a couple of weeks ago, I had disabled IPv6 on this machine, including on the loopback interface. So the system was in this state: net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1 However, /etc/hosts still contained the normal IPv6 localhost entry for ::1. That appears to be what produced the timeout you saw in the strace: localhost IPv6 was still advertised via /etc/hosts, but IPv6 loopback was not usable on lo. I tested that directly with a small Python socket test connecting to port 4101 on both 127.0.0.1 and ::1. With IPv6 still disabled on loopback, the result was: 127.0.0.1 ConnectionRefusedError [Errno 111] Connection refused after 0.0 s ::1 TimeoutError timed out after 3.003 s Then I re-enabled IPv6 on the loopback interface: sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=0 After that, the same Python test failed immediately for both IPv4 and IPv6: 127.0.0.1 ConnectionRefusedError [Errno 111] Connection refused after 0.0 s ::1 ConnectionRefusedError [Errno 111] Connection refused after 0.0 s I also tested this with xbrlapi itself: 1. Reinstalled xbrlapi while IPv6 loopback was still disabled. 2. Rebooted and logged in. 3. Confirmed that the login delay returned, around 135 seconds. 4. Re-enabled IPv6 loopback. 5. Rebooted and logged in again. 6. Confirmed that the login delay disappeared. So the reproducible condition seems to be: 1. brltty is absent / not listening on port 4101. 2. xbrlapi is installed and runs during session startup. 3. /etc/hosts contains the normal ::1 localhost entry. 4. IPv6 is disabled on lo, so ::1 is advertised but not actually usable. 5. xbrlapi gets ECONNREFUSED immediately from 127.0.0.1:4101, but the ::1:4101 attempt waits for the TCP timeout. So your firewall suspicion was pointing in the right direction: something local was making the IPv6 localhost connection get swallowed instead of refused cleanly. In this case it appears to have been disabled IPv6 loopback rather than a firewall rule. Regards, earthenvessel
