Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1271973

Summary: no more vpn dialog after previous canceling
Product: Red Hat Enterprise Linux 7 Reporter: Vladimir Benes <vbenes>
Component: NetworkManager-libreswanAssignee: Lubomir Rintel <lrintel>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 7.2CC: lmiksik, lrintel, rkhan
Target Milestone: rcKeywords: Regression
Target Release: 7.2   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: NetworkManager-libreswan-1.0.6-3.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 11:06:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
NetworkManager's log
none
[nm-libreswan 1/3] Early fail race fix
none
full log
none
[nm-libreswan 2/3] Fix for 100% cpu load on disconnect
none
[nm-libreswan 3/3] Fix reconnecting after a failure
none
[nm] Avoid disconnecting connection following an unsuccessful connection attempt none

Description Vladimir Benes 2015-10-15 08:14:15 UTC
Description of problem:
Canceling gnome's dialog after entering wrong password and leads to an inconsistent libreswan vpn state. I can then connect w/o entering any credentials seeing an lock icon for a short period in GS but it disappears again in a while. I am not connected anytime. 
 
Version-Release number of selected component (if applicable):
NetworkManager-1.0.6-21.el7.x86_64
gnome-shell-3.14.4-36.el7.x86_64
NetworkManager-libreswan-1.0.6-1.el7.x86_64
libreswan-3.12-10.1.el7_1.x86_64


How reproducible:
always

Steps to Reproduce:
1.start vpn connection
2.enter incorrect password 
3.cancel dialog when re-questioned
4.try to connect once more

Actual results:
no more dialog

Expected results:
should have dialog again

Additional info:

Comment 1 Vladimir Benes 2015-10-15 08:15:26 UTC
Created attachment 1083164 [details]
NetworkManager's log

Comment 2 Lubomir Rintel 2015-10-20 18:06:34 UTC
I can't reproduce this one. Seems like the nm-libreswan-service is stuck somehow and doesn't respond.

I'm wondering if you could check if it's really running and check what blocks it (attach gdb and get a traceback or maybe just strace it to see if it is caught in a loop)?

Comment 3 Vladimir Benes 2015-10-21 10:22:48 UTC
(In reply to Lubomir Rintel from comment #2)
> I can't reproduce this one. Seems like the nm-libreswan-service is stuck
> somehow and doesn't respond.
> 
We've reproduced together. You just need to connect, write in incorrect password and then when second dialog appears press cancel button.

> I'm wondering if you could check if it's really running and check what
> blocks it (attach gdb and get a traceback or maybe just strace it to see if
> it is caught in a loop)?

Comment 4 Lubomir Rintel 2015-10-21 15:28:40 UTC
Created attachment 1085201 [details]
[nm-libreswan 1/3] Early fail race fix

Brew build: https://brewweb.devel.redhat.com/taskinfo?taskID=9991436

Comment 5 Vladimir Benes 2015-10-22 08:02:44 UTC
Lubo,
it's slightly better as I can see another dialog after unsuccessful connection but that dialog doesn't work anymore with these errors:
 
Oct 22 09:52:08 trautenberg NetworkManager[927]: <info>  VPN plugin state changed: starting (3)
Oct 22 09:52:08 trautenberg NetworkManager[927]: <info>  VPN connection 'redhat' (ConnectInteractive) reply received.
Oct 22 09:52:08 trautenberg NetworkManager[927]: <warn>  VPN connection 'redhat' failed to connect interactively: 'Already connecting!'.
Oct 22 09:52:08 trautenberg NetworkManager[927]: <warn>  error disconnecting VPN: Could not process the request because no VPN connection was active.
Oct 22 09:52:14 trautenberg NetworkManager[927]: <info>  VPN plugin state changed: starting (3)
Oct 22 09:52:14 trautenberg NetworkManager[927]: <info>  VPN connection 'redhat' (ConnectInteractive) reply received.
Oct 22 09:52:14 trautenberg NetworkManager[927]: <warn>  VPN connection 'redhat' failed to connect interactively: 'Already connecting!'.
Oct 22 09:52:14 trautenberg NetworkManager[927]: <warn>  error disconnecting VPN: Could not process the request because no VPN connection was active.

whole log attached (3 incorrect attempts + new opening and 2 immediate failures)

Comment 6 Vladimir Benes 2015-10-22 08:03:34 UTC
Created attachment 1085437 [details]
full log

Comment 7 Vladimir Benes 2015-10-22 08:34:40 UTC
and whatmore it's eating a lot of CPU:
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                              
 3554 root      20   0  262752   3804   3012 R 100.0  0.0   0:56.65 nm-libreswan-se

it sits there for 3 minutes and then goes away. I can reconnect after it's gone.

Comment 8 Lubomir Rintel 2015-10-22 12:38:31 UTC
Created attachment 1085489 [details]
[nm-libreswan 2/3] Fix for 100% cpu load on disconnect

Comment 9 Lubomir Rintel 2015-10-22 12:41:14 UTC
Created attachment 1085491 [details]
[nm-libreswan 3/3] Fix reconnecting after a failure

Comment 10 Lubomir Rintel 2015-10-22 12:42:30 UTC
Created attachment 1085494 [details]
[nm] Avoid disconnecting connection following an unsuccessful connection attempt

Comment 12 Thomas Haller 2015-10-23 14:12:56 UTC
All patches LGTM. Didn't test though.

Comment 13 Lubomir Rintel 2015-10-23 16:38:47 UTC
nm-1-0:

26094b7 service: always tear down the connection on helper failure
f516f6b service: watch for pty master hangups
636b2a5 service: don't delete connection while it's being upped

master:

50fc66b service: always tear down the connection on helper failure
984035d service: watch for pty master hangups
f58fde3 service: don't delete connection while it's being upped

Comment 17 Vladimir Benes 2015-10-29 14:52:21 UTC
this works well with current libreswan and NM package.

Comment 18 errata-xmlrpc 2015-11-19 11:06:21 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-2315.html