bridge: learn-limit per bridge port, counter reset condition (on router reboot, on port down/up, manual etc)
dot1x: guest vlan for clients unsupporting dot1x - found workaround impemented in 7.2
dot1x: authentication per host (allow multiple (un)authenticated hosts on one port)
general: mc-lag or stacking for HW redundancy - mc-lag implemented in 7.1
bridge: more support for interface-list in configuration already implemented, don't know in which version
Router
ppp: push routes for VPNs (through DHCP-Info response) for split tunneling, same like split-include in IKEv2 - it is possible use Mikrotik DHCP as workaround from 7.21
dns: filtering request based on source IP
dns: action redirect requests to external DNS (regex or domain filtering) - implemented in 6.47
general: more support for interface-list in configuration (for ex. Routing rules)
proxy: ssl proxy - redirect incoming requests to http(s) servers based on sni (=SSL offload, only for powerful RBs) - can by implemented in container - finaly in 7.22
proxy: mDNS reflector for running mDNS across VLANs - can be implemented in container, but native support would be better - native in 7.16
IPsec: posibility to choose IPsec Proposal / Profile in IPIP, EoIP, L2TP etc. configuration
ikev2: optionally add dynamic routes for ikev2 connected clients (like with PPP links) for proxy-arp functional
ipsec: add VTI support (virtual interface for tunnels)
certificate: add pre and post script for automatic LE cert renewal
email: add OAUTH2 support (+ script for token refreshing)
WiFi
(Why Mikrotik missed oportunity in WiFi4EU?) - not actual
ap: add roaming standards 802.11r/k/v - also between APs already implemented
ap: add band steering or something like this (push multibands (2G/5G) client to specific band on defined conditions) - already implemented
CAPsMAN: compatibility wifiwave2 APs with old (non wifiwave2) APs - supported, but without dynamic vlan assigment
ap/radius: add quest/quarantine vlan options - similar behavior like in dot1x
Do you have a specific purpose here which cannot be achieved with the firewall now? Remember that the UDP IP cannot be trusted anyway.
Days of UDP DNS are counted like HTTP ones were ~2 years ago. Now Firefox ships with DoH by default, Chrome which is a market leader will probably follow suit soon. IMHO it’s a waste of time to implement any advanced DNS filtering/inspection/modification in ROS since it will be obsolete soon with DoH gaining popularity.
I don’t think this is a good fit for a router - such tasks are usually handled by specialized load balancers dealing with the mess of TLS & HTTP protocols as they are (since standards are one thing and how browsers & servers handle that is a way other thing). Additionally, this will get very quickly obsolete with ESNI which is in draft and prepared to work with TLS1.3. IIRC this will be an IETF standard in mid 2021 backed by CloudFlare & Google.
Actually if the 1st thing is implemented the 2nd is not needed. The whole point of 802.11 is that the client decides what to do and not the AP. Trying to mess with this (e.g. zero handoff) is a hack around the protocol which causes plenty of problems. If MT implements actual protocols to inform the clients about conditions from the AP’s perspective modern clients can roam without any problem.
The second thing is kind-of implementable today with access list & powers but kicking clients manually based on signal is a poor way of dealing with lack of 802.11r/k/v.
Yes, I have. For example, if I want have local DNS server for multiple LANs with different purpose, when some LANs need some records that other LANs shouldn’t see / know them. Or in case of DNS split. Yes, I know about DoT / DoH, but this technology are available only in browsers. There are many devices and aplications, that support only old DNS (over UDP).
Actually this has been implemented in 6.47.
In this point I agree with you. It si not primary function of router (but SMB is not too). It should help provide multiple https services (from different servers) through one public ipv4 to internet.
[/quote]
The problem is with clients, that don’t want roam or they have another bad behavior. I disagree with you, that only client should decides what to do. I think, AP should have mechanismus to push clients to another bands or another APs in network with multiple APs.
Yes, today on MT, I can defined minimal signal strength of connected clients, below that AP kicks clients. But this solution is very problematic in areas with worse coverage.
auth-types (dot1x | mac-auth; Default: dot1x)
Used authentication type on a server interface. > When both options are selected at the same time> , the server will prefer dot1x authentication type and only after 3 retrans-timeout periods, the > authentication type will fall back to mac-auth> . In order for mac-auth authentication type to work, the server interface should receive at least one frame containing a client’s device source MAC address.
So, I activated both auth types and for “dumb” client mikrotik tries auth them by their MAC, radius server refuse it and mikrotik assign port to reject-vlan-id.
Finally guest-vlan-id (and server-fail-vlan-id) spotted in documentation for v7.2. No more workarounds!
I wish they support more switch chips for Bridge VLAN filtering offload. Even older chips like Atheros8327 and others.
dot1x: authentication per host (allow multiple (un)authenticated hosts on one port)
Actually it should also allow per mac address assigned VLAN (via radius response message).
