On 19 Mar 2021, at 16:30, Marcus Schopen <[email protected]> wrote:
>
> Hi!
>
Hi
> For some reasons, one user, who fetches emails via pop3s (20 accounts
> per "batch"), has sometimes to fight with long SSL handshakes for about
> 14 seconds.
>
>
> Mar 19 04:09:24 imap01 cyrus/pop3s[8032]: accepted connection
> Mar 19 04:09:24 imap01 cyrus/pop3s[8032]: SSL_accept() incomplete ->
> wait
>
> [14 seconds nothing]
>
> Mar 19 04:09:38 imap01 cyrus/pop3s[8032]: SSL_accept() incomplete ->
> wait
> Mar 19 04:09:38 imap01 cyrus/pop3s[8032]: SSL_accept() succeeded ->
> done
> Mar 19 04:09:38 imap01 cyrus/pop3s[8032]: starttls: TLSv1 with cipher
> AES256-SHA (256/256 bits new) no authentication
> Mar 19 04:09:38 imap01 cyrus/pop3s[8032]: login: host.xyz.net [x.x.x.x]
> user001 plaintext+TLS User logged in SESSIONID=<cyrus-8032-1616123364-
> Mar 19 04:10:37 imap01 cyrus/pop3s[8032]: USAGE user001 user: 0.004000
> sys: 0.004000
> Mar 19 04:10:37 imap01 cyrus/pop3s[8032]: counts: retr=<1> top=<1>
> dele=<1>
>
>
> The strange thing is, that when it happens, it's always 14 seconds
> delay. popminpoll is set to 0, maxchild for pop3s is set to 100. I
> don't see the problem with other users, not even if both of them are
> connected to the same pop3s child. Server is not running under load.
> Any ideas?
>
> Cheers
> Marcus
>
>
There may be a configuration setting that could affect this, but I thought it
worth mentioning that I’ve had some issues with TLS connections which seemed to
get tangled with CGNAT. I could only resolve it by taking simultaneous tcpdumps
from both ends, reconciling the protocol progress and demonstrating that the
TCP flags and counters did were not from one interaction. The problem
eventually went away. I *think* that this was down to a change in the cellular
network at one end.
------------------------------------------
Cyrus: Info
Permalink:
https://cyrus.topicbox.com/groups/info/T2bda9ceee0e1b5da-M47fe27fc0892ffe7e74d6eea
Delivery options: https://cyrus.topicbox.com/groups/info/subscription
