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 723866 - RFE: Don't drop VPN immediately on underlying connection failure, try to continue if the connection comes up again within a sensible timeout
RFE: Don't drop VPN immediately on underlying connection failure, try to cont...
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: VPN (general)
0.9.8
Other Linux
: Normal enhancement
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks: 762113
 
 
Reported: 2014-02-07 17:07 UTC by David Jaša
Modified: 2020-11-12 14:29 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Jaša 2014-02-07 17:07:33 UTC
When connected over NATing router with weak Wi-Fi signal, connection to the AP drops from time to time but it gets usually reestablished within dozens of second with the same IP as before. Meanwhile, NAT table within router is not notified about client exit so it keeps the state over the whole underlying connection period. (Similar considerations should apply to VPNs over MPTCP where the failover connection doesn't have to be the same as original one at all.)

Given the case above, it would make sense to just give visual indication that the connection isn't fully operational but not to drop it till some timeout (2min? 3min? 5min?) expires, only then should be the connection dropped.

This RFE would make tremendous usability boost to 2-factor-auth VPNs accessed over unstable networks.

NM version: 0.9.8 @ Fedora 20
Comment 1 André Klapper 2020-11-12 14:29:17 UTC
bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).