Thanks Matt for the confirmation. Tested with the latest Monterey Beta 12.1 and still see the two issues. Memory leak when doing only piping through. The leak can be >100MB for over night by only piping through udp traffic. This is resolvable by killing the system extension process. 1pkill -9 $(pgrep com.familyzone.macappproxy.fzmacappproxy) Network stack crash after 2~3 hours with below error problem from kernel. 1[C24189 IPv4#334f7330:53 failed socket-flow (satisfied (Path is satisfied), interface: en0, ipv4, dns)] event: flow:failed_connect @0.079s, error Can't assign requested address 2nslookup: isc_socket_bind: address not available This is not recoverable even by uninstalling the system extension. Can you help double confirm you got both reproduced with the code I shared? We have at the moment some customers asking whether they could use Monterey with our software as there are some releases already available. But based on current test result, it is still not safe to use. Thanks in advance for any suggestion. Regards Richard

Yes, it is under terminal command with sudo. The process definitely is running as the filtering is functional and the logs are there. Installed with the sameUnder my Intel and M1 macbookpro: The case of Intel macbookpro BigSur 11.6.1: sudo ps -A|grep macappproxy 23656 ??     0:00.17 /Applications/macappproxy.app/Contents/MacOS/macappproxy 23708 ??     0:01.55 /Library/SystemExtensions/6E63B2AD-405A-424B-BF1C-792A81F25B98/com.familyzone.macappproxy.fzmacappproxy.systemextension/Contents/MacOS/com.familyzone.macappproxy.fzmacappproxy 23795 ttys002  0:00.01 grep macappproxy The case if M1 macbookpro BigSur 11.6.1: sudo ps -A|grep macappproxy 91611 ??     0:00.17 /Applications/macappproxy.app/Contents/MacOS/macappproxy 97980 ttys002  0:00.01 grep macappproxy We can see that under M1, the system extension process is not listed.

Tested with the latest Monterey beta 12.2, same issue is still there: after a couple of hours dns request piping through appproxy, no more network anymore. nslookup: isc_socket_bind: address not available ... [C278 IPv4#4aea03a5:53 failed channel-flow (satisfied (Path is satisfied), interface: en0, ipv4, dns)] event: flow:failed_connect @0.004s, error Can't assign requested address

Hi there, As confirmed with the latest Monterey Beta 12.2 with build number 21D5025f, this issue remains the same. And I believe I have provided the sysdiagnose as well as the minimum project to reproduce the issue (network crash + memory leak with dns request loop). Now that it becomes critical for us since more and more customers are asking when can they use our product based on Monterey. We do need your assistance to speed up the investigation and a clear roadmap for a solution. Thanks in advance for any suggestion. Richard

Thanks a lot for this suggestion: by using netstat -vnp udp | wc -l, it is obvious the difference between BigSur and Monterey. On Monterey, the return value keeps increasing when doing dns request loop from < 100 all the way to thousands; while on BigSur, it is steady at around 46~48! That was tested with the same set of code (same installer of our software) Obviously, there should be something wrong in terms of udp socket close missing with Monterey.

This could be done with a copier state update handler that is propagating state for both sides of the connection (local flow and remote side of connection). Currently it is done like that: any EOF read back, will close both sides flow and connection (session). Does it matter to simplify like that? For your update handler to propagate state, do you have any example code for a reference? Thanks in advance for any suggestion.

Thanks Matt for the reply. Are you noticing any failures for your Network System Extensions when you see these logs? These logs happens periodically within one minute interval. But it seems Network System Extensions are all healthy. Are you seeing these logs for specific flows that your provider is handling? For example system flows? This is a good point. There are some system flows from our system service. Need to verify is it the same without that. Thanks for the suggestion.

However, there do have some older devices, say 2015 macbook proc, even 2019 one has some problem of network drop after running for some time, say, in a couple of hours. Sorry. Correct statement here: However, there do have some older devices, say 2013 macbook proc, even 2015 one has some problem of network drop after running for some time, say, in a couple of hours.

Have seen something similar from this forum: https://developer.apple.com/forums/thread/672456

And I can see something similar as: System Policy: Google Chrome He(618) deny(1) system-privilege 10006 Attach the details as well. deny_chrome.txt Is that something in common?

Just upgraded to the latest Beta 12.2 beta 2. From a brief test so far, netstat -vpn udp |wc -l returns back constant value which was never before on Monterey! Will let it go for overnight running this dns request... The Build number of Monterey is: 21D5039d netstat.txt

After overnight, netstat -vpn udp |wc -l is 55 which is good: socket leak seems fixed. Concerning app proxy memory leak, seems also fixed: after overnight dns pooling test, it is 11MB, same as its start value.I will go on with dns proxy test for the same.

That is good point. Will check that in this regard. Also, something interesting to mention: that error is not seen from M1 running the same set of code.

As tried, works pretty well. Thanks a lot Matt for the confirmation!

As found that on ios if leave it long enough, that dns proxy extension process will get re-spawn again after crash. That is good to see.