I put this into a file: #if DEBUG #warning("Building with debug") #endif It always warns when I build in Xcode -- even when I'm (allegedly) using the Release configuration. I created a new scheme called "Release", and changed the Run > Build Configuration to "Release". (And then I went and changed everything from "Debug" to "Release" in the scheme.) But I always get the warning. (In Xcode. If I use xcodebuild -configuration Release I don't get the warning.)

The code I have is if (filterManager.providerConfiguration == nil) { NEFilterProviderConfiguration *providerConfiguration = [[NEFilterProviderConfiguration alloc] init]; providerConfiguration.filterPackets = YES; providerConfiguration.filterPacketProviderBundleIdentifier = filterBundle.bundleIdentifier; filterManager.providerConfiguration = providerConfiguration; NSString *appName = [NSBundle mainBundle].infoDictionary[@"CFBundleName"]; if (appName != nil) { filterManager.localizedDescription = [NSString stringWithFormat:@"%@ (packet filter)", appName]; } } if (filterManager.enabled) { NSLog(@"Packet filter already enabled, not doing so again"); return; } filterManager.enabled = YES; It's claiming the filter is already enabled. But System Settings > Network shows it there, with a yellow dot. My best guess is that it's showing up as already enabled in the preferences, even though it... isn't? I also log a message in the filter's init, and I don't see that showing up. I've got sysdiagnose from it and a working system, and I'm going over soooooooo many log lines. I don't know what might be causing this, however.

We added a packet filter to our app, then found a way to not need it, so we want to be able to remove it on upgrades. But we don't want to install it if it's not already installed. Simple, right? The basic flow of the code is, on start-up, it does a propertiesRequestForExtensiion request. The method for the delegate goes through the various versions, ignoring any that are property.isEnabled == NO. When it comes to one that is enabled, it checks the version -- if it's the same version as the running app, it goes to deactivate it. If it's a different version, it goes to enable the current version (creating a activationRequestForExtensiion request). This should all be very simple. Except. At some point during this, the properties request gets a failure -- Domain=OSSystemExtensionErrorDomain Code=1. Ok, it seems there are lots of them laying around (I haven't rebooted in a while), and that method doesn't return once it finds one that is enabled. So maybe it doesn't like that. And then the activation request that was submitted also fails, also with the same error that doesn't explain anything. I thought, ok, maybe they don't like to stop on each other's toes, so let's create a serial dispatch queue, and have all of the system extension requests use that queue. That way, the activation request won't begin until the properties request has finished! Only I did that. And it did get a bit further -- the request method was invoked! Only then I still got messages about the properties and activation requests failing with the same unknown error. So then I looked at console. And sysextd is crashing, every time this happens. And then I dump all of the logs around that time, and look through them, and see... nothing. I had hoped to end this with a description of how I achieved victory, but instead... I'm going to have to reboot and see if that solves the mysterious crashing of sysextd.

This one is sorta behaving similar to the FaceTime / AirDrop issue, but it does depend on order, which makes me wonder if it's a programming choice. Specifically, using FortiNet's VPN client, using IPSec, if I have a TPP installed and then try to connect it, it fails. If, however, I connect and then start the TPP, it succeeds, which at least makes it better than FaceTime and AirDrop. So my question here is... hm, not as well-articulated as I would like. I'm curious if a VPN can check to see if other VPNs are installed and configured, and if so say "nope." Hm, saying that more clearly: I think it's possible for a network extension to check the interface that a packet/flow is going to, and cause a failure of some sort if it's a VPN, correct? Does anyone do that? Or am I seeing lions in the waterhole weeds? I'm also curious if Apple's networking code has issues with multiple VPNs. (Although, I will note, our TPP works just fine with Tailscale, so it's not an inherent conflict. Also Cisco AnyConnect. So maybe it's just IPSec?) ETA: to make it clear, my test case involves using a ****** TPP, where handleNewUDPFlow and handleNewFlow both immediately return false, meaning that the system should behave as if it's not there, and yet... doesn't. I appreciate any comments/assistance/guffaws.

We have found a VPN that does not work while our TPP is running, and I have a hypothesis why, and it does not make any sense. It only fails when our TPP asks for UDP flows. Their VPN claims to fail at a DNS query, but it's getting EPIPE (this is Twingate for the curious). Looking at all the logs I can on the system, including dtruss and dtrace, I see that it does a sendto, and gets that errno. I can't, of course, determine more. By adding more logging, I can see that their VPN tunnel provider tries to open up a UDP flow to 8.8.8.8 port 53. First red flag: I did not think we were supposed to get DNS queries -- my guess is that only means for apps that use the system DNS libraries, implying (to me) that this VPN has their own DNS code. We look at the app name, and decide we don't care for it -- handleNewUDPFlow(_:initialEndpoint:) returns false/NO. I see this in the system logs: 2024-06-26 11:06:56.342680+0100 0x300c839 Default 0x0 40823 0 ${us}.Redirector: (NetworkExtension) [com.apple.networkextension:] [Extension ${us}]: provider rejected new flow UDP ${them}.macos.tunnelprovider[{length = 20, bytes = 0xca1b405e014154c2e38e20159d033f9b2d3eea18}] local port 0 interface en0(bound) which is all correct. But then the very next log entry is 2024-06-26 11:06:56.342717+0100 0x300cc14 Info 0x0 0 0 kernel: (399482302): received connect result 61 which, there you go, ECONNREFUSED which will be turned into EPIPE by sendto. (ETA: No, that's not what happens at all. I see other port 53 queries in my logs, and they follow the same, er, flow -- TPP refuses them, next log entry for the flow by the system is result 61.) There is no traffic to 8.8.8.8 over any of the interfaces. I have tried using a NENetworkRule that _excludes` port 53, but it does not allow that at all. I am very deeply confused by all of this, to the point I'm not quite sure how to begin to articulate a request for help. If anyone has any thoughts, comments, questions, commiserative howls of agony, I'd appreciate it.

This is definitely a weird one -- the laptop is running macOS 12, but it's trying to build using macOS 13 SDK? (The machine cannot run anything later than macOS 12, btw.) In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:20: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk/usr/include/dispatch/dispatch.h:69:10: fatal error: 'dispatch/block.h' file not found #include <dispatch/block.h> ^~~~~~~~~~~~~~~~~~ 1 error generated. I'm trying xcode-select --install but has anyone run into this before?

* [Error] Failed to stop recording session: Failed stoping ktrace session. (xcode-select version 2409) So why can't it stop the ktrace session? And how long has that typo been around? 😄 (Look, I've kept typos in log messages for years because it differentiated that message from other messages.)

I must be missing something really obvious, and I feel particularly dumb about it: I don't see any event -- authorization or notification -- for creating or removing a directory. I also don't see one for creating a symlink (although that can be handled via unlink, one presumes). The events for create seem to be file only (and I'm also quite surprised that the file mode isn't available in the authorization event for that). So how blind am I here? I mean, I *must* have missed something, right?

Has anyone made a Swift class for IP packets? This is just me being lazy -- the goal is to be able to print them out nicely, and possibly change the values, mainly for experimentation and fun. (I mean, I can do it in C, so I can always wrap that in ObjC and bridge to Swift.)

I wrote a very dumb transparent proxy. The extension simply sends data to a daemon, and that daemon sends network data back to the proxy. It worked with small test connections, and I was fairly pleased. Then I tried transferring a ~4mbyte file (using curl), and it got a way in, and then the daemon did a network read of something like 400kbytes, and went to send that to the extension, and the flow.write method never called the completion handler. If I limit the read size to 64k max, it works. The most frustrating thing is I don't see any logging information related to it, so I can only guess what's going on. Any ideas, thoughts, or clear stupidities on my part?

In particular, network extensions, which need to be installed/activated by the containing app. I'm not particularly great at GUI stuff, so maybe there's a way one can simulate/automate that part? I'm assuming CI testing, presumably done with VMs being created on the fly to build & test. (I admit a historical failure on unit testing for my code, but most of that has historically been kernel code. I'm trying to do better!) I again apologise for my obvious ignorance at some of this.

This is for a non-GUI program -- intended to be a LaunchDaemon at some point; I followed Quinn's instructions for this. As I've commented before, I'm using cmake to generate an xcodeproj (wheeeee), so I wouldn't be surprised if it's doing something wrong. I get the error if I use open Debug/HelperDaemon.app or try to run it in Xcode. That doesn't quite surprise me a lot (again, not a GUI app), and Xcode says there may be a problem with signing. If I run it via the command line (that is, ./Debu/HelperDaemon.app/Contents/MacOS/HelperDaemon), it is immediately killed. I haven't been able to find much in the logs. What I have noted is that if I do codesign --force --deep --sign - ./Debug/HelperDaemon.app, it then does work (although then I run into other crashes). However, doing codesign -vv Debug/HelperDaemon.app, it says everything is fine. (codesign -dv --entitlements :- Debug/HelperDaemon.app shows the entitlements I expect, as well.) This is on macOS; I'm building on and for 11.6, using Xcode 13.1. For the program's entitlements, I've got com.apple.developer.system-extension.install, keychain-access-groups, and com.apple.security.application-groups (although I tried removing that one, with no difference in behaviour).

The NSWorkspace method that does this, fullPathForApplication, is deprecated. So what's the alternative? I do note that oascript can do it by id of app "App Name", so unless that's going away too, there must be some way of doing it, no?

Consider: sef% mdfind 'kMDItemDisplayName =[c] "Zoom.us"' sef% sef% mdfind 'kMDItemDisplayName =[c] "zoom.us"' sef% vs sef% mdfind 'kMDItemDisplayName == "zoom.us"' /Applications/zoom.us.app (Using '==' vs '=' doesn't seem to make a difference.)

I'm specifically thinking about a transparent proxy provider, since that's what we're using, so what happens if: Process /Applications/Foo.app/Contents/MacOS/Foo opens a connection to, say, google port 443 After getting the connection set up, it then fork&execs /bin/sh (or whatever 😄). Does a new flow get created? Or does it continue to use the existing one?