User Profile

To test my own apps on an IPv6 network, I usually share a WiFi network using the option-click method in Sharing menu. This enables me to create a nat64 network. However, since my upgrade to iOS14 and Mac OS Catalina, this network is no longer giving me access to the internet. With an iOS13 device it does work. The behavior I see is that I get 2 IPv6 addresses, and a link-local IPv4 address. After connecting, iOS at some points prompts that this network has no connectivity and asks me if I want to stay connected. I found a related thread on the chinese forum that seems to describe the exact same situation: https://discussionschinese.apple.com/thread/251973678 I wonder whether there are more developers who have run into this issue.

We have found that it's no longer possible to retrieve Wi-Fi SSIDs from within a Packet Tunnel Provider using CNCopyCurrentNetworkInfo.Observations:Both the app and the packet tunnel provider are properly configured to be able to use CNCopyCurrentNetworkInfo, by including the required entitlements.When the app calls this method, a dictionary containing a valid SSID is returned.When the packet tunnel provider calls this method, a dictionary containing "Wi-Fi" is returned, no matter to which network are we connected.When removing the entitlement from the packet tunnel provider, nil is returned.From the app we can also use the NEHotspotHelper to obtain this information, but it is not possible to use this method from the packet tunnel provider.Taking into consideration the newly updated documentation: The requesting app must meet one of the following requirements: The app uses Core Location, and has the user’s authorization to use location information.The app uses the NEHotspotConfiguration API to configure the current Wi-Fi network.The app has active VPN configurations installed. An app that fails to meet any of the above requirements receives the following return value: An app linked against iOS 12 or earlier receives a dictionary with pseudo-values. In this case, the SSID is Wi-Fi (or WLAN in the China region), and the BSSID is 00:00:00:00:00:00. An app linked against iOS 13 or later receives NULL.ImportantTo use this function, an app linked against iOS 12 or later must enable the Access WiFi Information capability in Xcode. For more information, see Access WiFi Information Entitlement. Calling this function without the entitlement always returns NULL when linked against iOS 12 or later.This function returns NULL for iPad apps running in macOS.It seems the rules no longer apply to packet tunnel providers, only to apps.The app has active VPN configurations installed.Explicitly states that this applies to apps that have a VPN configuration installed. Not about the associated packet tunnel provider, if available. Has there been a policy change in how network extensions (in our case, a packet tunnel provider) can access CNCopyCurrentNetworkInfo? If the app has permission to read the CNCopyCurrentNetworkInfo because it has a VPN configuration installed (namely its own packet tunnel provider), why should that packet tunnel not be allowed the same permission?