After upgrading the hap ax3 to 7.17.0, I noticed that two WiFi devices on the network were unable to obtain an IP address from DHCP, namely an ESP32 board used to control lighting, and the other being a Frontier Smart Technologies Venice X Radio controller.
I saw there were many DHCP-related items in the 7.17.0 release notes, and my hope was that 7.17.1 would address this. However, following the upgrade to 7.17.1, none of the wireless devices were able to obtain and IP address (this includes a variety of devices, such as camera controllers, regular laptops (both PC and Mac) and other miscellaneous devices.
Logs show that wireless association succeeds, but devices fail to obtain an address and default gateway.
Wired devices (the majority on the network) have no issues.
I also noticed that devices connecting via remote access points were unaffected; only when the hap ax3 itself is used for wireless access is the problem present.
Our network is relatively simple, it consists of one /22 network and three /24 networks (one isolated), which are assigned based on VLAN (by router port) or wireless SSID.
The port that previously served one of the /24 networks is currently disabled, which I understand was an issue in 7.17.0 that was supposed to be addressed by 7.17.1.
The issue remains on 7.17.2.
The downgrade procedure of this device unfortunately failed (it remained 7.17.1 after downgrading with the 7.16.2 npk).
Fortunately, I have a backup device with 7.16.2 - switching out the devices restored service.
I raised this with Mikrotik support in early January, but unfortunately have yet to receive a response.
Does anybody have experience with this issue, and / or should I look at any specific logs aside from wireless and DHCP?
I think I was able to resolve the issue, which was actually a multi-part problem.
Some places online suggested a problem with WebFig saving configuration (unrelated to my problem), so I launched WinBox to see if that would help.
While configuring the 5GHz WiFi, I saw a message no channels available in WinBox.
Further investigation showed the following:
Problem 1)
The default configuration has
/interface/wifi/channel/add name=5GHz width=20/40/80/160mhz [...]
20/40/80/160mhz and 20/40/80+80mhz are not operating modes supported by the Hap ax3.
Despite this, I was able to apply
/interface/wifi/configuration/set [ find default-name=wifi2 ] channel=5GHz
to the 5GHz WiFi configuration without encountering any errors.
However, this configuration prevented the radio from starting.
Problem 2)
The default configuration contains channels that are prohibited in the United States (e.g. 5400MHz), but the US version of the router has a hardware restriction that enforces compliance with local regulations.
By re-writing the channel configuration like so
/interface/wifi/channel/add band=5ghz-ax frequency=5180,5200,5220,5240,5260,5280,5320,5745,5765 secondary-frequency=5500,5520,5540,5560,5580,5600,5620,5640,5660,5680,5700,5720 [...]
I was able to start the 5GHz radio. These are all frequencies that are both permitted in the US and supported by the 5GHz radio.
I am unsure if this is the ideal configuration, in particular I am not clear on the relationship between frequency and secondary-frequency.
Problem 3)
Some of the interfaces that were previously named in 7.16.x lost their names in 7.17, and became unassigned.
E.g.
;;; Home 2GHz
5 I *7 bridge 1 0x80 10 10 none
Instead of *7, it should have said wifi2
This was the reason for the original problem, which showed client associating to the wireless interface, but being unable to obtain an IP address (the link of the wireless interface to the bridge had been broken).
NB: I noticed the default naming was switched, in < 7.16 wifi1 was 5GHz and wifi2 2.4GHz, in 7.17 wifi1 became 2.4GHz and wifi2 5GHz. I suspect this is the cause of this problem, as I had not explicitly renamed the interfaces..
In summary, what I think happened:
7.16 → 7.17.0
The upgrade messed up the interface naming, resulting in the loss of connectivity to the bridge, which however only affected the 2.4GHz WiFi.
This manifested in the loss of connectivity of the 2.4GHz only devices, like the light controller.
That would explain why I continued to see the wireless association succeeding, but no address being assigned via DHCP for those devices, while not noticing a problem with the 5GHz band, which for whatever reason was not affected by the interface linking issue.
7.17.0 → 7.17.1
This update broke the 5GHz radio configuration, which manifested as a total loss of wireless connectivity (as I had already lost the 2.4GHz interface due to issue explained above).
Hope this helps somebody.
PS: I worked through all this on version 7.18.2
I doubt that default config would include bits not supported by hardware. Default config (you can always check it by running /system/default-configuration/print) in my wAP ax has channel.band=5ghz-ax channel.width=20/40/80mhz … Dedault config also doesn’t set property frequency at all, which means that radio is allowed to use all channels supported by hardware. Again if you actually see property being set, it was some other “magic” setting it, not default config.
secondary-frequency is for “80+80” channels. You determined that your device doesn’t support it, so there’s no need to bother setting secondary-frequency at all.