Open Radar

 
Area:
Network Extensions Framework

The NEHotspotConfiguration APIs make it really easy to configure a network both for developers and end users. It's possible to get feedback from the API and related ones for issues like: 

- can't find the SecCertificate to be trusted with the Keychain APIs
- malformed NEHotspotConfiguration or NEHotspotEAPSettings
- errors applying a configuration

Everything that happens beyond the apply step is hidden from API users, which on one hand is great. I would much rather let the OS handle network management in a consistent way without needing to write something like a NEHotspotHelperHandler. But sometimes there are issues after the apply step where it would be very helpful to have feedback about the network that the app has configured. Some examples:

- Invalid EAP credentials
- Authentication server certificate validation failed
- Something more internal like "RSSI too low" or "detected known SSID but it was geotagged at a different location" (I don't have a lot of general networking knowledge let alone the implementation details on iOS so maybe this isn't something that would actually happen, but hopefully you get the idea)

I'm currently trying to troubleshoot flaky join behaviour using the NEHotspotConfiguration APIs in a few different ways (rdar://38765658) and although the APIs are very easy to use when things go right, when they go wrong it's very difficult to troubleshoot.

It would be useful from a development standpoint to know why an attempt to join and authenticate on a network failed, whether it's the reasons above or others. This would also be useful from a network operator's perspective for ongoing maintenance and troubleshooting of the network. It can also allow us to provide valuable feedback to end users.

I don't have a specific suggestion as to what this additional API functionality would look like, and I can imagine it might be tricky to implement in a way that would seem obvious (like providing a callback for error notification via closure, selector, notification, etc.).

Compared to the NEHotspotHelper behaviour where the app will be woken in the background to process commands, NEHotspotConfigurationManager is expected to be invoked only when the app is in the foreground. Perhaps:

- When the app is in the foreground, allow getting previous errors even if they occurred when the app was in the background or suspended (relies on the user launching an app that might not be intended to be used after initial configuration application)
- Change the API behaviour to launch the app in order to invoke error handling code (probably defeats any power use benefits of the NEHotspotConfiguration API)
- Add an extension type that could be launched in the background without involving the app (maybe less of a power impact than launching the whole app, but increases the work for developers with coordinating between the extension and the app if needed)
- Simply log these failures to the system logs with actionable information