Bug 696107

Summary: NetworkManager Openconnect fails in FC15 Alpha
Product: [Fedora] Fedora Reporter: Charles Bovy <charles.bovy>
Component: NetworkManager-openconnectAssignee: Dan Williams <dcbw>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: dcbw, dwmw2, jlaska, tflink
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: RejectedBlocker, RejectedNTH
Fixed In Version: NetworkManager-openconnect-0.8.1-9.git20110419.fc15 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-24 04:10:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Charles Bovy 2011-04-13 09:39:18 UTC
Description of problem: In FC15 the NM-Openconnect doesn't work (or isn't ported yet to 0.9)


Version-Release number of selected component (if applicable): 0.8.1-7


How reproducible: always

Steps to Reproduce:
1. Configure OpenConnect VPN
2. Connect VPN
3.
  
Actual results: VPN failed


Expected results: auth-dialog with Username and SecurID form.


Additional info: F15 Alpha

If you need any additional  info, please let me know.

Comment 1 David Woodhouse 2011-04-13 09:42:27 UTC
I asked dcbw a few days ago what needed doing, and if he could point me at the corresponding commits in other VPN providers so I could do it.

I don't remember the details of that conversation, but I believe I came away without specific answers, and with the impression that he was going to do it himself.

Assigning to dcbw accordingly; if I was supposed to be doing it myself then I apologise for my stupidity; please assign it back and point me in the right direction (again) and I'll have a go.

Comment 2 David Woodhouse 2011-04-17 01:26:35 UTC
Commit 92933cf attempts to fix this, but it's not quite working.

The main problem is that NM seems to be storing some 'secrets' that I don't want it to (cookie), and *not* storing some secrets that I *do* want it to (xmlconfig)...

For example, this is the output from one run of my auth-dialog...

lasthost
192.55.54.27
lasthost-flags
0
form:main:username
david.woodhouse
form:main:username-flags
0
autoconnect
yes
autoconnect-flags
0
xmlconfig
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxBbnlDb25uZWN0UHJvZmlsZSB4bWxucz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvZW5jb2RpbmcvIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4c2k6c2NoZW1hTG9jYXRpb249Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL2VuY29kaW5nLyBBbnlDb25uZWN0UHJvZmlsZS54c2QiPg0KICAgIDxDbGllbnRJbml0aWFsaXphdGlvbj4NCiAgICAgICAgPFVzZVN0YXJ0QmVmb3JlTG9nb24gVXNlckNvbnRyb2xsYWJsZT0iZmFsc2UiPmZhbHNlPC9Vc2VTdGFydEJlZm9yZUxvZ29uPg0KICAgICAgICA8QXV0b21hdGljQ2VydFNlbGVjdGlvbiBVc2VyQ29udHJvbGxhYmxlPSJmYWxzZSI+dHJ1ZTwvQXV0b21hdGljQ2VydFNlbGVjdGlvbj4NCiAgICAgICAgPFNob3dQcmVDb25uZWN0TWVzc2FnZT5mYWxzZTwvU2hvd1ByZUNvbm5lY3RNZXNzYWdlPg0KICAgICAgICA8Q2VydGlmaWNhdGVTdG9yZT5Vc2VyPC9DZXJ0aWZpY2F0ZVN0b3JlPg0KICAgICAgICA8Q2VydGlmaWNhdGVTdG9yZU92ZXJyaWRlPmZhbHNlPC9DZXJ0aWZpY2F0ZVN0b3JlT3ZlcnJpZGU+DQogICAgICAgIDxBdXRvQ29ubmVjdE9uU3RhcnQgVXNlckNvbnRyb2xsYWJsZT0idHJ1ZSI+dHJ1ZTwvQXV0b0Nvbm5lY3RPblN0YXJ0Pg0KICAgICAgICA8TWluaW1pemVPbkNvbm5lY3QgVXNlckNvbnRyb2xsYWJsZT0idHJ1ZSI+dHJ1ZTwvTWluaW1pemVPbkNvbm5lY3Q+DQogICAgICAgIDxMb2NhbExhbkFjY2VzcyBVc2VyQ29udHJvbGxhYmxlPSJ0cnVlIj50cnVlPC9Mb2NhbExhbkFjY2Vzcz4NCiAgICAgICAgPEF1dG9SZWNvbm5lY3QgVXNlckNvbnRyb2xsYWJsZT0idHJ1ZSI+dHJ1ZQ0KICAgICAgICAJPEF1dG9SZWNvbm5lY3RCZWhhdmlvciBVc2VyQ29udHJvbGxhYmxlPSJ0cnVlIj5SZWNvbm5lY3RBZnRlclJlc3VtZTwvQXV0b1JlY29ubmVjdEJlaGF2aW9yPg0KICAgICAgICA8L0F1dG9SZWNvbm5lY3Q+DQogICAgICAgIDxBdXRvVXBkYXRlIFVzZXJDb250cm9sbGFibGU9ImZhbHNlIj50cnVlPC9BdXRvVXBkYXRlPg0KICAgICAgICA8UlNBU2VjdXJJREludGVncmF0aW9uIFVzZXJDb250cm9sbGFibGU9ImZhbHNlIj5BdXRvbWF0aWM8L1JTQVNlY3VySURJbnRlZ3JhdGlvbj4NCgkJPFBQUEV4Y2x1c2lvbiBVc2VyQ29udHJvbGxhYmxlPSJmYWxzZSI+RGlzYWJsZWQ8L1BQUEV4Y2x1c2lvbj4NCiAgICAgICAgPFdpbmRvd3NMb2dvbkVuZm9yY2VtZW50PlNpbmdsZUxvY2FsTG9nb248L1dpbmRvd3NMb2dvbkVuZm9yY2VtZW50Pg0KICAgICAgICA8V2luZG93c1ZQTkVzdGFibGlzaG1lbnQ+QWxsb3dSZW1vdGVVc2VyczwvV2luZG93c1ZQTkVzdGFibGlzaG1lbnQ+DQoJPEF1dG9tYXRpY1ZQTlBvbGljeT50cnVlDQoJCTxUcnVzdGVkRE5TRG9tYWlucz4qLmludGVsLmNvbTwvVHJ1c3RlZEROU0RvbWFpbnM+DQoJCTxUcnVzdGVkTmV0d29ya1BvbGljeT5EaXNjb25uZWN0PC9UcnVzdGVkTmV0d29ya1BvbGljeT4NCgkJPFVudHJ1c3RlZE5ldHdvcmtQb2xpY3k+Q29ubmVjdDwvVW50cnVzdGVkTmV0d29ya1BvbGljeT4NCgk8L0F1dG9tYXRpY1ZQTlBvbGljeT4NCiAgICAgICAgPENlcnRpZmljYXRlTWF0Y2g+DQogICAgICAgICAgICA8S2V5VXNhZ2U+DQogICAgICAgICAgICAgICAgPE1hdGNoS2V5PkRpZ2l0YWxfU2lnbmF0dXJlPC9NYXRjaEtleT4NCiAgICAgICAgICAgIDwvS2V5VXNhZ2U+DQogICAgICAgICAgICA8RXh0ZW5kZWRLZXlVc2FnZT4NCiAgICAgICAgICAgICAgICA8RXh0ZW5kZWRNYXRjaEtleT5DbGllbnRBdXRoPC9FeHRlbmRlZE1hdGNoS2V5Pg0KCQk8Q3VzdG9tRXh0ZW5kZWRNYXRjaEtleT4xLjIuODQwLjExMzc0MS4xLjUuMS4xMDEuMS4zPC9DdXN0b21FeHRlbmRlZE1hdGNoS2V5Pg0KICAgICAgICAgICAgPC9FeHRlbmRlZEtleVVzYWdlPg0KICAgICAgICA8L0NlcnRpZmljYXRlTWF0Y2g+DQogICAgPC9DbGllbnRJbml0aWFsaXphdGlvbj4NCiAgICA8U2VydmVyTGlzdD4NCgk8SG9zdEVudHJ5Pg0KCQk8SG9zdE5hbWU+IEludGVsIE5ldHdvcms8L0hvc3ROYW1lPg0KCQk8SG9zdEFkZHJlc3M+dnBuLmludGVsLmNvbTwvSG9zdEFkZHJlc3M+DQoJPC9Ib3N0RW50cnk+DQoJPEhvc3RFbnRyeT4NCgkJPEhvc3ROYW1lPkFNUiBGb2xzb20gQ0E8L0hvc3ROYW1lPg0KCQk8SG9zdEFkZHJlc3M+c2NzZm0uaW50ZWwuY29tPC9Ib3N0QWRkcmVzcz4NCgk8L0hvc3RFbnRyeT4NCgk8SG9zdEVudHJ5Pg0KCQk8SG9zdE5hbWU+QU1SIEZvcnQgQ29sbGlucyBDTzwvSG9zdE5hbWU+DQoJCTxIb3N0QWRkcmVzcz5zY3NmYy5pbnRlbC5jb208L0hvc3RBZGRyZXNzPg0KCTwvSG9zdEVudHJ5Pg0KCTxIb3N0RW50cnk+DQoJCTxIb3N0TmFtZT5BTVIgSHVkc29uIE1BPC9Ib3N0TmFtZT4NCgkJPEhvc3RBZGRyZXNzPnNjc2hkLmludGVsLmNvbTwvSG9zdEFkZHJlc3M+DQoJPC9Ib3N0RW50cnk+DQoJPEhvc3RFbnRyeT4NCgkJPEhvc3ROYW1lPkFNUiBKb25lcyBGYXJtIE9SPC9Ib3N0TmFtZT4NCgkJPEhvc3RBZGRyZXNzPnNjc2pmLmludGVsLmNvbTwvSG9zdEFkZHJlc3M+DQoJPC9Ib3N0RW50cnk+DQoJPEhvc3RFbnRyeT4NCgkJPEhvc3ROYW1lPkFNUiBBdXN0aW4gVFg8L0hvc3ROYW1lPg0KCQk8SG9zdEFkZHJlc3M+c2NzYW4uaW50ZWwuY29tPC9Ib3N0QWRkcmVzcz4NCgk8L0hvc3RFbnRyeT4NCgk8SG9zdEVudHJ5Pg0KCQk8SG9zdE5hbWU+Q0NSIENoaW5hIFNoYW5naGFpIE1hcnQ8L0hvc3ROYW1lPg0KCQk8SG9zdEFkZHJlc3M+c2Nzc2htLmludGVsLmNvbTwvSG9zdEFkZHJlc3M+DQoJPC9Ib3N0RW50cnk+DQoJPEhvc3RFbnRyeT4NCgkJPEhvc3ROYW1lPkNDUiBDaGluYSBaaXpodTwvSG9zdE5hbWU+DQoJCTxIb3N0QWRkcmVzcz5zY3NzaHouaW50ZWwuY29tPC9Ib3N0QWRkcmVzcz4NCgk8L0hvc3RFbnRyeT4NCgk8SG9zdEVudHJ5Pg0KCQk8SG9zdE5hbWU+Q0NSIFJ1c3NpYSBNb3Njb3c8L0hvc3ROYW1lPg0KCQk8SG9zdEFkZHJlc3M+c2Nza2guaW50ZWwuY29tPC9Ib3N0QWRkcmVzcz4NCgk8L0hvc3RFbnRyeT4NCgk8SG9zdEVudHJ5Pg0KCQk8SG9zdE5hbWU+R0FSIEluZGlhIEJhbmdhbG9yZTwvSG9zdE5hbWU+DQoJCTxIb3N0QWRkcmVzcz5zY3NpaW5kLmludGVsLmNvbTwvSG9zdEFkZHJlc3M+DQoJPC9Ib3N0RW50cnk+DQoJPEhvc3RFbnRyeT4NCgkJPEhvc3ROYW1lPkdBUiBKYXBhbjwvSG9zdE5hbWU+DQoJCTxIb3N0QWRkcmVzcz5zY3NqcC5pbnRlbC5jb208L0hvc3RBZGRyZXNzPg0KCTwvSG9zdEVudHJ5Pg0KCTxIb3N0RW50cnk+DQoJCTxIb3N0TmFtZT5HQVIgTWFsYXlzaWEgUGVuYW5nPC9Ib3N0TmFtZT4NCgkJPEhvc3RBZGRyZXNzPnNjc3BuLmludGVsLmNvbTwvSG9zdEFkZHJlc3M+DQoJPC9Ib3N0RW50cnk+DQoJPEhvc3RFbnRyeT4NCgkJPEhvc3ROYW1lPkdFUiBJc3JhZWwgSGFpZmE8L0hvc3ROYW1lPg0KCQk8SG9zdEFkZHJlc3M+c2NzaWlsLmludGVsLmNvbTwvSG9zdEFkZHJlc3M+DQoJPC9Ib3N0RW50cnk+DQoJPEhvc3RFbnRyeT4NCgkJPEhvc3ROYW1lPkdFUiBJc3JhZWwgTGFjaGlzaDwvSG9zdE5hbWU+DQoJCTxIb3N0QWRkcmVzcz5zY3NsYy5pbnRlbC5jb208L0hvc3RBZGRyZXNzPg0KCTwvSG9zdEVudHJ5Pg0KCTxIb3N0RW50cnk+DQoJCTxIb3N0TmFtZT5HRVIgVW5pdGVkIEtpbmdkb20gU3dpbmRvbjwvSG9zdE5hbWU+DQoJCTxIb3N0QWRkcmVzcz5zY3Npc3cuaW50ZWwuY29tPC9Ib3N0QWRkcmVzcz4NCgk8L0hvc3RFbnRyeT4NCiAgICA8L1NlcnZlckxpc3Q+DQo8L0FueUNvbm5lY3RQcm9maWxlPg0K
xmlconfig-flags
0
gateway
192.55.54.27:443
gateway-flags
0
gateway
192.55.54.27:443
gateway-flags
1
cookie
xxxxxelidedxxxx
cookie-flags
1
gwcert
2C1104B703504606AB12813AFC315438B94F85BB
gwcert-flags
1

... and this is what I get on stdin next time my auth-dialog is run:

DATA_KEY=lasthost-flags
DATA_VAL=4

DATA_KEY=xmlconfig-flags
DATA_VAL=4

DATA_KEY=pem_passphrase_fsid
DATA_VAL=yes

DATA_KEY=gwcert-flags
DATA_VAL=4

DATA_KEY=gateway-flags-flags
DATA_VAL=4

DATA_KEY=autoconnect-flags
DATA_VAL=4

DATA_KEY=enable_csd_trojan
DATA_VAL=no

DATA_KEY=usercert
DATA_VAL=/home/dwmw2/.cert/certificate.p12

DATA_KEY=cookie-flags-flags
DATA_VAL=4

DATA_KEY=cacert
DATA_VAL=/home/dwmw2/.cert/intel-certchain.crt

DATA_KEY=autoconnect-flags-flags
DATA_VAL=4

DATA_KEY=lasthost-flags-flags
DATA_VAL=4

DATA_KEY=gateway-flags
DATA_VAL=4

DATA_KEY=xmlconfig-flags-flags
DATA_VAL=4

DATA_KEY=gwcert-flags-flags
DATA_VAL=4

DATA_KEY=cookie-flags
DATA_VAL=4

DATA_KEY=form:main:username-flags
DATA_VAL=4

DATA_KEY=gateway
DATA_VAL=192.55.54.27

DATA_KEY=authtype
DATA_VAL=cert

DATA_KEY=form:main:username-flags-flags
DATA_VAL=4

DONE


And the need_secrets() function in nm-openconnect-service is never actually returning TRUE after the first successful connection, because the cookie is always already present (even though it's the old cookie).

What am I doing wrong?

Comment 3 David Woodhouse 2011-04-18 00:50:06 UTC
I think this should be basically working.

Please test the build at http://koji.fedoraproject.org/koji/taskinfo?taskID=3007611

Comment 4 Charles Bovy 2011-04-18 07:11:03 UTC
Thanks! I just tried.
The first time I ran the VPN, I got the auth-dialog, but VPN failed.
The second time I tried, the auth-dialog did not appear. Seems to do more than before, but no successful tunnel.

Apr 18 09:02:50 host NetworkManager[6178]: <info> Starting VPN service 'openconnect'...
Apr 18 09:02:50 host NetworkManager[6178]: <info> VPN service 'openconnect' started (org.freedesktop.NetworkManager.openconnect), PID 6790
Apr 18 09:02:50 host NetworkManager[6178]: <info> VPN service 'openconnect' appeared; activating connections
Apr 18 09:02:50 host NetworkManager[6178]: <info> VPN plugin state changed: 1
Apr 18 09:03:13 host NetworkManager[6178]: dbus_g_proxy_cancel_call: assertion `!DBUS_G_PROXY_DESTROYED (proxy)' failed
Apr 18 09:03:13 host NetworkManager[6178]: dbus_g_proxy_call_no_reply: assertion `!DBUS_G_PROXY_DESTROYED (proxy)' failed
Apr 18 09:03:13 host NetworkManager[6178]: <info> Policy set 'mooswief' (wlan0) as default for IPv4 routing and DNS.
Apr 18 09:03:18 host NetworkManager[6178]: <info> VPN service 'openconnect' disappeared
Apr 18 09:03:29 host dbus: [system] Activating service name='net.reactivated.Fprint' argv0='/lib/dbus-1/dbus-daemon-launch-helper'
Apr 18 09:03:29 host dbus: [system] Successfully activated service 'net.reactivated.Fprint'

Comment 5 David Woodhouse 2011-04-18 09:40:14 UTC
Can you run nm-openconnect-service (as root) from the command line, and run nm-applet from the command line too? 

Another debugging tool (which it would be nice if we could do with a command-line argument to nm-applet, perhaps), is to move nm-openconnect-auth-dialog out of the way and replace it with a shell script along the lines of this one:

#!/bin/sh

A=
( while [ "$A" != "DONE" ] ; do read A ;  echo "$A" ; done ) > /tmp/nm-auth-in-$$

cat /tmp/nm-auth-in-$$ >&2
cat /tmp/nm-auth-in-$$ | /home/dwmw2/git/network-manager-openconnect/auth-dialog/nm-openconnect-auth-dialog "$@" > /tmp/nm-auth-out-$$

echo "ARGS WERE $@" >> /tmp/nm-auth-in-$$
cat /tmp/nm-auth-out-$$
cat /tmp/nm-auth-out-$$ >&2


Note: DO NOT SHOW ME YOUR COOKIE. Note how I elided it in comment 2 above.

Comment 6 Fedora Update System 2011-04-19 13:35:48 UTC
NetworkManager-openconnect-0.8.1-9.git20110419.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/NetworkManager-openconnect-0.8.1-9.git20110419.fc15

Comment 7 Charles Bovy 2011-04-19 20:10:18 UTC
Update works, thanks! Case can be closed.

Comment 8 Fedora Update System 2011-04-20 02:42:16 UTC
Package NetworkManager-openconnect-0.8.1-9.git20110419.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing NetworkManager-openconnect-0.8.1-9.git20110419.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/NetworkManager-openconnect-0.8.1-9.git20110419.fc15
then log in and leave karma (feedback).

Comment 9 Tim Flink 2011-04-21 17:38:06 UTC
This was discussed at the 2011-04-21 blocker bug review meeting.

This bug does not impact any of the release criteria and thus, is not a blocker. It was deemed not to be a NTH since there are almost no situations where a user would need openvpn to pull down updates.

Once tested, this fix can be accepted into stable without blocker or nth.

Comment 10 Fedora Update System 2011-04-24 04:10:27 UTC
NetworkManager-openconnect-0.8.1-9.git20110419.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.