Same here. UDP port is for the DHT/ distributed database.
Summary of the below: unless there's some obvious flaw in my testing and reasoning below, Vuze has a bug causing it to fail to open it's UDP port for DHT/ distributed database connections.
I was originally using UPnP, which has same problem here - TCP works, UDP does not (same error as that posted above).
My system:
- Debian sid
- Belkin N300 Wireless-N Modem-Router
- wireless connection from computer to modem/router (wlan0)
- Java 1.7.0_75
Oracle Corporation
SWT v3836, gtk
Linux v3.16.0-4-amd64, amd64
V4.3.0.6/4 az2
First I was using local DHCP address on my wlan and UPnP (in Vuze) for the NAT hole punching/ Internet Gateway Device Protocol (IGDP) etc dynamic support.
I tried changing my dynamic setup to a static local IP address, chosen and configured after checking the DHCP range on the modem router and avoiding this range of course, and manual port forwarding, using the "Virtual servers" config option on this Belkin N300 configuration, to forward the chosen port(s) back to my nice shiny new static IP addy.
This was successful, in that Vuze continued to 'work', but did not solve the UDP port error/ problem. At first I tried static config and disabled the UPnP option in Vuze, then later re-enabled UPnP (with everything else static) - no change to the problem, but Vuze still working over TCP.
Originally picked ports 6001 TCP and UDP - this kinda worked, but it turns out 6000-6008 or something is a standard port range for X windows! Changed again to 38999, again TCP and UDP, again port forwarding back to the static ip on my computer, changed Vuze config to use the new port, and again Vuze works on TCP - downloading and uploading of torrents works - but still produces this pesky UDP error!
For port selections, see for example this page, regarding some ports, and that 38999 is generally not used:
http://www.networksorcery.com/enp/protoc...s38000.htm
Checking out the port/ connection usages within the OS with the following command:
sudo netstat -pantu|egrep -i 38999\|6001\|udp
, I see a bunch of "java" connections for 6001 as well as 38999 (I have kept open the 6001 port forwarding on the router, until no longer needed, perhaps tomorrow some time); thank you Vuze, you are performing an elegant hand over from one port to the other, rather than just killing all the connections on the old port, even though a new port is configured - this is really good.
But.
With the above netstat command I see NO udp port open on 6001 nor 38999! Although TCP gives me the listening port, and of course there are a bunch of connections which I won't paste in, here's the listening port, evidently a tcp listening port:
tcp6 0 0 192.168.2.161:38999 :::* LISTEN 31934/java
A process check (ps aux|egrep -i java\|vuze\|azur) confirms only one instance of Vuze is running. Good.
Bandwidth checks at the OS ('desktop') and Vuze UI levels confirm continuing solid upload and download speeds - around 100KBps up and down, so that's all good.
I have gotten the "Failed to establish listen on port UDP:$PORT" error for both ports 6001 and 38999.
SO! Something fishy is up. Time for lower level testing:
I now try netcat (the "nc" command) to listen on the UDP port which Azureus/Vuze is alleging has a problem (I first tried listening on lo/127.0.0.1 first and that worked too):
nc -v -l -u -4 -n -p 38999 192.168.2.161
You can note my local/ internal static ip address there.
No error was produced by netcat, just the following output, which is looking good (but not looking so good for Vuze):
Listening on [192.168.2.161] (family 2, port 38999)
and no surprises, netstat shows us a suitably satisfactory output:
sudo netstat -pantu|egrep 38999
udp 0 0 192.168.2.161:38999 0.0.0.0:* 1334/nc
SO, Vuze, "dear" Vuze, you are fibbing to me - you are failing to open the specified port and pretending to me and others that there's some problem other than yourself! At the very least, you (Vuze) are failing to keep open the very UDP port you are complaining about having a problem with!!
How do we notify the devs? I am happy to run further tests.
PS: more powerful than netcat and better in all was is socat, cryptcat or even netcat6.
