Re: connection to dovecot times out about every ten minutes
On 28Apr2021 17:23, Marco Fioretti wrote: >I honestly don't know if the old modem had an integrated router, and I >have already disposed of it. What I am sure of is that I had NOT >changed anything in its settings for many months, if not years, and >everything was working without problems until a few weeks ago, when I >posted here. Also, why would any modem come from the factory, or be >remotely updated by an ISP in ways that interfere with an absolutely >basic use case of hundreds millions of people, that is keeping one's >email client connected to its IMAP server for hours? These are good points. That the behaviour was new and the modem not pretty much invalidates my idea, unless a recent mutt IMAP change (or, I suppose, the upstream dovecot) made the connection more idle at a TCP level. But I'm grasping at straws. >As for the new one, I cannot check it right now because I am not at >home, but it is working, so whatever it does, it is OK. Q: How many user support people does it take to change a light bulb? A: We have an exact copy of the light bulb here and it seems to be working fine. Can you tell me what kind of system you have? Glad to hear this. Cheers, Cameron Simpson
Re: connection to dovecot times out about every ten minutes
Hi, I honestly don't know if the old modem had an integrated router, and I have already disposed of it. What I am sure of is that I had NOT changed anything in its settings for many months, if not years, and everything was working without problems until a few weeks ago, when I posted here. Also, why would any modem come from the factory, or be remotely updated by an ISP in ways that interfere with an absolutely basic use case of hundreds millions of people, that is keeping one's email client connected to its IMAP server for hours? As for the new one, I cannot check it right now because I am not at home, but it is working, so whatever it does, it is OK. Marco Il giorno mar 27 apr 2021 alle ore 00:13 Cameron Simpson ha scritto: > > On 26Apr2021 17:21, Marco Fioretti wrote: > >update on this: > >to make a long story short > >1) I did run mutt with debug enabled , but could not recognize anything > >useful > >2) I had the same problem with mutt from my laptop > >3) a few days ago I received a new modem from my ISP, as part of their > >network upgrade operations > >4) more or less in the same moment the problem I reported here > >disappeared. Now mutt stays connected even 24 hours without losing > >connection. > > > >I am NOT 100% sure that the problem disappeared AFTER the change of > >modem. That happened during a few chaotic days, both work- and > >family-wise, so I did not take notes. And modems may have nothing to > >do at all with the disconnections. But now the problem is not there > >anymore, I have no clue what may have happened, and if anybody can > >guess... thanks in advance. > > _If_ the new modem is relevant, maybe the modem's internal firewqll > rules are related. Anything which NATs (translates between your home LAN > private address range to some external IP address used by the modem) > must keep state for every connection crossing the modem. > > There's no "idle detection" in TCP (without keepalives) or UCP so if > some device on either side of the connection dies/crashes while the > connection is _idle_ there's no indication at the modem that this has > happenned - there's just no traffic for that connection, which is > already the case. > > So... stateful firewalls (eg your modem doing NAT) get bored, and > usually have some setting to discard long-idle connections. I can > imagine a "polite" device timing out such a TCP connection sending an > RST (reset) packet in each direction just before discarding the state to > inform the endpoints that the connection is gone (thus letting each end > see this in a timely fashion, rather than just "next time they try to > send traffic"). > > Maybe your previous modem's timeout for that was 10 minutes? And the new > one is more generous (or even does not timeout connection states)? > > Just guessing. > > Cheers, > Cameron Simpson
Re: connection to dovecot times out about every ten minutes
On 26Apr2021 17:21, Marco Fioretti wrote: >update on this: >to make a long story short >1) I did run mutt with debug enabled , but could not recognize anything >useful >2) I had the same problem with mutt from my laptop >3) a few days ago I received a new modem from my ISP, as part of their >network upgrade operations >4) more or less in the same moment the problem I reported here >disappeared. Now mutt stays connected even 24 hours without losing >connection. > >I am NOT 100% sure that the problem disappeared AFTER the change of >modem. That happened during a few chaotic days, both work- and >family-wise, so I did not take notes. And modems may have nothing to >do at all with the disconnections. But now the problem is not there >anymore, I have no clue what may have happened, and if anybody can >guess... thanks in advance. _If_ the new modem is relevant, maybe the modem's internal firewqll rules are related. Anything which NATs (translates between your home LAN private address range to some external IP address used by the modem) must keep state for every connection crossing the modem. There's no "idle detection" in TCP (without keepalives) or UCP so if some device on either side of the connection dies/crashes while the connection is _idle_ there's no indication at the modem that this has happenned - there's just no traffic for that connection, which is already the case. So... stateful firewalls (eg your modem doing NAT) get bored, and usually have some setting to discard long-idle connections. I can imagine a "polite" device timing out such a TCP connection sending an RST (reset) packet in each direction just before discarding the state to inform the endpoints that the connection is gone (thus letting each end see this in a timely fashion, rather than just "next time they try to send traffic"). Maybe your previous modem's timeout for that was 10 minutes? And the new one is more generous (or even does not timeout connection states)? Just guessing. Cheers, Cameron Simpson
Re: connection to dovecot times out about every ten minutes
update on this: to make a long story short 1) I did run mutt with debug enabled , but could not recognize anything useful 2) I had the same problem with mutt from my laptop 3) a few days ago I received a new modem from my ISP, as part of their network upgrade operations 4) more or less in the same moment the problem I reported here disappeared. Now mutt stays connected even 24 hours without losing connection. I am NOT 100% sure that the problem disappeared AFTER the change of modem. That happened during a few chaotic days, both work- and family-wise, so I did not take notes. And modems may have nothing to do at all with the disconnections. But now the problem is not there anymore, I have no clue what may have happened, and if anybody can guess... thanks in advance. Il giorno mar 13 apr 2021 alle ore 15:37 Kevin J. McCarthy ha scritto: > > On Tue, Apr 13, 2021 at 10:09:32AM +0200, Marco Fioretti wrote: > >imap_poll_layout was not set in my murttrc file. > > If not set, it defaults to 15 seconds. > > >Setting it to 0, which according to manual should disable it, just > >made mutt freeze > > Setting it to 0 turns off the polling. So Mutt is sending the > IDLE/NOOP/STATUS and trying to read the response, without polling the > connection first. > > If Mutt freezes in that case, then the connection to dovecot has died. > > >set imap_poll_timeout = 600 made it freeze too, but eventually > >recovered, and had to reopen the inbox > > Setting it to 600 means Mutt will wait 10 minutes for a response from > the server before declaring the connection is dead and trying to > reconnect. If it then reopened the mailbox, that also means the > connection to dovecot died. > > >Launching mutt with the -d 2 option did not produce anything visible. > >Where should debug messages appear, btw? In mutt itself, or in some > >log file? What could I try next? > > This flag produces a file ~/.muttdebug0 in your home directory with > debugging output, including IMAP commands sent and received. > > Perhaps you can compare that and the dovecot log, and see if you can > find out why all the "logged out" messages are appearing. > > -- > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
Re: connection to dovecot times out about every ten minutes
On Tue, Apr 13, 2021 at 10:09:32AM +0200, Marco Fioretti wrote: imap_poll_layout was not set in my murttrc file. If not set, it defaults to 15 seconds. Setting it to 0, which according to manual should disable it, just made mutt freeze Setting it to 0 turns off the polling. So Mutt is sending the IDLE/NOOP/STATUS and trying to read the response, without polling the connection first. If Mutt freezes in that case, then the connection to dovecot has died. set imap_poll_timeout = 600 made it freeze too, but eventually recovered, and had to reopen the inbox Setting it to 600 means Mutt will wait 10 minutes for a response from the server before declaring the connection is dead and trying to reconnect. If it then reopened the mailbox, that also means the connection to dovecot died. Launching mutt with the -d 2 option did not produce anything visible. Where should debug messages appear, btw? In mutt itself, or in some log file? What could I try next? This flag produces a file ~/.muttdebug0 in your home directory with debugging output, including IMAP commands sent and received. Perhaps you can compare that and the dovecot log, and see if you can find out why all the "logged out" messages are appearing. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: connection to dovecot times out about every ten minutes
Hi Kevin, imap_poll_layout was not set in my murttrc file. Setting it to 0, which according to manual should disable it, just made mutt freeze set imap_poll_timeout = 600 made it freeze too, but eventually recovered, and had to reopen the inbox set imap_poll_timeout = 60 makes no difference wrt the original problem, I just see the "Logged out" dovecot messages on the remote server appear every minute. Launching mutt with the -d 2 option did not produce anything visible. Where should debug messages appear, btw? In mutt itself, or in some log file? What could I try next? Thanks, Marco Il giorno lun 12 apr 2021 alle ore 18:32 Kevin J. McCarthy ha scritto: > > On Mon, Apr 12, 2021 at 05:13:10PM +0200, Marco Fioretti wrote: > >after years when everything worked without a hitch, mutt started to > >say "connection timed out" every ten minutes or so when connected to > >my remote dovecot imap server. I would need help to figure out where > >the problem is, on the client or server side, and then how to fix it. > >Details already are in the dovecot mailing list here > >https://dovecot.org/pipermail/dovecot/2021-April/121897.html > > The default value of $timeout is 10 minutes. At that time, Mutt would > typically sent a STATUS command to check for new mail in your mailboxes. > > Starting with version 1.9, Mutt added polling for IDLE, NOOP, and STATUS > commands to check for a dead connection. It sends the command and then > waits $imap_poll_timeout seconds for a response from the server. > > You might try increasing $imap_poll_timeout and seeing if that helps. > > If not, you could enable debug output, using "-d 2", and see if that > provides any clues. > > -- > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
Re: connection to dovecot times out about every ten minutes
On Mon, Apr 12, 2021 at 05:13:10PM +0200, Marco Fioretti wrote: after years when everything worked without a hitch, mutt started to say "connection timed out" every ten minutes or so when connected to my remote dovecot imap server. I would need help to figure out where the problem is, on the client or server side, and then how to fix it. Details already are in the dovecot mailing list here https://dovecot.org/pipermail/dovecot/2021-April/121897.html The default value of $timeout is 10 minutes. At that time, Mutt would typically sent a STATUS command to check for new mail in your mailboxes. Starting with version 1.9, Mutt added polling for IDLE, NOOP, and STATUS commands to check for a dead connection. It sends the command and then waits $imap_poll_timeout seconds for a response from the server. You might try increasing $imap_poll_timeout and seeing if that helps. If not, you could enable debug output, using "-d 2", and see if that provides any clues. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
connection to dovecot times out about every ten minutes
Greetings, after years when everything worked without a hitch, mutt started to say "connection timed out" every ten minutes or so when connected to my remote dovecot imap server. I would need help to figure out where the problem is, on the client or server side, and then how to fix it. Details already are in the dovecot mailing list here https://dovecot.org/pipermail/dovecot/2021-April/121897.html Thanks in advance for any help, Marco
