Ports question

[sabretache]

My Transmission Daemon has been running fine for about 6 months (two version upgrades done in that time - presently on Centos 2.33). It runs on a remote vps and I use the web client.

Transmission stopped working at about the same time my provider upgraded the vps and I suspect they have altered their NAT rules such that the vps open port configuration has changed. My config specifies rpc-port:9091 and peer-port:51413. The web-client preferences window reports port 51413 as open.

By 'stopped working' I mean that all torrents report 'unable to connect to tracker' or 'connection to tracker failed'.

I have used Nmap to determin the precise status of the above two ports. they are:
51413/tcp - open.
51413/udp - closed.
9091/tcp - filtered. Service 'xmltec - xmlmail'
9091/udp - open|filtered. Service 'xmltec - xmlmail'

Could somebody please advise on the above ports status - ie I suspect the problem may lie in Port 9091 already being apparently used by whatever that 'xmltec - xml - mail' service is.

Also, should both ports be open for both TCP and UDP traffic?

Thanks in anticipation.

[gunzip]

the fact that you can raise the interface with web client implies that port 9091/tcp is open and accepting incoming connections. you could run command like:

Code: Select all

$ netstat -tuapen | grep transmission

to see if it is indeed transmission binding port 9091. udp protocol is not used here.

nowadays public trackers are especially problematic, so having DHT enabled and working is important unless you use exclusively private trackers. thus in your case 51413/udp should be open also. in my case i manually forward both tcp/udp on my router and find that transmission is very effective in acquiring peers even when all the trackers error out.

[sabretache]

Thanks for that Gunzip.

This is what that 'Nstat' command returns - while Transmission is running with 3 x torrents, all paused:

Code: Select all

tcp   0  0 0.0.0.0:9091    0.0.0.0:*        LISTEN      102   336407411  27895/transmission-
tcp   0  0 0.0.0.0:51413   0.0.0.0:*        LISTEN      102   336407412  27895/transmission-
tcp   0  0 127.0.0.1:9091  127.0.0.1:45629  ESTABLISHED 102   342093332  27895/transmission-
tcp   0  0 127.0.0.1:9091  127.0.0.1:36795  ESTABLISHED 102   342045002  27895/transmission-
tcp   0  0 127.0.0.1:9091  127.0.0.1:44210  ESTABLISHED 102   342070556  27895/transmission-
tcp   0  0 :::51413        :::*             LISTEN      102   336407414  27895/transmission-
udp   0  0 0.0.0.0:33945   0.0.0.0:*                    102   336407424  27895/transmission-
udp   0  0 0.0.0.0:36876   0.0.0.0:*                    102   336407348  27895/transmission-
udp   0  0 0.0.0.0:51413   0.0.0.0:*                    102   336407415  27895/transmission-

Not sure what all that means but I'll investigate.

I had to have my vps provider open port 51413 udp and tcp when I first set the system up so it is probably something they have done to their NAT setup since, because I have not touched either the vps firewall or Transmission config. They recently stopped offering new vps contracts in favour of their new Cloud-based offerings. They have clearly had a major infrastructure upgrade/reorganisation and I guess my problem may well be connected with that changeover.

I'll request they open 51413/UDP and see if that does the trick. It will probably take them a day or two. I'll let you know the results since it may be of use to others.

[rb07]

You are trying to solve the wrong problem, perhaps 51413/udp is closed, but that is the peer port, and only used when peers connect using uTP protocol.

The real problem:

all torrents report 'unable to connect to tracker' or 'connection to tracker failed'

That's a different port, and usually several ports, all of them different from the peer port (51413) or the RPC port (9091).

You'll have to see tracker by tracker, some use port 80/UDP, others use their own port, both UDP and TCP. Those are the ones your ISP might be closing, in fact, from your description, it looks like your ISP closes everything unless you tell them to open it... I hope that is "incomming ports" not outgoing, because you need the outgoing connection to reach those trackers.

On the other hand, many trackers just plain don't work, some don't exist (but are still used inside .torrent files), some block traffic using whatever rule or reason (I've seen by country, by ISP), some seem to be spoofed by somebody else. What works for me in these cases is DHT, do you have it enabled? it needs some time to build its database, but then it just works as long as there are other peers (DHT is tracker-less).

Of course DHT shouldn't be used with private trackers (Transmission itself disables it on torrents marked as private).

[sabretache]

Thanks rb07. It was your help that got me going with Transmission originally back in March this year. Much appreciated.

The following are examples of the connection errors I am getting:

Code: Select all

1. Announce error: Could not connect to tracker
http://torrent.ubuntu.com:6969
http://linuxtracker.org:2710

2. Announce error: Connection failed
udp://tracker.example.com:80
udp://tracker.tracker.example.com:80

The 'connection failed' error appears confined to trackers specifying port 80, whereas the 'could not connet' errors are on trackers on other ports, in the above cases 6969 and 2710.

Doeas this mean that those ports need to be open on my Transmission machine? If so then, since the Transmission machine also runs Apache on port 80, will that not result in port 80 trackers being unusable anyway?

[rb07]

Doeas this mean that those ports need to be open on my Transmission machine?

will that not result in port 80 trackers being unusable anyway?

No, the difference is "incomming" vs. "outgoing". Take into account there are 3 separate parts on that URL, the connection is UDP or TCP, the address, and the port.

The "connection failed" trackers are well known unreliable trackers. Sometimes you can connect to them, some times not; both of them. So we can get no conclusion from those cases, the problem may very well be them.

The first 2 are interesting cases, there shouldn't be a problem with them, so let's try some testing:

1. On a terminal do a

   Code: Select all

   traceroute linuxtracker.org

   Does the name get resolved? Does the trace finish reaching the server?
   • If the name did not get resolved, then the problem is a DNS problem, check /etc/resolv.conf
   • If the trace did not finish (time-outs), then its a routing or other network problem.
2. If the first test worked, then let's try to connect

   Code: Select all

   telnet linuxtracker.org 2710

   You won't get any response if it connects, it just stays there (close the connection with Ctrl-D or Ctrl-C), and probably closes after some time. But if it can't connect you'll get an error after it times-out, or the connection is refused.
3. If both tests failed then something is preventing your connections, could be internal (i.e. iptables firewall, or another "security" measure, for instance moving the minimum port number that non-root users can open, usually its 1024, but it can easily be moved, and tested by repeating the test as user root). And it could be external, starting from your router (which probably has its own firewall and rules), out to your ISP. This is more difficult to test, perhaps nmap could be useful.

[sabretache]

Thanks for all the help with this. I've learned a lot.

Still haven't got it working on the offending vps but a fresh install on another of my vps's worked out-of-the-box and I can live with it on just that machine for now.

No time to get to the bottom of the problem but it does appear to be a vps firewall issue because the provider confirms port 51413 open for both TCP and UDP traffic. There are three areas where ports can be adjusted: The vps provider NAT's, the Plesk container firewall and the Linux IPTables setup. I think it most likely the Plesk setup is the problem but simply do not have the time to chase it down any further for now.

V2.42 runs perfectly on my other vps (NOT a Plesk container implementation) so that will do for now.

[rb07]

Service 'xmltec - xmlmail'

That might just be nmap's mis-identification of Transmission's RPC, I wouldn't pay much attention to that.

[badda]

Hi,
I'm having exactly the same problem: Each and every download will not even start because transmission cannot connect to the tracker. I tried many torrents, all same problem. Testing the port 51413 says, "Port is open". Another BT-client called "Download Station" on the same machine (QNAP TS-212p) is working perfectly. What could be the problem? Here my log after adding a torrent:
[2016-04-20 13:21:15.999 CEST] Saved "/share/MD0_DATA/.qpkg/Transmission/conf/torrents/slackware-12.2-dvd-iso.640fe84c613c17f6.torrent" (variant.c:1214)
[2016-04-20 13:21:15.999 CEST] slackware-12.2-dvd-iso Queued for verification (verify.c:264)
[2016-04-20 13:21:15.999 CEST] slackware-12.2-dvd-iso Verifying torrent (verify.c:219)
[2016-04-20 13:21:18.039 CEST] slackware-12.2-dvd-iso Connection failed (announcer.c:996)
[2016-04-20 13:21:18.039 CEST] slackware-12.2-dvd-iso Retrying announce in 20 seconds. (announcer.c:1005)
[2016-04-20 13:22:19.239 CEST] slackware-12.2-dvd-iso Connection failed (announcer.c:996)
[2016-04-20 13:22:19.239 CEST] slackware-12.2-dvd-iso Retrying announce in 20 seconds. (announcer.c:1005)
[2016-04-20 13:22:19.239 CEST] slackware-12.2-dvd-iso Connection failed (announcer.c:996)
[2016-04-20 13:22:19.239 CEST] slackware-12.2-dvd-iso Retrying announce in 20 seconds. (announcer.c:1005)
[2016-04-20 13:22:19.239 CEST] slackware-12.2-dvd-iso Scrape error: Connection failed (announcer.c:1279)
[2016-04-20 13:22:19.239 CEST] slackware-12.2-dvd-iso Retrying scrape in 20 seconds. (announcer.c:1288)
[2016-04-20 13:22:19.240 CEST] slackware-12.2-dvd-iso Connection failed (announcer.c:996)
[2016-04-20 13:22:19.240 CEST] slackware-12.2-dvd-iso Retrying announce in 355 seconds. (announcer.c:1005)

[badda]

Thanks for the tip - I checked the startup logs and saw that the bind to the local port was not successful. The other BT-client was using that port already. I changed the port number in settings.json, opened another port on my router and voilà, now everything works fine and dandy