FaceTime not working with transparent proxy tunnel installed

Even when it is disabled (that is, our app says "don't do anything" and all it does is start logging things).

I’d like to clarify what you mean by this. If you configure your transparent proxy such that it returns false to all handleNewFlow(…) calls, do you see this failure?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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.

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

A transparent proxy that returns false to all handleNewFlow(…) calls should be an (expensive) no-op. If you enable one and Apple system components fail, I recommend that you file a bug about that.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

I’m not sure a TSI will help here. Those focus on code-level workarounds, and what sort of code-level workaround would you expect for a problem like this?

The obvious workaround is to return false from the handleNewFlow(…) calls generated by FaceTime, but you’re already returning false for all calls and things still fail. I can’t imagine any other ways you might work around this.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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.

It also turns out AirDrop doesn't work

I’ve seen that reported by numerous other NE developers )-: Annoyingly, I don’t have a bug number handy )-:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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.