On 24-May-06 Bob Franklin wrote:
On Wed, 24 May 2006, Ted.Harding@nessie.mcc.ac.uk wrote:
Or, turning the question on its head, what is it that keeps my link with the remote host alive so long as the internet connection stays up?
Is the IP address on your ADSL connection static? If not, and that changes, there is no way for nessie to know that the packets coming from your new IP are part of the existing connection.
Yes, it is static (sorry, should have said that before), which is part of why I was puzzled. Many thanks for your remaining comments below -- vyr I'm getting a bit out of my depth there!
It is possible that your connection was down for your session to time out; normally, with no data passing over the link, it will just stay up. However, if nessie (or you) tried to send something, while the link was down, and it didn't come back before it gave up trying to resend it, the connection would be closed.
A similar thing applies to stateful firewalls - our campus firewall (I don't know what happens at Manchester) will expect to see activity on a TCP connection periodically. If it does not see this, it will assume it has been terminated by something like this situation, and remove it from the active session list. However, this timeout is suitably long (about 30 minutes by default, and we crank it up on a per-protocol basis).
The sort of time-gap I'm talking about is much shorter than 30 min. More like a couple of minutes, which is more in line with Ewan Leith's comment.
Yet another thing could be your modem at home - if you try to send something while the ADSL line is down, it may return a 'no route to host' message because it hasn't got one; this will be reported back by your telnet client.
I don't get such a message -- just a paralysed console!
Another thing related to your firewall/router might be its NAT session table - it has to maintain a mapping between your internal IP address and port number and the destination host and port number, so it can fiddle about with the packets to make them appear they're coming from your public (ADSL) IP, when you send something out onto the Internet, and then do the reverse, when it comes back in. It is possible that this table is flushed when the ADSL line goes down (because the public IP address is no longer available) and so it doesn't know how to map the packets, when the packets from the middle of the stream (i.e. not the ones that start and stop the session) hit it.
Yes, that could also make sense!
On my firewall/router at home (and work, in my case!), I know I can log in and check the status of these session tables and how long they have to timeout, to see what's going on. I don't know if Manchester have such a firewall, so it may not be an issue, and you might not be able to nose at the one at home.
Hope that helps (the fun part comes when you're debugging GRE tunnels and NATing routers; it's amazing how few of these do it properly).
- Bob
Thanks, Bob. Ted.
-------------------------------------------------------------------- E-Mail: (Ted Harding) Ted.Harding@nessie.mcc.ac.uk Fax-to-email: +44 (0)870 094 0861 Date: 24-May-06 Time: 21:35:48 ------------------------------ XFMail ------------------------------