WifiWave2 seems very limited without bridging. I’d love to have it running on my Audiences as the connection between them is quite poor with the standard drivers even with a clear 160Mhz channel and being in the same room. I regret buying 3 of them.
Unless there is another way to make it work?
Docker is nice, but wifi that operates at more than 15% of PHY rates would be great.
Looking forward on this as well, RC3 still missing the ability to set the routing-distinguisher on VRF, need this for routing import export in MP-BGP
The latest release that has this capability is beta6, none of the RC’s have this capability
Please bring back the capability to set, import and export route-distinguisher
Can I also suggest a better wiki/kb explanation on using/applying cake for wireless-default and as the default queues? We really needed cake here, so I applied it with the supposedly most stable beta-release I could find that has cake support, but it’s a total black box regarding config under the winbox queues dialog now. For now I just got somewhere with trial and error;
Which queue types do I switch to the cake kind, and do I really need to enter/create a new Simple queue, or do the defaults work best? In my testing, I had to drop the Simple queue with cake I created between LAN - WAN, and for the metal 52ac between wifi and ethernet port, since it merely caused needless delays for packets to get through and probably a hot bunch of routers and access points.
bugs:
[SUP-44860]: v7.1beta5 x86 still crashes (winbox ip route crash)
[SUP-58832]: 7.1rc2 - sorting ip route (full route) by winbox load only once core
still pending!!!
Please attention this, they are about basic function on x86.
regrards
Ros
I was trying to add a bridge to my CHR (running on vmware) and once I set auto-mac=no (with a unique MAC address) then ARP would stop working. Setting auto-mac=yes instantly reverted back to normal operation. A reboot did not resolve the issue. I have a hap ac2 running the same version with auto-mac=no with no issues, so it seems to be a CHR issue.
Or it could be issue with how virtualization platform of your choice deals with network interfaces … some don’t allow guest OS to play with MAC addresses …
I have 2x Chateau LTE12 and fighting with site to site OpenVPN for few days, yesterday i was happy because after RC1 and RC2, whole reset, OVPN was starting to work (ping between routers but still not ping from LAN PC’s to other PC’s in other LAN behinde VPN. Even LED’s for signal strenght are working by default…
Then today popup new RC3, so i updated… and no OVPN there xD, no button on PPP. When use PLUS sign and click OVPN server Bindings winbox 3.29 closes itself…
Please fix this fast and provide some tutorial for OpenVPN on this router with v7.1 because i dont know if i am doing something wrong or just this router and his FW…
I have freezed money because i bought 2x LTE services and 2x this routers to complete infrastructure change in some company… 
Edit:
I just checked new Winbox 3.30 and nod closes itself anymore but ofc webfig and winbox still no OVPN button/server…
Doh! Thanks!
The reported crash when double clicking on a VPLS interface in Winbox has been fixed by the new Winbox v3.30
My hAP ac doesn’t hold any configuration after a reboot. Before that, it completely obliterated my existed config on update.
/status/check-installation is OK
On WebFig – Log - view there is missing possibility to choose log target and formatting of topic bar is broken. Wondering also why there is 3 empty columns which just waste the space.
on v7.1c3:
on v6.48.4:
hAP ac2 - none of the beta6, rc1-rc3 versions of netinstall can be used. (Windows).
I had to use netinstall 6.48.4 in order to flash v7.1rc3 on this hAP ac2.
I watched the traffic using wireshark, tftp transfer went fine but the device just didn’t show up in netinstall, same behaviour on all v7 netinstall versions tried.
Known bug?
Netinstall version has to be <= currently installed firmware version. I think the versioning of the netinstall package is misleading in this regard, since I would expect it to be the same as the RouterOS version I want to flash.
Well I’ve upgraded to 7.1rc3 and updated the routerboard/firmware too.
Still no go with 7.1rc3 netinstall.
What you say doesn’t seem to be the case here.
Also on hAP ac2, by default this is set:
system/routerboard/settings/print
cpu-frequency: auto
Which under load causes this:
/system/resource/print
cpu-frequency: 896MHz
Can’t this lead to overheating and crashes? Since the default CPU frequency is 716MHz?
And nobody saw this as a problem? again..?.. (since it was also the default behaviour when it was introduced in RouterOS v6 but was limited to default frequency later).
I guess this is the effect of using modern linux kernel, which supports CPU frequency scaling. Intel has same technology, named Turbo Boost, which allows CPU clock to rise beyond nominal frequency. It is then throttled down in case CPU temperature approaches predefined limits. The nominal frequency is the one which allows CPU to operate safely for prolonged periods of time.
I guess we’ll see how MT devices behave in long term … perhaps you could perform some tests? Run something CPU intensive (e.g. bandwidth test) for prolonged time, observe CPU frequency (sadly hAP ac2 doesn’t have any health sensors) and try to correlate that to bandwidth observed (with CPU throttling throughput should drop according to CPU frequency decrease).
BTW, it’s possible to manually set CPU frequency on hAP ac2 to 896MHz in ROS 6.X (at least in 6.48.4). Since this setting is static, I guess even running at this frequency for prolonged time should not exactly kill the device in short time. 6.48.4 also allows to set cpu-frequency=auto and with unloaded router actual CPU frequency drops to 488MHz (the lowest possible value available for manual setting).
Automatic CPU frequency stepping was introduced in 6.48 too. But I remember it got limited to 716MHz, I don’t have any devices with 6.48.x to test again, I’m still on 6.46.7 on most of them 
What’s new in 6.48 (2020-Dec-22 11:20):
*) arm - added support for automatic CPU frequency stepping for IPQ4018/IPQ4019 devices;
Apparently I’ve reported this on 7.1beta2 too:
http://forum.mikrotik.com/t/v7-1beta2-development-is-released/142356/156
Let’s not kill the hardware prematurely, shall we?
Found that in this release no one leds blinking now. At rc2 it was
hap ac lite.
Do anyone else have issues with MTU > 1500 on hAPac2 or RB4011, I mean, like just having a bigger l2mtu than 1592 make the device reboot randomly ( this happens on my hAPac2, did not tried the rc3 on the RB4011, because I need MTU 1600 on the vlan used for PPPoE).
I’m aware of the issue regarding the MTU after the reboot, but, in this case not having MTU 1600 at all is a deal breaker…