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
[admin@MikroTik] > ip torrent/torrents/ add copy-from=
CopyFrom ::= see documentation
I don't quite understand you. Do you mean that you have downloaded something or not?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.
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.
... and Quick Setmaybe a separate soho.npk that includes the torrent client, kid-control and SMB server..
+1000Please 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..
100% agreed.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.
Amen!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..
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.please, think in scale: upgrading 10s or 100s of 1000s CPEs can run into serious bottleneck.
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.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.
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.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.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.
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.
ok, further info about the upgrade process - something that was ingeniously figured out by the FCL engineers.
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.
So, staged then. Quite interesting this possibility, a very well though system. But staged.ok, further info about the upgrade process - something that was ingeniously figured out by the FCL engineers.
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.
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.
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.
So, staged then. Quite interesting this possibility, a very well though system. But staged.ok, further info about the upgrade process - something that was ingeniously figured out by the FCL engineers.
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.
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.
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...
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).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?
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?... and Quick Setmaybe a separate soho.npk that includes the torrent client, kid-control and SMB server..
Hmm, did so many people really hate it that much?Changes in v7beta3
...
torrent - removed Torrent feature from RouterOS;
Who's nobody? Did you ask everybody?It's a good thing they removed torrent - nobody needs it.
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=noQuick 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.
I agree with thisNo 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.
What we REALLY need is some KVM virtualization, in order to run W10 and Crysis.We also need some Dropbox/Seafile functionality on the router.
Can't wait to play Crysis Remastered on the CCR screenWhat we REALLY need is some KVM virtualization, in order to run W10 and Crysis.We also need some Dropbox/Seafile functionality on the router.
Priorities people, priorities.
With KVM, we can add virtualized Seafile. That's not what we want! We need Seafile running natively!!!!111oneoneWhat we REALLY need is some KVM virtualization, in order to run W10 and Crysis.
Priorities people, priorities.
Unfortunately yes. Some requirements can be mad but make sense. To give you an example, web servers.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?
I disagree with this. Quick Set is very useful to get online in 5 seconds after a clean install/first time install to get up and running.... and Quick Setmaybe a separate soho.npk that includes the torrent client, kid-control and SMB server.. :)