More explicitly, RouterOS "v7" means "a suffusion of yellow", at a given release (around 7.17 if I recall correctly) the new "device-mode" was introduced, making a number of configuration changes only possible after having explicitly allowed them through these new "device-mode" settings.
It is not an Ax or Ax3 thing, also if you update/upgrade any older device to 7.17+ you will have to take into account this device-mode.
Thank you very much for your help! After switching the device mode from home to advanced, the Hotspot setup worked perfectly and now it is fully functional. Much appreciated!
After successfully setting up my hAP ax³ as the main router (running as a hotspot), I came back with a new problem.
I’m trying to use an older MikroTik hAP lite as a wireless access point/repeater that connects to the hAP ax³ without any cables, using station-bridge mode.
Everything seems to connect fine — the hAP lite associates with the hAP ax³, and I can see the connection in the registration table.
The bridge is configured, and the DHCP client on the repeater gets an IP address from the main router.
However, any device that connects to the repeater’s Wi-Fi does not receive an IP address (it just keeps trying to obtain one).
Here’s a short summary of my current setup:
Main router: MikroTik hAP ax³ (running as hotspot, with DHCP and login page enabled)
Secondary router: MikroTik hAP lite (configured as station-bridge, with DHCP client on bridge1)
The repeater shows connection in “registration table”, ping to 8.8.8.8 works fine from the repeater itself
Problem: devices connected to the repeater Wi-Fi never get an IP
Is there any known issue or special configuration required when using a hAP ax³ hotspot as the main AP and another MikroTik (hAP lite) as a wireless bridge/repeater?
I want all connected clients on the repeater to be redirected to the hotspot login page from the hAP ax³.
Your diagnosis is correct and indeed there is an issue.
What you want is bridged wifi, which unfortunately is not supported by the 802.11 standard. (You may wish to look up 4-address mode for an explanation.)
This feature is implemented by vendors in vendor-specific ways, which due to the lack of standardization are often mutually incompatible. Mikrotik switched drivers from their in-house ones (known as the “wireless” package) to drivers supplies by their vendor, Qualcomm named “wifi-qcom” and “wifi-qcom-ac”. Both of these support bridged modes, but in an incompatible way. Yeah, it sucks.
A possible workaround if to create an L2 tunnel, usually EoIP that is terminated on opposite ends fo your wireless link. This adds significant CPU load on both sides, so it should really only be considered if the devices that would be connected wirelessly don’t have higher bandwidth requirements.
Thanks for the suggestion! I understand your approach — using IPv6 firewall rules to block packets from the secondary router’s MAC address would effectively prevent that device from exchanging IPv6 traffic, while keeping the rest of the network IPv6-capable.
However, in my case, the issue doesn’t seem related to IPv6 traffic itself but to how the second router (used as a repeater) interferes with address assignment or routing at the IPv4 level. Disabling IPv6 might mask the symptom but not really solve the root cause.
I’ll still test your method just to verify if the IPv6 layer plays any role here, but ideally, I’d prefer a clean configuration where both routers coexist properly on the same subnet using IPv4 only (or with proper bridge configuration).