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

leech1980 wrote:

joligario wrote:

My drives power down after inactivity. I have a feeling your box is still getting pinged by trackers which cache your IP address. My router blocks all unsolicited incoming packets. Is it possible your box is exposed to the incoming requests?

How could I check if it is or isn't?

You can run a test. Remove all torrents, disconnect internet for however long your drive sleep time is set for. If drives power down, reconnect internet to see if drives kick back on. If they do, then transmission is most likely receiving requests.

I have been (and still use) the post download script to perform various actions although I do not send emails.

Thanks

Joe

OK--Finally! Been away from Unix for quite awhile, so took brain awhile to figure this out...
My Transmission is running as 'nobody'  so first off, the script has to be in a dir transmission
runs in, and the user nobody had to have a home dir so the mail init .emsmtprc could be found.
Now emailing just fine.

Thanks for the help...it was what I had to verify before I could figure it out.

If you always want to do that, than you can set the incomplete-folder on one drive, and the download-folder on the other.
The incomplete-folder is a session-wide setting, so you can't specify it for individual torrents.

$ transmission-remote --incomplete-dir /path/to/drive/a/downloads
$ transmission-remote --download-dir /path/to/drive/b/completed

Please note that a move from one drive to another is a copy-then-delete operation, which can take a considerable amount of time with large torrents on such a low-performance device like a NAS.
It's more efficient to have both the incomplete and complete folders on the same drive, because a file move is just a tiny change in the filesystem.

charlie wrote:

Is it somehow possible to automaticaly restart the daemon after every 4 days...

Easy. Just setup a cron job to issue a restart command.

Hi,

is there any experience weather it has sense to upgrade for ffp0.7? I have a DNS-320 with ffp0.5 and Transmission 2.42 running and this is the only purpose of the box (and unrar)! Is it worth upgrade? Do I need to update the libraries as well? 

Thanks,

A happy user of your Transmission builds :-)

KyleK wrote:

I added a download link for the current Transmission v2.42 for ffp-0.7-arm to the first post.
This is only for those who use ffp on a newer device (DNS-320, DNS-325) and are already running ffp-0.7-arm!

Hi guys...using the newest version of transmission.  Everything running fine.  A few days ago, I did a manual reboot of the NAS and now, Transmission shuts itself down every few hrs.

What could've changed?  Thanks in advance.

BTW...I'm on a DNS320...and I've changes to transmission.sh to ahve it run correctly.  It was doing so for over a month until a few days ago.

Does it have anything to do with this:

[05:26:38.796] UDP Failed to set receive buffer: requested 4194304, got 217088 (tr-udp.c:75)
[05:26:38.796] UDP Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf (tr-udp.c:80)
[05:26:38.797] UDP Failed to set send buffer: requested 1048576, got 217088 (tr-udp.c:86)
[05:26:38.797] UDP Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf (tr-udp.c:91)

Last edited by Fobio (2012-02-04 07:30:47)

cristian2k wrote:

KyleK mention something about these warnings in the past.

KyleK wrote:

Well, I'd say this is a rather informative warning message, as it tells you exactly what to do

I'd create a sysctl.conf in /ffp/etc with the lines mentioned in the warning, and then load it prior to starting Transmission:

Code:

$ sysctl -p /ffp/etc/sysctl.conf

This message has existed for as long as Transmission had UDP support, so it's nothing new.

I did as it says but didn't notice any behavioral difference.

Thank you.  I did the lines, and also called for/loaded sysctl (I'm a Windows guy, so my terminology may be off).  here's the new log entry:

[07:26:57.801] Transmission 2.42 (13028) started (session.c:718)
[07:26:57.801] RPC Server Adding address to whitelist: 127.0.0.1 (rpc-server.c:803)
[07:26:57.801] RPC Server Adding address to whitelist: 192.168.*.* (rpc-server.c:803)
[07:26:57.801] RPC Server Serving RPC and Web requests on port 127.0.0.1:9091/transmission/ (rpc-server.c:997)
[07:26:57.801] RPC Server Whitelist enabled (rpc-server.c:1001)
[07:26:57.801] RPC Server Password required (rpc-server.c:1004)
[07:26:57.801] DHT Reusing old id (tr-dht.c:305)
[07:26:57.801] DHT Bootstrapping from 90 IPv4 nodes (tr-dht.c:153)
[07:26:57.801] Using settings from "/mnt/HD/HD_a2/.transmission-daemon" (daemon.c:488)
[07:26:57.801] Saved "/mnt/HD/HD_a2/.transmission-daemon/settings.json" (bencode.c:1721)
[07:26:57.802] transmission-daemon requiring authentication (daemon.c:508)
[07:26:57.802] Loaded 94 torrents (session.c:1937)
[07:26:57.802] Port Forwarding (NAT-PMP) initnatpmp succeeded (0) (natpmp.c:72)
[07:26:57.802] Port Forwarding (NAT-PMP) sendpublicaddressrequest succeeded (2) (natpmp.c:72)
[07:26:58.810] Port Forwarding (UPnP) Found Internet Gateway Device "http://192.168.2.10:1780/control?WANIPConnection" (upnp.c:113)
[07:26:58.811] Port Forwarding (UPnP) Local Address is "192.168.2.166" (upnp.c:115)
[07:26:59.821] Port Forwarding (UPnP) Port forwarding through "http://192.168.2.10:1780/control?WANIPConnection", service "urn:schemas-upnp-org:service:WANIPConnection:1". (local address: 192.168.2.166:65246) (upnp.c:221)
[07:26:59.821] Port Forwarding (UPnP) Port forwarding successful! (upnp.c:224)
[07:26:59.821] Port Forwarding Forwarded (port-forwarding.c:93)
[07:26:59.821] 20110223 Could not connect to tracker (announcer.c:990)
[07:26:59.821] 20110223 Retrying announce in 104 seconds. (announcer.c:999)
[07:26:59.821] 20110223 Could not connect to tracker (announcer.c:990)
[07:26:59.821] 20110223 Retrying announce in 98 seconds. (announcer.c:999)
[07:26:59.821] 20110223 Could not connect to tracker (announcer.c:990)
[07:26:59.821] 20110223 Retrying announce in 305 seconds. (announcer.c:999)
[07:26:59.821] 20110223 Could not connect to tracker (announcer.c:990)
[07:26:59.822] 20110223 Retrying announce in 353 seconds. (announcer.c:999)
[07:26:59.822] 20110223 Could not connect to tracker (announcer.c:990)
[07:26:59.822] 20110223 Retrying announce in 60 seconds. (announcer.c:999)
[07:26:59.822] 20110223 Could not connect to tracker (announcer.c:990)
[07:26:59.822] 20110223 Retrying announce in 341 seconds. (announcer.c:999)
[07:27:06.911] 20110223 Starting IPv4 DHT announce (poor, 11 nodes) (tr-dht.c:574)

let's see if it sticks.

EDIT: no go...still shuts down by itself.

EDIT 2: when I reviewed the log, it seems like it crashes when Transmission "saved" the resume files.  After it saved stats.json, it crashed.

Last edited by Fobio (2012-02-04 10:28:18)

KyleK wrote:

Can you check if syslog contains any more info?
What about dmesg?

Hi kylek

the NAS's system log at the time of the most recent crash shows nothing out of the ordinary.

where can I find dmesg?

thanks.

KyleK wrote:

Just type "dmesg" on the commandline

Thanks.

The output is too much to paste here, so I took what I think may be useful:

printk: 1 messages suppressed.
TCP: drop open request from 69.107.115.16/40298
TCP: drop open request from 123.236.22.179/61317
TCP: drop open request from 116.217.174.249/59354
TCP: drop open request from 62.240.47.121/60100
printk: 7 messages suppressed.
TCP: drop open request from 62.240.47.121/60100
printk: 3 messages suppressed.
TCP: drop open request from 125.93.83.76/35514
printk: 27 messages suppressed.
TCP: drop open request from 75.167.161.170/61282
TCP: drop open request from 108.28.11.182/61762
TCP: drop open request from 114.35.33.128/61882
TCP: drop open request from 67.193.65.106/2361
TCP: drop open request from 141.237.33.25/3137
TCP: drop open request from 177.32.58.167/63778
TCP: Treason uncloaked! Peer 72.170.251.55:1672/63989 shrinks window 94240174:94242817. Repaired.

Please tell me because I'm very stupid and I don't know. You guys probably know that:

I have DNS-323. I wanted to upgrade to FFP 0.7. On first try I installed arm version which was not working (and I had segmentation fault in funplug log). So I reinstalled with FFP 0.7 oarm and everything is working fine. Then I installed transmission Transmission 2.42  (ffp-0.5) and it gives me error:

Starting transmission-daemon
/ffp/bin/transmission-daemon: can't resolve symbol 'posix_fadvise64'

I think that there should be compiled version of transmission for 0.7 BUT for ffp-0.7 oarm. Am I right? Is it possible to build such version?

Last edited by than33 (2012-02-10 10:09:16)