Hi there, We have a batch of customer ipad running our software older version with dnsproxy. They have not been running for a while. Then it is found that these devices cannnot load dnsproxy network extension and no network access anymore. Below is the ipad console. iPad neagent(NetworkExtension)[220] <Error>: Failed to start extension com.***.ios-dns.ext: Error Domain=PlugInKit Code=4 "RBSLaunchRequest error trying to launch plugin com.***.ios-dns.ext(***): Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x14de85170 {Error Domain=NSPOSIXErrorDomain Code=85 "Bad executable (or shared library)" UserInfo={NSLocalizedDescription=Launchd job spawn failed with error: 85}}}" UserInfo={NSLocalizedDescription=RBSLaunchRequest error trying to launch plugin com.***.ios-dns.ext(***): Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x14de85170 {Error Domain=NSPOSIXErrorDomain Code=85 "Bad executable (or shared library)" UserInfo={NSLocalizedDescription=Launchd job spawn failed with error: 85}}}} I guess it is because the dnsproxy provisioning profile there expires already? In this case is there any way to retain the network access remotely? There are hundreds of them. Cannot imagine need to remove the app one by one manually. Furthermore, is there any way to avoid such a situation: devices wakeup after not in use for some time, provisioning profile expires, not able to load dnsproxy network extension and no network anymore. Thanks in advance for any suggestion, Richard

Hi there, This is realized during the test on Monterey 12.2. Normally when we kill the dns proxy sys ext process, it will respawn very quickly within a couple of seconds. But after multiple times of trials, it can take more than one minute to respawn. Worst case even encountered was that it never gets respawn anymore. By comparison, the app proxy doesn't have the same problem: always gets respawn instantly. Not sure whether it is a bug or not. Thanks in advance for the suggestions. Regards Richard

Hi there, This was realised during the test. That is: When we use appproxy to filter all udp traffics with netbiosd running, and observe netbiosd cpu usage with Activity Monitor. Then if we just restart the appproxy (just kill the sys extension process is fine). After system extension process is re-spawn, you will find that netbiosd cpu usage boosts to above 100%. Tried as well to put netbiosd related udp port (137, 138 and 139) as excludedNetworkRules, but doesn't help. How to reproduce: Start netbios service by isudo launchctl load -w /System/Library/LaunchDaemons/com.apple.netbiosd.plist Start appproxy application (with wrapper process and system extension process). Setup in includedNetworkRules filtering all udp outbound traffics. Just kill appproxy system extension process so that the wrapper process will spawn a new system extension process. Observe from Activity Monitor cpu usage of netbiosd, you will find that it is above 100% then. It makes no difference even if you put in excludedNetworkRules all netbiosd related ports including 137, 138 and 139 (tcp and udp). Thanks in advance for any suggestion. Regards Richard

Hi there, This is the case of using dns proxy provider on ios. One thing noticed is that when the system extension process of dns proxy crashes, it is not re-spawn automatically by the wrapper process as it is when using the same dns proxy provider under macOS. The test I carried out was: Under macOS Launch an application with dns proxy provider sys extension. Kill that sys extension process. After several seconds, another sys extension process of dns proxy extension will be re-spawn. sudo ps -A|grep macappproxy Password: 47796 ??     0:00.35 /Applications/macappproxy.app/Contents/MacOS/macappproxy 47875 ??     0:00.62 /Library/SystemExtensions/439F12A7-1304-4A92-BEED-3EBEC979ADBE/com.familyzone.macappproxy.fzmacdnsproxy.systemextension/Contents/MacOS/com.familyzone.macappproxy.fzmacdnsproxy 47929 ttys001  0:00.00 grep macappproxy AU-L-0306:fc-ios-edu-client richardwang$ sudo pkill -9 com.familyzone.macappproxy.fzmacdnsproxy AU-L-0306:fc-ios-edu-client richardwang$ sudo ps -A|grep macappproxy 47796 ??     0:00.35 /Applications/macappproxy.app/Contents/MacOS/macappproxy 48433 ??     0:00.31 /Library/SystemExtensions/439F12A7-1304-4A92-BEED-3EBEC979ADBE/com.familyzone.macappproxy.fzmacdnsproxy.systemextension/Contents/MacOS/com.familyzone.macappproxy.fzmacdnsproxy 48531 ttys001  0:00.00 grep macappproxy We can see from above that dns proxy pid changed after it was killed and re-spawn. Under ios Doing the same thing, but slightly different: By adding below code into startProxy(), crashing dns proxy. 1 let bug: Int? = nil 2 os_log("bug: %{public}s", log: Log.ext, type: .debug, bug!) It can be seen from below the log that “starting proxy“ happens three times before it died. It makes no difference if we put the same bug inside handleNewFlow(). And that causes no browsing through under incognito mode. Can you help confirm this? If it is the case, is there any way to guard sys extension process and respawn it as a kind of robusness? Thanks in advance for any suggestion. Richard

Hi there, It is well known that system extension could not be uninstalled via api level since the beginning, typically OSSystemExtensionRequest.deactivationRequest. Now that with the latest Monterey release 12.2, is it still the case? Thanks in advance for any suggestion. Regards Richard

Hi there, Just to check with you any way to update filter rules on the run for app proxy. The setting up of filter rules is like below codes. let settings = NETransparentProxyNetworkSettings.init(tunnelRemoteAddress: "127.0.0.1") settings.includedNetworkRules = ... settings.excludedNetworkRules = ... setTunnelNetworkSettings(settings) { ... } That is inside startProxy() function followed by proxy start. I wonder is it possible to update these rules without restarting the proxy. Thanks in advance for any suggestion. Regards Richard

Hi there, We have app proxy + dns proxy both launched like below way: // Start App Proxy ProxyManager.shared().loadProxyManager(connect: true) { ProxyManager.shared().addObserver {} ProxyManager.shared().start() } // Start the DNS Proxy DNSManager.shared().start() With MDM profile, it work all good. But if without MDM profile, there will be two prompts asking confirmation to add net services for each proxy. But the first prompt will disappear and replaced by the second prompt. Thus can only confirm and add the second proxy net service. The result is only dns proxy net service added and running. No app proxy net service seen or running. Is it the right way that I launch both proxies like that? Still we need the use case without MDM profile. Thanks in advance for any suggestion. Richard

Hi there, Is there any way to configuration the MTU value with AppProxyProvider (DNSProxyProvider). I guess should be around NWConnection and NWUDPSession and see any configuration available? Thanks in advance.

Hi there, So far with the deployment of Network System Extension onto end devices of macbook pro, in general it all goes well. 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. Symptom is that network get stuck intermittently and then get totally loss. It seems that from time to time app proxy get stuck and cannot proceed further traffic fast enough, especially for dns request filtering currently going through the same app proxy. Thus causes network loss and not recoverable. So the question is: is there any requirement on the hardware in order to use Network System Extension correctly. Thanks in advance for any suggestion. Richard

Hi there, As seen from console error periodically message like "deny system-priviledge" for our appproxy, dnsproxy process as well as our system serivce process. Thanks in advance for any suggestion. deny_macappproxy.txt deny_dnsproxy.txt deny_system_service.txt

Hi there, This is seen from console log running AppProxyProvider. Sometimes can see like this: nw_endpoint_handler_set_adaptive_write_handler [C978 IPv4#759261e2:443 ready socket-flow (satisfied (Path is satisfied), viable, interface: en0, ipv4, dns)] unregister notification for write_timeout failed Would like to see with you guys what is going on when such logs on show? Is it because the peer flow (connection or session) closed and the local connection (session) timeout? As it have seen with that appproxy gets blocked for a while and then recovers. Is it normal and is it avoidable? Thanks in advance for any suggestion.

Hi there, With app proxy, when in case flow read, tcp connection read or udp session read empty is encountered. In this case, should I return directly, or close flow, connection, session and then return, or should I go on write through the empty data as usual even if it is empty? Put below the code example in case of flow read and connection write.      flow.readData { data, readError in       guard readError == nil, let readData = data else { log.error("[LogApp] Failed to read data from the TCP flow \(self.local.debugDescription)")           local.closeWriteWithError(readError) local.closeReadWithError(readError)         return       }               guard !readData.isEmpty else { log.verbose("[LogApp] Empty data from TCP flow \(self.local.description)") // What should I do here? // return directly // or close flow and return // or keep on going to connection write?       }       connection.send(content: data, completion: .contentProcessed( { connectionError in ...          })) Thanks in advance for any suggestion.

Hi there, Something interesting and not understand when trying to fetch my appproxy (and dnsproxy) system extension process with commands like below. With Intel macbook pro, all good to fetch back that pid. But with M1 macbook pro, it returns nothing although installed with the same Big Sur 11.6.1. ps -A | grep $MY_SYS_EXTENSION_PROCESS_NAME pgrep $MY_SYS_EXTENSION_PROCESS_NAME Do you have any suggestion to make it the same on M1? Thanks in advance for any suggestion. Regards Richard

Hi there, This is the question when using dnsproxy together with appproxy. In case I need to filter all udp traffic through appproxy. How about dns traffic to port 53? It will go through both appproxy and dnsproxy! Do I need to return false inside appproxy for outbound 53 udp traffic without even open the flow? Any conflict of such usage? Thanks in advance for any suggestion. Regards Richard

Hi there, This is found with duration test on Monterey 12.0. We are using appproxy and pipe through all udp traffics including dns requests (udp port 53). With below script doing only nslookup per second, in a couple of hours, it just fails. No network at all although no error on appproxy level reported. Only way to recover so far is uninstall the system extension. #!/bin/bash i=1 while true do i=$((i+1)) echo "loop $i" nslookup www.google.com sleep 1 done Tried the latest 12.1 beta, same failure. This test has no problem with Bigsur including 11.6. Thanks in advance for any suggestion. Regards Richard