Digging into some of the other threads and stuff online, I found out that the reason Openfire doesn’t handle IPv6 properly has to do with the way Java has handled IPv4 & IPv6 on the newer versions of Windows. Java 1.5 & 1.6 supports the separate IPv6 stack in Windows XP, but 2003 has better integration (you can even host SMB file transfers from Vista and Samba 3.2 clients), and Vista / 2008 uses an integrated dual-stack. The fix for the dual-stack is in Java 1.7, which is still in development. The Openfire service runs in 32-bit mode, so you’ll need the latest 32-bit version of JDK 1.7 installed; on my Server 2008 x64, I have 32-bit 1.6, and both x64 and 32-bit 1.7 (12-19-2008 build) loaded, with the path for the x64 1.7 binaries in my PATH, but you shouldn’t need all 3.
You can install the latest JDK 1.7 from Java.net. I want people to post back on which platforms this works on.
I would love to test this out, however it won’t be until next year when I return from vacation. Since I am using the all-in-one installation, how can I install and make sure it uses the latest beta version of the JRE? If you could post some instructions that would be great. I am using the 32 bit version of Windows 2003 Server.
Strip out the old versions of JRE, then download the latest 1.6 (if you need it for browser stuff), then download latest installer from the binaries page on the JDK 1.7 site. If you want help removing old versions of Java, you can use “JavaRa” to find and remove old versions of Java.
One other thing I did do on my install was set Windows to run JAR files with the JDK7 binary, but since the software didn’t use the x64 version, I’m assuming the service program finds the latest 32-bit version installed on your system.
Hmm…I deleted the jre folder out of c:\program files\openfire directory and put the new installation in my path. I restarted openfire and the web interface reports:
Java Version:
1.7.0-ea Sun Microsystems Inc. – Java HotSpot™ Client VM
Appserver:
jetty-6.1.x
So while the Java Version looks right, I’m not sure about the Appserver. When I look at netstat it is also not listening on the correct tcp ports on the ipv6 address. I did reboot the server after installing the jdk. Any thoughts would be greatly appreciated!
Make sure you have IPv6 installed as a network protocol on your network adapters (already installed on Vista/2008), and check the server config that its listening on all interfaces. I don’t recall seeing any IPv6 specific entries to modify.
Yep, ipv6 has been enabled and I can ping the ipv6 address. The server is not listening on port 5222 or 9090 on its ipv6 addresses. Do my java versions correspond with what you are seeing?
That would be correct. Next step would be to check your Windows Firewall settings to allow those ports on TCP & UDP from “Anywhere.” The client software should also be compatible with IPv6: in my setup, I use Pidgin, which the Win32 clients have no v6 support, but the Linux clients do and connect as IPv6 clients.
The windows firewall is turned off. As far as clients go, I’m using Adium which was successfully able to connect to a linux server running an ipv6 enabled version of OpenFire. When running netstat on the windows server I only see (ipv6 entries only):
I wish someone else could test this out. I can’t find anything in my setup to help you out. We originally had used a Linux server, but copied over our database and I think our config files as well. If there’s something a Linux install is doing differently to enable network access, but that’s a stretch…
Yeah I’ve been using versions of JRE 7 with OpenFire for over a year now without major issue. I update my install every few months. Here’s the latest version available atm…
Never mind…I had to update my path to point to the new version of the JRE I installed and then I had to delete the JRE folder from the OpenFire directory.
That does look like it worked; If I run a “netstat -a” I can see the server is listening on [::0] on the correct ports. However, if I dump the IPv6 address of the server into the spark client, it doesn’t work. Could this be a limitation of the Spark client?
Yeah: Pidgin & libpurple-based clients will work with IPv6 on Linux workstations; for any Windows client I’m aware of, you’ll need to use" netsh portproxy" or stone forwarder to make such connections.