I'm not sure that's how the vulnerability manifested itself, but it's Mikrotic describe the fix. Although I was happy 7.19.6 I moved to 7.20.x to minimise any risk
I dont really consider the current crop of CVEs fixed until
7.21beta5
*) www - handle escaped characters in resource IDs and names for REST API requests;
*) www - process REST API requests only after user authentication is completed;
Hopefully firewall filters are saving people from the worst affects of this, but it doesnt fill me with good feelings knowing anyone who can hit your REST API can throw requests at it without authentication.
Not sure this is for since 7.20.6, could have been introduced in 7.20.4.
Problem is with DUDE in Winbox.
Information for “RouterOS Info “ is completely empty now in Winbox 3 and 4, and in webfig.
All tabs of “RouterOS Info” (Resources,Routerboard, …)
Other tabs under DUDE like “devices” are still OK.
All subtabs of “RouterOS Info” are empty.
Use it often for “Registration Table”, what collects all wireless registrations in the network.
Thought is was caused by switching some AP from WAN to wifi. (Wifi is not collected, only wireless)
Terminal output is however still OK!
So it is related to Winbox and webfig (same problem).
Just sometimes an error is reported under Registration Table : “ERROR: Dude is disabled” what is NOT the case however.
Terminal output as detail. (edited MAC address)
[admin@hEXRoes] /dude/ros/registration-table> print
Columns: DEVICE, INTERFACE, MAC-ADDRESS, AP, SIGNAL-STRENGTH, TX-RATE, UPTIME
# DEVICE INTERFACE MAC-ADDRESS AP SIGNAL-STRENGTH TX-RATE UPTIME
0 wAP ac wlan1 xx:03:2A:B6:B3:xx no -61dBm@6Mbps 72.2Mbps-20MHz/1S/SGI 1w1d2h8s
1 wAP ac wlan1 xx:E2:E6:20:85:xx no -52dBm@1Mbps 72.2Mbps-20MHz/1S/SGI 1w23h32m43s
2 wAP ac wlan1 xx:E1:E9:B5:9E:xx no -73dBm@1Mbps 72.2Mbps-20MHz/1S/SGI 1w15h50m48s
3 wAP ac wlan2 xx:3C:B0:9C:54:xx no -33dBm@6Mbps 400Mbps-40MHz/2S/SGI 6d18h25m56s
4 wAP ac wlan1 xx:3C:B0:9C:54:xx no -92dBm@1Mbps 144.4Mbps-20MHz/2S/SGI 6d10h33m18s
5 wAP ac wlan1 xx:A2:6D:0A:52:xx no -79dBm@1Mbps 72.2Mbps-20MHz/1S/SGI 3h37m37s
6 wAP ac wlan1 xx:D2:1D:A8:F5:xx no -74dBm@1Mbps 43.3Mbps-20MHz/1S/SGI 2h20m37s
7 wAP ac wlan1 xx:F5:C4:90:34:xx no -76dBm@1Mbps 48Mbps 10m36s
8 wAP ac wlan1 xx:67:1F:47:87:xx no -78dBm@1Mbps 9Mbps 4m19s
This is not about “early updating”. I have found 7.19.6 to be “known good” version for my use in that specific environment and want to update a new device to that version. If I would want to “early update” then I would not had the problem because latest versions are easy to find.
Ignorance of Mikrotik in this regard is the easiest way to ruin the reputation of all products they have. To be honest - there’s less and less incentives to endorse “anything Mikrotik” to any of my customers or anybody else. I will offer the products, deliver them and when problems arise it is “all my fault”.
I had said for a long time that Mikrotik should have 4 release channels: long-term (currently latest of 6.49.x), previous-stable (last minor of previous release - 7.19.6 at the moment), stable (7.20.6 at this moment) and testing (7.21 rc1 at this moment).
If we get this missing “previous-stable” channel in release tree, then this would solve more than 80% of many problems related to adoption of “stable” (as per Mikrotik parlance) releases.
CAPSMAN configuration was empty after update from 7.20.4 to 7.20.6 (in Winbox 4b42). All CAPs stopped working. solution was to downgrade to 7.20.4. everything starts working as before.
lucky me
So far 7.21 doesn't seem any better than 7.20.x and once released if things does not improve significantly we would be needing previous-previous-stable for known good...
Maybe something like "recommended" (known good) release would be a better way...
That's not what the release notes says. It all depends on what functionality is required. That is the advantage and disadvantage of having a platform were one can do soo much of configuration.
@ak13, is it reproducable? Have you sent supout and config to support?
There’s no way to see who would determine which older release could be “recommended” over latest stable. Most probably not anyone at Mikrotik. Idea to place final minor version of previous release to separate “previous-stable” (until next release gets to its’ final minor version) would be most simple way to overcome most of “immaturity” problems of “stable” releases. Maybe even name that release channel “mature”?
Or "RIPE" (also as acronym for Recent Intermediate Pragmatic Edition).
RIPE is already taken.
This discussion gets really old. My proposal:
- rename “stable” to “current”
- rename “testing” to “next”
- add “previous” channel
This would resolve 8/10 of the usual complaints. “stable is not stable” being the most often named one. “current” would wipe away this complaint completely. Easy fix.
Some people have the theory to install previous stable. because it must be more stable. Etc voila: “previous” channel.
Some people don't like to be “free testers”. Etc voila: “next” channel. You get the chance to access next software release. How cool is that? 
Renaming channels is not viable i’m afraid, the channel names appear in configuration so that would have to be converted and creates another issue when importing config into a different version.
version still have an issue with occasional wrong label distribution in MP_REACH_NLRI bgp messages for MPLS VPN4. Sometimes happens follwoing situation: In the forwarding table the label for the VRF is one value, but inside the MP_REACH_NLRI for prefix in this VRF a different label is advertised. Because of this, the return traffic cannot enter the correct VRF.
Great idea, especially the "previous"...
I would be happy even if I could install specific versions from the “packages” page, rather than downloading files from a webpage.
Indeed! It already is a big improvement that you can now install packages from that menu without downloading a zip, unpacking it, sending packages to the router. I asked for that many times.
But in the “channel” field you should be able to type a more-or-less-recent version (like 7.19.6) and have it fetch those packages to apply a specific version.
If just renaming the channel could make a release stable current naming would work just fine, unfortunately it doesn't seem to work that way.
The point is only to prevent comments such as “stable channel - but this is not stable. full of bugs!!11!”. Nothing more. Everybody knows that any software has bugs, but people still come up with such arguments.
But in fact it would make sense for Mikrotik to drop this 2 or 3 decade old “alpha/beta/stable/testing” scheme. For example, Winbox 4 is still a “beta” version, but it is promoted like a stable version, even though Winbox 3 is still the stable release. Replacing “b” (for beta) with “n” (for next) in version naming would be “Winbox 4 n42” instead of “Winbox 4 b42”. Yes, it’s the “next” Winbox version. Of course you can promote the upcoming/next version. Of course the product quality remains the same. But it would stop this annyoing “naming critics” that does not help to improve anything.
Sometimes Mikrotik introduces new features while old features still have many issues. After the new feature is introduced, other problems suddenly appear due to the addition of that feature, and all features are bundled into one module, making the problem even more complicated.
Ugh. Just… Ugh.
I’m doing a project where I need to physically move 4-6 CCR2116’s from one location to another. At the one location, I have a bunch of hardware that can run CHR. Great. I’ll clone the 2116’s to CHR’s, migrate live traffic, then move the routers to the new data center, all in one day.
Only to find out with a basic configuration on Proxmox, I’m running into a limit of about 3Gbps or 300,000pps, despite having plenty of CPU and RAM (10 cores and 8GB of RAM per CHR on an 80-core 3GHz Ampere ARM64 box). Tried different queueing mechanisms and various Proxmox/Linux settings, but ran out of patience.
Tried to pass through the onboard Intel 550’s to 7.19.4, but RouterOS doesn’t recognize them. I added a Chelsio T540, card, only to realize that I need 7.20.6 for the new drivers. Oh well, not a bad idea because support said 7.20.x also has improvements for virtio.
Fine. Updated to 7.20.6 from 7.19.4. Wow.. Gross.
BGP broken all over the place. There is exactly one Router ID (i.e. one BGP instance), so you’d think it would be easy to upgrade/migrate.
Nope.
AS & RouterID in the BGP configs were all blanked out, and no instance was created as part of the conversion process, so router is totally isolated and I have to go figure out the missing bits.
Now, fortunately, it’s a CHR clone of one of the CCR2116’s I was going to move, so I have multiple ways in to fix it (namely the VGA console), and the remedy wasn’t horrible (a couple of CLI commands and poking around with Winbox), but this will not be the case with a dozen roof-mounted and/or very distant routers. The best I can hope for is to spend lots of time ensuring Romon works everywhere….
Here’s a little redemption for MikroTik.
Yes, the BGP upgrade was a flop (had to manually fix a couple things), so definitely have a backdoor handy for any in-field upgrades. But with that, it seems that CHR’s will fare better under 7.20/7.21 than previous versions.
I spent hours yesterday getting a number of ARM64 CHR’s on 7.19.4 working to temporarily carry the workload of my soon-to-be-relocated 2116’s, only to have them throttle around 2-3Gbps/300Kpps. I ended up moving the workload to my RDS2216 and CCR2116 storage servers (they aren’t serving storage yet anyway).
With the primary loads taken care of, I set out to see if this CHR on 7.20.6 with a Chelsio card passed through would be any good.
It is surprisingly good. It rivals the 2116 it’s backing up (not using L3HW offload on the 2116’s, CPU-only). This CHR has 16 3GHz cores and 8GB of RAM and, as part of a redundant pair with the 2116, is acting as a BGP internal aggregation router with 800K routes and 2-5Gbps of traffic. Throughput bursts to 7Gbps when I run an Ookla speed test from my laptop to my server in the data center (3.1-3.3Gbps down, 4.2Gbps up).
I’m not using virtio interfaces (which 7.20 is supposed to enhance), so I don’t know whether the enhancement is coming from 7.20 virtualization optimizations or passthrough, or a combination of both. (I’m inclined to believe the latter.)
The interesting thing I’ve noticed is when you do PCIe passthrough to a CHR VM, Proxmox is reporting insanely high CPU utilization of 80-120%, while RouterOS reports 9-12%.