Month: October 2018

FreeNas, Transmission and Corrupted Files – Part 2

This is continuation of FreeNas, Transmission and Corrupted Files – Part 1

When corruption started to hit it was bad… few of seeded torrent were crying about error, and each time I did Verify local files they end up cleaning them to 0%. It was very annoying, because after verification it want to redownload same file over and over again.

I started thinking… Could it be because of someone abusing tracker? I read multiply time about poisoning tracker and sending corrupted segments, but the more I read about that possibility the less it looked to be even possible, because of all those checksum inside bittorrent clients and microTP (uTP). It was more and more strange… I even reach out to mod of that tracker, but that didn’t yell any more information – but I did notice same IP sending same file so I reported that IPs as possible culprit – just in case because It would be faster and simpler for them to check if those few IPs are getting strange upload stats for less popular torrents (very rare Linux distributions)

I updated transmission by hand because I wanted to be sure its not a software issue – that did not helped.

I wanted to exclude possibility of external process modifying those files – I used AuditD…. and it was horror… It was horror because this is not suite for processes that run as deamons, its designed the way you could audit living/automated login into shell and then interrogate aka audit users/accounts.

Gladly someone said ‘I WANT TO USE IT THAT WAY’ and made a wrapper setaudit and it was a godsend. As Transmission is running inside Jail setaudit overcome any issue I had with auditd.

Running auditd gave me confirmation that the transmission indeed is overwriting files that I already had (basically nuke them).

It was time to check for hardware failure – but the strange thing was that always the same files got corrupted. But we live in strange times … anything is possible if you believe hard enough.

And after many-many hours and many-many tests later nothing came up from them I was still in middle of nowhere…

Then It hit me like a track… I tweak the jail because I was trying to overcome the issue with network and bypass limits of that container that In the end were not container fault, but I did not reverse those tweaks because they didn’t harm anyone, right?

Maybe it was cosmic radiation, maybe it was a lucky guess or conflict with upgraded version but after removing allow.raw_sockets=trueand rebooting I never had those corruptions issue ever again.

Facebooktwittergoogle_plusreddit

FreeNas, Transmission and Corrupted Files – Part 1

After many years of just ‘taking’ I mature and upgraded my setup to be able to give community back what I took.

I setup RAID 6 FreeNas machine. Thanks to playing with those I understood why everybody in FreeNas community hate Realtek and why people just say to throw it away and get something that works (FreeNas: Realtek 8111F and re0: Watchdog Timeout Error  and FreeNas: Realtek 8111F and “re0: Watchdog Timeout Error” – universal solution). In the end I join the ‘hate club’ and bought Intel PRO 1000 PT Dual Port NIC. Fun part is that Linux handle Realtek with ease but I been with Linux when It didn’t like most of hardware that Windows support so I can understand that there are still hardware issues with FreeBSD.

Cool, FreeNAS install without any issues.

If you unfamiliar with FreeNAS it comes with ‘plugins’ that are basically jails with pre-configured application that ‘just works’.

I slap that Install button and almost instantaneous I had working Transmission 2.93 (FreeNAS should work about pushing updates to plugins faster but yeah, nothing to complicate that we cannot fix ourself if needed)

I mounted needed directories, slap few torrent files that I already had there and enjoyed how transmission is handling all those sweet, sweet files out there.

And Tranmission was working and it was doing good. But after many, many torrent more that join the seeding happy farm not many people did connect to share the love from me. I started tweaking Transmission. Setting by setting I scope documentation looking for holy grail, some magic setting that would boost simultaneous connections. I found few. So I created new config file, and it was good. Not the best but I notice some connection increase. But I was thinking that maybe its because the application is inside jail aka virtual network interface. Few threads on popular forums, many many blog post later I saw the solution allow.raw_sockets=true. Great I saw a big improvement with connections – but who know if that was really all this tweaking doing or just someone join the swarm.

Few days later I notice big (I could even say tremendous) packet drop from/in my network. What was happening ? Router that is used between NAS and WAN have working QoS rules so it shouldn’t be a problem with using to much of bandwidth… So what was it ?

Culprit here was the CPU inside the router – we need to remember that using fancy feature that make router even smarter use CPU. QoS, Firewall, VPN all of them take some of that sweet-sweet pie (CPU). But why its dropping packets you ask? Simple, there is less and less CPU power to handle all the traffic that is going to and from network so everything is super slow. But wait, didn’t it work before Transmission? Yes it did – and we could disable some functions but we can do better. Lets optimize some firewall rules, we can cut QoS from 10 types to 5 without big sacrifices. Is that enough? No, but we can tweak both Transmission and firewall rule for it. Let set ‘Max connections’ to smaller number and double that with same (or 1% more on firewall rule so we are double sure that anything that is marked as ‘new connection’ and is about our limit get dropped).

And this gave enough room for that sweet-sweet pie named CPU could handle ‘few’ packets more.

And it was good for months and months…

Until the corruption start to show !

(continue in part 2)

Facebooktwittergoogle_plusreddit