I filed FB13732021, which has a sysdiagnose from the source machine.

I may have to file a tech support incident about this, but to do that I'll probably need to figure out how to let someone else run the suite ;)

We discussed this at an on-site yesterday, and it used to work -- it broke around the time we started looking at UDP flows as well. And it certainly works better if I remove that (which is to say, looking at TCP flows only, when it is all disabled [that is, returning false] from handleNewFlow in all cases, it works properly. Now, when we're disabled, we were still returning false in all cases, or should have been, so that's what I'll be looking at). oh yeah since I have to remember to say it periodically: hi Quinn! 😄

It also turns out AirDrop doesn't work (more importantly for us, it has never worked, but also does not work when we're self-disabled). The reason for a TSI would be on the presumption that I'm doing something wrong, but I'd also need to figure out how to make a test account or version that could demonstrate it without all the hoops a customer has to jump through.

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.)

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.

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. 😄

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

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.

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.

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.

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.

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

NB I filed FB13796015 earlier about this.

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.