Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
I know I filed this, but I can't find it. So I filed a new one, FB13796015
Post not yet marked as solved
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.
Post not yet marked as solved
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.)
Post not yet marked as solved
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.
Post not yet marked as solved
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! 😄
Post not yet marked as solved
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 ;)
Post not yet marked as solved
I filed FB13732021, which has a sysdiagnose from the source machine.
Post not yet marked as solved
I just set up a brand new VM, with only my brand new Irish Apple ID account. Before installing our stuff, I could turn a Messages chat into an audio call, and it worked.
After installing our stuff, I couldn't. It will fail, but it is doing something, because my phone and/or mac get notified of an incoming FaceTime call.
I disabled our stuff -- again, so the handleNewUDPFlow and handleNewFlow methods return false almost immediately -- and then there is no change in behaviour.
I added identityservicesd and avconferenced to the list of processes that are always ignore (that is, those methods return false almost immediately) with no change in behaviour as far as I can tell.
The signing identifiers I see in the "disabled" state are for com.apple.Safari.SafeBrowsing, com.apple.avconferenced, and com.apple.identityservicesd (I log the signing identifiers more than trying to get pathnames for everything).
I'm not sure what to look for in the system logs, and I don't think tcpdump would do me much good here since I assume everything is encrypted. 😄
Post not yet marked as solved
Correct. (Although I may be running into other issues involving multiple Apple IDs per device. We seem to have lost the test phone. sigh)
We check the process' name in the extension to see if we should just ignore it (that is, return false from the method), and I've bypassed identityservicesd and a few others, but it's not clear to me what processes are actually trying. And we don't get informed of inbound connections, of course.
Ok that is much nicer indeed.
Yeah I just found that, and confirmed it worked. :blush:
None of the examples I'd, ahem, borrowed from seem to have had the call, so I assumed it was all handled via ARC.
