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
Created attachment 409346 [details] icedtea stderr
Created attachment 409347 [details] icedtea stdout
[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.
Confirmed that I am able to connect with the Sun 1.6.0_20 JRE libnpjp2.so plugin.
I am having the same results on an Asus 1005HA running Fedora 13 i386. Using ncui 6.3.
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.
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.
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.
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.
I just installed the Sun JVM package and it works for me as well.
This also happens in Fedora 14. Applet comes up, but am immediately disconnected. Works fine with Sun's JRE and plugin.
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
(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).
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.
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.
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
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
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.
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
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
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
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.
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.
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?
Doh. Sorry, I misread the above trace and thought the error happened with Oracle plug-in too. Re-opening.
It also doesn't work with the 32-bit version of openjdk.
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.
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!
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?
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.
Oops wrong screenshot. above was for request "document". sorry.
(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.
Created attachment 542136 [details] GetMemberPluginCallRequest.parseReturn GetMemberPluginCallRequest.parseReturn for "cookie" before request.wait() finishes
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!
Created attachment 542151 [details] relevant log of getMember("cookie")
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.
See my proposed patch: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-December/016438.html
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.
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.
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
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.
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.
Okay, I'm getting the same behavior. I'll attach the log files.
Created attachment 549643 [details] icedtea.log Ran ICEDTEAPLUGIN_DEBUG=true firefox 2> icedtea.log & and this is icedtea.log
Created attachment 549644 [details] ~/.icedtea/java.stderr
~/.icedtea/java.stdout is empty
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.
(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.
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?
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.
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/
Yes, I have that certificate. It shows up in itweb-settings under "Trusted Certificates" and the "User" tab.
The new build works for me. I no longer have to install the Oracle version to connect. Thank you!
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
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
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 :/)
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?
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.
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?
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++.
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.
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?
Created attachment 556621 [details] output from firefox ICEDTEAPLUGIN_DEBUG=true firefox > IcedTea-messages.txt 2>&1 &
Created attachment 556622 [details] corresponding java.stderr java.stderr to go with attachment # 556621 [details]
Created attachment 556623 [details] corresponding thread dump Thread dump corresponding to attachment # 556621 [details] copied from visualvm.
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.
did you upgrade to firefox 10? there is a know issue with icedtea-web: see https://bugzilla.mozilla.org/show_bug.cgi?id=704249
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.
(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!
I just tried it and there are no further problems. Thank you for your work on this!
No problem. Thanks to Thomas Meyer for the patch!
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?
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?
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"
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.
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?
if you have the files, you can just click on "Add an attachment" at the top
Created attachment 572057 [details] icedtea-web-1.2.1-fc16 crashlog generated from ABRT. icedtea-web-1.2.1-fc16 crashlog generated from ABRT.
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
Created attachment 572062 [details] Backtrace Backtrace from icedtea-web crash.
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.
Created attachment 572071 [details] icedtea logs icedtea.log, java.stderr and java.stdout
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.
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.
It works! I will test this the next days under Fedora 16 x64 and Ubuntu 12.04 x64
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.
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
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.
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
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.