Ok, after doing some reading about the TCP keep alive option I think I
have found the explanation for the issue you describe. For reference
here is an extract from: http://tldp.org/HOWTO/TCP-Keepalive-
HOWTO/overview.html
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2.4. Preventing disconnection due to network inactivity
The other useful goal of keepalive is to prevent inactivity from
disconnecting the channel. It's a very common issue, when you are behind
a NAT proxy or a firewall, to be disconnected without a reason. This
behavior is caused by the connection tracking procedures implemented in
proxies and firewalls, which keep track of all connections that pass
through them. Because of the physical limits of these machines, they can
only keep a finite number of connections in their memory. The most
common and logical policy is to keep newest connections and to discard
old and inactive connections first.
Returning to Peers A and B, reconnect them. Once the channel is open,
wait until an event occurs and then communicate this to the other peer.
What if the event verifies after a long period of time? Our connection
has its scope, but it's unknown to the proxy. So when we finally send
data, the proxy isn't able to correctly handle it, and the connection
breaks up.
Because the normal implementation puts the connection at the top of the
list when one of its packets arrives and selects the last connection in
the queue when it needs to eliminate an entry, periodically sending
packets over the network is a good way to always be in a polar position
with a minor risk of deletion.
_____ _____ _____
| | | | | |
| A | | NAT | | B |
|_____| |_____| |_____|
^ ^ ^
|--->--->--->---|----------- SYN ------------->--->--->---|
|---<---<---<---|--------- SYN/ACK -----------<---<---<---|
|--->--->--->---|----------- ACK ------------->--->--->---|
| | |
| | <--- connection deleted from table |
| | |
|--->- PSH ->---| <--- invalid connection |
| | |
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
I guess the first step from here is to see if some firewall software can
be used to drop these connections after say 30 seconds so that this
scenario can be reproduced more easily then a fix for gvfs can be worked
on.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/377322
Title:
Nautilus sftp connection breaks spontaneously after a while, needing
re-login to fix it
Status in GVFS:
Confirmed
Status in “gvfs” package in Ubuntu:
Triaged
Bug description:
When I have used an sftp connection for a while - started from
Places/Connect to Server or from a bookmark - it breaks, typically
after an hour or so. The only way to get an sftp connection to that
server again is to re login to my computer. The error message I get is
Could not open location 'sftp://......'
DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a
reply. Possible causes include: the remote application did not send a
reply, the message bus security policy blocked the reply, the reply
timeout expired, or the network connection was broken
Sometimes when this happens, my computer freezes for about 60 seconds.
I have Ubuntu 9.04 64 bits - error happened on Hardy also - on a
computer with an AMD64 processor.
To manage notifications about this bug go to:
https://bugs.launchpad.net/gvfs/+bug/377322/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
