My (much smaller) test TPP app was able to do the FileHandle passing, but the (much bigger) real app wasn't. So I know it's possible, but also just as clearly I'm doing something wrong. Somewhere. :)

Oh, also, I am somehow causing sysextd to die often: Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4 Terminating Process: exc handler [20261] Thread 0 Crashed:: Dispatch queue: sysextd.extension_manager 0 sysextd 0x105fb8217 0x105f5d000 + 373271 1 sysextd 0x105f94340 0x105f5d000 + 226112 2 sysextd 0x105f94036 0x105f5d000 + 225334 3 sysextd 0x105f9749e 0x105f5d000 + 238750 4 sysextd 0x105f93df7 0x105f5d000 + 224759 5 sysextd 0x105f93c01 0x105f5d000 + 224257 6 sysextd 0x105f93e78 0x105f5d000 + 224888 7 Foundation 0x7ff80c04d018 __NSXPCCONNECTION_IS_CALLING_OUT_TO_EXPORTED_OBJECT_S1__ + 10 8 Foundation 0x7ff80bff76e8 -[NSXPCConnection _decodeAndInvokeMessageWithEvent:flags:] + 2347 9 Foundation 0x7ff80bfae2ce message_handler + 206 10 libxpc.dylib 0x7ff80ae07ae0 _xpc_connection_call_event_handler + 56 11 libxpc.dylib 0x7ff80ae068c6 _xpc_connection_mach_event + 1413 12 libdispatch.dylib 0x7ff80af113b1 _dispatch_client_callout4 + 9 13 libdispatch.dylib 0x7ff80af2a041 _dispatch_mach_msg_invoke + 445 14 libdispatch.dylib 0x7ff80af171cd _dispatch_lane_serial_drain + 342 15 libdispatch.dylib 0x7ff80af2ab77 _dispatch_mach_invoke + 484 16 libdispatch.dylib 0x7ff80af171cd _dispatch_lane_serial_drain + 342 17 libdispatch.dylib 0x7ff80af17dfd _dispatch_lane_invoke + 366 18 libdispatch.dylib 0x7ff80af21eee _dispatch_workloop_worker_thread + 753 19 libsystem_pthread.dylib 0x7ff80b0c5fd0 _pthread_wqthread + 326 20 libsystem_pthread.dylib 0x7ff80b0c4f57 start_wqthread + 15

As the documentation says, property list types are all allowed by default. You do need to set it for both sides of the interface (I just found this out with FileHandle). The ObjC side of the code is NSXPCInterface *interface = [NSXPCInterface interfaceWithProtocol:@protocol(RedirectorControlProtocol)]; NSSet<Class> *baseClasses; baseClasses = [interface classesForSelector:@selector(getApplicationBypass:) argumentIndex:0 ofReply:YES]; NSSet<Class> *newClasses = [baseClasses setByAddingObject:[MyClass class]]; [interface setClasses:newClasses forSelector:@selector(getApplicationBypass:) argumentIndex:0 ofReply:YES]; [interface setClasses:newClasses forSelector:@selector(addAppBypass:) argumentIndex:0 ofReply:NO]; _connection.remoteObjectInterface = interface;

I think I tried that and it didn't work; I'd have to confirm by rebuilding it, but the documentation says that "" is valid wildcard, and it did not work.

Another fun thing: the documentation is wrong about the NWHostEndpoint and NENetworkRule: if you use a wildcard (as my code above does), it ignores the port. So my code there doesn't quite work; I ended up adding 4 separate hosts, with a corresponding rule each: let udpHost_1 = NWHostEndpoint(hostname:"0.0.0.0", port: "4500") let udpHost_2 = NWHostEndpoint(hostname:"255.0.0.0", port: "4500") let udpHost_3 = NWHostEndpoint(hostname:"0::0", port: "4500") let udpHost_4 = NWHostEndpoint(hostname:"ff::ff", port: "4500") let ipsecRule_1 = NENetworkRule(destinationNetwork: udpHost_1, prefix: 1, protocol: .UDP) let ipsecRule_2 = NENetworkRule(destinationNetwork: udpHost_2, prefix: 1, protocol: .UDP) let ipsecRule_3 = NENetworkRule(destinationNetwork: udpHost_3, prefix: 1, protocol: .UDP) let ipsecRule_4 = NENetworkRule(destinationNetwork: udpHost_4, prefix: 1, protocol: .UDP) This is really really ugly, but it does appear to cause it to use look at the port part of the host/rule.

NB I filed FB13796015 earlier about this.

So there is no way for a proxy provider to tell that a process is done receiving data? Alas.

I filed a FB a while back about getting some socket options visible (mostly for UDP, mind you). But in this case, I asked what happens if I do a flow.write(Data(count:0)) -- or, alternately, if there is a way to non-destructively determine if the write-to-app side of the flow is opened or closed.

Well, that's just another aspect of the same problem; that's why I asked if there was a way to tell if it was still valid. I could possibly try to watch for the process to exit, but that wouldn't get all of the cases although it might be better than now. Or what happens if I do a flow.write(Data(count:0)) -- would that return success/error depending on whether it was still open, or would it be treated as telling the process that there was no more data coming? Setting a timeout is of course one way to go, but it's not necessarily the valid way to go -- there are pretty good reasons to keep connections open, but idling, for hours. But TCP at least has KEEPALIVE, which lets one end know if the other has gone away for some reason.

Just using TCP, since it's the simplest and more common one for us anyway: The TPP has two things to do related to each flow: Read data from the process, and send it to the thing that does the proxying; this is done by looping with flow.read(), which indicates that the process has closed the write-to-network side by returning a Data object of size 0. Just like POSIX read! Get data from the thing that is doing the proxying, and write it to the process; this is done by calling flow.write() each time data is presented to the TPP from the proxying thingy. Each of those sides is distinct -- processes can, and often do, close the write-to-network side (aka flow.read()) before they are done with reading from the network. However, if a process does close the read-from-network side, the only way to tell this is to try to send data to it (aka flow.write()) and get an error. Now consider a case where you've got a connection to an internet server (process -> TPP -> proxying thing -> server , and server -> proxying thing -> TPP -> process). The process closes the read-from-internet side, but the server does not close its end. This means that the connection is still open, but no data ever comes. There is no information given to the TPP, in that case, that the process has closed the read-from-network side.

I filed FB13792209 about this. I don't think it uploaded my 10+gbyte attachment. Please feel free to contact me OOB to figure out how to get the file to apple. leaks can't be used to arbitrarily turn it on and off. Running the process under either Instruments or with MallocStackLogging results in it using significantly more memory, which makes this all terribly fun.

I know I filed this, but I can't find it. So I filed a new one, FB13796015

For some reason, the forums took the word sim + ple and converted it to asterisks. I think the slur-checking might be a bit overzealous. 😄

And now I've updated it with a small, do-nothing TPP app that causes FT to not work when it is running, even though the new flow methods only return false.

Ok, I updated my FB to describe what's going on, and attached a sysdiagnose taken shortly after I demonstrated it working super strangely when our TPP is installed and activate (even when it's returning false almost immediately). (Specifically: with FaceTime it just fails, sometimes in weird ways; with AirDrop, nothing happens while the TPP is installed. And when I uninstall it, then all of the queued AirDrop attempts happen at once.)