*) security - fixed vulnerability for routers with default password (limited to Wireless Wire), admin could login on startup with empty password before default configuration script was fully loaded;

the downloaded files are no longer visible in /files section when using Package Updater

LeftyTs, the downloaded files are no longer visible in /files section when using Package Updater. You can still reboot the device and it will upgrade. Or use /sys pac upd cancel to free the storage.

System files have always been hidden / not accessible for a user in RouterOS. Packages are now following the same principle.

Yes, it was under 6.46. Although not particularly mentioning that files are now hidden. There were a few improvements in package updater.



Maybe you need to give us more description regarding your changing. if you didn't give us more info about downloaded files,from here can we get that?


*) upgrade - improved auto package updating using "check-for-updates";

System files have always been hidden / not accessible for a user in RouterOS. Packages are now following the same principle.

System files have always been hidden / not accessible for a user in RouterOS. Packages are now following the same principle.

System files have always been hidden / not accessible for a user in RouterOS. Packages are now following the same principle.

System files have always been hidden / not accessible for a user in RouterOS. Packages are now following the same principle.

That is just plain silly!
Now when I check for new version and click Download, or after uploading files using FTP, I cannot even check if the files were loaded completely before doing a reboot!
Please undo this change, it serves no useful purpose and has many disadvantages.

System files have always been hidden / not accessible for a user in RouterOS. Packages are now following the same principle.

That is just plain silly!
Now when I check for new version and click Download, or after uploading files using FTP, I cannot even check if the files were loaded completely before doing a reboot!
Please undo this change, it serves no useful purpose and has many disadvantages.

Agreed. Our network runs a complicated script to automatically upgrade units only to releases that have passed our testing and been made available on an internal server. The script takes pains to ensure that all files have been downloaded completely before automatically rebooting. Now it appears that you have introduced an unadvertised change that will cause the script to fail. (Ironically, this is a second order effect, because at the same time you also broke /system upgrade entirely so that they cannot even begin to execute.) This change has no obvious benefit to users, while actively impeding them (both scripts and humans) from ensuring that an upgrade Is complete and correct before installation reboot.

Please revert this change.

System files have always been hidden / not accessible for a user in RouterOS. Packages are now following the same principle.

Please undo this change, it serves no useful purpose and has many disadvantages.

Please revert this change.

+++ I totally agree with pe1chl, macsrwe and r00t. Please revert it back!

System files have always been hidden / not accessible for a user in RouterOS. Packages are now following the same principle.

That is just plain silly!
Now when I check for new version and click Download, or after uploading files using FTP, I cannot even check if the files were loaded completely before doing a reboot!
Please undo this change, it serves no useful purpose and has many disadvantages.

or use other more reliable ways.

Can anyone post reasonable reason why it's important?
Verification that file is downloaded is plain strange. If you don't trust the auto-upgrade mechanism, use Fetch, or use other more reliable ways.

System files have always been hidden / not accessible for a user in RouterOS. Packages are now following the same principle.

Please undo this change, it serves no useful purpose and has many disadvantages.

Please revert this change.

+++ I totally agree with pe1chl, macsrwe and r00t. Please revert it back!

Agree. Please revert it back.

Can anyone post reasonable reason why it's important?
Verification that file is downloaded is plain strange. If you don't trust the auto-upgrade mechanism, use Fetch, or use other more reliable ways.

Can anyone post reasonable reason why it's important?
Verification that file is downloaded is plain strange. If you don't trust the auto-upgrade mechanism, use Fetch, or use other more reliable ways.

Can anyone post reasonable reason why it's important?

3) If actual upgrade at reboot fails (due to missing packages or whatever), how does the admin know what packages are leftover in Files, and how does he remove them if Files is going to pretend to him that they don't exist?

Can anyone post reasonable reason why it's important? Verification that file is downloaded is plain strange.

Can anyone post reasonable reason why it's important?
Verification that file is downloaded is plain strange. If you don't trust the auto-upgrade mechanism, use Fetch, or use other more reliable ways.

Can anyone post reasonable reason why it's important?
Verification that file is downloaded is plain strange. If you don't trust the auto-upgrade mechanism, use Fetch, or use other more reliable ways.

Sometimes I just get the files from the mikrotik.com download section, collecting the main package and some optional packages, then I FTP the whole thing to the router and reboot. This is in fact the only way to add one or more optional packages. Of course after doing the FTP I first list the Files section to see if it all went well. Our network sometimes can be slow and unreliable, and the transfer may fail. That now does not work anymore, I checked, so I cannot check if all files were transferred.

[admin@3p_DUT_Audience] /file> print 
 # NAME                    TYPE                         SIZE CREATION-TIME       
..
18 routeros-7.0beta4-ar... package                   11.3MiB jan/21/2020 09:48:50
..

Sometimes I just get the files from the mikrotik.com download section, collecting the main package and some optional packages, then I FTP the whole thing to the router and reboot. This is in fact the only way to add one or more optional packages. Of course after doing the FTP I first list the Files section to see if it all went well. Our network sometimes can be slow and unreliable, and the transfer may fail. That now does not work anymore, I checked, so I cannot check if all files were transferred.

File uploaded by FTP is visible in files section

Code: Select all

[admin@3p_DUT_Audience] /file> print 
 # NAME                    TYPE                         SIZE CREATION-TIME       
..
18 routeros-7.0beta4-ar... package                   11.3MiB jan/21/2020 09:48:50
..

Ok I checked that by taking a test router which was updated to 6.46.2 and switching it to "testing" channel and then checking for new version. Then I clicked Download and nothing was visible, then I switched back to "stable" channel but I realized that there now was nothing I can do to avoid installation of this testing version on the next reboot!

/sys pac upd cancel

detect one problem of all mikrotik device, after update:

"DCHP lease time" parameter arbitrarily changed its value 10 min ( 10:00)

its NORMAL?

detect one problem of all mikrotik device, after update:

"DCHP lease time" parameter arbitrarily changed its value 10 min ( 10:00)

its NORMAL?

SNMP related problem with CRS328-4C-20S-4S+ and combo ports. If combo ports´ copper port is used SNMP shows notPresent(6) although copper port is physically up and traffic flows.
...
When I plug SFP in combo3 and use the copper port, then correct port status is reported. Correct status is also reported when only combo´s SFP port is used.

/interface ethernet monitor combo1 
                        ;;; # Transit Provider A
                      name: combo1
                    status: link-ok
          auto-negotiation: done
                      rate: 1Gbps
               full-duplex: yes
           tx-flow-control: no
           rx-flow-control: no
               advertising: 10M-full,100M-full,1000M-full
  link-partner-advertising: 10M-full,100M-full,1000M-full
               combo-state: copper
        sfp-module-present: no

iso.3.6.1.2.1.2.2.1.2.2 = STRING: "combo1"
iso.3.6.1.2.1.2.2.1.8.2 = INTEGER: 6 <--- ifOperStatus:notPresent(6) , but should be up(1) 

Ok I checked that by taking a test router which was updated to 6.46.2 and switching it to "testing" channel and then checking for new version. Then I clicked Download and nothing was visible, then I switched back to "stable" channel but I realized that there now was nothing I can do to avoid installation of this testing version on the next reboot!

emils wrote that

Code: Select all

/sys pac upd cancel

frees the storage. Possibly the same happens when channel is switched?
Would make sense at least.

MikroTik has been asked point blank to justify this change by citing any advantage at all, and they have completely avoided answering the question. Certainly they cannot justify it on the basis of user demand, because I have seen no one demand it.

But when WinSCP queries the server for a target of those links, the server returns an error.
I believe it's a server-side problem.

Can anyone post reasonable reason why it's important?
Verification that file is downloaded is plain strange. If you don't trust the auto-upgrade mechanism, use Fetch, or use other more reliable ways.

I'll turn the question around, could you provide a good reason why they should to be hidden? I'm not seeing it. One of the things I like about Mikrotik, is the control it gives me. This just obscures that control.

We are not office secretaries, we are techs, and we want to see what we are actually doing!

We are not office secretaries, we are techs, and we want to see what we are actually doing!

Going this way, you'll soon start asking to remove Quick Set from default package

We are not office secretaries, we are techs, and we want to see what we are actually doing!

Going this way, you'll soon start asking to remove Quick Set from default package

We are not office secretaries, we are techs, and we want to see what we are actually doing!

Going this way, you'll soon start asking to remove Quick Set from default package

Why packages are downloaded in a different directory? - If there are other .npk files under the "Files" menu, then upgrade will fail
What to do, if I want to cancel upgrade? - Use "/system package update cancel" feature
What to do if I want to verify packages after download? - First of all, how do you verify? Nobody has answered this question so far. Also, RouterOS on reboot firstly checks if packages are correct and if not, then they are not installed and you get a "broken package" error.
What to do if I do not like a new method? - Use fetch tool instead

What to do, if I want to cancel upgrade? - Use "/system package update cancel" feature

What to do if I do not like a new method? - Use fetch tool instead

1. This became broken in 6.46. Does MikroTik intend to fix it, or are they just going to leave it broken?
2. If the answer is that it will be fixed, will /system auto-update also be changed to put packages into an invisible directory, or will it operate as before? (If it operates as before, I am appeased — I still think invisible files is an awful idea, but it won't affect me because I will avoid using them.)

Regarding verification of packages after download, this is of course about actually seeing the file in /file. That is not the same as doing a hash check or something, but that is not what this is about

What to do, if I want to cancel upgrade? - Use "/system package update cancel" feature

What to do if I do not realize there is an upgrade present that needs to be cancelled, because I can't see it, and therefore fail to cancel it?

/system package update print

What to do if I want to verify packages after download? - First of all, how do you verify? Nobody has answered this question so far. Also, RouterOS on reboot firstly checks if packages are correct and if not, then they are not installed and you get a "broken package" error.

What to do, if I want to cancel upgrade? - Use "/system package update cancel" feature

What to do if I want to verify packages after download? - First of all, how do you verify? Nobody has answered this question so far. Also, RouterOS on reboot firstly checks if
packages are correct and if not, then they are not installed and you get a "broken package" error.

Simply download NPK files from router to PC and compare file checksums. That's the only way to be sure what router downloaded is not corrupted.

Pride comes before a fall. Companies much larger than MikroTik have had to learn this valuable lesson. One more time ... please hire a Product Manager who understands your users.

Why packages are downloaded in a different directory? - If there are other .npk files under the "Files" menu, then upgrade will fail
What to do if I want to verify packages after download? - First of all, how do you verify? Nobody has answered this question so far. Also, RouterOS on reboot firstly checks if packages are correct and if not, then they are not installed and you get a "broken package" error.

Pride comes before a fall. Companies much larger than MikroTik have had to learn this valuable lesson. One more time ... please hire a Product Manager who understands your users.

"Our" problem is that the subset of users who gather here on the forum is only a small subset of users to which MikroTik sell equipment.
Of course they are the tech savvy users who get MikroTik to get things done the cannot get done on equipment from other manufacturers in the same market segment by salesprice, and for which they do not want to spend 4 times at much at another company (which then wants even more money to receive firmware updates and access to a supportdesk).

But likely they sell 10 times more equipment via sales channels that reach customers without any such wishes, or with wishes that are satisfied by features like Kid Control and Detect Internet, and by products like Audience.
So we can ask for update transparency or IPv6 support as much as we want, we will be at the bottom of the list compared to users who ask for "products that perform a function out of the box".
(still I don't understand why something like "automatically update vulnerable products" is not covered by this)

And please finally retire the Tile architecture. It's a dead horse. There are much better architectures out there noawadays.

And please finally retire the Tile architecture. It's a dead horse. There are much better architectures out there noawadays.

P.S. All the "verification is a useless step", "we know better" answers are really ābols-style and it's sad to see that MikroTik has started going in this direction (a direction that is not very appreciated by IT people who might be a very notable share of current MikroTik users/customers).

Have you not read the above answers to your questions? Since I see repetition of the same flawed arguments.

1. looking at files is not verification
2. RouterOS does internal verification that is much better than looking with your eyes
3. if you want to do some advanced checksum operations, you still have Fetch tool available

all of this was offered above

Have you not read the above answers to your questions? Since I see repetition of the same flawed arguments.

1. looking at files is not verification
2. RouterOS does internal verification that is much better than looking with your eyes
3. if you want to do some advanced checksum operations, you still have Fetch tool available

all of this was offered above

[
Normis,

Can you please tell us:
What is the reason for hiding the files?

[
Normis,

Can you please tell us:
What is the reason for hiding the files?

Because you dont need it. You dont need access to Kernel, you dont need access to Filesystem. I hope mikrotik will never Listen to guys like you. This will Not improve the OS.

[
Normis,

Can you please tell us:
What is the reason for hiding the files?

Because you dont need it. You dont need access to Kernel, you dont need access to Filesystem. I hope mikrotik will never Listen to guys like you. This will Not improve the OS.

Note that update packages up/downloaded to the router are not system files, are not kernel files, or anyway other special files.

Most of the confusion has arisen from the fact that initially it was suspected that the files are now hidden (because of .npk extension), but still were loaded to the same location.
Later it turned out that the truth is that now the internal updater downloads the files to a DIFFERENT location, and of course this is not visible because no other files than the publicly visible Files section are visible.
This makes it a bit more reasonable, but still I think the system should offer the option to see what is in that download area, e.g. you click on a button and it shows a list of packages that has been downloaded, which version that is, and if the checksums are OK.
With that addition it would be fine, preferably when done in such a way that the result (version and status) can also be queried in a custom automatic upgrade script, so you can decide if it is safe to issue the reboot command or not.

Thanks @schadom, @R1st0.
We will try to fix SNMP reporting for combo interfaces in the next RouterOS version.

However when the Mikrotik came back up, for some reason it had disabled/unchecked the "Add ARP for Leases" setting in dhcp server.

I checked several routers and I do not see a memory leak. There is some increase in use roughly during the first day of uptime (like shown in your graphs) and then it stabilizes.
In one router that does a lot of NAT there is memory usage varying by time, it increases during peak hours but falls back to normal after that.

Maybe you have some problem with DoS or other resource exhaustion specific to your network, e.g. due to attackers or "people having fun".

CCR1009 upgrade from 6.42.2 to 6.46.2
All IPSec tunnels are works with strange notification in Policies about Peer's column as "unknown" or in CLI as "peer not set".

Policies have become bound to peers at least since 6.45 if not 6.44. That's nothing to claim as a bug, it is an intended change.

Have you not read the above answers to your questions? Since I see repetition of the same flawed arguments.

1. looking at files is not verification
2. RouterOS does internal verification that is much better than looking with your eyes
3. if you want to do some advanced checksum operations, you still have Fetch tool available

all of this was offered above

Today I've updated my hAP ac^2 from 6.44.6 to 6.46.2 (including firmware) and after a couple of hours, I've got a sudden router reboot.
Honestly, I can't remember such reboots at all (though I try to avoid beta versions).
My router has a pretty basic setup (default firewall + 2xWAN PCC balancing). Log says "router was rebooted without proper shutdown". What should I suspect & do?

Have you not read the above answers to your questions? Since I see repetition of the same flawed arguments.

1. looking at files is not verification
2. RouterOS does internal verification that is much better than looking with your eyes
3. if you want to do some advanced checksum operations, you still have Fetch tool available

all of this was offered above

Auto upgrader will not try to install if at least one package is missing or not finished downloading.

Auto upgrader will not try to install if at least one package is missing or not finished downloading.

But this all boils down to the question: "Is there any good reason for hiding the files?"
And the answer is definitely "no", at least MT has not come up with one single reason yet, apart from "the system files are hidden an now the upgrade files follow that path too" which sounds like a politician's answer...

@dg1kwa - please keep this forum topic strictly related to this particular RouterOS release.
MDB entries do timeout after a while if no membership reports are received, see "membership-interval" property. Make sure you have some device that acts as an IGMP querier. Otherwise, create a new forum thread or report to the support portal.

But this all boils down to the question: "Is there any good reason for hiding the files?"
And the answer is definitely "no", at least MT has not come up with one single reason yet, apart from "the system files are hidden an now the upgrade files follow that path too" which sounds like a politician's answer...

Repeated refusal to even acknowledge this question leads me to suspect that answer is somewhere in here. It just smells right.

It lloks that after latest update that /ip neighbor dicovery is enabled on wan port
i have flood on udp 5678 from Mikrotik devices all around the world
one of them is 159.148.147.229
route: 159.148.147.0/24
org: ORG-MA140-RIPE
descr: MIKROTIKLS
origin: AS51894
mnt-by: AS2588-MNT
created: 2010-11-29T08:32:40Z
last-modified: 2019-07-08T12:13:46Z
source: RIPE
b/r goran

Is there a problem with the auto upgrade via different source on version 6.46.1?
I added a package source, which is a different mikrotik to manage what OS I want to be installed onto my routerboards.
All my tests work with previous versions of routerOS, but as soon as I hit 6.46.1, it would seem to stop working.
I loaded 4.46.2 on my "package source router", but the mikrotik doing the auto upgrade does not see the package.

I wanted to implement my auto upgrade scripts this week and now before my deployment I did a quick final test with the newest routerOS and just does not work.
Now I'm scared to do the deployment on 100's of mikrotiks as newest version is not working.(upgrading in my scenario).