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 <c...@cskk.id.au> ha scritto: > > 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>
