Hello 
,
connecting to a Chatmail account in DC-iOS sometimes takes a long time.
It can last up to 40 seconds and seems to occur more frequently.
I’m not sure if it’s a bug or if it’s due to maintenance work on the chat server.
However, the problem has so far only occurred in DC-iOS.
Does anyone know more about it?
Indeed, it’s slow. This is with a quite fast connection:
pytest --durations=8 cmdeploy/src/cmdeploy/tests/online/test_0_login.py::test_login_basic_functioning
============================================================================================================ test session starts ============================================================================================================
platform linux -- Python 3.10.12, pytest-7.4.3, pluggy-1.3.0 -- /home/user/code/chatmail/venv/bin/python3
cachedir: .pytest_cache
Deltachat core=v1.132.0 sqlite=3.39.4 journal_mode=wal
rootdir: /home/user/code/chatmail/cmdeploy/src/cmdeploy/tests
configfile: pytest.ini
plugins: deltachat-1.132.0, cmdeploy-0.2, deltachat-rpc-client-1.127.0, xdist-3.5.0
collected 2 items
cmdeploy/src/cmdeploy/tests/online/test_0_login.py::test_login_basic_functioning[imap] PASSED [ 50%]
cmdeploy/src/cmdeploy/tests/online/test_0_login.py::test_login_basic_functioning[smtp] PASSED [100%]
============================================================================================================ slowest 8 durations ============================================================================================================
17.08s call online/test_0_login.py::test_login_basic_functioning[smtp]
8.82s call online/test_0_login.py::test_login_basic_functioning[imap]
(4 durations < 0.005s hidden. Use -vv to show these durations.)
============================================================================================================ 2 passed in 25.99s =============================================================================================================
CPU & RAM seem normal.
Then again, cmdeploy bench is working well:
[$ pytest --pyargs cmdeploy.tests.online.benchmark -vrx]
============================================================================================================ test session starts ============================================================================================================
platform linux -- Python 3.10.12, pytest-7.4.3, pluggy-1.3.0 -- /home/user/code/chatmail/venv/bin/python3
cachedir: .pytest_cache
Deltachat core=v1.132.0 sqlite=3.39.4 journal_mode=wal
rootdir: /home/user/code/chatmail
plugins: deltachat-1.132.0, cmdeploy-0.2, deltachat-rpc-client-1.127.0, xdist-3.5.0
collected 7 items
cmdeploy/src/cmdeploy/tests/online/benchmark.py::test_tls_imap PASSED [ 14%]
cmdeploy/src/cmdeploy/tests/online/benchmark.py::test_login_imap PASSED [ 28%]
cmdeploy/src/cmdeploy/tests/online/benchmark.py::test_tls_smtp PASSED [ 42%]
cmdeploy/src/cmdeploy/tests/online/benchmark.py::test_login_smtp PASSED [ 57%]
cmdeploy/src/cmdeploy/tests/online/benchmark.py::TestDC::test_autoconfigure PASSED [ 71%]
cmdeploy/src/cmdeploy/tests/online/benchmark.py::TestDC::test_ping_pong PASSED [ 85%]
cmdeploy/src/cmdeploy/tests/online/benchmark.py::TestDC::test_send_10_receive_10 PASSED [100%]
============================================================================================================= benchmark results =============================================================================================================
benchmark name median min max
---------------------------------------------------
imap_connect 0.14 0.13 0.14
imap_connect_and_login 0.23 0.21 0.25
smtp_connect 0.20 0.19 0.37
smtp_connect_and_login 0.29 0.28 0.30
dc_autoconfig_and_idle_ready 1.34 1.32 1.38
dc_ping_pong 0.59 0.56 1.30
dc_send_10_receive_10 2.65 2.35 2.67
============================================================================================================ 7 passed in 36.91s =============================================================================================================
There might be some bug where failed connection attempts (of being offline) stack up and trigger a timeout when it connects again. Have you played with stuff like flight mode?
No I haven’t. But I quit apps sometimes. I did it earlier because I thought it would save energy. Still trying to break the habit.
They are frozen on iOS, so not really save energy 
Anyways let’s check if it is faster again when the next version releases in ~1,5 months (according to our internal “roadmap”)
I know, but occasionally I slip back into old habits. 
Unfortunately, this issue still exists in DC-iOS 1.44. It can take up to a minute for a connection to be established. In DC-Desktop 1.44 and DC-Android 1.44, there can sometimes be problems connecting, but this is very rare.
During testing, I noticed that this problem only occurs with DC-iOS when I am connected to the Internet via WLAN and mobile data is deactivated. I don’t think the WLAN is the cause since the normal email accounts work with DC. In addition, the problem only occurs very rarely with DC-Desktop and DC-Android on the same WLAN.
Does anybody have the same Problem?
I have the impression that the situation improved over the weekend.
Maybe the server has been updated?
A log collected when connection takes long time would be helpful. There have been some improvements wrt. IMAP connection in 1.44, e.g. this: fix(imap): allow maybe_network to interrupt connection ratelimit by link2xt · Pull Request #5297 · deltachat/deltachat-core-rust · GitHub
The problem seems to weaken from time to time and then increase again.
Today, an error message was displayed for the first time:
Recently, DC-iOS sometimes crashes at startup.
As far as I can remember, this happened first in version 1.44.1.
Either the Delta Chat logo is displayed at startup and the app freezes or when trying to connect to Chatmail, it is closed. I can’t find anything in the log.
Therefore, I originally wanted to wait until the new log is implemented before reporting the problem. But now I think that the crashes and the connection problem are probably related somehow.
1 Like
that can mean that the background fetch function (background notification code) is currently running. or could also mean that sth went wrong somewhere else and stopped the account.
maybe it would make sense to show “account paused” there in the cases the background fetch locks the account?
maybe the new log can give you more info of what is happening, this screen should never appear to users
Could the connection problems be related to switching between DC-Desktop and DC-iOS?
Could the connection problems be related to switching between DC-Desktop and DC-iOS?
i’d try over with a fresh account. and without the existing account (either do a backup or maybe you already have a second device.
that way we can narrow down the issue. we could know by that if it is account-related - or an issue with some iOS-version or network-setup.
(in general, connecting to chatmail servers is fast, also on iOS)
also, the log should be better meanwhile and is usually accessible within the app (“Advanced Settings / View Log”)
1 Like
There was a recently fixed problem on chatmail side:
Server only allowed 100 logged in connections at the same time, so connecting to SMTP took some time, essentially requiring you to wait until someone else’s connection times out.
1 Like
After reinstalling DC-iOS and transferring the profiles from DC-Desktop via QR code, the problem no longer occurred at first, but after one day the connection problem reappeared.
I created a new profile for testing purposes. During this time DC also had problems connecting to the chatmail server.
Then I reinstalled DC-iOS and restored the new profile via backup and not via QR code. The connection problem reappeared immediately. It seems to make some difference how the profile is restored. I have saved the logs and noted when and under what conditions the problem occurred and will send it as a private message.
I have looked at the logs you sent. It seems nine.testrun.org resolves into IPv6 (2a01:4f8:241:4ce8::2) and IPv4 address 116.202.233.236. Then Delta Chat tries IPv6 address first, followed by IPv4. However, on your network IPv6 address connection attempt always times out (after 1 minute) and then IPv4 connection succeeds. This is why reconnecting always takes 1 minute.
Non-chatmail servers probably just don’t have IPv6 address.
Do you actually have IPv6 support on your network? If not, ideally it should at least return an ICMP error to make the connection error out instead of timing out.
In any case I think we should parallelize connection attempts using IPv6 and IPv4 in case IPv6 does not work like this.
1 Like
Thank you for the quick answer. 
That makes sense. But why does the problem only occur after a certain amount of time and not all the time?
According to my router, I have an IPv6 address.
On the other hand, the site “wieistmeineip.de” sometimes shows an IPv6 address and sometimes not. IPv6 tests on various websites show that I don’t have IPv6 support. Very strange. 
The feature: sort DNS results by successful connection timestamp #5818 has almost completely fixed the bug. Thank you very much!
After updating to DC-iOS 1.46.8, the problem initially persisted. Then I deleted the app, restarted iOS and reinstalled DC. Since then, the bug has only occurred once. After installing DC-Desktop 1.46.3, the problem also only occurred once.
I am currently using DC-Desktop 1.46.8.
Does Core 1.142.12 already contain the feature: parallelize IMAP and SMTP connection attempts #5915? I ask because according to GitHub it was merged on August 29, 2024. But it is not listed in the changelog.
Everything that is not listed in the changelog is not released, there are a lot of pending changes on the main branch that will go into core 1.143.x series. Parallelization should indeed make it better by attempting IPv4 and IPv6 address in parallel. It is not part of the current releases.
2 Likes