Page 1 of 1

Torrent client

Posted: Mon Sep 16, 2019 4:47 pm
by WojtusW5
Hi, can I describe how to use the Torrent client ??
In system hints there is no such information and the system expects only one parameter.
[admin@MikroTik] > ip torrent/torrents/ add copy-from=

CopyFrom ::= see documentation
Thanks in advance.

Re: Torrent client

Posted: Mon Sep 16, 2019 8:33 pm
by drothic
I was able to get the torrent client working but it wouldn't save the USB I had installed. It just ate up the ram disk.

Kali has torrents available and I downloaded a .torrent file and uploaded it to the 3011.

https://www.kali.org/downloads/

Then I enabled the client and it started downloading to RAM.

Placing the .torrent file in the USB or the changing the download location to the USB did not work. I suspect this might be used to download ROS updates for devices either on your network or from MT.

Re: Torrent client

Posted: Tue Sep 17, 2019 9:42 am
by WojtusW5
I was able to get the torrent client working but it wouldn't save the USB I had installed. It just ate up the ram disk.

Kali has torrents available and I downloaded a .torrent file and uploaded it to the 3011.

https://www.kali.org/downloads/

Then I enabled the client and it started downloading to RAM.

Placing the .torrent file in the USB or the changing the download location to the USB did not work. I suspect this might be used to download ROS updates for devices either on your network or from MT.
I don't quite understand you. Do you mean that you have downloaded something or not?
If so, how did you point to the torrent file to download?

Re: Torrent client

Posted: Wed Sep 18, 2019 2:16 pm
by krisjanisj
Torrent is an experimental thing in v7beta. Currently threre is a bug with filepathing that will be fixed in upcomming beta releases.

Re: Torrent client

Posted: Wed Sep 18, 2019 2:22 pm
by emils
It kind of works now. You can download a torrent by enabling the service (/ip/torrent/set enabled=yes) and downloading a .torrent file to the router. It should automatically detect the file and it will appear under /ip/torrent/torrents/print. The implementation is quite old and basic and "download-directory" parameter is quite broken in beta1 as you have already observed.

Anyway, this is an experimental feature and we have not yet decided whether it will be removed from RouterOS or not after beta. If you have any interesting use-case ideas, please share them here.

Re: Torrent client

Posted: Thu Sep 19, 2019 2:45 am
by nz_monkey
It kind of works now. You can download a torrent by enabling the service (/ip/torrent/set enabled=yes) and downloading a .torrent file to the router. It should automatically detect the file and it will appear under /ip/torrent/torrents/print. The implementation is quite old and basic and "download-directory" parameter is quite broken in beta1 as you have already observed.

Anyway, this is an experimental feature and we have not yet decided whether it will be removed from RouterOS or not after beta. If you have any interesting use-case ideas, please share them here.

Please remove it, or at a minimum put it in a separate .NPK from the base OS. maybe a separate soho.npk that includes the torrent client, kid-control and SMB server.. :)

Re: Torrent client

Posted: Thu Sep 19, 2019 8:59 am
by dvm
maybe a separate soho.npk that includes the torrent client, kid-control and SMB server.. :)
... and Quick Set

Re: Torrent client

Posted: Thu Sep 19, 2019 1:15 pm
by mada3k
Please put these kind of features in a external packages. Completely unnecessary for the majority of the users and will only end up as an security issue.

Normal people gets an NAS or mini-server to run torrents.

Re: Torrent client

Posted: Thu Sep 19, 2019 5:21 pm
by ditonet
Please remove it, or at a minimum put it in a separate .NPK from the base OS. maybe a separate soho.npk that includes the torrent client, kid-control and SMB server..
+1000

Re: Torrent client

Posted: Fri Sep 20, 2019 12:53 pm
by R1CH
Please put these kind of features in a external packages. Completely unnecessary for the majority of the users and will only end up as an security issue.

Normal people gets an NAS or mini-server to run torrents.
100% agreed.

Re: Torrent client

Posted: Sun Sep 22, 2019 10:25 am
by ziegenberg
+1

Please remove torrent or put it in a separate .NPK from the base OS, together with kid-control and SMB server.

Re: Torrent client

Posted: Mon Sep 23, 2019 3:10 pm
by Cha0s
Please remove it, or at a minimum put it in a separate .NPK from the base OS. maybe a separate soho.npk that includes the torrent client, kid-control and SMB server.. :)
Amen! :P

Re: Torrent client

Posted: Mon Sep 23, 2019 3:15 pm
by savage
Don't know what MT was thinking to add a torrent client, in a router?!?!?!?!

+1 - remove.

Re: Torrent client

Posted: Mon Sep 23, 2019 4:29 pm
by Paternot
No torrent client, please. It will waste resources from both the router and Mikrotik as a company. Better to focus in the router/wireless part, and deliver those long needed features.

Re: Torrent client

Posted: Mon Sep 23, 2019 11:59 pm
by doneware
torrent is used in the Terragraph ecosystem for node software distribution. just saying. in this interpretation to me it perfectly makes sense to download stuff only to ramdisk.
please, think in scale: upgrading 10s or 100s of 1000s CPEs can run into serious bottleneck.

but i do support the exile of QuickSet.
in my opinion quickset could be replaced by an IOS/Android app, that is solely dedicated for regular home users.

Re: Torrent client

Posted: Tue Sep 24, 2019 7:50 pm
by mt99
So there has to be years worth of "please enable feature X in v7" threads, why not investigate and prioritize those? If you don't know the use cases already, you have a solution in search of a problem. As for what to do with the torrent client, perhaps it's too simplistic but from a security perspective I think of functionality going into two buckets:

* Features I don't personally use, and there is no specific means of securing (kid control goes here)
* Features that need to be secured, whether I use them or not. Assuming I don't use a feature, this could be not installing an optional package, ensuring a feature is disabled, etc

I think a torrent client goes into the second bucket, and I could see how a hacker would love to enable and abuse this feature. So I'd much rather have it in an extra package that I wouldn't install.

Re: Torrent client

Posted: Tue Sep 24, 2019 10:29 pm
by ivicask
Well for me torrent client would be most awesome for home use, schedule download/s over night when nobody is using net to download some stuff on external drive, silent, and low power use compared to PC, + you can use the same drive for direct access over network ..

Big + 1 from me.

Re: Torrent client

Posted: Wed Sep 25, 2019 12:13 am
by Paternot
please, think in scale: upgrading 10s or 100s of 1000s CPEs can run into serious bottleneck.
I don't think it would be that big of a problem. If your network has thousands of routers the bandwidth must be equally big. The firmware is about 12MB to each router. As of today, one can barely load 20 web pages with so little data - probably less. If your users watch youtube - even at SD - your network can cope with this load.

To me, torrent client adds complexity, attack surface, bloat to the firmware and takes developers from what is really important.

Re: Torrent client

Posted: Wed Sep 25, 2019 1:05 am
by doneware
I don't think it would be that big of a problem. If your network has thousands of routers the bandwidth must be equally big.
it is a bit tricky to serve this amount of data quickly. esp. upgrading large number of CPEs managed by some tr-069 based system can be a bottleneck.
sw delivery with torrent is like nuclear fission, once it gets momentum, everything happens very quickly. torrent also offers great integrity checking as well. you can google "software deployment with torrent" and there are quite some solutions out there, so it is not just about movies and iso.
using the built-in torrent client we deployed ~200MB image files to ~250 units in less than 3 minutes - centrally controlled with just a push of a button [but it also can be controlled via API calls]

i agree with you, the function should be easily and completely deactivated if not needed. but this doesn't necessarily mean it must be removed from the system.
mikrotik's current package system is a bit old-school with all the reloads required for package activation/deactivation.

Re: Torrent client

Posted: Wed Sep 25, 2019 4:38 am
by Paternot
I don't think it would be that big of a problem. If your network has thousands of routers the bandwidth must be equally big.
it is a bit tricky to serve this amount of data quickly. esp. upgrading large number of CPEs managed by some tr-069 based system can be a bottleneck.
sw delivery with torrent is like nuclear fission, once it gets momentum, everything happens very quickly. torrent also offers great integrity checking as well. you can google "software deployment with torrent" and there are quite some solutions out there, so it is not just about movies and iso.
using the built-in torrent client we deployed ~200MB image files to ~250 units in less than 3 minutes - centrally controlled with just a push of a button [but it also can be controlled via API calls]

i agree with you, the function should be easily and completely deactivated if not needed. but this doesn't necessarily mean it must be removed from the system.
mikrotik's current package system is a bit old-school with all the reloads required for package activation/deactivation.
But one should never do a network wide upgrade: it should be staged - at least to minimize the convergence time of routes and everything else. I don't want to imagine 10k routers rebooting a few minutes apart one from another.

Yes, torrent is magical in this way: it scales linearly and can easily move an astounding number of bits. I just don't think it's worth the trouble, to distribute a system that is almost 12MB - and we don't want to share this distribution with the world.

But yes, the package system could do with a revamp: it is showing its age.

Re: Torrent client

Posted: Wed Sep 25, 2019 8:17 am
by doneware

But one should never do a network wide upgrade: it should be staged - at least to minimize the convergence time of routes and everything else. I don't want to imagine 10k routers rebooting a few minutes apart one from another.
ok, further info about the upgrade process - something that was ingeniously figured out by the FCL engineers.
image download happens with torrent and it is done simultaneously to all selected nodes. we usually first test it for interop, and do a net wide prepare.

then all nodes set up the new image in their second flash partition.

then the last upgrade step is invoked for
the selected nodes - i.e network wide on the controller, and here comes the clever part:

the controller knows the topology. it builds a graph of the network and splits it up into chunks that don’t affect others, so can be rebooted simultaneously w/o causing extra outage to non-rebooted units. this way you get nodes in a reboot batch that have fate sharing. you can in addition limit the number of the nodes the system can select
for a single batch.
since the network is engineered in a way that each non customer unit needs to have at least two independent backhaul links, you can be sure that there is someone still available next to you.
also, the reboot process is well coordinated inside a single unit: once the restart process is initiated it signals it to its neighbors, drains the traffic gracefully from the links, shuts down adjacencies and only then proceeds with the actual restart.

every step is precalculated and controlled centrally - you can even run a dry test to see how the process will actually happen. once the batch finishes its task, the next batch is initiated automatically, until all the selected nodes finish the upgrade.

Re: Torrent client

Posted: Wed Sep 25, 2019 1:52 pm
by Paternot

But one should never do a network wide upgrade: it should be staged - at least to minimize the convergence time of routes and everything else. I don't want to imagine 10k routers rebooting a few minutes apart one from another.
ok, further info about the upgrade process - something that was ingeniously figured out by the FCL engineers.
image download happens with torrent and it is done simultaneously to all selected nodes. we usually first test it for interop, and do a net wide prepare.

then all nodes set up the new image in their second flash partition.

then the last upgrade step is invoked for
the selected nodes - i.e network wide on the controller, and here comes the clever part:

the controller knows the topology. it builds a graph of the network and splits it up into chunks that don’t affect others, so can be rebooted simultaneously w/o causing extra outage to non-rebooted units. this way you get nodes in a reboot batch that have fate sharing. you can in addition limit the number of the nodes the system can select
for a single batch.
since the network is engineered in a way that each non customer unit needs to have at least two independent backhaul links, you can be sure that there is someone still available next to you.
also, the reboot process is well coordinated inside a single unit: once the restart process is initiated it signals it to its neighbors, drains the traffic gracefully from the links, shuts down adjacencies and only then proceeds with the actual restart.

every step is precalculated and controlled centrally - you can even run a dry test to see how the process will actually happen. once the batch finishes its task, the next batch is initiated automatically, until all the selected nodes finish the upgrade.
So, staged then. Quite interesting this possibility, a very well though system. But staged.

But back to Mikrotik:
1) We don't have this system. I think The Dude can create groups of routers - but this isn't really automatic.
2) Our images are 12MB long. A far cry from yours (theirs?) 200MB.
3) We are already having problems with the 16MB storage range. AFAIK, RoS 7 will run on current hardware. Well, one could put the torrent on an extra package. But the problem persists.
4) Every new service increases the surface attack. I don't think the costs of keeping a torrent client are less than the benefits, security and development wise.
5) We have a very long list of feature request with Mikrotik. Some will be addressed by RoS7 - full BGP tables is one of them. But there are many others that we don't know. I'd rater see these problems getting the man hours that would be dedicated to keeping a torrent client.
6) Not to mention support. The sheer number of clients complaining that Mikrotik shouldn't put a torrent client in a device with less than 16GiB of storage...

Re: Torrent client

Posted: Wed Sep 25, 2019 3:37 pm
by stuartkoh

but i do support the exile of QuickSet.
in my opinion quickset could be replaced by an IOS/Android app, that is solely dedicated for regular home users.

I guess I'm not a regular home user, because I found QuickSet to be quite useful when I first bought my hAP ac² and would have been upset if I had been required to install some app on my phone in order to set it up. :-) (My phone is provided by my employer, so I can't just install random apps on it.)

I don't use Windows, so I don't find Winbox to be the first tool I reach for either. I got started with QuickSet and then once I was connected and able to use the router I learned about it and set things up the way I wanted using a combination of Webfig and the command line via SSH. I'm still very much learning how to use the wide range of features in RouterOS :-)

I wouldn't have any problem with QuickSet being in a separate package that can be uninstalled, or maybe only originally installed by default on home or home office devices.

Re: Torrent client

Posted: Wed Sep 25, 2019 3:40 pm
by stuartkoh

But one should never do a network wide upgrade: it should be staged - at least to minimize the convergence time of routes and everything else. I don't want to imagine 10k routers rebooting a few minutes apart one from another.
ok, further info about the upgrade process - something that was ingeniously figured out by the FCL engineers.
image download happens with torrent and it is done simultaneously to all selected nodes. we usually first test it for interop, and do a net wide prepare.

then all nodes set up the new image in their second flash partition.

then the last upgrade step is invoked for
the selected nodes - i.e network wide on the controller, and here comes the clever part:

the controller knows the topology. it builds a graph of the network and splits it up into chunks that don’t affect others, so can be rebooted simultaneously w/o causing extra outage to non-rebooted units. this way you get nodes in a reboot batch that have fate sharing. you can in addition limit the number of the nodes the system can select
for a single batch.
since the network is engineered in a way that each non customer unit needs to have at least two independent backhaul links, you can be sure that there is someone still available next to you.
also, the reboot process is well coordinated inside a single unit: once the restart process is initiated it signals it to its neighbors, drains the traffic gracefully from the links, shuts down adjacencies and only then proceeds with the actual restart.

every step is precalculated and controlled centrally - you can even run a dry test to see how the process will actually happen. once the batch finishes its task, the next batch is initiated automatically, until all the selected nodes finish the upgrade.
So, staged then. Quite interesting this possibility, a very well though system. But staged.

But back to Mikrotik:
1) We don't have this system. I think The Dude can create groups of routers - but this isn't really automatic.
2) Our images are 12MB long. A far cry from yours (theirs?) 200MB.
3) We are already having problems with the 16MB storage range. AFAIK, RoS 7 will run on current hardware. Well, one could put the torrent on an extra package. But the problem persists.
4) Every new service increases the surface attack. I don't think the costs of keeping a torrent client are less than the benefits, security and development wise.
5) We have a very long list of feature request with Mikrotik. Some will be addressed by RoS7 - full BGP tables is one of them. But there are many others that we don't know. I'd rater see these problems getting the man hours that would be dedicated to keeping a torrent client.
6) Not to mention support. The sheer number of clients complaining that Mikrotik shouldn't put a torrent client in a device with less than 16GiB of storage...


I've had some thoughts along these lines as well.

What should be included in the base system package and what should be separate? Having everything separate gives maximum flexibility, but also can be confusing for the end user, and can mean that there's a huge number of permutations of code running on Mikrotik devices - all of which have to be supported, QAed, etc.

It's a tradeoff between having fewer permutations to support, having the least amount of unnecessary code running, least use of system resources, flexibility, etc.

I'm not sure I have a good understanding of what markets Mikrotik wants to be in either. From what I see on the forum and elsewhere, it looks like ISPs and WISPs are a large part of the customer base. There are some home users as well, and also some (non-ISP) business users. There are tradeoffs here as well. What group of customers should they devote their resources to? They can't be all things to all customers, so they need to narrow their focus to at least some extent.

Most ISPs also have residential customers, so concentrating on ISPs and to a lesser extent home users is probably a good idea, and seems to be what they're doing for the most part. (Once you grow your business in more niche markets, you have the resources to be able to try to break into other markets as well.)

The installers for some Linux distros used to have, along with the base install, "task-based" installation items. You could select "mail server," "web server," or "software development" and a set of packages would be installed that contained someone's choices of what packages would be appropriate for the task.

If RouterOS will have a variety of separate packages to choose from, I wonder if it would be possible to have an option to install them in a "task-based" manner? You could have an option for a home wifi router, ones for various purposes on an ISP or WISP's network, maybe one for a managed customer premise router, or for SOHO use, business branch office use for site-to-site VPN, etc. Perhaps whatever management framework people use for managing large numbers of Mikrotik devices could also take advantage of this, so you'd setup "classes" of devices with a "task" or "tasks" and then apply it to the various devices to get the correct mix of packages installed, similar to the way you can do this with Ansible or Puppet for server/desktop/laptop computers? (I suppose the torrent client feature could come into play here too, if that turns out to be an efficient way of distributing packages, updates, configs to Mikrotik devices.)

Re: Torrent client

Posted: Wed Sep 25, 2019 3:50 pm
by zakynthoswifi
+1 Please remove torrent support, is the only reason to turn back on cisco routers...

Re: Torrent client

Posted: Wed Sep 25, 2019 7:15 pm
by Sob
If RouterOS will have a variety of separate packages to choose from, I wonder if it would be possible to have an option to install them in a "task-based" manner?
Until there's hundereds of packages, this is non-existent problem. And current plan seems to go in opposite direction. We'll see if "hate for frivolous stuff" from enterprise customers through other channels will be as strong as in this forum, if it will force MikroTik to re-evaluate and at least move "home" stuff into separate package. And maybe "enterprise" stuff to another. That would surely make some people happy. I'm just not sure about those who would need something from both (small flash could be a problem in future).

Re: Torrent client

Posted: Wed Oct 23, 2019 5:47 pm
by pekr
maybe a separate soho.npk that includes the torrent client, kid-control and SMB server.. :)
... and Quick Set
Quickset should stay imo. Just don't touch it, if you don't need it. It does not posses any security risk, it is a configurator helper, so why to remove it?

Re: Torrent client

Posted: Wed Oct 23, 2019 6:29 pm
by Sob
Changes in v7beta3
...
torrent - removed Torrent feature from RouterOS;
Hmm, did so many people really hate it that much?

Quick Set's problem is that it's dangerous. One wrong click and config is ruined. And I don't know if it's still the case, but originally some changes were applied even before clicking OK, that was really bad.

Re: Torrent client

Posted: Wed Oct 23, 2019 6:32 pm
by Znevna
Question is, was it worth having it there taking up ~500KB of our precios space in devices with 16MB of storage?:)

Re: Torrent client

Posted: Wed Oct 23, 2019 7:31 pm
by sebastia
removed in beta3...

Re: Torrent client

Posted: Wed Oct 23, 2019 10:09 pm
by Sob
No, I don't think that it was worth taking up space in default package. But I was hoping that if resistance from enteprise segment would force MikroTik to evict it from main package into separate one, it could in long term lead to them discovering that optional packages are cool and we could perhaps get more of them for everything. ;)

Re: Torrent client

Posted: Thu Oct 24, 2019 10:52 am
by Keyko
It's a good thing they removed torrent - nobody needs it.

Re: Torrent client

Posted: Wed Oct 30, 2019 4:02 pm
by Chupaka
It's a good thing they removed torrent - nobody needs it.
Who's nobody? Did you ask everybody?

Re: Torrent client

Posted: Wed Oct 30, 2019 4:08 pm
by normis
Just to be clear, the implementation was there since old times, when torrent did not have encryption or DHT or such things. If somebody needs torrent, it will be something else than what we removed.

Re: Torrent client

Posted: Wed Oct 30, 2019 5:18 pm
by doneware
Quick Set's problem is that it's dangerous. One wrong click and config is ruined. And I don't know if it's still the case, but originally some changes were applied even before clicking OK, that was really bad.
you can't make everyone happy. i'm totally with you on QuickSet. that's the easiest way of screwing up stuff. having it there all the time - i mean disabling it is only possible with GUI customisation - is dangerous. at least there should be some kill switch in the config for this, a one-liner: /system quickset set enabled=no
and it uses PPTP as VPN in 2019, for crying out loud! even the 2016 MTCNA docs emphasise the insecurity of that protocol!

my proposal for the quickset stuff is a standalone app - and i am not talking about the Mikrotik App, as this is way more complicated than everyday users from the street would understand:
similar stuff, that most other vendors use for the consumer market. with friendly colours, emojis and stuff.
the mikrotik app is basically a mobile winbox for the experienced folks

Re: Torrent client

Posted: Wed Oct 30, 2019 6:17 pm
by deanMKD1
Why to remove torrent? Just seprate in with another package. Its great thing for SOHO users like me. Put something to DL till night, when wake up its ready to go. Very usefull thing.
P.S: For advanced users , pls dont comment that is not needed if you personally dont use it ! I use it, and i wnat to have it back.

Re: Torrent client

Posted: Thu Oct 31, 2019 5:19 pm
by BartoszP
Is it a problem for you to download it to your computer or any RPi device ... the cheapest one you can find? Should it be done by a router?

Printer Services, SMB, Torrent ... lets add full SMTP server, Backup server, WordPress, Spotify ,Netflix Player ...

Do we really need a monster like this?
Image

Re: Torrent client

Posted: Thu Oct 31, 2019 6:03 pm
by Chupaka
We do, in case of if all parts are optional :)

Re: Torrent client

Posted: Thu Oct 31, 2019 8:37 pm
by mkx
The problem is that all of that costs us ... we're loosing devs focus on core functionality ... and all those extra functions have to come from MT. Personally I don't want ROS to get opened for third party modules. We have that option already (OpenWRT or plain Linux).

Re: Torrent client

Posted: Thu Oct 31, 2019 11:55 pm
by Sob
It's not like they added too many "frivolous" features so far (of course everyone has the line somewhere else), to significantly slow down others. I don't expect that same guru developer alternates between adding new kernel and improving Kid Control.

I'm torn about third party packages. On one hand, they would be great way to be able to get less popular features. But on the other, there wouldn't be any guarantees about quality, support, availability or anything. Success would depend on what would be possible to do, whether some good community would form around it, etc.

It would make RouterOS more open, but still not as open as Linux is. Which is interesting, Linux is there, it's completely free, completely open, so ultimately more powerful than RouterOS... and yet we don't use it instead of RouterOS. Why? Because RouterOS has everything nicely put together. It doesn't and can't have everything, but sometimes it needs only some small tweak to be perfect.

And that's the frustrating part, if it's not there, you can't do anything about it. If you need it, you have to get another device just for that. It's like having perfect house where you're happy with everything, except the mailbox could be bigger... but it's not possible to change it, you have to get another house for that. Aargh!

Re: Torrent client

Posted: Fri Nov 01, 2019 9:13 am
by normis
I already replied that we did not remove torrent. More correctly would be to say, that we did not even create torrent. That package was not a full implementation of modern Torrent protocols and features.