I'd like to be able to do the equivalent of getrusage(3) for some of our other processes. These are daemons, so they're not connected in any way. Obviously, Activity Monitor and top can do the things I want, but I'm not Apple. 😄 I went down a maze of twisty APIs, all a-Mach, and have decided to ask. (We're trying to keep track of the processes in the field. We also want to know what's going on if a process has stopped responding but hasn't died. I suppose I could, absolute worst case, periodically send getrusage(3) info to the monitoring process.)

I create a DispatchIO object (in Swift) from a socketpair, set the low/high water marks to 1, and then call read on it. Elsewhere (multi-threaded, of course), I get data from somewhere, and write to the other side of it. Then when my data is done, I call dio?.close() The cleanup handler never gets called. What am I missing? (ETA: Ok, I can get it to work by calling dio?.close(flags: .stop) so that may be what I was missing.) (Also, I really wish it would get all the data available at once for the read, rather than 1 at a time.)

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?

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.0.sdk/usr/include/c++/v1/__format/formatter_floating_point.h:66:30: error: 'to_chars' is unavailable: introduced in macOS 13.3 66 | to_chars_result __r = std::to_chars(__first, __last, __value, __fmt); Which, ok, I can accept that this is true. Except that this worked on Friday, on the same machine running Sonoma and the previous version of Xcode. The project is configured for a deployment target of 12.0, so it should have failed before, but didn't. (This is a CMake-generated xcodeproj, but that also should not have been any change.)

The archive build part works, and uses the correct entitlements file: [Key] com.apple.developer.networking.networkextension [Value] [Array] [String] app-proxy-provider-systemextension That's from codesign -dv --entitlements - ...../NetworkExtensionExperiment.app However, the distribution log shows "Error Domain=DVTPortalProfileErrorDomain Code=4 \"Cannot create a Developer ID provisioning profile for \"com.kithrup.NetworkExtensionExperiment\".\" UserInfo={NSLocalizedDescription=Cannot create a Developer ID provisioning profile for \"com.kithrup.NetworkExtensionExperiment\"., IDEDistributionIssueSeverity=3, NSLocalizedRecoverySuggestion=The Network Extensions capability is not available for Developer ID provisioning profiles. Disable this feature and try again., NSUnderlyingError=0x600013e719b0 {Error Domain=DVTPortalProfileTypeErrorDomain Code=0 \"Cannot create a Developer ID provisioning profile.\" UserInfo={UnsupportedFeatureNames=(\n \"Network Extensions\"\n), NSLocalizedDescription=Cannot create a Developer ID provisioning profile., NSLocalizedRecoverySuggestion=The Network Extensions capability is not available for Developer ID provisioning profiles. Disable this feature and try again.}}}", "Error Domain=IDEProfileLocatorErrorDomain Code=1 \"No profiles for 'com.kithrup.NetworkExtensionExperiment' were found\" UserInfo={IDEDistributionIssueSeverity=3, NSLocalizedDescription=No profiles for 'com.kithrup.NetworkExtensionExperiment' were found, NSLocalizedRecoverySuggestion=Xcode couldn't find any Developer ID provisioning profiles matching 'com.kithrup.NetworkExtensionExperiment'.}" which, given that I was able to build a signed version with the entitlement as shown first, seems to be a problem. All my years of hating xcode are coming back to haunt me, I can tell.

First, for the  employees reading, I filed FB14844573 over the weekend, because this is a reproducible panic or hang. whee I ran our stress tests for an entire long weekend, and my machine panicked, due to mbufs. Normally, I tell my coworkers that we can't really do anything to cause a panic -- but we're doing network things, so this is an exception. I started periodically testing the mbufs while the tests were running -- netstat -m | grep 'mbufs in use' -- and noticed that in fact they were going up, and never decreasing. Even if I killed our code and uninstalled the extensions. (They're increasing at about ~4mbufs/sec.) Today I confirmed that this only happens if we include UDP packets: let udpRule = NENetworkRule(destinationNetwork: host, prefix: 0, protocol: .UDP) let tcpRule = NENetworkRule(destinationNetwork: host, prefix: 0, protocol: .TCP) ... settings.includedNetworkRules = [udpRule, tcpRule] If I comment out that udpRule, part, mbufs don't leak. Our handleNewUDPFlow(:, initialRemoteEndpoint:) method checks to see if the application is a friendly one, and if so it returns false. If it isn't friendly, we want to block QUIC packets: if let host = endpoint as? NWHostEndpoint { if host.port == "80" || host.port == "443" { // We need to open it and then close it flow.open(withLocalEndpoint: nil) { error in Self.workQueue.asyncAfter(deadline: .now() + 0.01) { let err = error ?? POSIXError(POSIXErrorCode.ECONNABORTED) flow.closeReadWithError(err) flow.closeWriteWithError(err) } } return true } } return false Has anyone else run into this? I can't see that it's my problem at that point, since the only thing we do with UDP flows is to either say "we don't want it, you handle it" or "ok sure, we'll take it but then let's close it immediately".

Using our transparent proxy provider, I noticed that the mbuf usage was... weird: 15839/750028 mbufs in use: 15810 mbufs allocated to data 29 mbufs allocated to packet headers 734189 mbufs allocated to caches The amount allocated to caches does go down a bit, but nothing significantly. I started looking into this because I've had a couple of panics from remoted not checking in enough, and it was (as I recall, I can't find the crash logs now) mbuf-related. I've looked through an older version of the xnu source, and nothing jumped out, but that doesn't have the code for the network extension support. I hate mbufs and always have.

BUG IN CLIENT OF LIBDISPATCH: Unexpected EV_VANISHED (do not destroy random mach ports or file descriptors) Which, ok, clear: somehow a file descriptor is being closed before DispatchIO.close() is called, yes? Only I can't figure out where it is being closed. I am currently using change_fdguard_np() to prevent closes anywhere else, and every single place where I call Darwin.close() is preceded by another call to change_fdguard_npand thenDispatchIO.close()`. eg self.unguardSocket() self.readDispatcher?.close() Darwin.close(self.socket) self.socket = -1 self.completion(self)

I have this in my start code: for p in [4500] + Array(3478...3497) + Array(16384...16387) + Array(16393...16402) { // According to the documentation, I *should* be able to // use "" for the hostname, and prefix:0, but it complained // about the prefix length, so we use the top bit for ipv4 // and ipv6. let port = "\(p)" os_log(.debug, log: Self.log, "Setting up to exclude port %{public}s", port) let host_1 = NWHostEndpoint(hostname:"0.0.0.0", port: port) let host_2 = NWHostEndpoint(hostname:"255.0.0.0", port: port) let host_3 = NWHostEndpoint(hostname:"0::0", port: port) let host_4 = NWHostEndpoint(hostname:"ffff::0", port: port) for host in [host_1, host_3] { let udpPortRule = NENetworkRule(destinationNetwork: host, prefix:1, protocol: .UDP) excludeRules.append(udpPortRule) } } settings.excludedNetworkRules = excludeRules This produces the log message 2024-07-23 11:16:38.335649+0100 0x901984 Debug 0x0 20686 0 com.kithrup.SimpleTPP.Provider: [com.kithrup:Provider] Setting up to exclude port 3483 Later on, when running, I log the new flows in handleNewUDPFlow(:,initialRemoteEndpoint:), and it produces 2024-07-23 11:17:05.712055+0100 0x901984 Debug 0x0 20686 0 com.kithrup.SimpleTPP.Provider: [com.kithrup:Provider] handleNewUDPFlow(_:initialRemoteEndpoint:): new UDP flow for host 17.252.13.7:3483 app com.apple.identityservicesd So port 3483 is definitely in the excludedRules array, but it's not being excluded. (All of this is because I still can't figure out why FaceTime isn't working with us.)

That's probably a bad title, let's try with specifics: we have a network extension, it has some classes / functions of its own, and they, when push comes to build, depend on (for example) NEAppProxyFlow and its subclasses. The code is written in Swift, since it is the language of the future. If I want to do a unit test for my code, I need to provide something that at least looks like NEAppProxyFlow, since I can't otherwise create one. I thought I could provide my own NetworkExtension module for test case, but that... did not work well, and I still don't understand why. On the other hand, I'm really bad at making unit tests, so the odds that I'm missing something fairly obvious to most other people are pretty high.

That's pretty much it -- I can increase memory, file descriptor, etc., but can I increase the number of threads? (I've got a case where, in an error condition, my threads block [still trying to figure out why] and new ones are still being generated, until I hit a limit of 512 threads.)

I have var idleScanTimer = DispatchSource.makeTimerSource() as a class ivar. When the object is started, I have self.idleScanTimer.schedule(deadline: .now(), repeating: Double(5.0*60)) (and it sets an event handler, that checks some times.) When the object is stopped, it calls self.idleScanTimer.cancel(). At some point, the object containing it is deallocated, and ... sometimes, I think, not always, it crashes: Crashed Thread: 61 Dispatch queue: NEFlow queue [...] Application Specific Information: BUG IN CLIENT OF LIBDISPATCH: Release of an inactive object [...] Thread 61 Crashed:: Dispatch queue: NEFlow queue 0 libdispatch.dylib 0x7ff81c1232cd _dispatch_queue_xref_dispose.cold.2 + 24 1 libdispatch.dylib 0x7ff81c0f84f6 _dispatch_queue_xref_dispose + 55 2 libdispatch.dylib 0x7ff81c0f2dec -[OS_dispatch_source _xref_dispose] + 17 3 com.kithrup.simpleprovider 0x101df5fa7 MyClass.deinit + 87 4 com.kithrup.simpleprovider 0x101dfbdbb MyClass.__deallocating_deinit + 11 5 libswiftCore.dylib 0x7ff829a63460 _swift_release_dealloc + 16 6 com.kithrup.simpleprovider 0x101e122f4 0x101de7000 + 176884 7 libswiftCore.dylib 0x7ff829a63460 _swift_release_dealloc + 16 8 libsystem_blocks.dylib 0x7ff81bfdc654 _Block_release + 130 9 libsystem_blocks.dylib 0x7ff81bfdc654 _Block_release + 130 10 libdispatch.dylib 0x7ff81c0f3317 _dispatch_client_callout + 8 11 libdispatch.dylib 0x7ff81c0f9317 _dispatch_lane_serial_drain + 672 12 libdispatch.dylib 0x7ff81c0f9dfd _dispatch_lane_invoke + 366 13 libdispatch.dylib 0x7ff81c103eee _dispatch_workloop_worker_thread + 753 14 libsystem_pthread.dylib 0x7ff81c2a7fd0 _pthread_wqthread + 326 15 libsystem_pthread.dylib 0x7ff81c2a6f57 start_wqthread + 15 I tried changing it to an optional and having the deinit call .cancel() and set it to nil, but it still crashes. I can't figure out how to get it deallocated in a small, standalone test program.

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.

I was trying to check the documentation for handleNewUDPFlow over at https://developer.apple.com/documentation/networkextension/neappproxyprovider/3192017-handlenewudpflow and... it says it's deprecated on everything. Retroactively.

This doesn't particularly surprise me, but I am curious about it, and whether we can change it: our TPP won't start if the only IP address available is in 169.254.0.0/16. I can see (from our logs) that the preferences are loaded & saved, and the extension is loaded, but until it gets a real address, the startProxy method is not invoked.