New installation problems

[sabretache]

Hi all

By way of intoduction: I am no techie but, having run a medium traffic site on my own VPS for 12 months, I guess I'm not a totally tech-dummy either. My VPS is Centos 5.5 and I do most admin with Webmin + a little ssh console stuff. The site's primary purpose is to host a fairly large MediaWiki installation - software I am now fairly proficient with. VPS is in Ireland and I'm in UK running a small network of windows and linux boxes for different things.

A few months ago I started to host a mirror on the vps. It requires regular updates from large zip files provided exclusively via the bittorrent protocol. I was used to downloading torrents to my home network and began by doing the same with the big zip files and then uploading to the VPS - total waste of bandwidth and time. Enter a clear need for suitable headless server bittorrent software with remote admin for the VPS.

It turns out Centos is NOT the best when it comes to the cutting-edge stuff but I'm stuck with it. I started with the Standard Bittorrent client. Soon became fed up with no Magnet facility or workable remote Web or other GUI - plus other niggles. Tried to graduate to Rtorrent + RUtorrent Web UI. Won't bore you with the time that wasted - though it had to do with with the near impossibility of compiling Rtorrent with RPC capability on Centos. Anyway, here I am with a working Transmission installation - but issues.

I have the daemon running and the web UI working OK. I can download the files that triggered the need in the first place very well (12Mb in about 30 seconds when unrestricted !!). My problem is that the installation does not seem to want to to do any seeding and neither will it resolve Magnet links. I can't find any clues in the logs either. The Transmission log simply reports that the seeding has timed-out after the set interval of inactivity and the torrent is paused. If I download the same files to my home machines there is plenty of seeding activity going on so it's not that there is no demand.

Also, loading a magnet link gets stuck on 'retrieving metadata' at 0.00% forever.

Whilst I can currently use it for what I need it's hardly in the spirit of p2p protocol not to share ANY of it.

Any pointers, observation, suggestions welcome.

[rb07]

My problem is that the installation does not seem to want to to do any seeding and neither will it resolve Magnet links.

Test the "seeding" port by using:

Code: Select all

transmission-remote --port-test

on a terminal. If the output says no, and you are behind NAT, then you have to map the port; otherwise you probably have to open the port at your firewall, and use a fixed port, not the default that is a random port number.

What version are you using?

Most magnetized links need DHT enabled, others have the full URL to the tracker, and there are some that just don't work (I haven't bothered finding out why).

You can check if DHT is enabled with:

Code: Select all

transmission-remote -si

the result doesn't include DHT but the full words: "Distributed hash table enabled: Yes".

[sabretache]

Thanks rbo7

I figured it was probably connected with ports. My vps firewall is set up OK but I suspect that inbound traffic to the VPS has to negotiate a Service Provider NAT first. I'll work on this off-and-on today.

Meanwhile, whilst logged on to a console session as root, both of the above commands return the same message which is:

Code: Select all

Unexpected response: <h1>401: Unauthorized</h1> Unauthorized user

The heading tags suggest to me that the error is generated by Apache but, at current logging level, nothing relevant appears in the logs.

BTW I do have the 9091 Apache ProxyPass and ReverseProxyPass directives set up so that's probably where the above messages are coming from I guess.

[sabretache]

Further to the above:

I disabled authentication (used the -T switch on the daemon config) and that allowed the port and dht tests to proceed.

The port test does indeed confirm that the required ports are NOT open, but that dht IS enabled.

Just to be clear, since port 9091 is redirected with the Apache proxy, I assume I don't need it open. Rather it is just the 'peer port' (default 5143) that is needed with 'peer-port-random-on-start' set to false. Is that right?

[rb07]

The heading tags suggest to me that the error is generated by Apache

No, it means you have authentication enabled, for example:

Code: Select all

$ transmission-remote hpmediavault -si
Unexpected response: <h1>401: Unauthorized</h1>Unauthorized Userst: hpmediavault:9091
Accept: */*
Accept-Encoding: deflate, gzip

$ transmission-remote hpmediavault -n adm:pwrd -si
VERSION
  Daemon version: 2.22 (12099)
...

the required ports are NOT open

Its one port, not ports.

since port 9091 is redirected with the Apache proxy, I assume I don't need it open

Correct.

the 'peer port' (default 5143) that is needed with 'peer-port-random-on-start' set to false.

It would make things easier by taking the "random" out of the equation. Each time the daemon starts it could change the port, I'm not sure if it does in practice since I use a fixed port. The default is 51413 by the way.

The way I do it is to set the parameter -P (or --peerport) on my start-up script. But it may work the way you imply (changing settings.json when the daemon is down).

[sabretache]

Thanks rb07. All helpful stuff and much appreciated

Service provider has confirmed they have a NAT installed which renders my own firewall settings incapable of allowing traffic which the NAT is blocking. I have a request in for them to open 41413 for both TCP and UDP traffic.

I'll let you know how it goes when they get around to actioning it - hopefully today.

[rb07]

Service provider has confirmed they have a NAT installed which renders my own firewall settings incapable of allowing traffic which the NAT is blocking.

That doesn't sound right, NAT doesn't block anything, it just maps everything from an external to an internal IP address.

[sabretache]

Service provider has confirmed they have a NAT installed which renders my own firewall settings incapable of allowing traffic which the NAT is blocking.

That doesn't sound right, NAT doesn't block anything, it just maps everything from an external to an internal IP address.

Sorry. Their exact words were "There is a hardware firewall in place in front of the network".

Still haven't got the port open though. They tell me it is but both my port Nam scanner and 'transmission-remote --port-test' say otherwise.

still working on it.

[sabretache]

I've got the port open now - transmission-remote --port-test reports "Yes". Also DHT is enabled.

However, problems remain exactly as before: ie No seeding occurs and attempts to use Magnet links produce a red progress-bar outline and the messages:

Code: Select all

Downloading from 0 of 0 peers - DL: 0.0 KiB/s UL: 0.0 KiB/s

Magnetized transfer - retrieving metadata (0.00%)

And there they stay.

As I said above, I can download regular torrents lightning fast from peers that are clearly not throttled, but so far I haven't been unable to share a single byte.

One thought occurs: Do I need to set the "bind-address-ipv4" parameter to something other than the default "0.0.0.0" - ie the server IP address or something else?

[rb07]

Do I need to set the "bind-address-ipv4" parameter to something other than the default "0.0.0.0" - ie the server IP address or something else?

No. If the port is shown as open, then everything is set-up.

No seeding occurs

Do these show "got 0 peers" and a non-zero number of Leechers (on the tracker info)?

[sabretache]

Do these show "got 0 peers" and a non-zero number of Leechers (on the tracker info)?

Sorry. Seeding is OK now. Just the Magnet links not working.

Also, there does seem to be a problem connecting to some trackers, notably:

Code: Select all

udp://tracker.example.com:80/announce

which is the one used most extensively by the providers of the files I am interested in. The message returned is:

Code: Select all

announce error: tracker did not respond

Might that be a UDP issue? My home machine uTorrent client connects to it and the other problem ones OK.

Is there any way of checking if it IS a UDP issue?

[rb07]

Might that be a UDP issue?

Yes, Transmission doesn't connect to UDP trackers. You'll have to wait for version 2.30 (Feature Milestone 2.30) for that.

[sabretache]

I guess the UDP thing is probably at the root of the my Magnet links problem too. The only ones I have tried have the trackers hosted at openbittorrent .com which uses only UDP.

Thanks for all your help rb07 - much appreciated.

Any idea of a timeframe on v2.30?

[Jordan]

My guess is there will be at least a 2.30 beta within a fortnight.