Our particular issue was related to having a Host Application for testing. We wanted to run unit tests on a system where, for reasons I won't go into here, we wanted to not run the application itself. We run tests by using the App scheme, which has the test targets listed under the Test option in the scheme editor. If we set Host Application to none, then Xcode will try to run the unit tests. It will build them, and it will look like it's starting them, but will lock up and require a Force Quit. The unit tests do run fine from the CLI in that case using xcodebuild. If we select the AppUnitTest scheme and run the unit tests then it works, but you can't debug them. Setting breakpoints in the tests doesn't work. Definitely an Xcode bug--Xcode should never need a Force Quit. If it's a testing scenario it can't handle, it shouldn't run it.

I'll check this, but the excluded routes are not local networks. They're routes defined by the VPN gateway admin, who doesn't necessarily know anything about the user-side physical networks. If it does work I'd be mightily surprised (and think that the documentation was even more obscure than I do now). Kevin

The definition of excludedRoutes: excludedRoutes The IPv4 network traffic that the system routes to the primary physical interface, not the TUN interface. Makes it clear that they should not be sent to the TUN interface. This is not what's happening. If we define neither includeAllNetworks nor enforceRoutes, then the excludedRoutes are properly excluded. If we define either includeAllNetworks or enforceRoutes, then the excludedRoutes are ignored, and all traffic gets tunneled. We tested every combination of the enforceRoutes, includeAllNetworks, excludeLocalNetworks, and overridePrimary options. We can provide logs showing the network settings provided to the Network Extension framework at start time, along with the protocol settings, as well as the traffic from the excluded network going to the VPN extension.

Ok, I'll open a report. When I say I checked every combination I do mean every combination, even ones that didn't make sense. I would have expected the behavior you described. This is the log from enforceRoutes YES, includeAllNetworks NO, excludedRoutes set (pruned a bit because it was pretty verbose): # Protocol properties seen by the extension: # [Jun 1, 2023 at 3:57:58 PM PDT] <Debug>: Protocol Properties: . . . includeAllNetworks = NO excludeLocalNetworks = NO excludeCellularServices = YES excludeAPNs = YES enforceRoutes = YES . . . # Network settings we're passing to setTunnelNetworkSettings:completionHandler: # [Jun 1, 2023 at 3:57:59 PM PDT] <Debug>: setting NEPacketTunnelNetworkSettings: { tunnelRemoteAddress = 10.200.1.200 DNSSettings = { protocol = cleartext server = ( 172.16.1.1, ) matchDomainsNoSearch = NO } proxySettings = { autoProxyDiscovery = NO autoProxyConfigurationEnabled = NO HTTPEnabled = NO HTTPSEnabled = NO FTPEnabled = NO SOCKSEnabled = NO RTSPEnabled = NO gopherEnabled = NO excludeSimpleHostnames = NO usePassiveFTP = YES } IPv4Settings = { configMethod = manual addresses = ( 172.16.1.1, ) subnetMasks = ( 255.255.255.255, ) includedRoutes = ( { destinationAddress = 0.0.0.0 destinationSubnetMask = 0.0.0.0 }, ) excludedRoutes = ( { destinationAddress = 10.10.0.0 destinationSubnetMask = 255.255.255.0 }, ) overridePrimary = NO } } # And here we have the message printed when we receive a SYN packet for a destination. This # should never be seen for excluded routes # [Jun 1, 2023 at 3:58:11 PM PDT] <Debug>: Trying to establish TCP tunnel to server 10.10.0.2:443...

Sometimes, but we take that into account in our code that handles the server cert validation when there's a trust question. It's one reason we have a handler for the server certs. Kevin

Looks like it might be. I'll take a look at using NSExceptionDomains to get around this when needed. The main use case is testing, not distribution--we really don't want to let people loosen up too much on production setups--so if this is the issue we should be able to build in specific exceptions for test builds. Thanks for pointing out that entry. Kevin

Yes, that was it. Setting Allow Arbitrary Loads for testing worked. Thanks. Kevin

Thanks. I'll look into that. I'll probably need to repro it with a smaller test app because of some of the data in the result bundle for our full app. Kevin

I haven't had time to get back to them with the information, and I haven't found a way around it.

You’re talking about the write system call here, yes? If so, these two statements don’t really gel. If write fails, it returns -1 and sets errno. If the file is getting filled with zeroes, the write succeeded, but it just wrote zeroes. And yet it's happening. write() returns -1 errno is set to EFAULT file size changes by the number of bytes attempted file is filled with 0s I’m not aware of sandbox or security restriction that’d cause that behaviour. It’s either a bug in the file system side of things, or your code has actually passed a buffer full of zeroes to write. The latter is by far the most likely. No, it's not--this happens with the shipping applications, and on earlier versions of the OSes the correct information is written. The only difference is the OS versions. A bug in the betas seems likely, but one question would be why more people aren't seeing it. I recommend you add some temporary logging to your… well… logging (-: that logs a subset of this data to the system log. You can then compare the system log results with the contents of the file. We've done that. When we log to both, we see that we're logging valid data. Kevin

I'll see what I can do. My suspicion right now is that it's something related to the app group, because if write() was broken in a general sense there would have been more noise on the forums about it.

This is reproducible with the shipping apps, in the App Stores. No connections needed--as soon as you open the applications there is data written to the files, and the problem can be seen. I've filed two bugs, one for iOS/iPadOS and one for macOS: iOS: FB12663311 macOS: FB12663328

This is still happening. Only on M1/M2 systems. We also see swift-frontend taking 5GB per-instance, with three of them visible in Activity Monitor. It's bad enough that the systems will sometimes become unusable--a standard build for test will take many hours, and it shows 9GB of swap being used. We can't be the only ones seeing this issue...

I’ve narrowed down the problem. This code: NSString* nstb = [NSString stringWithFormat:@"[%@] <%@>: %@\n", time, tag, info]; char* cstring = [nstb cStringUsingEncoding:NSASCIIStringEncoding]; Always returns a NULL cstring on the betas. On all previous OS versions it returns a valid cstring. The data in the NSString is all data which can be represented with the ASCII encoding, and the documentation for the function says that it will return NULL only when the data cannot be represented with the requested encoding. This is a pretty fundamental change in behavior.

We can convert to UTF8 where we first saw the problem, but we can't send that over the internet... I checked into contents, and we use NSDateFormatter's stringFromDate to generate the time, with standard setLocale, setDateStyle, and setTimeStyle. It appears that it's generating a lovely ASCII string except for the first space in " PM PDT" at the end of the date string: e280af 50 4d 20 50 44 54 e280af = sp?? 50 = P 4d = M 20 = sp 50 = P 44 = D 54 = T So that's the root here. Of course we can't use that in any Internet exchange that wants ASCII headers or payload, and an unexpected change in the behavior of NSDateFormatter isn't really cool.