On 26Apr2021 17:21, Marco Fioretti <marco.fiore...@gmail.com> 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 <c...@cskk.id.au>

Reply via email to