NEAppProxyTCPFlow keep-alive

correction: safari works fine, connection doesn't interrupt. Chrome still forcibly closes a connection after 45 sec and Firefox after 11 min 22 sec with error net::ERRTIMEDOUT

Make sure the proxying side of the NEAppProxyTCPFlow contains the property for NWProtocolTCP.Options() - enableKeepalive and try taking a packet trace to see which side is hanging up. This should allow you to determine if a browser is causing this issue or the remote the browser is connecting to causing the issue.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Thank you for the answer, meaton! I've already enabled enableKeepalive in NWProtocolTCP.Options() along with noDelay, but it isn't an issue because the termination of the connection is caused by the source app's side. I've been experimenting for a few weeks with different approaches and analyzing network communication via WireShark. And my conclusion is: the bug is in the NEAppProxyTCPFlow because the source app behaves like it doesn't receive keep-alive approvement from the NEAppProxyTCPFlow even though it receives data. I tried to just call NEAppProxyFlow.open() and NOT writing any data to it - the result is the same, browser waits for 45 second and forcibly closes the connection with net::ERRTIMEDOUT, the same behavior as when I transmit data to the source app via NEAppProxyFlow.write(). This issue relates to all Chromium browser. As I said, Safari works fine, but I assume the reason of it is because Safari uses different approach of keeping sockets alive.

Should I submit a bug report?

Thanks for the extra details. I think you should submit a bug report ONLY if NEAppProxyTCPFlow is the factor that provides differentiating results in the connection flow process. For example, if you take the App Proxy Provider out of the equation and test this with the browser do you see the same results? If you do see the same results then you should take this up with the team that manages the Chromium browser. If you do not see the same results and the addition of NEAppProxyTCPFlow looks to be causing the issue then this is bug-worthy. Make sure that if you open a bug that you include your packet traces that you have taken along with any logs.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Thank you, meaton

 if you take the App Proxy Provider out of the equation and test this with the browser do you see the same results?

With NEAppProxyProvider disabled browser works as it should work - without any connection interruption. That's one of the reasons why I considered the NEAppProxyTCPFlow to be the cause of the issue.

Make sure that if you open a bug that you include your packet traces that you have taken along with any logs.

Ok, I'll try to assemble as much details about the issue as I can. Alas, I cannot capture packets between source app and NEAppProxyTCPFlow via WireShark to see the difference in packets between enabled NEAppProxyProvider and disabled, only packets from NWConnection from proxying side are shown to me. I guess only developers of the NEAppProxyProvider can get to the bottom of the problem :)

And one more question. Should I attach a link to this thread to the bug report?

With NEAppProxyProvider disabled browser works as it should work - without any connection interruption.

Okay, then I would open a bug report with your findings and please add as much information as you have available. Feel free to add a link to this thread in your bug report.

Please follow up with the Feedback ID so I can copy myself on it for future updates.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Thanks for approval, meaton. I have submitted a bug report. Its ID is FB7868606

Thank you, I see your bug report internally and requested to be notified upon any future updates. I will keep this thread updated when there is more information to share.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Hi! Ay updates on the subject?

Today I updated to macOS 11 Big Sur Beta and tried to reproduce the issue. I could NOT reproduce the issue. Does that mean that apple has already fixed the issue for Big Sur or NetworkExtension in Big Sur did not suffer from that problem from the very beginning!? The last version of macOS where the issue repoduces is 10.15.6

Glad to hear you are seeing resolution to your issue on Big Sur. Please update you bug report with this information. I am not aware of any changes that were made for this API in either version so it's hard to say one way or another.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Updated and closed the bug report. Best regards to the development team!!! :) I guess the issue will not be resolved for Catalina, will it?