Thanks for removing my whole thread Normunds, but it's still a feature request, so I'm reposting it.


1) I'd like to see a release of a btest application designed to run under a bash shell on linux. Something that I could run as a daemon and connect to remotely, so tests can be made back to a central network location that isn't running mikrotik. If MT doesn't have time to write this, just send me the specs on how the btest system works, and I'll try to write my own.

2) Under System/Auto Upgrade, it would be nice to be able to use a regular FTP server - again to utilize a central network location that isn't running MT.

As sergejs posted:

I think running Dude somewhere on central point, where all routers are accessible will be the same. You can upgrade all the routers from the Dude to appropriate version, moreover Dude will provide you with many useful monitoring features.

I respond with simply, I would rather not use Dude to do this. The flexability of being able to do this with FTP, as well as your software, would be very handy.

I do not see any real argument, why Dude cannot be used as tool to upgrade,
there are a lot of tools besides upgrade in Dude. It is very flexible to perfrom different application.

I respond with simply, I would rather not use Dude to do this. The flexability of being able to do this with FTP, as well as your software, would be very handy.

Where is the problem to use MikroTik router as router in system, where you have to grab all packages ?
Where is the problem to run upgrade from local PC to update the routers ?

I do not see any real argument, why Dude cannot be used as tool to upgrade, there are a lot of tools besides upgrade in Dude. It is very flexible to perfrom different application.

I didn't say that it couldn't, I said that I would prefer not to use it.

Where is the problem to use MikroTik router as router in system, where you have to grab all packages ?

I'm not quite sure what you mean, I know that I can FTP the package up to one router and use that router as the source for all of the others, what I'm asking for is a way to remove that extra step. Instead of configuring all of the routers to point to a central router, then FTP the packages to that router - why not be able to point all of the routers at the FTP server, then upload the files to that server. That's a much simpler way to handle it.

Where is the problem to run upgrade from local PC to update the routers ?

You don't always have a local PC in any given network, other than say, the FTP server I'd like to use to provide updates

I'm for the ftp mirror. Seems it is (or something like it) built into ROS but doesn't function. I just started working with "dude" and found it to be something to integrate into our network. But! We have several dozen and growing RBs that are not on our network and behind NAT. No dude there!

your FTP mirror idea is the same thing as is available now, the only thing is that instead of a linux/windows ftp server, you can use an existing RouterOS machine. you will not need a separate server just for updates.

Seems it is (or something like it) built into ROS but doesn't function.

It does function, just fine. Simply upload the files, then in another ROS router select System->Auto Upgrade, then "Upgrade Package Sources" and add the IP, username, and password of the ROS router you've uploaded it to (this is where I'd like to specify a standard FTP server). Then go back to "Available Packages" and click refresh - you should, momentarily, see the versions available from that router.

your FTP mirror idea is the same thing as is available now, the only thing is that instead of a linux/windows ftp server, you can use an existing RouterOS machine. you will not need a separate server just for updates.

Yes, it's not that I need a separate server, but rather that I'd like to have one. For instance, I could upload all packages in my version database to the FTP server without wondering about disk space (since AP's usually have 128 to 256MB flash, instead of an 80GB disk). I've tested it, and the ROS router will not log in to an FTP server and function in this way.

In my particular situation, the network consists of a dozen or so Routerboards & x86 Mikrotik AP's, the most central thing in the network is my FTP server (also DNS and other such network tasks), residing on the most inner core of the network, whereas the ROS boxen are all at the network edge.

Basically it just comes down to a little more flexibility in the update process.

Seems it is (or something like it) built into ROS but doesn't function.

It does function, just fine....

I had meant to a FTP server. We will often strip packages for certain machines and not others. We created different logins for FTP that would have the proper packages for that device. Our hope for an auto-upgrade script before that feature was documented.

The way MT does it seems odd to me since the source packages go away after a reboot and might not reflect the device architecture anyway.