Hi Folks,
Someone out there will know the answer to my ignorant query ...
Suppose I have an up-and-running internet connection via my ISP. So I telnet into a remote host (e.g. nessie.mcc.ac.uk) and establish a login-session. So far so good.
Next, for DSL reasons, the internet connection is interrupted (the router re-syncs). Shortly afterwards, it is re-established again.
But now, I have lost contact with the login session.
My question is: What is the mechanism (or perhaps absence of mechanism) leading to losing the contact?
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?
The naive version of the question: If my packets can find their way to my login to nessie before the line drops, and nessie's can find their way back to my telnet, how come they can't continue to do so after the line drops and is re-estiblished?
I hope people understand what I'm asking -- I'll try better if you don't!
Thanks, and best wishes to all, 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:03:41 ------------------------------ XFMail ------------------------------
Telnet (and tcp applications in general) sends a keepalive pack every 75 seconds, if you had been lucky enough to resync without clashing with one of these 75 second intervals, your link would have continued.
more specifically, i think the message your telnet client sends to the server is "ack 31" and it expects in reply "ack 4". if the server doesn't receive an ack 31 within it's window, it will end the connection, and the client will end the link without an ack 4 in response.
if you're using a UDP application instead of TCP, it'll implement its own similar keepalive system independantly of any other applications.
if you regularly have these problems, you can look into a gpl application called screen - you use it as part of your login session setup and it will let you run multiple telnet sessions over one link, and more usefully for you, reconnect to a session which had been lost
Ewan
On 5/24/06, Ted Harding Ted.Harding@nessie.mcc.ac.uk wrote:
Hi Folks,
Someone out there will know the answer to my ignorant query ...
Suppose I have an up-and-running internet connection via my ISP. So I telnet into a remote host (e.g. nessie.mcc.ac.uk) and establish a login-session. So far so good.
Next, for DSL reasons, the internet connection is interrupted (the router re-syncs). Shortly afterwards, it is re-established again.
But now, I have lost contact with the login session.
My question is: What is the mechanism (or perhaps absence of mechanism) leading to losing the contact?
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?
The naive version of the question: If my packets can find their way to my login to nessie before the line drops, and nessie's can find their way back to my telnet, how come they can't continue to do so after the line drops and is re-estiblished?
I hope people understand what I'm asking -- I'll try better if you don't!
Thanks, and best wishes to all, 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:03:41 ------------------------------ XFMail ------------------------------
On 24-May-06 Ewan Leith wrote:
Telnet (and tcp applications in general) sends a keepalive pack every 75 seconds, if you had been lucky enough to resync without clashing with one of these 75 second intervals, your link would have continued.
more specifically, i think the message your telnet client sends to the server is "ack 31" and it expects in reply "ack 4". if the server doesn't receive an ack 31 within it's window, it will end the connection, and the client will end the link without an ack 4 in response.
if you're using a UDP application instead of TCP, it'll implement its own similar keepalive system independantly of any other applications.
if you regularly have these problems, you can look into a gpl application called screen - you use it as part of your login session setup and it will let you run multiple telnet sessions over one link, and more usefully for you, reconnect to a session which had been lost
Ewan
Thanks, Ewan, that makes sense! (And shows that I did manage to explain my question). And the tip about 'screen' looks useful (I used to use screen quite a lot in the old SLIP days, between machines connected with a serial cable, but I haven't touched it for years now).
But your comment raises another question: If the hiatus in the "ACK 31"/"ACK 4" exchange causes the link to be ended by one side or the other as you explain, how can 'screen' reconnect to it?
Thanks again! 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:24:16 ------------------------------ XFMail ------------------------------
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.
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).
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.
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.
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
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 ------------------------------
-
Bob Franklin -
Ewan Leith -
Ted.Harding＠nessie.mcc.ac.uk