Suddenly out of the blue I'm getting "Port Tested:http error 0: No Response"
I am using Version 2.5, Revision=13228, RpcVersion=14, RpcVersionMinimum=1 on a headless CENTOS 6.2 box (no GUI).
Together with Transmission Remote v3.24.(build3) on Win7
This happens when I click the "Test Port" buttom in the Win client.
Firewall/router etc is another headless box, running CENTOS 5.5 together with IP-Tables ROUTE2 and PPTP.
Ports is forwarded, as far as I can see, So whats up?
It downloads some files OK others not, as it seems.
It cant connect to any HTTP trackers.
Port Tested:http error 0
Re: Port Tested:http error 0
I have the same problem. Thought it had something to do with the older version of Transmission-daemon that I was using so I upgraded to 2.73-1 (or something).
No matter what I do I keep getting the "http error 0" whenever I try to either a) test my port mapping b) add a torrent by url.
The lame part is that I can use wget or curl to download the torrent url and everything works fine. I can also work with magnet links just fine. The thing of it is that this issue means that I can't scrape from any normal tracker (http based).
Basically transmission won't seem to make any http connection but Remote gui (RPC) works fine, the web interface works fine. EVERYTHING works flawlessly except HTTP trackers and port mapping testing.
FYI- the port mapping succeeds (as verified by web based port tester), just the HTTP request that gets sent to test the port mapping doesn't work.
This bug is EXTREMELY annoying as google search basically just makes things work.
------
Running this on debian on a Goflex Home (3.3.2-kirkwood).
No matter what I do I keep getting the "http error 0" whenever I try to either a) test my port mapping b) add a torrent by url.
The lame part is that I can use wget or curl to download the torrent url and everything works fine. I can also work with magnet links just fine. The thing of it is that this issue means that I can't scrape from any normal tracker (http based).
Basically transmission won't seem to make any http connection but Remote gui (RPC) works fine, the web interface works fine. EVERYTHING works flawlessly except HTTP trackers and port mapping testing.
FYI- the port mapping succeeds (as verified by web based port tester), just the HTTP request that gets sent to test the port mapping doesn't work.
This bug is EXTREMELY annoying as google search basically just makes things work.
------
Running this on debian on a Goflex Home (3.3.2-kirkwood).
Code: Select all
# cat /etc/transmission-daemon/settings.json
{
"alt-speed-down": 3130,
"alt-speed-enabled": true,
"alt-speed-time-begin": 480,
"alt-speed-time-day": 127,
"alt-speed-time-enabled": true,
"alt-speed-time-end": 120,
"alt-speed-up": 160,
"bind-address-ipv4": "0.0.0.0",
"bind-address-ipv6": "::",
"blocklist-enabled": false,
"blocklist-url": "http://www.example.com/blocklist",
"cache-size-mb": 4,
"dht-enabled": true,
"download-dir": "/mnt/bigbertha/torrent/2-complete",
"download-queue-enabled": true,
"download-queue-size": 6,
"encryption": 1,
"idle-seeding-limit": 30,
"idle-seeding-limit-enabled": false,
"incomplete-dir": "/mnt/bigbertha/torrent/1-in_progress",
"incomplete-dir-enabled": true,
"lazy-bitfield-enabled": false,
"lpd-enabled": false,
"max-peers-global": 200,
"message-level": 2,
"open-file-limit": 32,
"peer-congestion-algorithm": "",
"peer-limit-global": 300,
"peer-limit-per-torrent": 100,
"peer-port": 54322,
"peer-port-random-high": 65535,
"peer-port-random-low": 49152,
"peer-port-random-on-start": false,
"peer-socket-tos": "default",
"pex-enabled": true,
"port-forwarding-enabled": true,
"preallocation": 1,
"prefetch-enabled": 1,
"proxy": "",
"proxy-auth-enabled": false,
"proxy-auth-password": "",
"proxy-auth-username": "",
"proxy-enabled": false,
"proxy-port": 80,
"proxy-type": 0,
"queue-stalled-enabled": true,
"queue-stalled-minutes": 30,
"ratio-limit": 2,
"ratio-limit-enabled": false,
"rename-partial-files": false,
"rpc-authentication-required": true,
"rpc-bind-address": "0.0.0.0",
"rpc-enabled": true,
"rpc-password": "{adf02473c3d9011d20aab09c6cb9b5d7cbda4b8aAW6JHnjM",
"rpc-port": 9091,
"rpc-url": "/transmission/",
"rpc-username": "floodo1",
"rpc-whitelist": "127.0.0.1,10.0.1.*",
"rpc-whitelist-enabled": true,
"scrape-paused-torrents-enabled": true,
"script-torrent-done-enabled": false,
"script-torrent-done-filename": "",
"seed-queue-enabled": false,
"seed-queue-size": 5,
"speed-limit-down": 5150,
"speed-limit-down-enabled": true,
"speed-limit-up": 200,
"speed-limit-up-enabled": true,
"start-added-torrents": true,
"trash-original-torrent-files": false,
"umask": 18,
"upload-limit": 100,
"upload-limit-enabled": 0,
"upload-slots-per-torrent": 8,
"utp-enabled": true,
"watch-dir": "/mnt/bigbertha/torrent/0-torrents/_watch",
"watch-dir-enabled": true
}
Code: Select all
# transmission-remote --auth _____:_____ -a "http://www.doesntmatter.com/thissucks.torrent"
Error: gotMetadataFromURL: http error 0: No ResponseCode: Select all
portTested: http error 0: No ResponseRe: Port Tested:http error 0
After copious troubleshooting I determined that my /etc/resolv.conf file was only readable by root. Because of this no other users could resolve domain names, so transmission-daemon which was running as a special user (debian-transmission) was unable to resolve domain names, so could only work with magnet links that were calling out ip addresses. Couldn't do port testing / tracker updating / torrent downloading because all of those things were relying on domain names.
The way that I determined this was to run the daemon in the foreground (-f option), but make sure that you grab any configuration options from whatever method you are using to launch the daemon normally. In my case this meant checking /etc/init.d/transmission-daemon and /etc/default/transmission-daemon to notice that the configuration is stored in /var/lib/.....
Once I did this the error messages got a little more explicit. Tried running the daemon in the foreground as root and everything worked fine...so then I knew it was a problem with the user. Tried using curl via su or sudo and realized that it was borked. Then used strace to find that curl was having problems accessing /etc/resolv.conf (amongst other things, that weren't the problem).
Hope these steps help people out. So much googling makes this seems like an IPv6 problem, but it's probably a permissions problem.
I do have to say that transmission really sucks at giving you error messages that let you realize the permissions are wrong. Perfect example is that if downloaded files have the wrong permissions it will just change the status to stopped no matter what you do. No kind of error talking or anything, just the strange behvaiour of stopping them. Oh well, live and learn
The way that I determined this was to run the daemon in the foreground (-f option), but make sure that you grab any configuration options from whatever method you are using to launch the daemon normally. In my case this meant checking /etc/init.d/transmission-daemon and /etc/default/transmission-daemon to notice that the configuration is stored in /var/lib/.....
Once I did this the error messages got a little more explicit. Tried running the daemon in the foreground as root and everything worked fine...so then I knew it was a problem with the user. Tried using curl via su or sudo and realized that it was borked. Then used strace to find that curl was having problems accessing /etc/resolv.conf (amongst other things, that weren't the problem).
Hope these steps help people out. So much googling makes this seems like an IPv6 problem, but it's probably a permissions problem.
I do have to say that transmission really sucks at giving you error messages that let you realize the permissions are wrong. Perfect example is that if downloaded files have the wrong permissions it will just change the status to stopped no matter what you do. No kind of error talking or anything, just the strange behvaiour of stopping them. Oh well, live and learn