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 504807 - Can't connect with vpnc after entering password once
Can't connect with vpnc after entering password once
Status: RESOLVED DUPLICATE of bug 346547
Product: NetworkManager
Classification: Platform
Component: VPN: vpnc
0.6.6
Other All
: Normal major
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Blocks:
 
 
Reported: 2007-12-21 05:50 UTC by Phil Mitchell
Modified: 2008-11-14 16:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Phil Mitchell 2007-12-21 05:50:20 UTC
Please describe the problem:
My network uses a key fob for the user password, but a static group password.  When I select the option to remember only the group password, it attempts to remember both (though only the group password is stored in the keyring).

Steps to reproduce:
1. Select VPN to connect
2. Select "Save group password in keyring"
3. Enter the passwords
4. Click OK
5. Wait for the VPN to connect, then disconnect it
6. Select the same VPN to connect

Alternative (once the group password is in the keyring):
1. Select VPN to connect
2. Click Cancel in the password dialog



Actual results:
NetworkManager shows the vpn-connecting-icon for a second, and then gives up.  The following appears on the console (in both cases):

** Message: <info>  vpnc started with pid 24863

NetworkManager: <info>  VPN connection 'MyVPN' (Connect) reply received.
/usr/sbin/vpnc: warning: unknown configuration directive in stdin at line 2
/usr/sbin/vpnc: warning: unknown configuration directive in stdin at line 3
/usr/sbin/vpnc: warning: unknown configuration directive in stdin at line 4
/usr/sbin/vpnc: warning: unknown configuration directive in stdin at line 6
/usr/sbin/vpnc: noninteractive can't reuse password

Subsequent attempts to connect, even if you've used the alternative repro (i.e. clicked cancel) will forego the password dialog and give the error above.

In order to reset this behaviour, I have to restart NetworkManager, at which point it works as expected (the first time I connect to VPN).

Expected results:
Since the user password should not have been remembered in any way, I should have been prompted for my password again.

Does this happen every time?
Yes.

Other information:
Comment 1 jeremy 2008-03-20 22:02:58 UTC
I'm seeing exactly the same thing.  It should always re-prompt for the password and not attempt to cache it.
Comment 2 jeremy 2008-03-20 22:15:42 UTC
Duplicate of 363918, btw.
Comment 3 Phil Mitchell 2008-03-21 01:03:42 UTC
Not really.  363918 is more of a request for this feature.  The feature appears to be there (the dialog has the appropriate radio button), but it just doesn't work.  This is not a feature request, but a request to make it work as it was supposed to.  

Now, it's possible that whoever added the radio buttons intended to have the user password saved in memory (i.e. remember for session), but there's actually a radio button that says "remember passwords for this session."  I did not select that one, so it should not do so....maybe I'm missing something in the wording.

Speaking strictly about one distribution (hopefully w/o loss of generality), the release that came with Fedora Core 5 worked perfectly.  That release included a patch that was provided by Red Hat.  Fedora Core 6 and 7 did not have the feature at all.  Fedora Core 8 has the feature, but, as I've explained, it does not work.
Comment 4 Denis Leroy 2008-04-27 08:22:46 UTC
You may want to try to clean up your passwords with gnome-keyring manager. If the password is found in the keyring manager, the VPNC dialog will use to fill the dialog. We need to fix this by storing the preference in gconf also...
Comment 5 jeremy 2008-04-27 08:31:20 UTC
(In reply to comment #4)
> You may want to try to clean up your passwords with gnome-keyring manager. If
> the password is found in the keyring manager, the VPNC dialog will use to fill
> the dialog. We need to fix this by storing the preference in gconf also...

As I said in the original report, the keyring does not remember my password.  But NetworkManager itself does, so its impossible to reconnect to the vpn without restarting it.
Comment 6 jeremy 2008-04-27 08:35:09 UTC
Uh, s/As I said in the original report/As the original report says/
Comment 7 Denis Leroy 2008-04-27 09:05:18 UTC
Yes sorry, I realized that soon after replying. NM indeed caches the password in memory...
Comment 8 Phil Mitchell 2008-04-27 15:41:32 UTC
In response to Denis' original comment, my keyring was empty when I was trying this.  Also, I wouldn't have a problem if it used the stored passwords to "fill in" the box, but it doesn't even *display* the box, so I have no opportunity to change the group password.  However, as Jeremy pointed out, the real problem here is that NM is caching the password even when I think I'm asking it not to.

I realize now that the 3 radio buttons:  "store in memory", "store both passwords in keyring", or "store group password in keyring" imply that the store in memory part will always happen because there is no way to store *nothing.*

Change the options to checkboxes: "store in meomory," "store group password in keyring," and "store user password in keyring," and all will be well (when the underlying behaviour matches the check boxes, of course).  You might consider splitting up the first option into "store group password in memory" and "store user password in memory," but I'm not all that concerned as I won't be using the in-memory options.

Alternatively, you could have:
Store Group password in:
 X memory
 X keyring
Store User password in:
 X memory
 X keyring

or:
Store group password: "Nowhere"|"Memory"|"Keyring"|"Both" (drop-down)
Store user password: "Nowhere"|"Memory"|"Keyring"|"Both" (drop-down)

There are lots of UI options, but the important thing is that it doesn't store the password when I don't want it to.
Comment 9 Dan Williams 2008-11-14 16:58:54 UTC
Fixed in svn r4283

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