ElonSatoshi
commented
4 years ago Open ElonSatoshi opened 4 years ago
ElonSatoshi
commented
4 years ago 
poljar
commented
4 years ago You'll have to either connect to a proxy and check the HTTP responses or enable debug logs and provide more info.
This could be due to the server not responding in the given time-period. Trying to increase the lag_reconnect setting might help.
ElonSatoshi
commented
4 years ago How do I enable debug logs?
poljar
commented
4 years ago We have the debug_buffer, debug_category, and debug_level settings under the matrix.network config section.
ElonSatoshi
commented
4 years ago Alright. I have a debug log and even an error:
matrix: Error: KeysUploadError: 400 One time key signed_curve25519:[scrubbed] already exists. Old key: {"key":"[scrubbed]","signatures":{"@copenhagen_bram:chat.weho.st":{"ed25519:NXHNUGEVKU":"[scrubbed]"}}}; new key: {'key': '[scrubbed]', 'signatures': {'@copenhagen_bram:chat.weho.st': {'ed25519:NXHNUGEVKU': '[scrubbed]'}}}
Which parts of the debug info are sensitive information? Should I turn down the debug level?
poljar
commented
4 years ago Well the user id might be sensitive if you don't want people to know about it. If an access token exists in the logs, that is sensitive. The keys are all public keys, so not really sensitive.
Your error indicates that you're trying to upload account keys but you already uploaded them. Which might mean that you lost your database that holds the keys but are still using the same device id.
You'll likely need to delete your database and device id. It's under ~/.weechat/matrix/{server_name}/.
Valodim
commented
4 years ago I'm also running into this problem, and indeed also on other clients logging in takes minutes for me. That's not ideal, but it is what it is (until synapse gets better or I get an SSD on the server).
I tried the lag_reconnect parameter you mentioned above, but that doesn't seem to make a difference for me in connection behavior. Looking at the code, the http timeout seems to be hardcoded? A setting there would be helpful for me.
Thanks for your work on this, btw! :)
poljar
commented
4 years ago That's the long poll timeout for a sync request, how long the server can wait before giving you a response if there's no activity. The lag reconnect timeout can be found here.
I'm not sure what the cause here could be other than synapse taking its time.
clonejo
commented
4 years ago Running into the same issue with 0.2.0-1 (Arch Linux package) and weechat 2.8, connecting to a custom matrix server. The delay after which the disconnect occurs is closer to 100 seconds for me, but still similar to the 90 seconds above.
Is a matrix client supposed to sent keep alives? Maybe some HTTP reverse proxy let's the connections time out?
clonejo
commented
4 years ago So I have been looking at the (encrypted) traffic with Wireshark for a bit and it looks like there are packets going back and forth each second. But after roughly 100 seconds, the server sends:
TLSv1.2 Record Layer: Alert (Level: Warning, Description: Close Notify)
on a side note: decrypting TLS traffic is surprisingly easy to do using SSLKEYLOGFILE
poljar
commented
4 years ago Keep-alives no, but a sync request will be always waiting around. Does that happen for the initial login request or a sync or when?
clonejo
commented
4 years ago The TLS close notify is sent by the server right after giving a successful reply to a sync request. The gap between the two packets is in the order of microseconds. Also I don't see anything suspicious in either the nginx access log or the synapse log.
This occurs on both synapse 1.12.3 and 1.12.4. But I suspect this problem occurs due to reverse proxy (nginx) or some OS config.
I'll also try with matrix.org.
poljar
commented
4 years ago If it actually connects but periodically disconnects it's hitting the max requests setting http://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_max_requests.