NEHotspotHelper cababilities (background, app termination) + System keychain

Hello. I'm developing application that helps user with Wi-Fi connectivity. This application works with special hotspots. It supports are generally 2 types of hotspots: WPA2 (EAP-TLS) and WISPr. I have couple of questions about capabilities of NEHotspotHelper.

1. WPA2 Connectivity: if I clearly understand the only way to avoid user interaction with connection process is to add this known hotspots SSIDs to .mobileconfig and install it. And there is no way to programmatically install .mobileconfig to device keychain, correct? So, only way to install .mobileconfig is to place it on remote server and open link to file in Safari browser (or mail app).
2. WISPr connectivity: My aim is to avoid any user interaction with connectivity process. I use NEHotspotHelper to get callbacks when necessary hotspot is connected and programmatically authenticate on Captive Portal. So, when my application is running, it works like a charm. But, if user "kill" application, my app lose control in some cases: if user connect to Captive network when my app not running, my hotspot helper doesn't recognize connection. Connection is just recognized by system hotspot helper.

So, my questions:

1. Is it possible to get callback when my app is killed? Maybe there are way to suggest user to run my app? Any "legal" way. Maybe it possible with mobileconfig?

2. Is it possible to set high confidence to my network on start app when my hotspot already connected?

3. Is it possible to get access to system keychain, modify it, or at least read (check is certificate is valid or expired).


I'm will be grateful for any information which you can give me.

Up vote post of houseworks Down vote post of houseworks
2.0k views
Posted by
houseworks
Reply
Add a Comment

Accepted Reply

And there is no way to programmatically install .mobileconfig … correct?

Correct.

Note I’ve elided some of your text to enable a clear answer. Configuration profiles aren’t installed into the keychain, they’re installed on the system as a whole. Some parts may end up in the keychain, but there’s a lot of other complexity here.

But, if user "kill" application, my app lose control in some cases: if user connect to Captive network when my app not running, my hotspot helper doesn't recognize connection.

This is expected. If the user removes your app from the multitasking UI, that’s a clear indication that they don’t want it running. The system won’t run your hotspot helper app again until the user explicitly launches it from the home screen.

1. Is it possible to get callback when my app is killed?

Not reliably. If your app is suspended in the background when the user removes it from the multitasking UI, there’s no way for your app to know about that. The process running your app is killed without any more of your app’s code running.

2. Is it possible to set high confidence to my network on start app when my hotspot already connected?

There’s nothing stopping you from doing that. However, I suspect that there’s some background to this that I don’t understand. Care to elaborate as to what you’d expect this to do?

3. Is it possible to get access to system keychain …

No. On iOS there isn’t really a system keychain. Rather, there’s a single keychain and access is controlled by keychain access groups. Items installed in the keychain via a configuration profile will typically end up in the Apple keychain access group, and it is not possible for your app to get access to that group.

Taking a step back here, I want to stress that the hotspot helper mechanism was designed for typical user hotspot scenarios, and thus does not really have the flexibility you need. For example, in a typical user scenario:

  • Hotspot networks have no authentication, or at most trivial authentication (like WPA2 Personal)

  • The user is expected to explicitly join a hotspot for the first time

  • The hotspot helper is there to make it easier for the user to join that network on subsequent occasions

Given the above, my recommendation is that you file enhancement requests for the features you’d like to see hotspot helper support. And please post any bug numbers, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Replies

And there is no way to programmatically install .mobileconfig … correct?

Correct.

Note I’ve elided some of your text to enable a clear answer. Configuration profiles aren’t installed into the keychain, they’re installed on the system as a whole. Some parts may end up in the keychain, but there’s a lot of other complexity here.

But, if user "kill" application, my app lose control in some cases: if user connect to Captive network when my app not running, my hotspot helper doesn't recognize connection.

This is expected. If the user removes your app from the multitasking UI, that’s a clear indication that they don’t want it running. The system won’t run your hotspot helper app again until the user explicitly launches it from the home screen.

1. Is it possible to get callback when my app is killed?

Not reliably. If your app is suspended in the background when the user removes it from the multitasking UI, there’s no way for your app to know about that. The process running your app is killed without any more of your app’s code running.

2. Is it possible to set high confidence to my network on start app when my hotspot already connected?

There’s nothing stopping you from doing that. However, I suspect that there’s some background to this that I don’t understand. Care to elaborate as to what you’d expect this to do?

3. Is it possible to get access to system keychain …

No. On iOS there isn’t really a system keychain. Rather, there’s a single keychain and access is controlled by keychain access groups. Items installed in the keychain via a configuration profile will typically end up in the Apple keychain access group, and it is not possible for your app to get access to that group.

Taking a step back here, I want to stress that the hotspot helper mechanism was designed for typical user hotspot scenarios, and thus does not really have the flexibility you need. For example, in a typical user scenario:

  • Hotspot networks have no authentication, or at most trivial authentication (like WPA2 Personal)

  • The user is expected to explicitly join a hotspot for the first time

  • The hotspot helper is there to make it easier for the user to join that network on subsequent occasions

Given the above, my recommendation is that you file enhancement requests for the features you’d like to see hotspot helper support. And please post any bug numbers, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Thank you so much for your response, eskimo!



2. Is it possible to set high confidence to my network on start app when my hotspot already connected?



There’s nothing stopping you from doing that. However, I suspect that there’s some background to this that I don’t understand. Care to elaborate as to what you’d expect this to do?


If user kill my app and then connects our captive network, captive portal will appear on the iPhone screen. What I expect: as soon as user run my app again, my hotspothelper "handle" this network and captive portal no more appears. I didn't found mechanism to realize it, because I can set high confidence only when my hotspot helper get some resposne from system (e.g. Evaluate command). Is it possible? Please let me know if you still don't understand what I want.

Posted by
houseworks
Up vote reply of houseworks Down vote reply of houseworks
Add a Comment

THanks for the explanation. However, I think I’m still missing something. You wrote:

If user kill my app and then connects our captive network, captive portal will appear on the iPhone screen. What I expect: as soon as user run my app again, my hotspothelper "handle" this network and captive portal no more appears.

If the captive network UI is on screen, how can the user run your app? Perhaps you can walk me through the problematic case step-by-step?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

Of course!



Note: my app is designed for help user with connect to our hotspots. It's means that I want to avoid any user interaction in connect process. All captive portal authentication I do programatically in app.


So, because Hotspot Helper doesn't support mechanism to programmatically connect hotspots (is it?), we suggest users to install .mobileconfig file that includes information about known hotspots and user's iPhone automatically connects to our hotspots. If my app is running it works like a charm. Hotspot connects - app authenticate user in WISPr.


But this is scenario that i can't fix:


1. User install my app.

2. Run it.

3. Install .mobileconfig file.

4. Hotspot automatically connected.

5. My app authenticate device in WISPr.

6. Manually reconnect to other hotspot.

7. Quit and kill my app.

8. Connect to our hotspot again. ---> On this step there are no internet connection. iOS present captive portal to user.

9. Captive portal presented.

10. User click cancel.

11. Run my app again.

12. Trying to use internet (e.g. open any web link in safari) --> Still no internet connection. iOS present captive portal again.


On step 11 I want to pickup control over internet connection by my hotspot helper again. But to do it, I should create NEHotspotHelperResponse object and

set HighConfidence network by my hotspothelper. This possible only when hotspothelper get some callback from system (e.g. for evaluate command), isn't it? But on step 11, when my app runs again and hotspothelper registers, hotspot already connected and my hotspothelper don't receive any callbacks.


So, my question: is there any ways to return control over internet connection by my hotspothelper on step 11?


Thank you so much for help!

Posted by
houseworks
Up vote reply of houseworks Down vote reply of houseworks
Add a Comment

is there any ways to return control over internet connection by my hotspothelper on step 11?

Not that I can think of.

Realistically, you’re a long way off the beaten path here, with a test case that involves both installing a configuration profile and the user terminating your hotspot helper app. I’m not surprised that the hotspot infrastructure isn’t up for handling that case.

At this point my only suggestion is a trip to RadarLand™. You might want to file two reports:

  • A bug report about the specific scenario you’ve described here. It would be reasonable, at least in IMO, for the hotspot infrastructure to pass networks to a helper that’s newly come online after being offline due to user termination.

  • An enhancement request for APIs that would allow you to avoid the configuration profile malarkey.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment