Bug 586194 - Unable to connect to connect with Juniper VPN client
Unable to connect to connect with Juniper VPN client
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: java-1.6.0-openjdk (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Deepak Bhole
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-26 23:43 EDT by Ray Van Dolson
Modified: 2015-01-19 08:08 EST (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-16 18:30:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
icedtea stderr (87.98 KB, text/plain)
2010-04-26 23:45 EDT, Ray Van Dolson
no flags Details
icedtea stdout (1.01 KB, text/plain)
2010-04-26 23:45 EDT, Ray Van Dolson
no flags Details
Screenshot of debugger session (175.14 KB, image/png)
2011-12-07 14:00 EST, Thomas Meyer
no flags Details
GetMemberPluginCallRequest.parseReturn (190.54 KB, image/png)
2011-12-07 14:07 EST, Thomas Meyer
no flags Details
PluginAppletViewer.getMember (193.78 KB, image/png)
2011-12-07 14:09 EST, Thomas Meyer
no flags Details
relevant log of getMember("cookie") (4.48 KB, text/plain)
2011-12-07 14:37 EST, Thomas Meyer
no flags Details
icedtea.log (703.72 KB, text/x-log)
2011-12-26 21:05 EST, Garrett Mitchener
no flags Details
~/.icedtea/java.stderr (501.91 KB, application/octet-stream)
2011-12-26 21:07 EST, Garrett Mitchener
no flags Details
"Trusted Certificate" "MultiFactor" in itweb-settings (36.54 KB, image/png)
2011-12-28 17:37 EST, Thomas Meyer
no flags Details
output from firefox (73.36 KB, text/plain)
2012-01-20 17:58 EST, Garrett Mitchener
no flags Details
corresponding java.stderr (49.63 KB, application/octet-stream)
2012-01-20 17:59 EST, Garrett Mitchener
no flags Details
corresponding thread dump (17.86 KB, text/plain)
2012-01-20 18:00 EST, Garrett Mitchener
no flags Details
icedtea-web-1.2.1-fc16 crashlog generated from ABRT. (11.21 KB, text/x-log)
2012-03-22 14:14 EDT, Dominik Kupschke
no flags Details
Backtrace (99.64 KB, text/plain)
2012-03-22 14:39 EDT, Dominik Kupschke
no flags Details
icedtea logs (48.63 KB, application/zip)
2012-03-22 15:38 EDT, Dominik Kupschke
no flags Details
icedtea x64 logs from Fedora 16 x64 (19.90 KB, application/zip)
2012-03-23 02:08 EDT, Dominik Kupschke
no flags Details

  None (edit)
Description Ray Van Dolson 2010-04-26 23:43:11 EDT
After upgrading from Fedora 11 to Fedora 13, I am unable to connect to my enterprise's VPN (running Juniper NetworkConnect).

I have removed both the ~/.juniper_networks and ~/.icedteaplugin directories.

The applet appears to start up, but does not successfully connect -- instead, a "session timeout" window pops up and the applet exits.

I will attach debug output.

firefox-3.6.3-4.fc13.i686
java-1.6.0-openjdk-plugin-1.6.0.0-37.b17.fc13.i686
Comment 1 Ray Van Dolson 2010-04-26 23:45:04 EDT
Created attachment 409346 [details]
icedtea stderr
Comment 2 Ray Van Dolson 2010-04-26 23:45:27 EDT
Created attachment 409347 [details]
icedtea stdout
Comment 3 Ray Van Dolson 2010-04-26 23:46:32 EDT
[rayvd@tinyox .icedteaplugin]$ find . -type f -ls
10402823  136 -rw-rw-r--   1 rayvd    rayvd      132951 Apr 26 18:16 ./cache/https/connect.esri.com/dana-cached/nc/ncLinuxLauncher.jar
10402812    4 -rw-rw-r--   1 rayvd    rayvd         146 Apr 26 18:16 ./cache/https/connect.esri.com/dana-cached/nc/ncLinuxLauncher.jar.info
10402786    4 -rw-rw-r--   1 rayvd    rayvd        1038 Apr 26 18:16 ./java.stdout
10402718   92 -rw-rw-r--   1 rayvd    rayvd       90089 Apr 26 18:16 ./java.stderr

There appears to be some sort of null pointer exception in the stderr output.  I'm not sure if this particular error occurred under Fedora 11 and was harmless or not.
Comment 4 Ray Van Dolson 2010-04-29 22:08:49 EDT
Confirmed that I am able to connect with the Sun 1.6.0_20 JRE libnpjp2.so plugin.
Comment 5 JYundt 2010-05-26 13:52:41 EDT
I am having the same results on an Asus 1005HA running Fedora 13 i386.  Using ncui 6.3.
Comment 6 Samuel Sieb 2010-06-07 15:55:14 EDT
I get the same thing with seamonkey.  I just upgraded (re-install) to F13 from F11 and now it doesn't work.  The first attempt crashed the browser.  Following attempts load, but don't work.  And I see the endless null pointer exceptions in the icedtea logs.
Comment 7 Samuel Sieb 2010-06-07 16:03:23 EDT
It appears to be related to the graphical interface.  On the client I'm using, there are three tabs.  If I'm viewing the first one that normally shows a blinking "light" showing the connection status and also shows the traffic counters, then the exceptions get logged.  If I change to one of the other tabs, the exceptions stop, but the connection still doesn't work.  If I close the applet popup window and reopen it, it doesn't load.  I have to restart the browser.
Comment 8 Samuel Sieb 2010-06-07 17:30:15 EDT
I found a couple of potentially related errors.
In the browser's "Error Console", there is the following message:
Error: uncaught exception: Error calling method on NPObject! [plugin exception: null ].

In the java.stdout:
Cannot get IVE host: java.lang.ClassCastException: netscape.javascript.JSObject cannot be cast to java.lang.String
Get run level: https:/dana/cs/csdbg.cgi?app=jcp error: java.net.ConnectException: Connection refused

That URL should have a hostname before the /dana part.
Comment 9 Shane F. 2010-06-08 13:59:02 EDT
Having the same issue with Juniper VPN access using OpenJDK,  switched to Oracle/Sun java for now and that works fine.  Will switch back once openJDK is fixed.
Comment 10 Samuel Sieb 2010-06-09 13:40:01 EDT
I just installed the Sun JVM package and it works for me as well.
Comment 11 Ray Van Dolson 2011-01-13 22:04:24 EST
This also happens in Fedora 14.  Applet comes up, but am immediately disconnected.  Works fine with Sun's JRE and plugin.
Comment 12 Chris Kloiber 2011-01-25 20:16:34 EST
Here's the error I'm see ing on F14/x86_64: (Substituting "company.com" for my actual employer name.

[ckloiber@f14 ~]$ firefox
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.4) (fedora-50.1.9.4.fc14-x86_64)
OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)
Calling Super Init.
document not found!
cookie not found!
/home/ckloiber/.juniper_networks
Here is the standard output of the command:

No difference found
Here is the standard error of the command (if any):

in get Proxy info..
linux_start_script= 
linux_end_script= 
notification_message= null
always_show_notification_msg= null
dnsSuffix= company.com,corp.company.com
para 0 is /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java
para 1 is -classpath
para 2 is /home/ckloiber/.juniper_networks/network_connect/NC.jar
para 3 is NC
para 4 is -h
para 5 is vpn.company.com
para 6 is -n
para 7 is 
para 8 is -t
para 9 is 
para 10 is -x
document not found!
cookie not found!
java.lang.ClassCastException: netscape.javascript.JSObject cannot be cast to java.lang.String
	at SecureNCLauncher.getDSID(SecureNCLauncher.java:213)
	at SecureNCLauncher.RunTargetApp(SecureNCLauncher.java:416)
	at SecureLauncherApplet.startTargetApp(SecureLauncherApplet.java:473)
	at SecureLauncherApplet.doInstall(SecureLauncherApplet.java:253)
	at SecureLauncherApplet.start(SecureLauncherApplet.java:223)
	at sun.applet.AppletPanel.run(AppletPanel.java:476)
	at java.lang.Thread.run(Thread.java:636)
ERROR ___ get DSID __ FAILED 
Launching "/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java" "-classpath" "/home/ckloiber/.juniper_networks/network_connect/NC.jar" "NC" "-h" "vpn.company.com" "-n" "" "-t" "" "-x" 
Res: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java -classpath /home/ckloiber/.juniper_networks/network_connect/NC.jar NC -h vpn.company.com -n  -t  -x
Comment 13 Deepak Bhole 2011-01-26 10:35:52 EST
(In reply to comment #12)
> Here's the error I'm see ing on F14/x86_64: (Substituting "company.com" for my
> actual employer name.
> 
...
> cookie not found!
> java.lang.ClassCastException: netscape.javascript.JSObject cannot be cast to
> java.lang.String
>  at SecureNCLauncher.getDSID(SecureNCLauncher.java:213)

Thanks for the trace. 

The above looks like an error in the server side code, and not the plugin. It is attempting to cast netscape.javascript.JSObject provided by the plugin to a String, which is not possible given that JSOBject inherits from java.lang.Object (Both in IcedTea plugin and in the Oracle plugin).
Comment 14 Ray Van Dolson 2011-01-26 10:50:05 EST
Chris, does everything work OK for you using Sun's (Oracle's) JRE?  What version?

I will try to get a trace on my Fedora 14 system as well.
Comment 15 JYundt 2011-01-26 10:57:27 EST
I can confirm that the juniper client (ncui-6.5-R6) works fine with Sun JRE 1.6.0_23 on i686.  The OpenJDK does _not_ work.
Comment 16 Chris Kloiber 2011-01-27 02:14:31 EST
Alas, no. I can only get the VPN working with Windows or Mac OS X at this time. The ncui rpm version our company uses is also newer than those listed. 

NetworkConnectLinux_7.0R1.i386.rpm
Comment 17 Ray Van Dolson 2011-01-30 22:08:48 EST
I have been troubleshooting this a bit tonight on Fedora 14 (32-bit) with the current stable OpenJDK's.

I get the same JSObject issue:

java.lang.ClassCastException: netscape.javascript.JSObject cannot be cast to java.lang.String

The applet starts up, but shortly thereafter closes out with a connection error.

However, if I call NC.jar from the command line (using the junipernc script[1] for example), I can connect.

Note that this is with Network Connect 6.4R2.  I will test with Sun's JRE, but I presume it will work as it did with Fedora 13.

[1] http://mad-scientist.us/juniper.html
Comment 18 Ray Van Dolson 2011-01-30 22:53:43 EST
Confirmed that everything works fine when initiated from the web browser when using Sun's JRE:

java-1.6.0-sun-plugin-1.6.0.22-1jpp.1.el6.i686
java-1.6.0-sun-1.6.0.22-1jpp.1.el6.i686

(Pulled these from RHEL6 Supplemental).

So, I understand the thought is that this is a bug in Juniper's Network Connect; however:

- My company's version of Network Connect has not been upgraded in a long while.  It _used_ to work with OpenJDK just fine.
- It works with Sun's JRE.
Comment 19 Garrett Mitchener 2011-10-01 21:43:25 EDT
I'm using fedora 15, just updated to firefox 7.  I have NEVER been able to get the juniper VPN to work with OpenJDK.

I used to use the Sun/Oracle JDK and once I got it installed, it would work.  But something about firefox 7 that just got pushed broke it.

From about:plugins:

IcedTea-Web Plugin (using IcedTea-Web 1.0.5 (fedora-1.fc15-i386))

    File: IcedTeaPlugin.so

Here's the output on the console using OpenJDK / IcedTea:

java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.3) (fedora-59.1.10.3.fc15-i386)
OpenJDK Server VM (build 20.0-b11, mixed mode)
java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:616)
	at sun.applet.PluginAppletSecurityContext$4.run(PluginAppletSecurityContext.java:691)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.applet.PluginAppletSecurityContext.handleMessage(PluginAppletSecurityContext.java:688)
	at sun.applet.AppletSecurityContextManager.handleMessage(AppletSecurityContextManager.java:69)
	at sun.applet.PluginStreamHandler.handleMessage(PluginStreamHandler.java:310)
	at sun.applet.PluginMessageHandlerWorker.run(PluginMessageHandlerWorker.java:80)
Caused by: java.lang.NullPointerException
	at SecureAuth.ImportPKCS12(SecureAuth.java:1870)
	at SecureAuth.access$2400(SecureAuth.java:42)
	at SecureAuth$13.run(SecureAuth.java:2327)
	at java.security.AccessController.doPrivileged(Native Method)
	at SecureAuth.SaveUserCertificate(SecureAuth.java:2321)
	... 10 more
Error on Java side: null
Comment 20 Garrett Mitchener 2011-10-02 22:36:08 EDT
I found part of my problem: I disabled third party cookies in Firefox at some point, which breaks the Juniper VPN connection process, at least at my institution.  (And I knew that and forgot and tinkered with it and had to un-forget.  *sigh*  This Juniper VPN has been just one frustrating waste of time after another for me...)  Now that I've enabled third party cookies again, Juniper VPN works with the Sun / Oracle JDK 1.6.0u25 and firefox 7.  But I also have to disable OpenJDK: Remove the link /usr/lib/mozilla/plugins/libjavaplugin.so
Comment 21 Dennis Appelon Nielsen 2011-11-15 16:48:21 EST
What is the status of making this work with OpenJDK ? I just switched from Oracle Java to OpenJDK, and found it works fine for me, now after my company have switched to Juniper VPN I have to use Oracle Java again ?

I was told that OpenJDK and Oracle/SUN JDK is the same...

My Output when I try to connect...

OpenJDK Runtime Environment (IcedTea6 1.10.4) (fedora-60.1.10.4.fc16-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
Calling Super Init.
/root/.juniper_networks
Here is the standard output of the command:

No difference found
Here is the standard error of the command (if any):

in get Proxy info..
linux_start_script= 
linux_end_script= 
notification_message= null
always_show_notification_msg= null
dnsSuffix= logica.com,logica.co.uk,uk.logica.com, groupinfra.com,groupinfra.de, global.logica.com,logica.com
para 0 is /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java
para 1 is -classpath
para 2 is /root/.juniper_networks/network_connect/NC.jar
para 3 is NC
para 4 is -h
para 5 is gateway6.logica.com
para 6 is -L
para 7 is 0
para 8 is -l
para 9 is 0
para 10 is -n
para 11 is 
para 12 is -t
para 13 is 
para 14 is -x
java.lang.ClassCastException: netscape.javascript.JSObject cannot be cast to java.lang.String
	at SecureNCLauncher.getDSID(SecureNCLauncher.java:213)
	at SecureNCLauncher.RunTargetApp(SecureNCLauncher.java:416)
	at SecureLauncherApplet.startTargetApp(SecureLauncherApplet.java:473)
	at SecureLauncherApplet.doInstall(SecureLauncherApplet.java:253)
	at SecureLauncherApplet.start(SecureLauncherApplet.java:223)
	at sun.applet.AppletPanel.run(AppletPanel.java:476)
	at net.sourceforge.jnlp.NetxPanel.run(NetxPanel.java:69)
	at java.lang.Thread.run(Thread.java:679)
ERROR ___ get DSID __ FAILED 
Launching "/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java" "-classpath" "/root/.juniper_networks/network_connect/NC.jar" "NC" "-h" "gateway6.logica.com" "-L" "0" "-l" "0" "-n" "" "-t" "" "-x" 
Res: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java -classpath /root/.juniper_networks/network_connect/NC.jar NC -h gateway6.logica.com -L 0 -l 0 -n  -t  -x
Comment 22 Adam Hough 2011-11-22 19:19:55 EST
Dennis:

You have an additional issue in that you are using a 64-bit Fedora. 

For Juniper network connect Version: 7.1R2 to work you have to use a 32-java environment as the file that it installs some binaries and libraries that are 32-bit in your home directory.

~/.juniper_networks/network_connect $ file ncdiag
ncdiag: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped
~/.juniper_networks/network_connect $ file libncui.so
libncui.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped


It is not really a java problem but a java + binary blob issue.

The way around this is to run firefox in a 32 bit mode.
 ~/bin $ cat firefox-32 
#!/bin/bash
JAVA_HOME=/usr/java/default-i386
export PATH=$JAVA_HOME/bin:$PATH
setarch i386 firefox
 
I have java setup so that I have a 32-bit java installed just for when I run firefox in 32-bit mode.


This is the work around I have found.
Comment 23 Deepak Bhole 2011-12-05 10:44:30 EST
I am going to close this since it is an error in the applet code, and not icedtea-web. However, please feel free to keep adding comments for the record.
Comment 24 Thomas Meyer 2011-12-05 15:50:16 EST
Hi Deepak,

why does the applet work with the Sun/Oracle mozilla plugin then, if this is not a bug in the icedtea-web plugin?
Comment 25 Deepak Bhole 2011-12-05 16:01:22 EST
Doh. Sorry, I misread the above trace and thought the error happened with Oracle plug-in too.

Re-opening.
Comment 26 Samuel Sieb 2011-12-05 16:16:32 EST
It also doesn't work with the 32-bit version of openjdk.
Comment 27 Deepak Bhole 2011-12-06 17:20:35 EST
I think a assessment of CLOSED CANTFIX is more appropriate here.

I have no idea how it is working with the Oracle plugin, it shouldn't (assuming it is trying to do the same thing, casting JSObject to String). It shouldn't work because String is a final class and thus cannot be extended by JSObject.

Since I cannot see the Juniper code, I cannot be certain. But based on the logs, I don't see what IcedTea-Web can do to fix this.
Comment 28 Thomas Meyer 2011-12-07 01:20:53 EST
Hi,

some more infos from my side. I see this stack trace:
java.lang.ClassCastException: netscape.javascript.JSObject cannot be cast to java.lang.String
	at SecureHCLauncher.GetHTMLParams(SecureHCLauncher.java:106)
	at SecureLauncherApplet.RunTargetAppCommand(SecureLauncherApplet.java:691)
	at SecureHCLauncher.RunTargetApp(SecureHCLauncher.java:589)
	at SecureLauncherApplet.startTargetApp(SecureLauncherApplet.java:473)
	at SecureHCLauncher.doInstall(SecureHCLauncher.java:259)
	at SecureLauncherApplet.start(SecureLauncherApplet.java:223)
	at SecureHCLauncher.start(SecureHCLauncher.java:205)
	at sun.applet.AppletPanel.run(AppletPanel.java:476)
	at net.sourceforge.jnlp.NetxPanel.run(NetxPanel.java:69)
	at java.lang.Thread.run(Thread.java:679)

The message "java.lang.ClassCastException: netscape.javascript.JSObject cannot be cast to java.lang.String" is actually not true.

Looking at SecureHCLauncher.GetHTMLParams() it does:
1.) Calls private method SecureHCLauncher.getBrowserDocument() which returns a JSObject (private method first calls JSObject.getWindow() and than JSObject.getMember("document"))
2.) Call JSObject.getMember("cookie") which returns an Object, that should be a String.
3.) Above Exception occurs.

I can see this corresponding entries in the java.stderr plugin log:
[...]
JSObject.getMember GOT [object HTMLDocument]
JSObject.getMember cookie
[...]
JSObject.getMember GOT lastRealm=company; DSSIGNIN=url_default; DSPREAUTH=xxxxx

The code in SecureHCLauncher.GetHTMLParams() actually tries to extract the value of DSPREAUTH, but fails as the Object returned by getMember("cookie") doesn't seem to return a String.

OTOH the log entries indicates that the returned "cookie" string is okay! Something strange is going on here!
Comment 29 Thomas Meyer 2011-12-07 13:42:46 EST
Some more remote debugging of the applet jvm:

request for getMember("cookie") is set for "instance 0 reference 9 GetMember 3583646000 58" via requestFactory.getPluginCallRequest().
Stack:
Thread [Thread-5] (Ausgesetzt (Unterbrechungspunkt bei Zeile 1002 in PluginAppletViewer))	
	PluginAppletViewer.getMember(long, String) Zeile: 1002	
	JSObject.getMember(String) Zeile: 155	
	SecureHCLauncher.GetHTMLParams() Zeile: 106	
	SecureHCLauncher(SecureLauncherApplet).RunTargetAppCommand() Zeile: 691	
	SecureHCLauncher.RunTargetApp() Zeile: 589	
	SecureHCLauncher(SecureLauncherApplet).startTargetApp() Zeile: 473	
	SecureHCLauncher.doInstall() Zeile: 259	
	SecureHCLauncher(SecureLauncherApplet).start() Zeile: 223	
	SecureHCLauncher.start() Zeile: 205	
	NetxPanel(AppletPanel).run() Zeile: 476	
	NetxPanel.run() Zeile: 69	
	Thread.run() Zeile: 679	

Next thing I see is this (in a different thread):
Thread [Thread-3] (Ausgesetzt (Unterbrechungspunkt bei Zeile 54 in GetMemberPluginCallRequest))	
	GetMemberPluginCallRequest.parseReturn(String) Zeile: 54	
	PluginStreamHandler.finishCallRequest(String) Zeile: 300	
	PluginStreamHandler.handleMessage(String) Zeile: 224	
	PluginMessageHandlerWorker.run() Zeile: 78	

with "reference 9 JavaScriptGetSlot 62"! I guess this message should be "JavaScriptGetMember". But I dont know how sends this message in this multi-thread consumer/produced world.

After the JavaScriptGetSlot finish, the JSObject.getMember() will find a JSObject after the request.wait() is finished.

any ideas who sends the wrong "GetSlot" message?
Comment 30 Thomas Meyer 2011-12-07 14:00:09 EST
Created attachment 542128 [details]
Screenshot of debugger session

I think the problem is that for the getMember request "cookie" (which I guess is a String in the javascript object an JSObject instead of a String is returned. See also the attached screenshot! If you want me to debug some special line just drop me an email.
Comment 31 Thomas Meyer 2011-12-07 14:02:10 EST
Oops wrong screenshot. above was for request "document". sorry.
Comment 32 Omair Majid 2011-12-07 14:04:10 EST
(In reply to comment #28)

> I can see this corresponding entries in the java.stderr plugin log:
> JSObject.getMember GOT [object HTMLDocument]
> JSObject.getMember cookie
> [...]
> JSObject.getMember GOT lastRealm=company; DSSIGNIN=url_default; DSPREAUTH=xxxxx
> 
> The code in SecureHCLauncher.GetHTMLParams() actually tries to extract the
> value of DSPREAUTH, but fails as the Object returned by getMember("cookie")
> doesn't seem to return a String.
> 
> OTOH the log entries indicates that the returned "cookie" string is okay!
> Something strange is going on here!

Would you mind posting more of the log? I am curious if there are any additional hints about what's going on in the [...] section.

As noted in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4260458 the cast:
(String) window.getMember("document").getMember("cookie")
is supposed to succeed.
Comment 33 Thomas Meyer 2011-12-07 14:07:46 EST
Created attachment 542136 [details]
GetMemberPluginCallRequest.parseReturn

GetMemberPluginCallRequest.parseReturn for "cookie" before request.wait() finishes
Comment 34 Thomas Meyer 2011-12-07 14:09:56 EST
Created attachment 542137 [details]
PluginAppletViewer.getMember

PluginAppletViewer.getMember after request.wait() has finished for "cookie" and returned an JSObject. I guess a String should be returned here!
Comment 35 Thomas Meyer 2011-12-07 14:37:57 EST
Created attachment 542151 [details]
relevant log of getMember("cookie")
Comment 36 Thomas Meyer 2011-12-08 15:45:35 EST
I think the problem is in "IcedTeaPluginRequestProcessor.cc" in "PluginRequestProcessor::sendMember". I guess this function will always create a "JSObject" object, I'm not sure if this is correct.

Also this check looks suspicious (line 600):

    if (*(message_parts->at(2)) == "GetSlot")
    {
        response.append(" JavaScriptGetMember ");
    } else {
        response.append(" JavaScriptGetSlot ");
    }

Isn't the command in *(message_parts->at(4))? Debugger shows that at(2) contains "reference" at execution time.
Comment 37 Thomas Meyer 2011-12-09 13:30:36 EST
See my proposed patch: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-December/016438.html
Comment 38 Deepak Bhole 2011-12-16 14:49:16 EST
Ah, I see. Thanks for the patch Thomas, it makes the issue (and solution) much clearer now.

I will take a look at it as soon as I can get to it.
Comment 39 Deepak Bhole 2011-12-21 18:02:11 EST
Thanks for the patch Thomas!

I have committed them upstream and built RPMS with it for F15 and F16:

http://koji.fedoraproject.org/koji/buildinfo?buildID=279808
http://koji.fedoraproject.org/koji/buildinfo?buildID=279809

Can someone please try them out and let me know if they resolve the issue? If so, I will create a Fedora update accordingly.
Comment 40 Volker Grabsch 2011-12-23 19:25:24 EST
Many thanks to Thomas Meyer for analyzing and fixing that issue!

Just a few hours ago I had an urgent need for this, on a Debian system. So I created a local Debian package using those 2 patches.

I can confirm that those patches in fact resolve the issues and everything works fine with them! (at least on Debian/Wheezy)

For the record, I was using the following commands:

aptitude build-dep icedtea-web
apt-get source icedtea-web
cd icedtea-web-1.1.4
wget -O- http://icedtea.classpath.org/hg/release/icedtea-web-1.1/raw-rev/cdd0bbf399e8 | patch -p1
wget -O- http://icedtea.classpath.org/hg/release/icedtea-web-1.1/raw-rev/9f7d46c3314d | patch -p1
rm ChangeLog.rej ChangeLog.orig NEWS.rej NEWS.orig
dpkg-source --commit . juniperbugfix
dch -l '.juniperbugfix' -m 'Juniper Bugfix'
dpkg-buildpackage -b -uc -us
dpkg -i ../icedtea*.deb

I also posted a small article about this to the mailing list of my local LUG (sorry, German language only):

http://mlists.in-berlin.de/pipermail/linux-l-mlists.in-berlin.de/2011-December/067193.html
Comment 41 Garrett Mitchener 2011-12-23 20:03:59 EST
I tried out the F16 rpm you just posted.  Iced Tea is still not working for me.
 (The Oracle java plugin still works fine.)

I get past the part where I type in my user name, but then it gives me an error
message within the web page:

The SecureAuth Applet was not able to load in a timely manner. This occurs when
the applet is competing for computer resources.

If there is a prompt above to install the JRE, please follow the JRE
installation prompts.

Else:

    Close other applications
    Click the 'Launch' button below to manually start the SecureAuth Applet.

Ironically, there's a little message in the bottom corner of the firefox window
that says "Applet started".    There's a "Launch" button, and when I click it,
the login process goes on to the next page, but I get the following exception
message in the terminal:


OpenJDK Runtime Environment (IcedTea6 1.10.4) (fedora-61.1.10.4.fc16-i386)
OpenJDK Server VM (build 20.0-b11, mixed mode)
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
        at java.lang.reflect.Method.invoke(Method.java:616)
        at
sun.applet.PluginAppletSecurityContext$4.run(PluginAppletSecurityCont
        at java.security.AccessController.doPrivileged(Native Method)
        at
sun.applet.PluginAppletSecurityContext.handleMessage(PluginAppletSecu
        at
sun.applet.AppletSecurityContextManager.handleMessage(AppletSecurityC
        at
sun.applet.PluginStreamHandler.handleMessage(PluginStreamHandler.java
        at
sun.applet.PluginMessageHandlerWorker.run(PluginMessageHandlerWorker.
Caused by: java.lang.RuntimeException: Interrupted waiting for call request.
        at
sun.applet.PluginAppletViewer.requestPluginProxyInfo(PluginAppletView
        at
sun.applet.PluginProxySelector.getFromBrowser(PluginProxySelector.jav
        at
net.sourceforge.jnlp.runtime.JNLPProxySelector.select(JNLPProxySelect
        at
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConne
        at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect
        at
sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLCon
        at SecureAuth$7.run(SecureAuth.java:966)
        at java.security.AccessController.doPrivileged(Native Method)
        at SecureAuth.GetUserCertificate(SecureAuth.java:938)
        ... 10 more
Caused by: java.lang.InterruptedException
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:502)
        at
sun.applet.PluginAppletViewer.requestPluginProxyInfo(PluginAppletView
        ... 18 more
Error on Java side: Interrupted waiting for call request.
Comment 42 Thomas Meyer 2011-12-24 06:20:54 EST
Hi Garett, this looks like an different error. could you please run with "ICEDTEAPLUGIN_DEBUG=true firefox 2> icedtea.log" and attach the icedtea.log and the java.stdout and java.stderr files in ~/.icedtea directory.

you may want to try to delete the ~/.icedtea* directories and try again.
Comment 43 Garrett Mitchener 2011-12-26 21:03:54 EST
Okay, I'm getting the same behavior.  I'll attach the log files.
Comment 44 Garrett Mitchener 2011-12-26 21:05:27 EST
Created attachment 549643 [details]
icedtea.log

Ran

ICEDTEAPLUGIN_DEBUG=true firefox 2> icedtea.log &

and this is icedtea.log
Comment 45 Garrett Mitchener 2011-12-26 21:07:53 EST
Created attachment 549644 [details]
~/.icedtea/java.stderr
Comment 46 Garrett Mitchener 2011-12-26 21:10:11 EST
~/.icedtea/java.stdout is empty
Comment 47 Thomas Meyer 2011-12-28 11:21:11 EST
Hi Garrett.

I did have a look at these traces. The problems seems to happen in the applet jar provided from your site, but I think the stack trace you provided is unrelated.

This method SecureAuth.GetUserCertificate() is called and returns:

(from java.stderr log):
Calling public java.lang.String SecureAuth.GetUserCertificate(java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String) on SecureAuth[panel3,0,0,0x0,layout=java.awt.FlowLayout] with  username collegename xxkeyxx and that returned: <SecurePackage><cipherData>zzz</cipherData><cipherKey>xxx</cipherKey><ERRORCODE>2</ERRORCODE></SecurePackage> of type class java.lang.String
appletviewer writing CallMethod 73

I don't know what ERRORCODE 2 means. Everything looks okay from the java applet side.

You may want to delete your ".java" directory and try again. Also make sure to install all relevant certs into a trusted keystore.

you can set the system property "deployment.user.security.trusted.clientauthcerts" for this. But I don't know how to set the system properties of the jvm that is spanned by the firefox-plugin.

Sorry.
Comment 48 Omair Majid 2011-12-28 11:29:48 EST
(In reply to comment #47)
> 
> you can set the system property
> "deployment.user.security.trusted.clientauthcerts" for this. But I don't know
> how to set the system properties of the jvm that is spanned by the
> firefox-plugin.

http://icedtea.classpath.org/wiki/IcedTea-Web#Configuration

IcedTea-Web reads these properties from a "deployment.properties" file located at ~/.icedtea/.

You can also use the control panel (itweb-settings) to import the keys into the trusted keystore directly.
Comment 49 Garrett Mitchener 2011-12-28 16:41:04 EST
I'm not having any luck with this.  I tried setting up ~/.icedtea/deployment.properties to contain

deployment.user.security.trusted.certs=/home/garrett/.java/security/trusted.certs

and I'm getting exactly the same behavior.

The only file in ~/.java/security is trusted.certs.  When I do

 keytool -list -keystore ~/.java/security/trusted.certs 

I get one entry, and when I do

 keytool -list -keystore ~/.icedtea/security/trusted.certs

I get one entry with the same md5 sum.

So, I'm guessing that somewhere the VPN must be refusing to reply to the applet because something isn't being encrypted properly?  And the applet just stalls waiting for a reply that never comes?
Comment 50 Garrett Mitchener 2011-12-28 17:14:51 EST
Okay, now I'm confused:  There's also a directory

~/.java/deployment

that contains a deployment.properties file.

There are also lots of certificates in files in

~/.java/deployment/security

and none of the properties listed at 

http://docs.oracle.com/javase/6/docs/technotes/guides/deployment/deployment-guide/properties.html

default to a directory like that.  I tried copying those files into .icedtea/security, but I think they're signed with a jvm-specific key and the VPN applet still won't work.
Comment 51 Thomas Meyer 2011-12-28 17:37:09 EST
Created attachment 549873 [details]
"Trusted Certificate" "MultiFactor" in itweb-settings

Do you have the MultiFactor certificate in the "Trusted Certificates" in itweb-settings? btw. your bug is not juniper, the company is this one: http://www.multifa.com/Support/
Comment 52 Garrett Mitchener 2011-12-28 18:38:04 EST
Yes, I have that certificate.  It shows up in itweb-settings under "Trusted Certificates" and the "User" tab.
Comment 53 Samuel Sieb 2012-01-04 18:04:05 EST
The new build works for me.  I no longer have to install the Oracle version to connect.  Thank you!
Comment 54 Fedora Update System 2012-01-04 18:22:11 EST
icedtea-web-1.0.6-3.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/icedtea-web-1.0.6-3.fc15
Comment 55 Fedora Update System 2012-01-04 18:22:52 EST
icedtea-web-1.1.4-4.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/icedtea-web-1.1.4-4.fc16
Comment 56 Deepak Bhole 2012-01-04 18:24:29 EST
Thanks for trying it Samuel. I have pushed out the updates for F15 and F16 (though the system will not auto-close this bug, as certain configurations still seem to have issues :/)
Comment 57 Thomas Meyer 2012-01-07 06:25:13 EST
Hi Deepak,

there is another problem with the junpier classes. the SecureHCLauncher classes seems to only work once in a new plugin jvm!
After destroying applet instance 1, it seems as for the applet instance 2 the SecureHCLauncher keeps a list of all previous instances. and there is this funny static method getFirstApplet(), that keeps a list of all SecureHCLauncer objects created. so we end up in instance 2 with a call to JSObject.getWindow(instance 1) which results in this message on the c++ side:

ITNPP Thread# -143279680: plugin_in_pipe_callback
ITNPP Thread# -143279680:   PIPE: plugin read: instance 1 reference 35 GetWindow
ITNPP Thread# -143279680: Instance 1 is not active. Refusing to consume message "instance 1 reference 35 GetWindow"
ITNPP Thread# -143279680: plugin_in_pipe_callback return
ITNPP Thread# -143279680: ITNP_SetWindow
ITNPP Thread# -143279680: ITNP_SetWindow: window already exists.
ITNPP Thread# -143279680: ITNP_SetWindow return

and this endless wait in the java side:
JSObject.getWindow
STARTING getWindow
STARTING postCallRequest
Securitymanager=net.sourceforge.jnlp.runtime.JNLPSecurityManager@831a91
STARTING postCallRequest done
  PIPE: appletviewer wrote: instance 1 reference 35 GetWindow
wait request 1
wait request 2

stack trace is:
Thread [Thread-27] (Ausgesetzt)	
	Object.wait(long) Zeile: nicht verfügbar [native Methode]	
	GetWindowPluginCallRequest(Object).wait() Zeile: 502	
	PluginAppletViewer.getWindow() Zeile: 989	
	JSObject.getWindow(Applet) Zeile: 247	
	Util.getNeoterisDSID(boolean) Zeile: nicht verfügbar	
	Util.openURL(String, boolean, boolean) Zeile: nicht verfügbar	
	SecureHCLauncher(SecureLauncherApplet).InstallTargetApp() Zeile: 805 [lokale Variablen nicht verfügbar]	
	SecureHCLauncher(SecureLauncherApplet).startTargetApp() Zeile: 472	
	SecureHCLauncher.doInstall() Zeile: 259	
	SecureHCLauncher(SecureLauncherApplet).start() Zeile: 223 [lokale Variablen nicht verfügbar]	
	SecureHCLauncher.start() Zeile: 205 [lokale Variablen nicht verfügbar]	
	NetxPanel(AppletPanel).run() Zeile: 476	
	Thread.run() Zeile: 679	

I wonder what is the correct thing to do here? return a null reference in IcedTeaNPPlugin::consume_message()?

Can anyone using the Oracle plugin check if you can login to a website several times using the same browser process?

or is this a bug in the SecureHCLauncher class?

any ideas?
Comment 58 Fedora Update System 2012-01-07 17:58:07 EST
icedtea-web-1.1.4-4.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 59 Thomas Meyer 2012-01-09 14:43:40 EST
Mhh! I watched the behaviour on Mac OS 10 with the Oracle plugin and Safari. jps shows that the java plugin seems to run each time in a different process...

The class Util (see above stack trace) has a static Vector of all previous Applets (i.e. SecureHCLauncher) the method getFirstApplet() seems to return the first entry of this static Vector.

I wonder why the destroy applet doesn't throw the Util and ScecureHCLaunhcer class out of the jvm?

I wonder why the appletReload() method has this:

        /**
         * Fixed #4501142: Classlaoder sharing policy doesn't
         * take "archive" into account. This will be overridden
         * by Java Plug-in.         [stanleyh]
         */
        AppletPanel.flushClassLoader(panel.getClassLoaderCacheKey());

I wonder if something similar is needed for destroyApplet()?

another idea is to throw an IllegalArgumentException/JSException in the static JSObject.getWindow(Appplet applet) method for an inactive/destroyed Applet.

what do you think?
Comment 60 Deepak Bhole 2012-01-09 18:39:32 EST
Hi Thomas,

Thanks for digging into the issue! I have opened a bug for it: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=852

I have a simple fix for it, but I'd like to test it a bit more before posting. I will post a fix tomorrow.

As for the issue about having consume_message return null, that is a separate issue IMO whereby the Java side is not notified about the C++ side having discarded the message. The idea of consume message returning null is not a bad one, but will need some testing to cover the various requests Java makes to C++.
Comment 61 Fedora Update System 2012-01-13 22:56:53 EST
icedtea-web-1.0.6-3.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 62 Fedora Update System 2012-01-15 15:03:27 EST
icedtea-web-1.0.6-3.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 63 Garrett Mitchener 2012-01-20 17:57:08 EST
I'm still having trouble.  Secure Auth + Juniper + IcedTea + firefox was actually working on my desktop machine for a few days, but never on my netbook, and now today it's not working on my desktop any more.  I have no explanation, other than it may possibly be a race condition?
Comment 64 Garrett Mitchener 2012-01-20 17:58:54 EST
Created attachment 556621 [details]
output from firefox

ICEDTEAPLUGIN_DEBUG=true firefox > IcedTea-messages.txt 2>&1 &
Comment 65 Garrett Mitchener 2012-01-20 17:59:39 EST
Created attachment 556622 [details]
corresponding java.stderr

java.stderr to go with attachment # 556621 [details]
Comment 66 Garrett Mitchener 2012-01-20 18:00:27 EST
Created attachment 556623 [details]
corresponding thread dump

Thread dump corresponding to attachment # 556621 [details] copied from visualvm.
Comment 67 Samuel Sieb 2012-02-07 17:02:14 EST
Well, that was short-lived.  The Juniper client on the site I use has been updated recently and now it causes Seamonkey to crash when using the icedtea plugin.  I installed the Oracle Java plugin and it works.
Comment 68 Thomas Meyer 2012-02-07 17:23:59 EST
did you upgrade to firefox 10? there is a know issue with icedtea-web: see https://bugzilla.mozilla.org/show_bug.cgi?id=704249
Comment 69 Samuel Sieb 2012-02-22 18:05:24 EST
I'm actually using SeaMonkey, but it appears to be the same underlying engine as FF10 (xulrunner 10).  So that looks to be the problem.
Comment 70 Deepak Bhole 2012-03-14 15:53:44 EDT
(In reply to comment #69)
> I'm actually using SeaMonkey, but it appears to be the same underlying engine
> as FF10 (xulrunner 10).  So that looks to be the problem.

I pushed an update for IcedTea-Web a few days ago that should address this. Can you please give it a try? Thanks!
Comment 71 Samuel Sieb 2012-03-14 17:54:26 EDT
I just tried it and there are no further problems.  Thank you for your work on this!
Comment 72 Deepak Bhole 2012-03-15 14:38:14 EDT
No problem. Thanks to Thomas Meyer for the patch!
Comment 73 Dominik Kupschke 2012-03-17 12:24:05 EDT
Hi,

I try to connect to my Juniper SA 7.1r6.0 with Fedora 16 amd64, without any luck.

Which version and architecture of Fedora are you using?
Which version of Network Connect do you use?

I use icedtea-web 1.2.1-fc16, is this the right one?
Comment 74 Samuel Sieb 2012-03-17 12:51:30 EDT
I don't know what version of Juniper is being used.  I'm using F16 32-bit with icedtea-web-1.2-1.fc16.i686.

What is happening when you try to connect?
Comment 75 Dominik Kupschke 2012-03-19 15:50:18 EDT
After the Network Connect tries to start I get redirected to the front page.

I also installed a Fedora 16 i686, on this system the Network Connect starts but crashes after some seconds.

I can provide logs from the i686 system tomorrow.

You can find the version of your Juniper at the Network Connect Applet under "Help --> Info"
Comment 76 Volker Grabsch 2012-03-20 04:18:11 EDT
The browser crash is a well-known issue of IcedTeaWeb:

https://bugzilla.mozilla.org/show_bug.cgi?id=704249

Is has been fixed in the following changeset:

http://icedtea.classpath.org/hg/release/icedtea-web-1.1/rev/0e782b6b2cbb

So IcedTeaWeb >= 1.1.5 doesn't crash anymore.
Comment 77 Dominik Kupschke 2012-03-22 13:35:02 EDT
I attached the crashlog from my Fedora 16 i686 with icedtea-1.2.1-fc16, generated from ABRT:

https://kupschke.net/owncloud/apps/files_sharing/get.php?token=ebd7457aacc2cae288683d140127aa464c6d8aac

How can I attach files to this ticket?
Comment 78 Deepak Bhole 2012-03-22 14:08:38 EDT
if you have the files, you can just click on "Add an attachment" at the top
Comment 79 Dominik Kupschke 2012-03-22 14:14:11 EDT
Created attachment 572057 [details]
icedtea-web-1.2.1-fc16 crashlog generated from ABRT.

icedtea-web-1.2.1-fc16 crashlog generated from ABRT.
Comment 80 Deepak Bhole 2012-03-22 14:25:03 EDT
Is there also a trace log? If it's there, it should be somewhere in /var/spool/abrt

Unfortunately without a trace log, I won't be able to determine the issue
Comment 81 Dominik Kupschke 2012-03-22 14:39:44 EDT
Created attachment 572062 [details]
Backtrace

Backtrace from icedtea-web crash.
Comment 82 Thomas Meyer 2012-03-22 15:27:46 EDT
could you please run with
"ICEDTEAPLUGIN_DEBUG=true firefox 2> icedtea.log" and attach the icedtea.log
and the java.stdout and java.stderr files in ~/.icedtea directory.
Comment 83 Dominik Kupschke 2012-03-22 15:38:57 EDT
Created attachment 572071 [details]
icedtea logs

icedtea.log, java.stderr and java.stdout
Comment 84 Deepak Bhole 2012-03-22 15:53:10 EDT
Looks like the crash originated in Juniper code from here:

/home/bommi/.juniper_networks/network_connect/libncui.so

We cannot do anything about this as it is 3rd party code and the JVM cannot prevent errors arising from such JNI code. You will have to file the bug with Juniper/whoever wrote the applet.
Comment 85 Thomas Meyer 2012-03-22 16:01:55 EDT
could you please install xterm on your system and restart your browser and see
if this helps? there seems to be a script expecting xterm to be available:
".juniper_networks/network_connect/xlaunchNC.sh: Zeile 56: xterm: Kommando
nicht gefunden."

you may want to check the directory ".juniper_networks" for additional logs,
maybe somewhere an Exception is recorded.

besides that the icedtea logs look okay, I can't find anything obviously wrong
in there.
Comment 86 Dominik Kupschke 2012-03-22 16:11:39 EDT
It works!

I will test this the next days under Fedora 16 x64 and Ubuntu 12.04 x64
Comment 87 Dominik Kupschke 2012-03-23 02:08:38 EDT
Created attachment 572165 [details]
icedtea x64 logs from Fedora 16 x64

Under Fedora 16 x64 it seems to be a bit more than just installing xterm.

The ABRT-Tool doesnt show up under x64.
Comment 88 Thomas Meyer 2012-04-03 14:14:33 EDT
so x86 works and x86_64 doesn't?

this comment seems to indicate that the juniper software only supports 32bit environments!? - https://bugzilla.redhat.com/show_bug.cgi?id=586194#c22
Comment 89 Dominik Kupschke 2012-04-03 15:41:37 EDT
Yes x86 works perfect but x86_64 doesn't.

Under Windows and MacOS X you get official x86_64 support.

For Windows also the Internet Explorer 64bit version is supported in the new Juniper SSL-VPN 7.2r1 Release:
http://www.juniper.net/techpubs/software/ive/releasenotes/j-sa-sslvpn-7.2R1-supportedplatforms.pdf)

Tommorow I will try to get up firefox running in 32 bit mode.
Comment 90 Fedora End Of Life 2012-08-16 18:31:01 EDT
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 91 David Woodhouse 2015-01-19 08:08:44 EST
Juniper users: We are working on adding Juniper support to the OpenConnect VPN client.

If you would like to have an open source VPN client which is shipped by default in Fedora and fully integrated with NetworkManager, send an email either to me or (preferably) the openconnect-devel mailing list and please help to test its compatibility.

We are at the very early stages, but in my test branch I've committed something that *might* just be able to transport data packets. I don't actually have a server I can test against myself though, so I'm relying on users.

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