4 ms·

I remember something about this from a few years back. Can't recall the link now though. His ssh sessions were constantly timing out. It only happened when he

I remember something about this from a few years back. Can't recall the link now though. His ssh sessions were constantly timing out. It only happened when he left the SSH session to idle. It turns out his router was dropping the TCP sessions because it considered them dead. He got around it by implementing a "keep alive" packet, of sorts. Very interesting stuff. I don't really work at such a low level in the stack regularly, so it's quite fascinating to see the strange issues people encounter with these tools. Especially when ISP's meddle around with stable protocols. Also reminds me of how some ISP DNS servers totally ignore TTL values from DNS records[0]. [0]: https://news.ycombinator.com/item?id=29568510 https://news.ycombinator.com/item?id=29568510

viraptor 5y ago
This is a pretty common issue. See https://access.redhat.com/solutions/23874 https://access.redhat.com/solutions/23874 The keep alive pings can be added on both the TCP and app level. If you ever cross a NAT, you will have some expiry on your connection. It's not really "meddling".
- fragmede 5y ago
  Yes it is. A packet being sent isn't reaching its destination because your ISP is choosing not to forward it? That we've come to expect that broken behavior is the reality that we live in, but a different route would be for the firewall/NAT device to forge an RST to both ends, since it will no longer be forwarding said packets on that TCP connection. Given all the advances in technology, I don't think that's as bad an idea as it once was.
  - viraptor 5y ago
    "choosing not to forward it" is an interesting phrase. NAT needs to have some expiry for each entry, because we don't have unlimited space for that table. Dropping the mapping entry has the same result as the other side becoming unavailable and is an understood state. You can't just produce RST out of nowhere on the NAT expiry, because that connection may actually be active somewhere else. Consider a replicating pair of NATs - your connection gets moved from one to the other because (network reasons), but the previous one does not get a message about it because (network reasons). If it sent the RST packets it would actively kill live connections which it should not touch anymore.
Neil44 5y ago
Yeah PuTTY has the keepalives option for exactly this reason. My home router doesn't seem to need them but when I'm out and about on 4G they help. You also have the SO_KEEPALIVE option on TCP connections in general.

viraptor 5y ago

This is a pretty common issue. See https://access.redhat.com/solutions/23874 https://access.redhat.com/solutions/23874 The keep alive pings can be added on both the TCP and app level. If you ever cross a NAT, you will have some expiry on your connection. It's not really "meddling".

fragmede 5y ago
Yes it is. A packet being sent isn't reaching its destination because your ISP is choosing not to forward it? That we've come to expect that broken behavior is the reality that we live in, but a different route would be for the firewall/NAT device to forge an RST to both ends, since it will no longer be forwarding said packets on that TCP connection. Given all the advances in technology, I don't think that's as bad an idea as it once was.
- viraptor 5y ago
  "choosing not to forward it" is an interesting phrase. NAT needs to have some expiry for each entry, because we don't have unlimited space for that table. Dropping the mapping entry has the same result as the other side becoming unavailable and is an understood state. You can't just produce RST out of nowhere on the NAT expiry, because that connection may actually be active somewhere else. Consider a replicating pair of NATs - your connection gets moved from one to the other because (network reasons), but the previous one does not get a message about it because (network reasons). If it sent the RST packets it would actively kill live connections which it should not touch anymore.

Neil44 5y ago

Yeah PuTTY has the keepalives option for exactly this reason. My home router doesn't seem to need them but when I'm out and about on 4G they help. You also have the SO_KEEPALIVE option on TCP connections in general.