After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 613422 - Allow configuration of cable disconnect timeout
Allow configuration of cable disconnect timeout
Status: RESOLVED DUPLICATE of bug 688284
Product: NetworkManager
Classification: Platform
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Dan Williams
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2010-03-20 17:32 UTC by Michael Wood
Modified: 2013-02-11 19:04 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Wood 2010-03-20 17:32:54 UTC
It would be useful if NetworkManager didn't down the network interface as soon as it detects that there is no cable. By all means alert the user as to the fact that the cable has been disconnected, but don't down the interface until the timeout defined by /proc/sys/net/ipv4/tcp_fin_timeout has been reached.

If you've got a download going, ssh, IM.. etc etc there is no reason why these need to be shut off if your cable pops out for <tcp_fin_timeout time
Comment 1 Dan Williams 2010-03-24 08:28:34 UTC
It depends; if you're a laptop user who's disconnecting and taking your laptop to a conference room, you don't really want NM to think that you're still using the cable for internet.  NM 0.8 currently has a 4-second timer where it will delay taking the device down if the carrier comes back within 4 seconds, but any more than 10 seconds really and the use-cases will really start to conflict like I describe here.

We should think about it more and see if there is some way to handle this better though.
Comment 2 Pavel Simerda 2012-08-16 22:15:22 UTC
Adjusting this bug report. It would be useful to make the timeout configurable. Maybe globally, maybe per interface, I don't know. But some advanced users would like to retain their previous practice of maintaining TCP connections over longer
physical disconnects.

Of course, if we have a better way, no problem.
Comment 3 Dan Williams 2013-02-11 19:04:58 UTC
We'll actually be work on this more in bug #688284 so duping it there for now.  In the future we can potentially revisit configurable timeouts, but perhaps the additional options proposed in bug 688284 will work for now.  They will allow you to specify that NM should ignore carrier events if you know that you'll never be moving that workstation.

A random follow-on to that would be to renew the DHCP lease if the cable has been disconnected more than 30 seconds, which could indicate a router restart or something liek that.

*** This bug has been marked as a duplicate of bug 688284 ***