Updated hap AX3 from 7.15.3 to 7.16RC.
Entire WIFI/capsman configuration empty(All the tabs, configuration, channel, security..etc), router half responsive, cant connect phone to WIFI at all, barely managed to connect via Winbox.
I tried to make supout file for support but that also was somehow broken and saved nothing.
Reverted to 7.15.3 and all back in working order.
Does Mikrotik support maybe want my router config so you can try reproduce entire thing locally for your self?
Compare the price of these products and you know!
Also note that with MikroTik you get free software upgrades and technical support, while with those other brands you need to pay for a support contract to get these.
And that makes you pay the device again in a couple of years.
not to forget e.g. Cisco APs in the 150€ business line have a very very bad reputation. A “serious” Cisco AP from the catalyst line cost at least 5x of a cap ax for example. So lol.
With the recent update:
*) DNS - match NXDOMAIN static entry only if other type entries for the same name are not found;
I’ve noticed an issue that affects the way DNS rules are applied. Previously, it was possible to block adservice.google.com by returning NXDOMAIN and then forward the rest of google.com domains to an external DNS server. However, with this update, it’s no longer possible to block ads this way because the second forwarding rule matches *.google.com, which overrides the first NXDOMAIN entry for adservice.google.com.
I believe this change introduces a problem. In most DNS-related configurations, like in dnsmasq, the rules are executed sequentially from top to bottom. I’m not sure why this change was made, but I strongly suggest that the rules should be executed based on their order, rather than checking for matches with other rules.
Here is the example code I’m referring to:
/ip dns static
add name=adservice.google.com type=NXDOMAIN
add forward-to=dns.google regexp="(\\.|^)google\\.com\$" type=FWD
I have the same problem. I hope the developers will seriously consider it.
I always had the issue that a regex FWD record had priority over a static A record. Was that different with NXDOMAIN?
The priority should normally be determined by the order of the rules, not by their type. In other words, rules that appear earlier should have higher priority than those that come later.
Well, your opinion. RFC 1034 is what is relevant.
https://www.ietf.org/rfc/rfc1034.txt
The order of RRs in a set is not significant, and need not be preserved by name servers, resolvers, or other parts of the DNS.
I wonder why you use a regexp match instead of an explicit match for google.com + the setting “match subdomain”?
I would think that is much more efficient…
Maybe because that capability was introduced later?
That is something different! It specifies the order of the data in the DNS reply, not the order of processing of rules.
Indeed, pe1chl.
As I understand it, regardless of order, NXDOMAIN should overrule anything. It says basically the domain does not exist, so it makes no sense to look further. IMHO it is a bug when NXDOMAIN records exist but other records are considered instead. In fact a huge bug.
It’s difficult for me to evaluate the match subdomain feature, but I can say that it’s not very useful. Besides the fact that it randomly fails to match, which many people around me have experienced (including myself, leading me to abandon it), there’s also the reason why I’m using regex. Below is the complete code, which match subdomain simply can’t achieve:
/ip dns static
add forward-to=dns.google regexp="(\\.|^)google\\.[a-z][a-z]([a-z]|)(\\.[a-z][a-z]|)\$" type=FWD
This “fix” was probably introduced for the case where you have two explicit static entries, one for “machine.example.com IN A 1.2.3.4” and another for “machine.example.com NXDOMAIN” and then the client asks for MX or AAAA or whatever.
In that case a proper DNS server should reply with “no data” instead of “no such domain”, but we all know the quality of the MikroTik DNS service and it probably had issues with this, which they fixed.
But now it runs in trouble with wildcard entries…
It will continue like this until they throw the towel and use an established and well-tested resolver.
Mikrotik is not known for “throwing the towel”. Not a single line of code is given up voluntarily.
You do realize you can simply set the regexp to be the explicit name and that will ensure it gets blocked accordingly and the rest is allowed. Like below.
/ip dns static
add regexp=adservice.google.com type=NXDOMAIN
add forward-to=dns.google regexp="(\\.|^)google\\.com\$" type=FWD
The AP has the ability to tell clients that the AP’s channels are going to change at a specific time, then everybody jumps at the exact same time to provide seamless switching. If the hardware has the capability to listen in the background for cleaner channels, then it will do a background scan, then (ideally) jump to a cleaner/clearer section of the band.
*) wifi - send channel switch announcements to clients when switching channels at requested re-select intervals;
Is it supported for standalone wifi, capsman or both?
If i understand correct, can i use this commands as a kind of whitelist?
-faxxe
You would expect that to work, but the bug reported here is that it does not work (in this version).
Cool that you try to interpret their changelog entry. But I want that confirmed by Mikrotik staff. The changelog leaves too much room for interpretation. It could be either a background scan and then the AP promotes the new channel right away. But it could also be that the AP just promotes the 2ghz BSSID when the 5ghz BSSID goes down for scanning (or vice versa)…