azureus/vuze totally broken after intrepid upgrade

Bug #293491 reported by Sam Brightman
10
Affects Status Importance Assigned to Milestone
azureus (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Binary package hint: vuze

I guess long-time users of Azureus on Ubuntu are used to this by now. Azureus was working normally before upgrading to Intrepid/Vuze. Now it is broken in multiple ways. It has silently changed my port number from 49512 to 49151 which now appears to be some kind of upper limit. Upstream are disclaiming responsibility for this, as you can see here:

http://forum.vuze.com/thread.jspa?threadID=77827&tstart=0

This initially caused the program to permanently stay in the upgrading state for azupdater (i.e. "updating" window in foreground, no progress) and after cancelling that the red "Firewalled" light is lit. So I changed my router to reflect this new port and everything went green but it did not connect to any peers for either the azupdater or the torrent I was attempting.

I left it overnight with green NAT/DHT etc. and came back to find it using 250MB RAM despite having no connections or other activity and the UI pretty unresponsive. I managed to click quit on the menu (the program was running so slowly this took several minutes and the strings in the menu were showing their localization names) but the java process remained afterwards. It seems my default java is GNU, which I guess from past experience could be responsible for some of this, but I'm pretty sure I didn't set it to GNU (I have Sun installed and feel sure I was using this before), so that was probably also changed silently to a broken state during upgrade.

Let me know if any logs or configs are helpful.

Revision history for this message
John Dong (jdong) wrote :

The port # change was made for security reasons. By default, Azureus opens a port on localhost for controlling itself and ANY LOCAL USER CAN ASSUME FULL CONTROL OVER ANY OTHER LOCAL USER'S AZUREUS INSTANCE. This behavior is horribly broken for multiuser setups and upstream was unwilling to coordinate a fix, so we were left with no choice but to do this.

As far as the Java switching to GNU, this should not happen -- OpenJDK is the default Java. It is well known that Azureus will not function with GNU Java correctly.

Can you try switching back to OpenJDK or Sun Java and see if these problems persist?

Perhaps we should blacklist GNU Java in the launcher.

Stefano Maioli (smaioli)
Changed in azureus:
assignee: nobody → smaioli
status: New → In Progress
Revision history for this message
Sam Brightman (sambrightman) wrote :

 I would think that either adding a notification that the port has been changed and possibly an explanation of the limit on the options page would be a minimum requirement for making this kind of change.

Having completely removed GNU Java it seems to be working properly. It seems GCJ is still not playing nicely with Azureus so some solution or further testing is probably required. Blacklist or not, I'm concerned that the upgrade switched me from Sun to GNU (I'm 95% sure I was on Sun before and Azureus was certainly operating normally) although I guess it is now difficult to test this and is quite likely nothing to do with Azureus.

Revision history for this message
John Dong (jdong) wrote :

Stefano, I agree with Sam that we need to better explain to the user when we mangle their previous port selection. Perhaps bring up the port selection wizard or something, and the string that explains the reservation of the ports should mention that they are for "internal Azureus control ports" or something like that.

As far as GNU Java, it is confirmed by upstream that GNU Java will *NOT* work with Azureus. I don't have any reason to doubt this claim. In Jaunty, I think we should blacklist GNU Java altogether from Azureus -- when we merge the next version of Azureus from Debian we'll do this. Why GCJ got set as default after your upgrade, as you speculated, is probably another bug and it certainly isn't related to Azureus.

Revision history for this message
Stefano Maioli (smaioli) wrote :

About reserved ports:

I remember seeing notifications about the port being changed due to reserved ranges. It's probably the new Vuze interfaces that's hiding all notifications. Anyway, I think fiddling with UI code is a little too risky for a SRU and this doesn't really sound like a good reason to diverge from upstream to me.

In the new version I'm preparing I'm changing the reserved range to > 65000, taking only about 500 ports. Let's hope most ppl won't remember that 2^16-1=65535 :). I hope this is good enough.

Revision history for this message
Sam Brightman (sambrightman) wrote :

In case you are not aware, I should add that choosing an Azureus port in the now-forbidden range is common practice to help dodge ISP banning/throttling P2P traffic.

Stefano Maioli (smaioli)
Changed in azureus (Ubuntu):
assignee: Stefano Maioli (smaioli) → nobody
status: In Progress → Confirmed
Revision history for this message
Javier Moreno (elpasmo) wrote :

Thank you for reporting this bug. It seems that the lastest versions of vuze don't have those problems (in fact, the restriction of ports no longer exists). Please confirm if you are having problems with current versions (4.3.0.6-1).

Changed in azureus (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for azureus (Ubuntu) because there has been no activity for 60 days.]

Changed in azureus (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.