same bug
I’m staying on 7.20.8 LT because it performs far better on my hAP ac2 and hAP ax S.
With 7.22, the situation is simply worse:
-
On the hAP ac2, there is not enough free storage space and I’m getting critical errors in the logs.
-
On the hAP ax S, WiFi throughput is about 3 times lower, which is a massive regression.
So for me, 7.22 is not an upgrade at all — it actually makes both devices less usable. Until MikroTik fixes the storage issue on the ac2 and the severe WiFi performance drop on the ax S, 7.20.8 LT remains the only sensible choice.
I had an issue where my backhaul for CAP was configured to skip DFS channels even though it was configured to work on one. This was misconfiguration that I didn’t notice before update. After update the backhaul didn’t start correctly and I needed to physically connect to it and fix my configuration to skip-dfs-channels=disabled. After that backhaul started. I'm regarding the previous behaviour as bug and current more stricter behaviour correct.
time for netinstall
before update my log showed :
[Raw-TCP-Drop] prerouting: in:pppoe-out1 out:(unknown 0)
after update my log showed:
[Raw-TCP-Drop] prerouting: in:(unknown 15) out:(unknown 0)
hummm….. What is this “unknown 15” ?
why the “pppoe-out1” bacame “unknown 15”?
do /export show-sensiteive (DO NOT POST ON FORUM) and find if any item have "*" inside, like "=*15" or like "=*F" (regardless, any * in export is bad)
Or try /interface/print show-ids, I guess that will do the trick.
Yes, but if something is lost or broken on update it stands out better from the export...
thank you for your reply
I used this command and found this pppoe interface ID is B ,not 15
Small issue when upgrading 3 Audiencé (one acting as AP and the other 2 connecting as station-bridge): I had to switch to wpa2-psk, then delete and reapply the /interface/wifi/security statement for my mesh network.
The clients were looping with a message stating "no common authentication".
The exact message is wifi3: incompatible security with XX:XX:XX:XX:XX:37, no common auth
thank you for your reply!
I used this command and found neither "", "15", nor "*F"
i think the interfaces ids are shown in hexadecimal form
the real 15 —which should be “*F” , is one of my internal VLAN interface 
My guess was this.
Look for any occurrence of entries starting with an asterisk in the export; it means some association has been lost... and not just in the interfaces.
It should be done with every update... 
Upgraded from?
You have shell access to current versions?
Thank you again for your reply.
I understand what you meant now, and I used the export command (+show-sensitive) to export all configurations. Unfortunately, there wasn’t a single configuration line containing the * character, and they all appear to be functioning normally. I also checked the Raw rules in the firewall, and the port names are displayed correctly.
It seems like there are no other impacts—it’s just that the log display appears to be mangled from pppoe-out1 to unknown 15 
Perhaps adding the interface name in log message works for pppoe interfaces (and probably more...) and fails for your vlan interface? Do you know what interface was actually used when this message appeared (from firewall rules logic)? Can you reproduce from different interfaces (and interface types)?
Thank you for the reply !
I’m sure this “unknown 15” is my pppoe-out1 and it’s using pppoe-out1 interface when the log appeared
This raw rule is created to add some bad IPs to blacklist if they tried to visit my port 22
before the update i can see these in the log : input interface name “pppoe-out1” +some IP be added to blocklist
after the update ,the pppoe-out1 became unknown 15 ,but the rule is still OK because it is still blocking bad ips which tried to visit my port 22