DSM-G600, DNS-3xx and NSA-220 Hack Forum

Soprano wrote:

Something is wrong with the latest update. I was running 1.92 for along time with no issues, once I upgraded to 2.12, Every torrent from a few private trackers and public trackers error out with "Announce error: tracker did not respond - Today 09:33:58 PM
Next announce in 31 min 45 seconds"

I did get it to work after rebooting my router, but any newly added torrents gave this same error. I even tried downgrading back to 1.92, and I still have this issue. Any ideas?

I have this exact issue too.  Did you find anything that works Soprano?

Thanks,

Dave

Edit: Actually I get 404 errors.

Last edited by graffix (2010-11-27 02:09:57)

I've uploaded a new Transmission package. This is still v2.12, but I fixed the problem FunFiler was talking about (gzopen64 not available).

The problem was that I had installed a newer version of zlib, which was a bad idea

On a sidenote, charles from transmissionbt.com let me know that the blocklist from transmissionbt.com won't be available much longer.
Anyone using the blocklist, and using the update feature of the daemon should go look for other sources.

graffix, I'd say the curious part is that a previous version works as TPB seems to resolve to local loopback

[root@www scripts]# dig tracker.thepiratebay.org

; <<>> DiG 9.2.1 <<>> tracker.thepiratebay.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8184
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;tracker.thepiratebay.org.      IN      A

;; ANSWER SECTION:
tracker.thepiratebay.org. 3525  IN      A       127.0.0.1

;; AUTHORITY SECTION:
thepiratebay.org.       86325   IN      NS      ns0.thepiratebay.org.
thepiratebay.org.       86325   IN      NS      ns1.thepiratebay.org.
thepiratebay.org.       86325   IN      NS      ns2.thepiratebay.org.
thepiratebay.org.       86325   IN      NS      ns3.thepiratebay.org.

KyleK, thanks, it did indeed resolve the issue. This will be useful even when transmissionbt stops providing a blocklist as I'm sure others will also offer gzipped downloads. Thanks

Define "connectiong via SSL". Do you want to use the web interface via secure interface (https://)? Then you would need to set up a separate web server on the NAS (lighttpd for example) and configure it so it accepts secure connections on port 443, and redirects them to the daemon's internal webserver.

Other than that, you can always open a SSH connection (which uses SSL) to open a shell, and then talk to the daemon via command-line.

You'd have to ask the Transmission Remote GUI devs on how tocconnect via SSH, I don't use that tool.

The blocklist update probably doesn't work because the Transmission website won't provide the list anymore. You'll have to find another site that has the blocklists. Check the official Transmission forum for more information.

Hi everyone!
Recently I upgraded transmission from 1.72-4 to 2.12-2 on my NSA220 in the way how it is given at the top of this thread.
Since what I see that transmission is using some other configuration, not matching with settings.json
It can be seen if I give the transmission-remote -l from ssh session to NSA. As a result the system responding with 401: Unauthorized
This mean, that rpc whitelist is enabled. With settings dump it is confirming with "rpc-whitelist-enabled": true, string inside.
But! settings.json has this option disabled (false)! Also, some other settings are different.
So, transmission is running without using settings.json, is it?
If so, how to bind the settings.json with transmission? Which fconfiguration file content I see then giving transmission-daemon -d now???
Attached I've put some outputs helping to illustrate my issue.
Could anyone advise me, please?

P.S. Sorry for bad english, it is not my native language.

Last edited by Lector (2010-11-28 17:01:00)

---

Attachments:
json_file, Size: 4,976 bytes, Downloads: 708

Yes, shure.
I did the same changes like it was before for 1.72: TRANSMISSION_HOME=/ffp/share/transmission/.transmission-daemon

I did the following:
- chmod 777 settings.json
- started daemon again
- setting.json mode become 600 again
Pls. see transmission-daemon.log from last restart.
There is a string with <Saved "/ffp/share/transmission/.transmission-daemon/settings.json" (bencode.c:1686)>
This mean, that json-file is available for reading by daemon.
And also I believe that everything fine with formatting of this file as it was used by previous transmission version perfectly.

Last edited by Lector (2010-11-28 17:46:51)

---

Attachments:
transmission-daemon.log, Size: 1,628 bytes, Downloads: 430

FunFiler wrote:

graffix, I'd say the curious part is that a previous version works as TPB seems to resolve to local loopback

Code:

[root@www scripts]# dig tracker.thepiratebay.org

; <<>> DiG 9.2.1 <<>> tracker.thepiratebay.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8184
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;tracker.thepiratebay.org.      IN      A

;; ANSWER SECTION:
tracker.thepiratebay.org. 3525  IN      A       127.0.0.1

;; AUTHORITY SECTION:
thepiratebay.org.       86325   IN      NS      ns0.thepiratebay.org.
thepiratebay.org.       86325   IN      NS      ns1.thepiratebay.org.
thepiratebay.org.       86325   IN      NS      ns2.thepiratebay.org.
thepiratebay.org.       86325   IN      NS      ns3.thepiratebay.org.

Imho this is a server-side issue, either on the side of TPB, or whoever hosts the DNS server you're using (e.g. your ISP).

That tracker address resolves to localhost for me as well, on both the NAS and Windows.

Maybe the other clients you tested with happened to have the original IP address of the tracker cached, so they were able to connect? This just a wild guess :)

Btw, I thought TPB was shutdown anyway?

Make sure that after you stop transmission there isn't another copy tisll running. Your log shows

Address already in use

So, do this:

- stop transmission
- check to make sure there are no left over processes using "ps -ef|grep transmission". If there are, stop it again or kill the processes.
- edit settings.json as required
- start transmission
- check the log again to ensure it starts clean

Last edited by FunFiler (2010-11-28 19:46:29)

DId you verify that all instances of transmission were shut down as outlined in my previous post? No one else seems to be experiencing this issue, so I must assume that it is something unique to your setup. If indeed all instances are shut down, I would completely remove transmission and any associated directories and files then start from scratch using the default install locations (although I've never had an issue running from a custom path myself).

The proper settings string is "rpc-whitelist-enabled", and no, there isn't an option to transmission-daemon or transmission-remote to enable/disable it.

It wouldn't help you anyway, since obviously Transmission does not like your settings.json and always loads the default values.

As much as you might hate to do it, the only option you have left is to delete (better: rename) your current .transsmission-daemon folder and start from scratch (as posted in the first post of this thread).

Without the concrete setup of your NAS I simply can't tell you exactly what the error is, I can only give you advise on how you might fix it.

Running the "ps -ef" command will tell you instanatly if there is another copy running.