Those device are running our app released a couple of years ago. If I try fresh install this old version app on a device, it will just fail with the prompt saying this app cannot be installed because its integrity could not be verified. So it should be the provisioning profile built into that app binary expire already.
Thanks
Richard
Post
Replies
Boosts
Views
Activity
TSI submitted: Follow-up: 794081746
Thanks Matt for the reply.
Is there anything out of the ordinary going on in your provider that the system may be trying to clean up before respawning the System Extension? For example, if you take a blank NEDNSProxyProvider and start it on a fresh test machine, does it take the same amount of time to respawn as your application?
Minimised my project with NEDNSProxyProvider only and inside handleUDPFlow, doing nothing but return true directly like blew, same behaviour reproduced.
Interesting thing is that when it happens, the respawn time is constant at around one minute five seconds (after sys ext process got killed). But if you rest it for a while before the next process kill, it might return back to normal again until you keep trying for multiple times (< 10 times normally).
import NetworkExtension
class DNSProxyProvider: NEDNSProxyProvider {
override func startProxy(options:[String: Any]? = nil, completionHandler: @escaping (Error?) -> Void) {
completionHandler(nil)
}
override func stopProxy(with reason: NEProviderStopReason, completionHandler: @escaping () -> Void) {
completionHandler()
}
override func sleep(completionHandler: @escaping () -> Void) {
completionHandler()
}
override func wake() {
}
// MARK: Flow Handling & filtering
override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool {
if flow is NEAppProxyTCPFlow {
return false
} else if let udpFlow = flow as? NEAppProxyUDPFlow {
return self.handleUDPFlow(udpFlow)
}
return false
}
@available(macOS 10.15, *)
private func handleUDPFlow(_ flow: NEAppProxyUDPFlow) -> Bool {
return true
}
}
Also, does this same thing reproduce on multiple machines?
Tried on a fresh installed Big Sur 11.6.2, same thing reproduced.
Thanks Matt for the suggestion.
Submitted TSI 9915482 and uploaded system diagnosis via Feedback Assistant.
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.
As tried, works pretty well.
Thanks a lot Matt for the confirmation!
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.
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.
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
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?
Have seen something similar from this forum:
https://developer.apple.com/forums/thread/672456
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.
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.
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 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.