Would ThreadSafeBoolQueue cause crash or deadlock when it's used on the main queue and the system is busy that could not spawn a new thread?

One other thing I am not sure if it's related, I tested on my 2019 intel mac, same code works 100% (tested over 200 times), however, on my 2021 m1 max mac, this issue is reproducible every 5 ~ 6 times. Both macs are on macOS Monterey.

I have no idea. It's very random, 80% of time I can use the same code to start it with no issue, however, if I enabled and disable a few times, there will be one time that I cannot start it. Since there is no error but just silent fail, what's the best way to debug it?

Thanks for your detailed explanations as always! Eskimo.

This is an error message from the system when calling [OSSystemExtensionRequest activationRequestForExtension: queue:]: Error Domain=OSSystemExtensionErrorDomain Code=4 "Extension not found in App bundle: perhaps App is not validly structured" UserInfo={NSLocalizedDescription=Extension not found in App bundle: perhaps App is not validly structured} I am also facing the same error, any help is appreciated. I also have the similar ID.

Thanks, I was worried about cancelling the original session(_session in the above example) would cause the new session object to be cancelled too since it created on top of the original one.

We are trying to build an always-on VPN, and user can disable this always-on feature in the App UI. However, we found many users prefer to use Settings to enable and disable VPN. But not many of them understand how to disable always-on when they need to do it even if we have described it in the container app. They still complain when they disable VPN from Settings, the VPN turns itself back on again and again which makes their phone unusable in many slow networks. And we have talked to some of our users, they have an opinion like this: When I turn on VPN, I want it to stay on even if the device reboots(automatic system updates, etc) and when I turn if off, it should stay off and not turns itself back on.

I am trying to disable on-demand feature when VPN stops for a specific NEProviderStopReason and yes, I am trying to do it in the packet tunnel provider. In particular, I am trying to achieve when -stopTunnelWithReason: completionHandler: is called because this is the only method that is guaranteed to be called when the VPN stops on iOS.

Yes, it will take affect. But there is no guarantee that the container app will be alive when the user turns off the VPN from the Settings app, do you happen to know any way to achieve this effect?

It seems that TCP works just fine. We switched to not block on UDP writing which seems to solved the issue.

One thing that is worth mentioning, we do wait for the network settings to be updated before we create a new session: (NSError *)updateTunnelNetworkSettings:(NEPacketTunnelNetworkSettings *)settings { dispatch_semaphore_t semaphore = dispatch_semaphore_create(0); __block NSError *updateError; WEAKIFY(self); [self setTunnelNetworkSettings:settings completionHandler:^(NSError *_Nullable error) { STRONGIFY_OR_RETURN(self); if (error) { updateError = error; } dispatch_async(self->_tunnelProviderQueue, ^{ if (self->_startCompletionHandler) { self->_startCompletionHandler(nil); } self->_startCompletionHandler = nil; }); dispatch_semaphore_signal(semaphore); }]; dispatch_time_t timeout = dispatch_time(DISPATCH_TIME_NOW, kUpdateNetworkSettingsTimeout * NSEC_PER_SEC); if (dispatch_semaphore_wait(semaphore, timeout) != 0) { updateError = TIMEOUT_ERROR; } return updateError; }

Do you suggest that we should create the session first then update the network settings? Is there any reason you need to do this? Because each time we get a different network setting from the server when we try to reconnect.