iOS 18 Wi-Fi connectivity issue

^^^
Thank you, sir. Marvellous find. encryption=ccmp,gcmp, solved it for me too. Working again with FT enabled.

These two are basic encryption algorithms (ccmp is almost another name for AES, used in WPA2) which every device supports pretty bug-free. They use 128-bit keys. The other two (ccmp-256 and gcmp-256) are new ones (using longer keys), but it seems that only a few devices support them (or rather claim to support, but their support is flakey) and some don't support them but barf upon stumbling on an AP which mentions support for them.

I did some testing a while ago (with ROS 7.1 and old wave2 driver running on Audience) and some of my older devices (which even don't support WPA3) didn't want to talk to such AP. So the result is that on my APs only basic encryption types are available for now.
I'm surprised that this is s problem with such a modern OS as latest iOS (personally I'm not an iVictim, so what do I know :wink:). But then there might be a problem with implementation of Xcmp-256 codecs in ROS.

We’ve been using both the preview and the latest releases of iOS 18 and macOS 15 (Sequoia) for a while now. I also checked with some colleagues who’ve spent a lot of time at different customer sites (including some Mikrotik setups) and none of them have had the issues described in this thread. My wife upgraded her iPhone to 18 a few days ago and hasn’t had any problems either at work or at home.

I’m not ruling out bugs but I’m pretty sure if there was a bigger Wi-Fi issue we’d have noticed it by now. This makes me think there might be some misconfigurations in the Wi-Fi network causing these devices not to connect.

Here are some useful resources:

If you’re still having issues and are convinced it’s a bug I’d recommend reaching out to Apple Support: https://getsupport.apple.com/products

I have this same problem - configs worked fine on iOS 17/mac14, not working anymore on iOS 18/mac15.

Setup:

  • wifi devices: works after enabling encryption=ccmp,gcmp, doesn’t work in default (ccmp only?) mode
  • wireless devices: I can’t find the encryption setting, so I can’t make these work

What I suspect happens is that the new iOS/macOS versions enable ccmp256 by default, but either Mikrotik or iOS doesn’t support that well, so the connection doesn’t work. Forcing only ccmp/gcmp, it works.

@iustin,
The problem is not in ROS. Everything works for me on iOS18 regardless of whether encryption is enabled (ccmp/gcmp/ccmp256/gcmp256) or not

Did OP ever tell us which ROS version his/her problem occurs on?? Or which Mikrotik AP? I would guess Audience but who knows.

Link to Apple Support: https://getsupport.apple.com/products

Latest v7 release. I’ve already swapped out the MikroTik Audience APs for a competing Wi-Fi AP product from another vendor and “like magic”, everything works fine, even iOS 18 devices. I’ve switched on/off from MikroTik’s Wi-Fi gear so many times over the years, I don’t even see the point in continuing to use their Wi-Fi gear. There would need to be significant and compelling reasons for me to switch back at this point. The competition in the Wi-Fi space is so far ahead of MikroTik it’s actually kind of sad. I’ll continue to use the routers and switches but ugh, the wireless gear is like being in the stone age at this point. That doesn’t even brush upon the shortcomings of the management solution for them (CAPsMAN) which is a wholly separate problem in itself.

Hell, I haven’t even had a response or acknowledgment yet on my open ticket with support about this. I’ll leave the ticket open and hope maybe it helps everyone else but I think I’m done and moving on for a while. I need wireless gear that works without me having to touch it to fix something and it needs to be much easier to navigate, set up and manage. What we have now leaves much to be desired. There isn’t even 6e or 7 wireless standard hardware available yet from them.

@k2dI5umrD9VO:
Link to Apple Support: https://getsupport.apple.com/products

Latest v7 release.

That was a simple question about the ROS version number; the answer to that is not “latest”. We don’t know what you think “latest” is.

Yet, you come to the forum, create a topic, and want to place all the blame on ROS. That’s a rather strange approach. The device you’ve updated has a problem after update. Is there a correlation?

Sure, ask for help and for ways to solve the problem. Or for sharing your experience. There were also plenty of suggestions to direct the issue to Apple. Yet, Mikrotik gets all of your frustration. The hurdle for an Apple developer account is probably higher than venting your frustration in Mikrotik user forum.

No one denies that there is also a problem in ROS. However, the issue specifically occurs after an update of the iOS device. It makes sense to first report to Apple.

And because you didn’t mention it, many people here believed your issue was was with an AX AP (wifi-qcom driver). That’s why there are also responses saying it works perfectly on iOS 18. However, the Audience is an AC device with a wifi-qcom-ac driver. That’s a completely different driver and hardware.

Some remarks:

  • no reason to enable FT on mesh link (wifi3). Or are your Audiences moving around?
  • connect-priority=0/1. I see this in every second config pasted here. Are you all copy pasting from the same topic?
  • .encryption=ccmp,gcmp,ccmp-256,gcmp-256. Is this something WinBox sets? Or is this on purpose?

I found that @normis gave this as advice:

As this wasn’t working form me, I set it back to default. But that is were it might have come from.

The default is “ccmp” - according to wifi docs. So there is no need to explicitly disable TKIP.

https://help.mikrotik.com/docs/display/ROS/WiFi#:~:text=encryption%20(list,to%20ccmp.

Hi,
We are also facing the same problem. Our case is:

  • Corporate Mikrotik Network using Radius


  • Devices connection in other networks using WEP2


  • The devices never had a problem before iOS 18/Sonoma

There is a point. If you restart the device, it will work (either in your home or the organization).

That is what I need to do, as well as others.

Any clue?

I have the same issue with my iPhone 15 Pro Max and MacBook M1 Pro (2021) when connecting to the cAP Ax2 (ROS 7) as well as the hAP Ac2 (ROS 6) with CAPsMAN. Turning on the GCMP cipher resolves the issue with the cAP Ax2 (ROS 7). I’m going to try the same with the hAP Ac2 (ROS 6) CAPsMAN, where I couldn’t connect to my network until I rebooted the MacBook. However, after deep sleep or some time, the issue reappears, and I have to reboot the MacBook again to make it work. Meanwhile, my wife’s iPhone 16 Pro Max has no issues at all, regardless of whether the GCMP cipher is enabled.

I also have a similar issue with my BMW X4 CarPlay function. BMW uses Bluetooth and WiFi for streaming audio, and after a fresh iPhone reboot, it works. However, after some time (maybe a few hours), it won’t connect until I reboot my iPhone.

It seems like this is an Apple problem, and I can’t resolve it myself in the BMW like I did with the MikroTik. And it’s better described as a workaround rather than a solution.

Update: solved in iOS 18.2 beta 2

Hi all. Just wanna contribute some info (with temporary workaround) that I have found during investigation of the issue.
So, after updating my iPhone15 to 18.0.1 I got similar issues as described in this topic:

  1. I was using hAP AX3 (WPA2 PSK+WPA3 PSK / CCMP+GCMP) and hAP AH2 as temporary wireless bridge (it was connected as a station to AX3’s 2.4 GHz network and was repeating the same SSID with it’s own 5Ghz interface in a pseudo-bridge mode, but with WPA+WPA2/ aes + ccm).
    So after update I wasn’t able to connect to the wireless bridge running on AH2 (I was getting the same logs as were posted above: connected/disconnected).

  2. I lost ability to connect to my action cameras: Insta X3, Insta X4 and GoPro 11 (they are using their own wifi to transfer filmed data).

At the same time my old iPhone 12 (iOS 16.5.1) works perfectly with all my cameras and hAP AH2 )

First issue was solved by migration to hAP AX2 + CAPSMAN.
With second issue I went to Apple (I even came to their office and brought my cameras hehe ).
I was sure that it’s an issue with implementation of WPA2 + ccmp back-compatibility.
But today after updating my iPhone15 to iOS 18.1 I found a way to reproduce an issue and even to find a workaround.
It’s very funny: if I connect iphone to some network with WPA3 and then try to switch to other wifi with WPA2 (this is exactly what was happening in both my cases) I get “incorrect password” error :slight_smile:
So…
If I disable “auto-join” for WPA3 network, reboot the phone - my first connection to any WPA2 network will be successful. If I then join any WPA3 network I won’t be able to connect to any other WPA2 network again until reboot )

So looks like this bug in iOS “caches” somehow WPA3 auth. method and trying to use 192 bit key everywhere until reboot (otherwise I don’t know how to explain “incorrect password” error for saved networks that were used before iOS update without any issues).

HTH

Usually, you just need ‘Forget Network’ to clear cached auths.

I wish that things would be so simple but nope ) this iOS update have brought a lot of surprises.
It’s not some kind of intended “cache”. Before going to apple office I have tried “forgetting” network, changing the behavior of MAC address (this feature was implemented in this update), complete resetting network settings (this action actually deletes all known networks, all settings related to those networks and even VPNs).
It’s some kind of glitch “cache” but I can reproduce it for 100% of my attempts: after connecting to any WPA3 powered network you will be no longer able to connect to any WPA2 network unless you reboot the phone. I think iPhone starts to use WPA3 for any WIFI connection since it tried it once )
This actually explains most of the floating problems described in this thread…
I went to Apple’s office to report the bug cause I am too lazy to install XCode ) their office is 20 minutes far away from my place :slight_smile:

Well, according to Apple Support ‘Forget Network’ should clear cached auths. Unless there’s a new flaw in iOS 18 I don’t know about..

I don’t have such issue, at home using MT device (ac wifi) and WPA3; and at work is WPA2 (non MT device). Can connect to both with iPhone iOS 18.1 (different SSID/BSSID ofc)

Who knows - may be it’s hardware dependent. But differently the need of rebooting device to connect to some wifi networks is something that I wouldn’t expect from the gadget with $1500 price )
For me it’s reproducible in 100% cases: connect to WPA3 powered WiFi (MT) leads to no connectivity to any WPA2 network (neither running on MT nor Action camera) unless device is rebooted.

IMHO: I don’t have anything special about my MT setup

/interface wifi security
add authentication-types=wpa2-psk,wpa3-psk disabled=no encryption=ccmp,gcmp ft=yes ft-over-ds=yes name=MyWiFi-VLAN10-SEC
/interface wifi configuration
add disabled=no mode=ap name=MyWiFi-VLAN10-CONF security=MyWiFi-VLAN10-SEC security.ft=yes .ft-over-ds=yes ssid=MyWiFi-VLAN10
/interface wifi
add channel.band=2ghz-ax .width=20mhz configuration=MyWiFi-VLAN10-CONF configuration.mode=ap disabled=no name=cap-wifi0-2Ghz radio-mac=XX:XX:XX:XX:XX:XX security=MyWiFi-VLAN10-SEC
add channel.band=5ghz-ax .width=20/40/80mhz configuration=MyWiFi-VLAN10-CONF configuration.mode=ap disabled=no name=cap-wifi0-5Ghz radio-mac=XX:XX:XX:XX:XX:XX security=MyWiFi-VLAN10-SEC
set [ find default-name=wifi2 ] channel.band=2ghz-ax .skip-dfs-channels=10min-cac .width=20mhz configuration=MyWiFi-VLAN10-CONF configuration.hide-ssid=no .mode=ap \
    datapath.bridge=CAPSMAN-BRIDGE disabled=no name=wifi0-2Ghz security=MyWiFi-VLAN10-SEC security.authentication-types=wpa2-psk,wpa3-psk .encryption=ccmp,gcmp,ccmp-256
set [ find default-name=wifi1 ] channel.band=5ghz-ax .skip-dfs-channels=10min-cac .width=20/40/80mhz configuration=MyWiFi-VLAN10-CONF configuration.mode=ap datapath.bridge=\
    CAPSMAN-BRIDGE disabled=no mtu=1500 name=wifi0-5Ghz security=MyWiFi-VLAN10-SEC
/interface wifi capsman
set enabled=yes interfaces=CAPSMAN-BRIDGE package-path="" require-peer-certificate=no upgrade-policy=none

And I totally agree with Larsa: all those issues should be reported to apple support.