Getting timeouts when requesting certain gemini servers about kristall HOT 11 OPEN

It appears to be due to the way that the QSslSocket handles TCP resets. Using Wireshark, I was able to see that the Qt socket class is sending A (IPv4) and AAAA (IPv6) DNS queries. Both of these queries respond with hits, so I have both IPv4 and IPv6 addresses for the hosts I've tried. The socket class first tries to open a connection at port 1965 using the IPv6 address by sending a TCP packet with the SYN flag set. In the case of a "good" host that responds quickly, the server responds with a SYN+ACK TCP packet, and the rest of the gemini request life cycle (TLS negotiation, request, response, close) continues.

In the case of a "bad" host that responds slowly, the host responds immediately with a packet that has the RST (reset) flag set. The client appropriately quits the IPv6 connection. Rather than immediately trying to connect using IPv4 like the simple python client does, the QSslSocket waits 30 seconds before connecting with IPv4 which it does so successfully. I'm not sure where this 30-second delay is configured, but it seems sensible and safe that if there are exactly 2 addresses to try, it's ok for Kristall to immediately try IPv4 if it gets an RST packet from the IPv6 attempt.

I'll keep poking around to see if there's a good known solution to this. I imagine Qt has a good reason for putting the 30-second delay in, but I also imagine that there's a stock solution for this somewhere.

from kristall.

Kristall timeouts will happen when a server doesn't send data or close the connection for the configured timeout (5 seconds). If you think this value is too low, try increasing it in the settings to 10 seconds or more.
When i'm using a mobile connection, i usually set the timeout to 15 seconds

I just checked and at least gemini://zaibatsu.circumlunar.space worked, but i noticed that solderpunks server tends to time out from time to time on mobile/slow connections

from kristall.

I increased the timeout to 60000ms, and I ultimately did get responses from those hosts, but they took over 30 seconds to finish--thanks for the suggestion.

As far as I can tell, it appears to be related to an interaction between Kristall and my home network. When I am on my home network without a VPN, I get those long response times with Kristall (but not with a minimal CLI client). When I am on the same network but using my work VPN, the affected hosts finish responding quickly. I'll keep investigating this.

from kristall.

Just spitballing here, but maybe Qt is doing some funny DNS interception?

from kristall.

Huh, weird. @rowedonalde can you contact me via IRC or mail so we could make some kind of live debugging? I'd like to find out why this is so slow… Contacts can be found on my home page, i'm also in #gemini on the tilde IRC, find me as xq

from kristall.

Apologies for the long delay. A few nights ago I added some debug statements to pick up on state changes. In the case of the troublesome hosts, it's the ConnectingState that the Gemini client gets stuck in so long. Note that for the good one (gemini.circumlunar.space), the ConnectingState transitions to ConnectedState very quickly (0.1 sec), but for vi.rs it takes 30 seconds to arrive in ConnectedState, and for zaibatsu it completely times out in this step:

2020-07-13 22:30:07.084659-0700 kristall[85184:273466] start request QUrl("gemini://gemini.circumlunar.space/")
2020-07-13 22:30:07.086521-0700 kristall[85184:273466] Socket state changed to QAbstractSocket::HostLookupState
2020-07-13 22:30:07.119748-0700 kristall[85184:273466] Socket state changed to QAbstractSocket::ConnectingState
2020-07-13 22:30:07.208695-0700 kristall[85184:273466] Socket state changed to QAbstractSocket::ConnectedState
2020-07-13 22:30:07.407300-0700 kristall[85184:273466] ignoring 1 out of 1
2020-07-13 22:30:07.407338-0700 kristall[85184:273466] socket encrypted
2020-07-13 22:30:07.491420-0700 kristall[85184:273466] socket ready read
2020-07-13 22:30:07.491514-0700 kristall[85184:273466] 2 0 "text/gemini"
2020-07-13 22:30:07.492345-0700 kristall[85184:273466] socket ready read
2020-07-13 22:30:07.493215-0700 kristall[85184:273466] Socket state changed to QAbstractSocket::ClosingState
2020-07-13 22:30:07.493313-0700 kristall[85184:273466] Socket state changed to QAbstractSocket::UnconnectedState
2020-07-13 22:30:07.493430-0700 kristall[85184:273466] socket disconnected
2020-07-13 22:30:07.493511-0700 kristall[85184:273466] Loaded 1138 bytes of type "text" / "gemini"

2020-07-13 22:30:23.787994-0700 kristall[85184:273466] start request QUrl("gemini://vi.rs")
2020-07-13 22:30:23.788291-0700 kristall[85184:273466] Socket state changed to QAbstractSocket::HostLookupState
2020-07-13 22:30:24.019760-0700 kristall[85184:273466] Socket state changed to QAbstractSocket::ConnectingState
2020-07-13 22:30:54.054689-0700 kristall[85184:273466] Socket state changed to QAbstractSocket::ConnectedState
2020-07-13 22:30:54.123514-0700 kristall[85184:273466] ignoring 1 out of 1
2020-07-13 22:30:54.123551-0700 kristall[85184:273466] socket encrypted
2020-07-13 22:30:54.145128-0700 kristall[85184:273466] socket ready read
2020-07-13 22:30:54.145269-0700 kristall[85184:273466] 2 0 "text/gemini"
2020-07-13 22:30:54.145306-0700 kristall[85184:273466] socket ready read
2020-07-13 22:30:54.147208-0700 kristall[85184:273466] Socket state changed to QAbstractSocket::ClosingState
2020-07-13 22:30:54.147244-0700 kristall[85184:273466] Socket state changed to QAbstractSocket::UnconnectedState
2020-07-13 22:30:54.147319-0700 kristall[85184:273466] socket disconnected
2020-07-13 22:30:54.147376-0700 kristall[85184:273466] Loaded 4020 bytes of type "text" / "gemini"

2020-07-13 22:31:11.925922-0700 kristall[85184:273466] start request QUrl("gemini://zaibatsu.circumlunar.space")
2020-07-13 22:31:11.926447-0700 kristall[85184:273466] Socket state changed to QAbstractSocket::HostLookupState
2020-07-13 22:31:11.973133-0700 kristall[85184:273466] Socket state changed to QAbstractSocket::ConnectingState
2020-07-13 22:32:20.356872-0700 kristall[85184:273466] Socket state changed to QAbstractSocket::UnconnectedState
2020-07-13 22:32:20.357063-0700 kristall[85184:273466] Loaded 101 bytes of type "text" / "gemini"

Is there a way to get finer resolution on what's happening in ConnectingState? Additionally, does QSslSocket reveal the IP addresses determined in HostLookupState? That may be helpful in seeing if there's a discrepancy in how it resolves the slow hostnames.

I'll reach out via email or IRC if I dead-end here.

from kristall.

To add to the above, socket.peerAddress() returns the IP address that the QSslSocket is using, but only after connecting successfully. The QAbstractSocket docs suggest that there could be more than one address returned in the HostLookup state, so I'm wondering if it's cycling through needless IP addresses somehow.

After it does connect, socket.peerAddress() returns 209.141.50.214 for the vi.rs connection which is consistent with what my simple Python client has and what ping vi.rs shows me.

from kristall.

I assume that Qt does its own resolving instead of using the system one… This could introduce such a long time. I wanted to rewrite the timeout handling for streaming support anyways, but for now just crank up the timeout to large times.

If you could still figure out why that happens i would be very happy :)

from kristall.

Hi I am developing server framework for Gemini apps and I bumped into similar issue. My server works perfectly with Amfora browser but when I tried it in Kirstall it always crashed my server and the page timed-out. I found out that it was due to the fact that I configured the server to only support TLS 1.3 - when I added the support for TLS 1.2 it worked as expected.

Could that be also issue for some servers out there? The issue manifested itself with time-out in the browser.

from kristall.

Ah, i can set the TLS version to "1.2 or later" instead of enforcing 1.2

from kristall.

Yeah that would be great and also according to specs :)

Servers MUST use TLS version 1.2 or higher and SHOULD use TLS version 1.3 or higher. TLS 1.2 is reluctantly permitted for now to avoid drastically reducing the range of available implementation libraries. Hopefully TLS 1.3 or higher can be specced in the near future. Clients who wish to be "ahead of the curve MAY refuse to connect to servers using TLS version 1.2 or lower.

from kristall.