Posts

Post not yet marked as solved
7 Replies
1.6k Views
I have an app that implements my own Packet Tunnel Provider, and to my knowledge everything I do is working as intended. However, I came across an issue with NEVPNStatusDidChange NotificationCentre observations when calling the following function multiple times:NETunnelProviderManager:loadAllFromPreferences(completionHandler:) From the documentation: You must call loadFromPreferences(completionHandler:): at least once before calling this method the first time after your app launches. As a result of this note, an early implementation I had took a very conservative approach; calling loadFromPreferences(completionHandler:): every time before operating on my NEPacketTunnelProvider. This was done by a helper function which was run as a precursor to any operation done to the manager, ensuring that the latest manager was being used every time. This looked something like:func myStartVPN() { 		loadHelper { (manager: NEPacketTunnelProvider, error: Error?) in /* handle errors */ startVPN(withManager: manager) } } When using this approach, I noticed that observers that look for NEVPNStatusDidChange events got triggered multiple times for these events, with the number of times it being triggered machine the number of times I called loadAllFromPreferences(). Chronologically speaking I was experiencing something along the lines of Appendix 1. As a result of this issue, my production equivalent of loadHelper(), above, only calls load once the first time a manager is requied, and then subsequent operations on the manager use a cached value - a bit like a standard lazy field. Obviously this is not a big issue as I have a working solution, however I haven't been able to work out what causes this behaviour - does anyone have any ideas? Could it be a general Swift/Objective C pitfall with KVO that I am not aware of? Could it be some sort of issue with NetworkExtension/my approach? (I'm thinking some references might not be being cleaned up every time I load?) Appendix 1 Previously set up NEPacketTunnelProvider* loadAllFromPreferences() followed by saveManager() Recieve NEVPNStatusDidChange - Disconnected loadAllFromPreferences() followed by startVPNTunnel() Recieve NEVPNStatusDidChange - Connecting x2 Recieve NEVPNStatusDidChange - Connected x2 loadAllFromPreferences() followed by stopVPNTunnel() Recieve NEVPNStatusDidChange - Disconnecting x3 Recieve NEVPNStatusDidChange - Disconnected x3 loadAllFromPreferences() followed by startVPNTunnel() Recieve NEVPNStatusDidChange - Connecting x4 Recieve NEVPNStatusDidChange - Connected x4 loadAllFromPreferences() followed by stopVPNTunnel() Recieve NEVPNStatusDidChange - Disconnecting x5 Recieve NEVPNStatusDidChange - Disconnected x5
Posted Last updated
.
Post not yet marked as solved
1 Replies
307 Views
When running scripts in the Scheme's build pre/post actions, I have been struggling to determine the difference between when the action has been run through a Build, Clean or Archive. The motivation in this case is that I have a Build Post-action that increments build numbers after building^[1]. So far the best solution I have come up with is to select the "Provide build settings from" and then specify my target. This way I can detemine some things from the environment variables in the script, for example: ACTION is empty when building/cleaning both Debug and Release builds, but set to "install" when archiving. CONFIGURATION is set to Debug/Release when building/cleaning Debug/Release builds respectively. The biggest gripe I have is that I haven't found a way to determine if a clean is being run vs a build - especially if you relate it to the motivating example that is incrementing build numbers, you don't want them to increment on a clean! Does anyone know of a way to do this? Alternatively, does anyone know if it is possible to specify Xcode configuration variables that are only set for clean vs build, much like you can restrict variables to Debug/Release or certain architectures? [1] The reason for this being a post action is my current solution in place is to leave a market file in /tmp/ in a build-phase run script, and then when the Build Post-action runs I can detect for the presence of that file to know that this was a build. This however does not solve the issue for pre-action scripts which would (in my opinion) be a more ideal place to increment the build number.
Posted Last updated
.
Post not yet marked as solved
6 Replies
1.5k Views
Hi there,Been writing a NEPacketTunnelProvider implementation, and currently trying to handle the case where a user calls the VPN directly from the system settings but there is an error in estabilishing the connection. The rationale here is to either provide a quick link back to the application for the user, or simply give them some feedback as to why a connection has failed should they choose to use the system preferences instead of the application. Looking around the documentation and developer forums have lead to different trains of thought and deprecated methods.The first and most obvious method was the use of displayMessage(_:completionHandler:). This works for a simple error messsage but is now deprecated as of iOS 12.0 and macOS 10.14. Thus, this is not ideal.Searching further, the closest post I could find was this one where the poster was recommended to make use of the UserNotifications framework. However when requesting authorization with requestAuthorization(options:completionHandler:) from the tunnel provider I am returned notificationNotAllowed- "Notifications are not allowed for this application".Is this expected behaviour? The only indication from a comment from Apple Staff user "eskimo" in the post linked above (sorry I don't know of a way to directly link to that comment) was that they were "pretty sure they work from a packet tunnel provider", so I'm not sure if this is in fact not allowed or if I am simply doing something wrong?Alternatively if a better/more conventional modern approach exists for notifying the user of an error, I'd be grateful for it to be pointed out.Thanks!
Posted Last updated
.