You are not logged in.
Pages: 1
If I install either jre or openjdk6 with icedtea-web, Firefox (both 3 and 4) show a java plugin. However, if I try to view a web page containing java, Firefox hangs until I kill all java processes (not always possible) or until I kill Firefox itself.
I've verified the permissions of the plugins and gotten the same results on two different (nearly identical) installs. Both systems are 64-bit.
Any suggestions as to what the problem could be?
Offline
I had an issue a while ago where if ipv6 was enabled java didn't work in Firefox ( but did in Opera ). Disabling the kernel ipv6 module "fixed" it.
Offline
Your 2-year old solution to disable the ipv6 modules worked. I can use java applets and Firefox no longer hangs. I never would have thought to check that.
What's weird is that I've had this happen with both the jre and openjdk-6 packages, so it's not just a fluke in one of the projects. You didn't mention openjdk-6 -- did that ever work for you before this solution?
This needs to be resolved properly -- clearly others don't have this problem, this shouldn't be happening.
Offline
Maybe it isn't hanging, there might just be a very long timeout waiting for an ipv6 response
Offline
Maybe it isn't hanging, there might just be a very long timeout waiting for an ipv6 response
At first I thought that couldn't be the problem because it is a long timeout, but then I thought about it and realized that I've seen TCP/IP timeouts that are very long when the receiving party never replies to any packets.
I immediately looked at my firewall and saw that I have
ip6tables -P INPUT DROP
in my firewall script at start-up. Since I don't use IPv6, I decided to effectively disable it a year or so ago. I removed this iptables rule and Java applets work again. Furthermore, if I let the applet just sit for about 5 minutes (literally), the applet will run. I guess I never let it sit for that long before, although it did feel like I gave it enough time. So the problem does appear to be an IPv6-related timeout. Good call.
I had this iptables rule above the rule that accepts all connections on the local interface, so it's possible that I simply need to accept all local interface packets (and only drop foreign IPv6 packets) to fix the problem.
I don't know why my interface needs to receive any IPv6 packets for the Java applet to work, but it does. I'll get a packet sniffer out later today and see if I can make better sense out of what is happening.
dschrute: Do have have anything similar in your IPv6 configuration? Possibly another iptables IPv6 rule? I wonder if your problem is also caused by IPv6 not responding.
Last edited by B-Con (2011-05-09 21:13:23)
Offline
dschrute: Do have have anything similar in your IPv6 configuration? Possibly another iptables IPv6 rule? I wonder if your problem is also caused by IPv6 not responding.
I never specifically blocked IPV6, but I don't use it either so I typically just disable it, especially after reading the info in the wiki here. In fact I think java was working for me without disabling IPV6 for the past year or so, and that the issue was possibly related to either a flakey gateway/router or something my ISP was doing. Both my router and ISP have changed but I never specifically checked that java was working again.
Offline
OK, thanks for the feedback, dschrute.
So long as I accept IPv6 packets on the local feedback interface, I'm good. I opened Wireshark and watched the Java applet try to load. I saw a standard TCP connection established from ::1 to ::1 on high numbered ports; size total packets: SYN, SYN|ACK, ACK, FIN|ACK, FIN|ACK, ACK. I couldn't be fast enough with netstat to catch which process(es) were communicating, but I'd assume it was Firefox and/or Java.
So, there's a configuration solution to my problem. But I think that the applications shouldn't be using IPv6 to begin with. Anyone with further insight as to why there's this quick connect-and-disconnect IPv6 TCP session has a captive audience. :-)
Offline
Pages: 1