Not using CAPsMAN and I had same issue, iOS connects and auto-joins if wifi is saved but on 1st join it stuck after entering password and it was unable to join. MacOS was able to connect but auto-join when saved was not working (on OS startup or wifi enable/disable toggle), only manual join worked when clicked on listed wifi, could be due to some auto-join timeout because join took much longer than usual. These issues was not present when connecting to slave wifi interfaces.
Unsettling interworking.realms-raw on master wifi interfaces, as suggested above, resolved these issues.
Meaning that you did not manage to delete the interworking,realms.raw and it is still there or that you managed to remove the setting but still you cannoit connect wiht an IOS device?
The error talked about in this thread is about the (hidden and arbitrary) creation of a
interworking.realms.raw=""
value (when using Winbox 3.x on 7.22.x).
How come you have a interworking1 ?
(maybe some values is needed for it in your configuration?)
Do you have an export of the device before the upgrade?
I presume you have already tried on the IOS devices to "forget" the SSID and re-connect?
Since iPhones broken down I started to make experiments with setting and unsettling directly within configurations, but I get tired quickly since there 4 of configs.
Then I and created interworking1 for setting and unsetting separately in one place.
Didn't try to forget-and-reconnect manually, will do.
The command (copied from erlinden's suggestion in another thread) more or less means:
Code
Action
/interface wifi configuration
change to section where there is one or more occurrences of interworking.realms-raw=""
unset value-name=interworking.realms-raw [find]
find each and every occurrence of interworking.realms-raw in the curent section and unset its value (i.e. set it to null, that is different from empty string)
So, yes, if the value in other configurations is under /interface wifi, your command will work.
Even with the commands listed, I was not able to get my 5ghz band to work with my apple devices. 2.4ghz band worked fine though. The only thing that worked for me was downgrading back to v7.21.3.
With 5GHz band there's a very real possibility that AP selects frequency that is either not supported by client (and client doesn't even show such AP in the list of detected SSIDs) or is subject to DFS and then AP defers start of transmission due to checking for radars (anywhere from 1 minute up to several tens of minutes, depending on frequencies chosen and actual scan results).
Either way, check what AP is doing (/interface/wifi/monitor <interface_name> run on CAPsMAN) ... it'll show something like this:
[CAPsMAN] > /interface/wifi/monitor cap-wap-5g-42
;;; operated by CAP F6:1E:57:XX:YY:ZZ%vlan-99, traffic
;;; processing on CAP
state: running
channel: 5260/ax/Ceee/DI
registered-peers: 2
authorized-peers: 2
tx-power: 20
channel-priorities: 0:5260/ax/Ceee/DI
1:5260/ac/Ceee/DI
state will show "scanning" (or something like that) while doing DFS check ... and channel will show you which actual frequency and channel layout was chosen by AP.
Also: some clients are not entirely happy if channel layout (for channels wider than 20MHz) is anything but Ce or Ceee or Ceeeeeee (i.e. anything else than C on the lowest 20MHz part of "wide" channel).