On 19 Mar 2021, at 16:30, Marcus Schopen <lists@xxxxxxxxxxxx> 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
