Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1337424 - Very short timeout for establishment of VPN connection
Summary: Very short timeout for establishment of VPN connection
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 24
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-19 07:54 UTC by Alexander Mayorov
Modified: 2016-08-19 19:50 UTC (History)
6 users (show)

Fixed In Version: NetworkManager-1.2.4-2.fc24
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-19 19:50:02 UTC
Type: Bug


Attachments (Terms of Use)

Description Alexander Mayorov 2016-05-19 07:54:04 UTC
Description of problem:
  There is very short timeout for VPN connection establishment via NM = 25 seconds.
Usually there is enough time if credential data are prepared before a connection attempt. But for OTP (one-time password) receiving via SMS it is really hard to get connected at least the very first time while you are reading, selecting parameter and typing credentials
and second times, e.g. connection profile modified with xml configuration downloaded from VPN GW and it is need to start profile configuration from beginning next time.
Even in case of good luck it is not easy to get connected via NM and afterwards if SMS with new OTP delayed few seconds.
There is no such kind of problem to connect via openconnect command.
  I've checked the issue with OpenConnect, PPTP and vpnc plugins.

Version-Release number of selected component (if applicable):
NetworkManager-1.2.2-1.fc24.x86_64
NetworkManager-openconnect-1.2.2-1.fc24.x86_64
NetworkManager-pptp-1.2.2-1.fc24.x86_64
NetworkManager-pptp-gnome-1.2.2-1.fc24.x86_64
NetworkManager-vpnc-1.2.2-1.fc24.x86_64
NetworkManager-vpnc-gnome-1.2.2-1.fc24.x86_64


How reproducible:
Always in case of delay in establishment of VPN connection is more than 25 seconds.

Steps to Reproduce:
1. Start VPN connection via NM applet and don't send requested authentication data for a half of minute.
2. Then you can proceed further with authentication (it will always fail silently) or cancel the connection.
3. Check NM logs, e.g. with
journalctl --unit NetworkManager
You'll find following error
NetworkManager[8145]: <error> [1463641447.3416] vpn-connection[0x5617c05107a0,f273dcb1-6ec3-4bd2-9b7b-1a7c0d28ed9d,"vpnc",0]: Failed to request VPN secrets #3: No agents were available for this request.

Actual results:
Establishment of VPN connection fail in case of delay is more than 25 seconds, e.g. because of awaited OTP via SMS.

Expected results:
There should be enough time to enter all required data especially in case of two-factor authentication.

Additional info:
  OpenConnect:
May 19 12:45:23 zb15.alexus NetworkManager[8145]: <info>  [1463640323.8144] audit: op="connection-activate" uuid="370302f3-bb4e-473a-930d-815966088408" name="OpenConnect" pid=1726 uid=1000 result="success"
May 19 12:45:23 zb15.alexus NetworkManager[8145]: <info>  [1463640323.8196] vpn-connection[0x5617c05107a0,370302f3-bb4e-473a-930d-815966088408,"OpenConnect",0]: Started the VPN service, PID 10177
May 19 12:45:23 zb15.alexus NetworkManager[8145]: <info>  [1463640323.8300] vpn-connection[0x5617c05107a0,370302f3-bb4e-473a-930d-815966088408,"OpenConnect",0]: Saw the service appear; activating connection
May 19 12:45:48 zb15.alexus NetworkManager[8145]: <error> [1463640348.9026] vpn-connection[0x5617c05107a0,370302f3-bb4e-473a-930d-815966088408,"OpenConnect",0]: Failed to request VPN secrets #3: No agents were available for this request.
  PPTP:
May 19 13:15:25 zb15.alexus NetworkManager[8145]: <info>  [1463642125.0676] audit: op="connection-activate" uuid="80de8e52-9bf2-4079-8b0e-5476a866155b" name="PPTP" pid=1726 uid=1000 result="success"
May 19 13:15:25 zb15.alexus NetworkManager[8145]: <info>  [1463642125.0941] vpn-connection[0x5617c05105b0,80de8e52-9bf2-4079-8b0e-5476a866155b,"PPTP",0]: Started the VPN service, PID 12494
May 19 13:15:25 zb15.alexus NetworkManager[8145]: <info>  [1463642125.0998] vpn-connection[0x5617c05105b0,80de8e52-9bf2-4079-8b0e-5476a866155b,"PPTP",0]: Saw the service appear; activating connection
May 19 13:15:50 zb15.alexus NetworkManager[8145]: <error> [1463642150.2336] vpn-connection[0x5617c05105b0,80de8e52-9bf2-4079-8b0e-5476a866155b,"PPTP",0]: Failed to request VPN secrets #3: No agents were available for this request.
  VPNC:
May 19 13:03:41 zb15.alexus NetworkManager[8145]: <info>  [1463641421.9434] audit: op="connection-activate" uuid="f273dcb1-6ec3-4bd2-9b7b-1a7c0d28ed9d" name="vpnc" pid=1726 uid=1000 result="success"
May 19 13:03:42 zb15.alexus NetworkManager[8145]: <info>  [1463641422.0643] vpn-connection[0x5617c05107a0,f273dcb1-6ec3-4bd2-9b7b-1a7c0d28ed9d,"vpnc",0]: Started the VPN service, PID 11724
May 19 13:03:42 zb15.alexus NetworkManager[8145]: <info>  [1463641422.1107] vpn-connection[0x5617c05107a0,f273dcb1-6ec3-4bd2-9b7b-1a7c0d28ed9d,"vpnc",0]: Saw the service appear; activating connection
May 19 13:04:07 zb15.alexus NetworkManager[8145]: <error> [1463641447.3416] vpn-connection[0x5617c05107a0,f273dcb1-6ec3-4bd2-9b7b-1a7c0d28ed9d,"vpnc",0]: Failed to request VPN secrets #3: No agents were available for this request.

Comment 1 Andy Campbell 2016-07-04 19:12:52 UTC
Confirmed - I noticed this after upgrading to F24.  Was ok in F23

Comment 2 Adam Connor 2016-07-12 19:55:37 UTC
I had the same experience in Fedora 24. Seems like is it something hardcoded into NetworkManager: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/420411

Comment 3 Francesco Giudici 2016-07-13 11:55:20 UTC
Hi, thanks for reporting.

This seems a duplicate of bugs:
https://bugzilla.gnome.org/show_bug.cgi?id=767321
https://bugzilla.redhat.com/show_bug.cgi?id=1349740

It has been tackled upstream recently:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=10c53528552d1f0df8c28326a8f0bd2a31b9fa46

and has already been backported on nm-1-2 tree.
Should be fixed in the next release.

Comment 4 Fedora Update System 2016-08-05 07:53:01 UTC
NetworkManager-1.2.4-1.fc24 network-manager-applet-1.2.4-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-f739ece3cf

Comment 5 Fedora Update System 2016-08-05 21:21:41 UTC
NetworkManager-1.2.4-1.fc24, network-manager-applet-1.2.4-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-f739ece3cf

Comment 6 Fedora Update System 2016-08-18 16:39:07 UTC
NetworkManager-1.2.4-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-fade485364

Comment 7 Fedora Update System 2016-08-19 00:56:53 UTC
NetworkManager-1.2.4-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-fade485364

Comment 8 Fedora Update System 2016-08-19 10:29:15 UTC
network-manager-applet-1.2.4-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-f739ece3cf

Comment 9 Fedora Update System 2016-08-19 19:49:39 UTC
NetworkManager-1.2.4-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.