As BitTorrent gains legitimacy in the Internet marketplace, it’s more and more important to be able to utilize the benefits of P2P networking to share all kinds of files.

I’ve been trying to download a series of files for quite some time now; “old fashioned” means work, but not nearly so efficiently. So, being a die-hard [1] Azureus user ever since I discovered BT a few years ago, I cranked up my copy again to try one last time. (Azureus is an outstanding, cross-platform, Java-based BitTorrent client, and the winner of the SourceForge Community Choice Award, Best Overall for 2006!) Now, previously, I had tried to crank up Azureus and had had limited success in even getting the program running.

I added the torrent I wanted, and waited for the notification icon to turn from “no peers” to seeds and peers connected in a healthy torrent swarm. I waited….

And waited.

And waited some more.

Eventually, I was getting Remotely established connections, but not any locally established. [2] Safepeer wasn’t blocking any connections, for one thing, which is unusual: there are always a few miscellaneous IPs that fail the blacklist checks just from network error, if not from malice. My NAT was routing fine, everything was green, the tracker was returning an OK signal. Nothing. I couldn’t connect outward.

This time, I was on a mission. I was not giving up on this. So I opened up the built-in Azureus IRC support channel and started asking around. No leads.

A little Googling turned up nothing on the matter—until, a few hours later, I sat fuming at the console. What was going wrong? And since when did Azureus spout this many debug messages to stdout when running in the background in non-debug mode?

—That was the tip-off. I looked carefully at the console, freezing the output to allow me to examine the following:

DEBUG::[date]::[specific call that caused the error]
java.net.SocketException: Permission denied
at [snip much more debug nonsense here]

So the problem was in one of the 64-bit libraries in this copy of Azureus; Java was throwing an exception at the socket level: it didn’t have permissions to access the network. Furthermore, I had been using the GNU Java Compiler [roughly] equivalent to version 1.4.2 of Sun’s “official” Java. But Googling this turned up [3] unhelpful results.

Then I tried downloading the [4] latest Java from Sun for the AMD64 platform in an RPM file (wrapped in their license agreement, of course). But when I installed and ran “java -version” or “whereis java” at the console, the system didn’t even see the new install—it was still linked to the GNU compiler! Frustrated, I Googled again, this time for a way to hard-delete option for the GNU compiler, a way to remove it if not with yum or rpm then by hand and reassign the $JAVA_HOME variable….

Then I ran across this invaluable post on the Fedora Forums. The relevant part I’ll echo here to mirror the data, but the credit goes to [5] bytesniper; this version is edited for typos and some emphasis:

There is a link in /usr/bin/java that actually starts java so it needs to be pointed to the correct java installation. The easiest way to do this (to presserve both or all installations of java) is to use alternatives.

if you type alternatives --config java you will see a single entry pointing to something like /usr/lib/jvm/jre-1.4.2-gcj/bin/java.

all you need to do is add the link (path) to the new installation of java from sun

alternatives –install /usr/bin/java java /pathto/sunjava/java 2
(usage is alternatives <link> <name> <path> <priority>)

once you add the new java configuration to alternatives all you need to do is activate, to tell the system this is what should be run as /usr/bin/java:

alternatives –config java
this will give you a menu of java installations. choose the second option (hence, priority 2) and hit enter. now when you type something like java -jar filename.jar it will use the sun java instead of the inlcuded gcj.

Note: You can also delete /usr/bin/java and make a new symbolic link to the java binary of the new java installation, but I do not recommend this.

When I set up Sun’s as my default Java installation, the problem then became the error when trying to load Azureus, “Wrong ELF class: ELFCLASS64.” I was running the latest 64-bit installation of Azureus with the latest version of 64-bit Java on an Athlon64. Given that in this context, ELF stands for “Executable and Linking Format,” this error would be somewhat comparable to getting a “Wrong or Missing DLL” error in Windows when you’re absolutely certain that’s not the case. In short, it was infuriating.

After some more conversation and some more Googling, cyb2063 in the #Azureus-Support channel linked me to [6] this workaround for Mandrake and Azureus on the AMD64 platform. Even after following the instructions to a tee, it still didn’t work.

At this point, I’ll be honest with you, I gave up. If the 64-bit class of my executable format is “wrong,” I figured, I’d just try the 32-bit version. Doing a clean install of 32-bit Azureus corrected all of those problems, and now it’s running like a dream.

---

Now, to summarize, my practical advice if you find yourself in this situation would have to be to do as I did, and install the 32-bit version; but I’m still interested in this from an academic standpoint. If you have any ideas of what I could do differently, I’d be willing to try this all again with the 64-bit version just to get it working and learn something. Let me know. I hope this helps someone out there; thanks to bytesniper and cyb2063, again, for your help.

As BitTorrent gains legitimacy in the Internet marketplace, it’s more and more important to be able to utilize the benefits of P2P networking to share all kinds of files.

I’ve been trying to download a series of files for quite some time now; “old fashioned” means work, but not nearly so efficiently. So, being a die-hard [7] Azureus user ever since I discovered BT a few years ago, I cranked up my copy again to try one last time. (Azureus is an outstanding, cross-platform, Java-based BitTorrent client, and the winner of the SourceForge Community Choice Award, Best Overall for 2006!) Now, previously, I had tried to crank up Azureus and had had limited success in even getting the program running.

I added the torrent I wanted, and waited for the notification icon to turn from “no peers” to seeds and peers connected in a healthy torrent swarm. I waited….

And waited.

And waited some more.

Eventually, I was getting Remotely established connections, but not any locally established. [8] Safepeer wasn’t blocking any connections, for one thing, which is unusual: there are always a few miscellaneous IPs that fail the blacklist checks just from network error, if not from malice. My NAT was routing fine, everything was green, the tracker was returning an OK signal. Nothing. I couldn’t connect outward.

This time, I was on a mission. I was not giving up on this. So I opened up the built-in Azureus IRC support channel and started asking around. No leads.

A little Googling turned up nothing on the matter—until, a few hours later, I sat fuming at the console. What was going wrong? And since when did Azureus spout this many debug messages to stdout when running in the background in non-debug mode?

—That was the tip-off. I looked carefully at the console, freezing the output to allow me to examine the following:

DEBUG::[date]::[specific call that caused the error]
java.net.SocketException: Permission denied
at [snip much more debug nonsense here]

So the problem was in one of the 64-bit libraries in this copy of Azureus; Java was throwing an exception at the socket level: it didn’t have permissions to access the network. Furthermore, I had been using the GNU Java Compiler [roughly] equivalent to version 1.4.2 of Sun’s “official” Java. But Googling this turned up [9] unhelpful results.

Then I tried downloading the [10] latest Java from Sun for the AMD64 platform in an RPM file (wrapped in their license agreement, of course). But when I installed and ran “java -version” or “whereis java” at the console, the system didn’t even see the new install—it was still linked to the GNU compiler! Frustrated, I Googled again, this time for a way to hard-delete option for the GNU compiler, a way to remove it if not with yum or rpm then by hand and reassign the $JAVA_HOME variable….

Then I ran across this invaluable post on the Fedora Forums. The relevant part I’ll echo here to mirror the data, but the credit goes to [11] bytesniper; this version is edited for typos and some emphasis:

There is a link in /usr/bin/java that actually starts java so it needs to be pointed to the correct java installation. The easiest way to do this (to presserve both or all installations of java) is to use alternatives.

if you type alternatives --config java you will see a single entry pointing to something like /usr/lib/jvm/jre-1.4.2-gcj/bin/java.

all you need to do is add the link (path) to the new installation of java from sun

alternatives –install /usr/bin/java java /pathto/sunjava/java 2
(usage is alternatives <link> <name> <path> <priority>)

once you add the new java configuration to alternatives all you need to do is activate, to tell the system this is what should be run as /usr/bin/java:

alternatives –config java
this will give you a menu of java installations. choose the second option (hence, priority 2) and hit enter. now when you type something like java -jar filename.jar it will use the sun java instead of the inlcuded gcj.

Note: You can also delete /usr/bin/java and make a new symbolic link to the java binary of the new java installation, but I do not recommend this.

When I set up Sun’s as my default Java installation, the problem then became the error when trying to load Azureus, “Wrong ELF class: ELFCLASS64.” I was running the latest 64-bit installation of Azureus with the latest version of 64-bit Java on an Athlon64. Given that in this context, ELF stands for “Executable and Linking Format,” this error would be somewhat comparable to getting a “Wrong or Missing DLL” error in Windows when you’re absolutely certain that’s not the case. In short, it was infuriating.

After some more conversation and some more Googling, cyb2063 in the #Azureus-Support channel linked me to [12] this workaround for Mandrake and Azureus on the AMD64 platform. Even after following the instructions to a tee, it still didn’t work.

At this point, I’ll be honest with you, I gave up. If the 64-bit class of my executable format is “wrong,” I figured, I’d just try the 32-bit version. Doing a clean install of 32-bit Azureus corrected all of those problems, and now it’s running like a dream.

---

Now, to summarize, my practical advice if you find yourself in this situation would have to be to do as I did, and install the 32-bit version; but I’m still interested in this from an academic standpoint. If you have any ideas of what I could do differently, I’d be willing to try this all again with the 64-bit version just to get it working and learn something. Let me know. I hope this helps someone out there; thanks to bytesniper and cyb2063, again, for your help.