Am I able to download somewhere ROS 7.2rc3 again? Or is it safe to downgrade back to 6.49.3 from 7.2rc4 (what about different routing table config during downgrade)?
All older versions can be found on the MikroTik download page.
When you downgrade from v7 to v6 your configuration will revert to what it was when you last had v6, so all changes made since then will be lost.
Of course you can export your config before you downgrade and import it after the downgrade, but it may be that edits in the export are required.
And of course you have to reset to a blank config before you can import an entire config. But maybe you only have a specific section where you made changes, and you can clear and import only that.
Thanks but it seems that v 7.2rc3 cannot be downloaded… (or where exactly?) the archive contains only stable releases, not beta and rc?
Ok indeed it seems the development release tree has been removed from that.
As always, I recommend to partition the router (if possible, not on 16MB FLASH devices) so you can always go back after an upgrade.
It seems most users do not know about that.
Any ETA or update regarding the usage of DDNS at the WG endpoint and the tunnel would not be established after a reboot?
Any chance to get it now somewhere? I need mmips version.
It’s still there, no ?
Copy the link for the latest version, paste in browser and change version to what you need (2 places).
E.g. for arm: https://download.mikrotik.com/routeros/7.2rc4/routeros-7.2rc4-arm.npk
change 7.2rc4 to 7.2rc3
→ https://download.mikrotik.com/routeros/7.2rc3/routeros-7.2rc3-arm.npk
You may download it by direct link: https://download.mikrotik.com/routeros/7.2rc3/routeros-7.2rc3-arm.npk (I just replaced “4” from current download link published on the website to “3”).
Thanks!!! 
Is it available in a bridge filter rule only or throughout RouterOS (incl. IP filter)? I hope automatic WMM → VLAN priority is preserved when vlan is configured on a wlan too.
Unfortunately cannot test all of this at this time myself.
Yes that should work (unless there are bugs, of course…). The priority field remains with the packet as long as it is forwarded through the device (and is not overridden by some mangle rule), and it does not matter if a VLAN is used. Only when the packet is forwarded outside of the device this comes into play.
Unfortunately there is no option to do the usual DSCP->WMM priority mapping in RouterOS, so one will have to use a firewall mangle rule for that (e.g. “set priority from DSCP high 3 bits”), which when you want to apply it to bridged traffic implies that “use IP firewall for bridge” has to be set. (because bridge filter cannot set priority from DSCP)
How exactly?
Router is hAP ac2. Upgrade to 7.2rc4 went without issues.
I have connected APC BackUPS ES 700G which worked fine with 6.x, but there is no System->UPS menu.
I can see that UPS is connected in System-Resources->USB
1 device=“1-1” vendor=“APC” name=“Back-UPS ES 700G FW:871.O4 .I USB FW:O4 " serial-number=“5xxxxxxxx " vendor-id=“0x051d”
device-id=“0x0002” speed=“1.5” usb-version=” 1.10”
Where to go next?
Ask them to replace whatever they are using for the UPS package with NUT and proper drivers, that should make the UPS package a little more useable.
@sinisa UPS is an extra package.
I decided to give the 7.2rc* a try mainly to see what this does:
*) pppoe - use default MTU of 1492; (from 7.2rc1 changelog).
But the description of the fix seems wrong.
Findings:
PPPoE client running on ether1, ether1 MTU set to 1500, PPPoE client tries 1492 MTU and sets it right, so far so good.
Setting ether1 MTU to 1508 makes the PPPoE client to try for MTU 1500, so it seems the extra 12 bytes were removed from the math (previously this was happening when ether1 MTU was set to 1520).
BUT, if the client fails to negotiate 1500 for some reason (ISP doesn’t support it etc) the PPPoE client falls back to 1480 instead of 1492.
So it seems that only those 12 bytes are gone but 1480 lives on in some part of the code.
still dhcp-client is broken when cake queue type is applied in its queue tree interface, status is stuck at searching, strange that fq-codel doesnt have this issue
I think this is a great point. Figure out a way to handle exports with sensitive information in a secure way, but not as a binary backup. This frustrates me to no end when dealing with devices having issues, as I am unsure if I’m dealing with them related to some strange corruption in a backup file, since dealing with exports is so painful when operating under time constraints. Backups have many downsides when dealing with hardware swaps, differing versions, etc. I’m really surprised exports that support sensitive information haven’t been implemented with how easy it would be to generate and restore, and with the lessened support load regarding backups/restores.
you explained that a lot better than me, but it’s exactly what I meant.
It was a pain to restore the router yesterday using an export file taken from the same device the night before.
There were some logical / ordering issues within the file, that wouldn’t let me restore the config at once.
So I had to sit there with a text editor open and the router running /import .. verbose=yes, watching at which line the import failed, fixing it manually in a terminal and continue with /import .. from-line=x.
Exactly that! There often are issues in the sequence of the exports and details of the parameters, I wonder if they even test that.
And the lack of a “continue on minor errors” during an import is a pain as well. Just print what is wrong and continue, so at least one has a reasonable config and can work from there.
E.g. older devices had LCD and more LEDs than newer devices, what is the point of aborting an import when a /lcd section is encountered on a device without LCD? Just ignore it!
And when loading in the same device, the messup between things that are not exported and are (or can be) kept when reloading causes problems too.
E.g. when you choose to “keep user information” it also keeps group configuration, but that IS included in a /export so the import fails on “group already exists”. Arghh!!
It requires some changes that in fact are just minor touches, but have never been taken up no matter how often it has been discussed.
The procedure of restoring an existing router or migrating a router config to a new device (or a standby device one keeps ready in case there is a problem) is just painful with MikroTik.
The user (or admin) experience could be improved a lot.