NETransparentProxyProvider breaks FaceTime

Question

Created Feb ’21

Replies 5

Boosts 0

Views 1.2k

Participants 3

Each time when AppProxy extension is running, FaceTime fails to make a call using iPhone connected with Mac Book. It displays the following error:
Your iPhone and Mac must be on the same Wi-Fi network.

The console log contains a message that is likely related to the problem:

Code Block error     14:33:53.710813+0300 identityservicesd - [IDSUDPLink _sendBytesArray:lengthArray:arraySize:localInterfaceIndex:localAddress:destinationAddress:trafficClass:DSCP:]:472 sendmsg(53B) failed errno=22
default  14:33:53.710865+0300 identityservicesd send binding response failed with UnknownError

The problem happens if AppProxy just bypasses all TCP and UDP flows by returning FALSE from the callback. So the flows should be handled by the system.

Answered by DTS Engineer in 877064022

Someone pinged me about this via a different channel so I thought I’d post an update here.

I confirm that we use NETransparentProxyProvider and return FALSE from the callback.

Right. This a key test. A transparent proxy should be… well… transparent when you always return false from your handle-new-flow method. If you’re having compatibility problems with your transparent proxy, this is a great diagnostic test: Tweak your code to always return false and see if the problem persists. If so, it’s not your proxy’s fault, pretty much by definition.

Anyway, I just took a look at FB9002173 and it didn’t result in a fix. However, a different developer filed their bug about this, FB13053446, and it’s carrying the torch forward.

Having said that, I’ve no meaningful information to share about FB13053446. It’s still subject to investigation.

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

Boost

Answer 1

Systems Engineer OP

Apple

Feb ’21

The problem happens if AppProxy just bypasses all TCP and UDP flows by returning FALSE from the callback. So the flows should be handled by the system.

The flows will only be handled by the system if you are using NETransparentProxyProvider. If you are using NEAppProxyProvider and you return false then the flows (TCP and UDP) will be discarded if you return false.

If this is not what you meant and you are actually using NETransparentProxyProvider then I would open a bug report against this and respond back with your Feedback ID.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0

Answer 2

SerusMac OP

Feb ’21

I confirm that we use NETransparentProxyProvider and return FALSE from the callback. So, this should not affect the FaceTime in any way.
I have submitted bug FB9002173.
Thanks!

0

Answer 3

Systems Engineer OP

Apple

Feb ’21

Thank you for submitting a bug report. I see it internally, but would like to ask that your reproduce the issue and then trigger a sysdiagnose and attach it to your bug. Please note the date and timestamp the issue was reproduced on your bug report.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0

Answer 4

SerusMac OP

Feb ’21

We have attached the sysdiagnose report to FB9002173 as requested.
(Apparently Feedback Assistant had some problems but I hope that the file was uploaded correctly).

0

Answer 5

DTS Engineer OP

Apple

Feb ’26

Recommended

Someone pinged me about this via a different channel so I thought I’d post an update here.

I confirm that we use NETransparentProxyProvider and return FALSE from the callback.

Right. This a key test. A transparent proxy should be… well… transparent when you always return false from your handle-new-flow method. If you’re having compatibility problems with your transparent proxy, this is a great diagnostic test: Tweak your code to always return false and see if the problem persists. If so, it’s not your proxy’s fault, pretty much by definition.

Anyway, I just took a look at FB9002173 and it didn’t result in a fix. However, a different developer filed their bug about this, FB13053446, and it’s carrying the torch forward.

Having said that, I’ve no meaningful information to share about FB13053446. It’s still subject to investigation.

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

0