RC5? OMG…
More RCs increase the probability that 7.16.0 will be reasonably stable. I think this is better than having to wait for 7.16.1 or 7.16.2.
Thanks! 
In a critical environment you will have to do that anyway, as 7.16 will get much more exposure than any of the beta or rc releases and new problems will inevitably pop up once 7.16 is released…
Maybe it would be an idea to separate the two channels “testing” and “development”, which are currently the same, and have beta+rc versions in “development” and only rc versions in “testing”.
Then users could be encouraged to select channel “testing” instead of “stable” in environments that are not that critical, and have more installs of rc versions before they become the “stable” release.
wow 3 weeks and only this i have to say im a little disapointed and no AX any thing mmmm
feeling left out
I still do not get it. Qualcomm is probably one of the largest wireless chipset manufacturers of the world. Then there is ROS, claiming to use manufacturer drivers (wifi-qcom/wifi-qcom-ac). And still there are long staying issues that apparently only affect ROS - and none of the other AX vendors also using Qualcomm chips?
Oh it’s coming. I know this for a fact.
This is exactly what puzzles me too, the implementation of AX and WPA3 that leads to serious interoperability glitches with Intel WiFi clients is the major problem I have with Mikrotik but unfortunately I don’t see much effort to mitigate the issues.
It’s a shame to have decommissioned a bunch of Mikrotik WiFi devices replacing them with other manufacturers’ APs to seamlessly connect clients with Intel AX2xx which btw is what the vast majority of laptop computers currently use.
Lets hope so as the ax and wpa3 is very unstable no matter what device and config you use
Lots of annoyed and frustrated customers filled the forums with so many issues lets hope the next round still waiting for has the magical fix that a lot of us are waiting on
1 ros works for some and not others and so on with different ros
Its my OPINION that MikroTik is having issues integrating the Qualcomm drivers with the Tik Hardware due to some hardware compromises in manufacturing … the great majority of other vendors who use the Qualcomm drivers are without the same issues THAT is affecting the Tik Hardware … Qualcomm drivers are EXCELLENT
It is very unlikely that an issue that affects clients with a certain manafacturer of wifi interface and a certain authentication protocol is caused by hardware issues on the AP side. This is 99% sure a driver issue.
But, when we deployed a large WiFi installation using the competitor’s (in the same price range) hardware, we faced issues as well.
And it was with clients with intel wireless, too. But not WPA3, it was 802.11k/r/v at that time.
Apparently some interoperability issues are unavoidable. That same competitor, who now has moved to different hardware, is now facing issues with “IoT devices”. And cannot get it under control.
According to changelogs (https://mikrotik.com/download/changelogs), development tree should be at 7.1rc7. Talking in account the quality of the releases, beta-versions should first got to development channel. RCs should go to testing channel. Final/Public/Official releases to stable of course.
*) dns - added support for DoH with static FWD entries
So, to my understanding, you should be able to point your main dns resolvers to DoH,
and then create a static forwarder for your internal domains to your internal dns resolver
It should use 8.8.8.8 or 1.1.1.1 t resolve the actual DoH I guess.
example
/ip dns
set allow-remote-requests=yes cache-max-ttl=1m servers=8.8.8.8,1.1.1.1 \
use-doh-server=https://security.cloudflare-dns.com/dns-query
/ip dns static
add forward-to=10.10.10.10 regexp="[*my.internal.domain.]" type=FWD
But this config still seem to forward all requests to internal dns resolver 10.10.10.10
The functionality is ok, your regular expression is wrong (matching nearly everything).
Ok, can you show me an example where I only want to forward my internal domain name (my.internal.domain.)
I thought my example would work, as I am only wildcarding the left part?
That page is wrong. development is the same as testing now.
Talking in account the quality of the releases, beta-versions should first got to development channel. RCs should go to testing channel. Final/Public/Official releases to stable of course.
That is what I already suggested, no need to repeat it.
With the improvements on ip dns static forwarding along with DoH, is it possible to add multiple servers to “forward-to” directive
http://forum.mikrotik.com/t/dns-forwarding-multiple-dns-servers/163556/4
This is not the neatest solution, as it will fail first request instead of retrying the next dns-server.
the forward-to directive should support multiple ip-addresses!
we found an issue on x86 and about E810-C dual 100g board about not propely passing eoip packets, seems dropped on intel side.
We were able to reproduce the issue in lab with two routers Core/Border connected back to back, with a Mellanox Connectx-5 on Core side, and intel 810 on Border side, with an EOIP an IPIP and a GRE tunnels configured back to back on a /30 configured between the routers.
In this configuration the Core/Mellanox side see the eoip tunnel up, the Border/Intel see it down.
On the same rotuers the ipip and gre tunnels are fine!
Moving both routers on Mellanox cards the problem disappeared.
SUP-165980 opened adding supout and rtrace
regards
user inactivity settings, will be nice to see how this works
