A reminder to everyone experiencing issues with wifi and Intel AX cards: report as much as you can to Mikrotik support. See http://forum.mikrotik.com/t/v7-16rc-testing-is-released/177857/1
In wifi security
Enable “WPA PSK” “WPA2 PSK” Group Encryption “CCMP”
Group Key Update “00:40:00”
Disable PMKID “enabled”
Management Protection “disable”
In FT tab
FT Enabled “enabled”
FT Over DS “enabled”
My Passphrase is 8 in length numbers and capital letters only
I used to see “SA Query timeout” but no longer do with these settings running 7.15.3
I do see a few disconnects,
Try changing the “Antenna Gain” to reduce Tx Power the lower the number to reduce the Tx Power
Success: CRS326 upgrade from 7.13 → 7.16
Took 4 minutes before switch started pinging again.
But you could upgrade your 7 year old switch to newly developed software in 2024!
For most manufacturers your device would have been end-of-life with no new firmware releases, and at most a fix for a newly discovered critical security problem… even when you had paid 20% of its new cost every year “for support”.
Just upgraded my RB4011 and hAP AX2.
All working fine, except that my 5GHz Wifi networks seem to have disappeared. Will have a proper look later.
Upgraded my hap ax3 from 7.15.2 to 7.16 about a week now ( simple home router).It feel like better throughput on wifi ax 5GHz.All my wifi client was wifi 6 (2 intel wifi 6, 2 qualcomm wifi 6 devices and one mediatek wifi device).TQ mikrotik
I checked with the support: regexes are indeed processed first. Therefore the *.home.arpa$ regex of type NXDOMAIN will override non-regex entries regardless of its relative position. Thus the workaround by @Amm0 is necessary.
It seems to me that administrative control over DNS leakage is lacking on RouterOS.
I am on 8+ days and RAM is declining indeed. I have not enabled graphing so I can’t proof it. But 2 days ago it was 31 or 32MiB free-memory. Now it is down to 29.3MiB. Let’s see where this is going.
/system/resource/print
uptime: 1w1d9m
version: 7.16 (stable)
build-time: 2024-09-20 13:00:27
factory-software: 6.44.6
free-memory: 29.3MiB
total-memory: 128.0MiB
cpu: ARM
cpu-count: 4
cpu-frequency: 448MHz
cpu-load: 1%
free-hdd-space: 736.0KiB
total-hdd-space: 16.0MiB
write-sect-since-reboot: 1128
write-sect-total: 32915
architecture-name: arm
board-name: cAP ac
platform: MikroTik
Hi,
Version v7.16 and v7.17xx are totally broken for ipsec.
I have escalated support, it does not renegotiate SAs, policies are shown as “Established” on one end but not on the other… these versions are a disaster for ipsec.
Regards,
Declining of available memory on itself is not the problem.
RAM is intented to be used by whatever process. That’s what the operating system needs to take care of.
It’s only when it’s not being released anymore when needed, then an out of memory condition happens.
That’s when the problems start…
I do not consider that a workaround, the solution with “match subdomain” is better than with “regexp” anyway!
The reason regexp is often suggested as solution for subdomains is that “match subdomain” was only recently introduced.
So there are two ways of doing it:
- use a NXDOMAIN for the domain with match-subdomain, plus explicit entries for hosts within the subdomain (best solution).
- use regexp but use it for both the all-hosts match and the explicit hosts, and put them in order with all-hosts last.
It seems to me that administrative control over DNS leakage is lacking on RouterOS.
To me it seams it isn’t… it can be done, and you can only debate whether some of these entries should be part of default config.
Probably not, because such conventions change over time and most users use none of them.
You could also want NXDOMAIN entries for rfc1918 reverse lookups as I wrote above. Probably saves more load on DNS system than this.
Can someone point me if I missing something new related to “scripts”, I have a script which was work prefectly fine before 7.16 !!
I belive part of the problems is
# Current GW
:local activeGW [/ip route get [/ip route find where active and dst-address=0.0.0.0/0] value-name=gateway ];
this return 0 why ?
/ip route find where dst-address=0.0.0.0/0
That jumped the shark since a client can just use DoH etc… Plus “content filtering” is rapidly moving target…and RouterOS development is not rapid. And they give you some tools, like regex/match-subdomain/NXDOMAIN/FWD to build-your-own.
And if you look Blocky container, it give you more control over blocking DNS (and the have arm/arm64 images that should work). For example, it has an option for the “home.arpa problem”:
https://0xerr0r.github.io/blocky/latest/configuration/#special-use-domain-names
But it also has dozen of other ones - that you/someone else might want - & no doubt change at more rapid pace than DNS updates in RouterOS.
_FWIW, I suspect the root cause of the “home.arpa” appearing comes from devices using Apple’s OSS implementation of mDNS Discovery Proxy, since it defaults to “home.arpa”. See also https://www.rfc-editor.org/rfc/rfc6762#appendix-G_
As Amm0 wrote:
/ip/dns/static/add name=nas.home.arpa type=A address=192.168.88.100 match-subdomain=yes
/ip/dns/static/add name=home.arpa type=NXDOMAIN match-subdomain=yes
The A record is not “explicit”. It also matches foobar.nas.home.arpa.
True. But to @kenzo’s point RouterOS is ill-suited to this.
Along the “home.arap” A records, it’s also very likely SRV and PTR ones too also with “.home.arpa” that escape too. So, theoretically, you need to block type=SRV and type=PTR too. Now… it’s actually the PTR ones you’d want to block since those “leak” stuff that your public IP was searching for light bulbs (_hap._udp.home.arpa PTR), printers (_ipp._udp.home.arpa PTR), etc.
But… the PTR records you cannot block since PTR is not allowed in type= within /ip/dns/static. I have two year old bug about it: SUP-100671.
Now… I really do think these “advanced DNS” tasks are better for a container. And at least some Mikrotik can just run a container.
This update make my LTE interface inactive on AT LTE18 . Can’t reach internet,read something that i must downgrade.
On downgrade i add routeros-7.15.3-arm64.npk file to File list and can’t update because winbox say that file is missing? try also with terminal to execute but same. Then im sugested to reset configuration, i do reset and now i can’t enter with admin and blank password in winbox. See device in winbox and now address is 192.168.188.1 but no enter with old password or blank password. What a mess with this update!
do you have a password sticker on your device?
Yes, but device is on pole, must go to roof, i miss to make picture of that password, can go worse:face_with_peeking_eye:
Beware of Change regarding BDPU and Bridge Mode!
In the past, STP on Mikrotik was not behaving well with Cisco Switches an PVSTP and Vlans. The solution was to disable STP on the Mikrotik to make it a transparent switch.
BDPU from one Cisco would be flooded throught the Microtik Bridge to the other Switch in the ring and the Cisco would set a port to ‘blocking’.
After Upgrading to 7.16 BDPU flooding with disabled STP does not seem to happen anymore. This results in broadcast looping!
I had to enable STP on the Mikrotik Bridge to stop the loop.
As regards to “SA Query Timeout” issue I reported earlier, I guess the reason is my config where the 2 GHz radio is used in both “ap” and “station” modes. The hAP ax3 connects over Wi-Fi to another MiktoTik router (hAP ac lite) - backup internet connection. Thus the hAP ax3 and the other router broadcast different SSIDs at the same frequency which may cause interference.
18:05:04 wireless,info 90:09:DF:**:**:**@wifi2 disconnected, SA Query timeout, signal strength -53
18:05:09 wireless,info 90:09:DF:**:**:**@wifi2 connected, signal strength -54
18:08:15 wireless,info 90:09:DF:**:**:**@wifi2 disconnected, SA Query timeout, signal strength -46
18:08:19 wireless,info 90:09:DF:**:**:**@wifi2 connected, signal strength -50
I tried to kick the client manually from the Registration table in a hope the laptop would connect to 5 GHz (wifi1), but that has not happened. And that it most likely the Intel’s AX203 issue…
18:09:10 wireless,info 90:09:DF:**:**:**@wifi2 disconnected, removed by user, signal strength -43
18:09:10 wireless,info 90:09:DF:**:**:**@wifi2 connected, signal strength -52
18:09:18 wireless,info 90:09:DF:**:**:**@wifi2 disconnected, removed by user, signal strength -45
18:09:18 wireless,info 90:09:DF:**:**:**@wifi2 connected, signal strength -52
18:09:27 wireless,info 90:09:DF:**:**:**@wifi2 disconnected, removed by user, signal strength -45
18:09:28 wireless,info 90:09:DF:**:**:**@wifi2 connected, signal strength -53
The Wi-Fi configuration is
> /interface/wifi/print detail
Flags: M - master; D - dynamic; B - bound; X - disabled, I - inactive, R - running
0 M BR ;;; comment
default-name="wifi1" name="wifi1" mtu=1500 l2mtu=1560 mac-address=78:9A:18:**:**:C4 arp-timeout=auto radio-mac=78:9A:18:**:**:C4
configuration=conf-home
configuration.mode=ap .ssid="Home" .country=*****
security.authentication-types=wpa2-psk .passphrase="*****" .disable-pmkid=yes .wps=disable .ft=yes
channel=ch-5ghz
channel.frequency=5170-5730 .band=5ghz-ax .width=20/40/80mhz .skip-dfs-channels=10min-cac
steering.rrm=yes .wnm=yes
1 M B ;;; changed intended channel to 2437/n/Ce
default-name="wifi2" name="wifi2" mtu=1500 l2mtu=1560 mac-address=78:9A:18:**:**:C5 arp-timeout=auto radio-mac=78:9A:18:**:**:C5
configuration=conf-home
configuration.mode=ap .ssid="Home" .country=*****
security.authentication-types=wpa2-psk .passphrase="*****" .disable-pmkid=yes .wps=disable .ft=yes
channel=ch-2ghz
channel.frequency=2437 .band=2ghz-ax .width=20/40mhz
steering.rrm=yes .wnm=yes
. . .
6 BR name="wifi7" l2mtu=1560 mac-address=76:4D:28:**:**:2A arp-timeout=auto master-interface=wifi2
configuration.mode=station .ssid="Backup ISP"
security.passphrase="*****"
Even though the band is set to “2ghz-ax” for wifi2, the radio operates in “2ghz-n” mode because of connection to the hAP ac lite.
Next time before a video meeting in Zoom I’ll make sure the laptop is connected to 5 GHz and hopefully won’t experience disconnects and see those “SA Query Timeout” messages.
@ips, @infabo, @flynno - thanks for you comments and suggestions!