NEHotspotConfigurationManager apply(_:completionHandler:)

Let me see if I understood your questions correctly:

Regarding:

Should "apply (: completionHandler:)" always be done when connecting? When you execute "apply (: completionHandler:)," it will be added to MYNETWORKS and automatically connected without having to apply again.

If you setup a NEHotspotConfiguration and then apply it with joinOnce set to false AND as long as the app that installed this configuration still remains on the device, then the network will attempt to re-associate automatically. If the association attempt is not successful then I would check the logs for further information. If joinOnce is set to true this association will only happen one time. Likewise, if the app that installed the configuration is deleted from the device the configuration will also be removed.

Regarding:

One more question, please. Have you set lifeTimeInDays and joinOnce in NEHotspotConfiguration? On our system, it remains the default because we want to be connected anytime, indefinitely. Should lifeTimeInDays = 365, joinOnce = false?

If you leave these values as the default values then, yes, as long as the situation I described above is true then an automatic re-association should attempt to happen if you are within range of the previously configured network.

When connecting with NEHotspotConfigurationManager apply (_: completionHandler:), joinOnce = false was set. lifeTimeInDays = 365. But things didn't change. The first connection that changes date drops in 15 seconds. I thought it was because I connected with the NEHotspot Configuration Manager apply from the app, but when I connected from Settings in iPadOS, it was disconnected. Has anyone had a similar problem that has been solved? Does anyone know of a change from iPasOS 14 to iPadOS 15 that might have caused this phenomenon?

But things didn't change.

Does this only happen for a specific Wi-Fi network, or if you attempt a configuration with another network do you see better results? If this is only for a specific network, I would take a look at the logs on the device when trying to automatically re-associate with this network.

Thank you for your reply. The event occurs when you have a Wi-Fi connection with the equipment we developed. This device connects to iPad via Wi-Fi (IEEE 802.11 n: 2.4 GHz). Up until iPadOS 14, everything was fine. It didn't happen until iPadOS 15. I have no idea why. Our device only connects to one iPad. I'm using DPMS. The IP address is always the same. Passwords aren't complicated. Could that be the cause?

This device connects to iPad via Wi-Fi (IEEE 802.11 n: 2.4 GHz). Up until iPadOS 14, everything was fine. It didn't happen until iPadOS 15.

This sounds like grounds for a bug report. By definition if something starts working differently than it used to, a bug should be opened to figure out why. It could just be that this behaves correctly, but to know for sure, a bug should be opened for further investigation.

Outside of the hardware your team built, does the configuration apply for other access points or are you just seeing this issue with your hardware?

We have not been able to confirm whether the event occurred outside of our equipment. partly because there is no Wi-Fi (IEEE 802.11 n: 2.4 GHz). When the same app was connected to a device using 5GHz, there were reports it wasn't happening. iPad (iPad 8, iPad 9, iPadmini 5, iPadmini 6, iPadAir 3, iPadAir 4) with iPadOS 15 installed is causing the issue. Does not occur in iPadOS 14. Does not occur when connecting with a static IP. Happens on the first connection of the day. With these three, if you can show us the case in which disconnection is performed, we can consider it.

When the same app was connected to a device using 5GHz, there were reports it wasn't happening.

Okay, this is good to know. If you do end up opening a bug report, please add this there.

Regarding:

if you can show us the case in which disconnection is performed, we can consider it.

If I understand you correctly, an API level dis-association can be performed using the API for removeConfiguration.

Okay, this is good to know. If you do end up opening a bug report, please add this there.

I also put it on feedback Assistant, but our poor English doesn't seem to understand it. Unfortunately, I've tried changing the title, changing the expression, and getting creative, but there's no answer, and a year is about to pass.

If I understand you correctly, an API level dis-association can be performed using the API for removeConfiguration.

If you use removeConfiguration., the settings you changed to manual connection will revert to automatic connection. Then it connects again and disconnects after 15 seconds.

A new fact was confirmed. iPad mini 5gen. + iPadOS 15.7.1 = Disconnect iPad mini 6gen. + iPadOS 16.1.1 = Disconnect iPad 8gen. + iPadOS 15.7.1 = Disconnect iPad 9gen. + iPadOS 16.1.1 = Not disconnected Results vary by model. That's going to be hard for apps to deal with.

JoinOnce does not work properly. In iPad 9 + iPadOS 16.1.1, turning our app to Sleep with JoinOnce = false does not disconnect the Wi-Fi. But on the iPad mini 6 + iPadOS 16.1.1, setting JoinOnce = false and turning our app to Sleep would disconnect the Wi-Fi. Maybe I'm using the NEHotspot Configuration Manager incorrectly? Well folks, is my code correct? We develop with Xamarin.

inline-code

	//----------------------------------------------------------------------
	// Interface（IWifiConnector）
	//----------------------------------------------------------------------
	/// <summary>
	/// Request a connection.
	/// </summary>
	/// <param name="ssid">SSID</param>
	/// <param name="securityKey">Security key</param>
	/// <param name="notifyResultAction">Connection result notification action (Request result, connection in progress)</param>
	public void RequestConnect(
		string						ssid,
		string						securityKey,
		Action<UsCommResult, bool>	notifyResultAction)
	{
		// If you are already connected to the specified SSID, notify the connection result and exit
		string currentSsid = GetCurrentSsid();
		if ((currentSsid != null) && (currentSsid == ssid)) {
			// WiFi connection complete
			notifyResultAction(UsCommResult.Ok, false);
			return;
		}

		// To use NEHotspotConfiguration Manager and NEHotspotConfiguration, enable "Hotspot" in the provisioning profile and "Entitlements.plist"
		var wifiManager = new NEHotspotConfigurationManager();
		var wifiConfig  = new NEHotspotConfiguration(ssid, securityKey, false/*isWEP*/);

		wifiConfig.JoinOnce = false; 	
		wifiConfig.LifeTimeInDays = 1;

		wifiManager.ApplyConfiguration(wifiConfig, (error) => {
			if (error != null) {
				// WiFi connection error
				//  ( Even when connected, the message is stored in error, so check connected before execution.)
				notifyResultAction(UsCommResult.WifiConnectionFailure, false);
			}
			else {
				UsDeviceModel.GetInstance().IsAutoFreezeOFF = true;

				// Start WiFi connection
				notifyResultAction(UsCommResult.Ok, true);
			}
		});
	}


	/// <summary>
	/// Get the SSID of the current connection.
	/// </summary>
	/// <returns>SSID（Unconnected：null）</returns>
	public string GetCurrentSsid() {
		// To use CaptiveNetwork, enable the provisioning profile and "Access WiFi Information" in "Entitlements.plist"
		string[] interfaces;
		CaptiveNetwork.TryGetSupportedInterfaces(out interfaces);
		if ((interfaces == null) || (interfaces.Length <= 0)) {
			return null;
		}

    try
    {
			NSDictionary networkInfo;
			CaptiveNetwork.TryCopyCurrentNetworkInfo(interfaces[0], out networkInfo);
			if (networkInfo == null) {
				return null;
			}

			string ssid = networkInfo[CaptiveNetwork.NetworkInfoKeySSID].ToString();
			return ssid;
		}
		catch (Exception ex) {
			return null;
		}
	}