These are my observations on the last 2 long-term releases (6.46.7 and 6.46.8), there are things that just break that used to work before, and it is just annoying and frustrating.
1. False positive DFS detections
Observed on RB952Ui-5ac2nD that is located on the ground floor of internal courtyard (more like a chimney) of a building. The opening is approximately 15x18 meters, there are 6 stories on top of this router, and there are at least 8 walls (4 rebar, 4 wooden framing) in the nearest direction outside of this building, so there is absolutely no way that external radar signals can be seen at this install location. The closet weather radar is located some 17 miles away, and is actually below terrain level from this location. There are also at least 60 other APs visible from this one (only 2 are on DFS channels), and about 300 clients when I scan the site. Region is set to "united states" and tx-power is set to regulatory and mode is set to 5Ghz-AC only 20/40/80-XXXX, 802.11. U-NII-1 and U-NII-3 are so noisy that the AP does not select them. Usual selection after a restart is 5500 Ceee. Once or twice a day the radio will decide it has detected radar, again it is physically impossible for a radar to be received where this radio is.
2. Wrong/impossible channel selection
With the above setup, very often after the false positive the radar detection the radio will select a channel that does not exist in the united states AC channel plan https://apps.fcc.gov/kdb/GetAttachment. ... uROw%3D%3D , and should have never been selected with the above settings, such as 5710-eeeC, but also 5715, 5695, and other such that no client can see.
3. Not following scan list
If I set the scan list to 5270-5590 and 5650-5710, expecting that I would get channels 56,60,62,64,100,102,104,106,108,110,112,116,132,134,136,140, however that is not what the radio shows. It would say 5700-eeCe, which is channel 138 and clearly outside of the frequency I am asking the radio to work. If it selects 5700 it should be running in 20Mhz mode only as that is the only possible legal channel in US on that frequency with the above given limits
4. Bridges/bonded interfaces stop transmitting traffic when qos is disabled.
This is being observed on several RB750Gr3 with latest 6.46.8, the other side is hap ac lite or . There is a bonded interface (2 ethernet ports) part of a bridge, and also another ethernet interface. There are vlans under these that are part of separate bridges. There is a queue-tree with several queues, and more specifically 2 separate queues for the same traffic marker - one with parent global and one with parent the bonding interface. Ever since 6.46.8 as if the sub-queue for the market traffic that is under the bonding parent is disabled, the connection to the other router drops. Looking at the interfaces (vlans under the bonding) they do not show any transmitted packets, only received ones. That affects all vlan interfaces,not just those that the marked traffic relates to. With prior versions I could enable and disable either of those two queues at will without the things going lopsided.
5. NV2 not transmitting traffic
This used to work just fine, again not any more. I had several links at 2.4 with 5Mhz channels running NV2 with fixed downlink percentage of 20. These links are sending sensor data upstream, there isn't downstream. After client and AP upgrade to 6.46.8 (from 6.46.6 or earlier) all the links came up, but there was no data flowing from the remote sites. Look up the AP - see the link is up and running and station radios registered. Torch shows nothing coming in though, no RX packets on the interface. Several restarts I drive there with another AP, pour in the config - same thing. Drive out to the remote side and swap a client radio, I see station is connected but again no relived packets. Wasted 2 days in replacements until I decided to switch the NV2 to dynamic downlink - lo and behold - IP starts flowing. I switch back to the fixed downlink with 20% and IP stop flowing. Fiddle with percentages - set it to 26 - IP packets flow again.
I and my customers have invested a good amount of time in the mikrotik setups, and it is just not possible for me to recommend you any more when you break things that used to work just fine, especially when most of my customer's deployments are remote and take anywhere from 4 to 24 hours to get to. Couple of years ago this things used to happen in "Stable", that's when I switched everything to "Long-term", but come on, how can so many things, in so many different areas break, in what is supposed to be the most stable release? What is going on?
I have grudgingly started replacing some devices with other vendors.