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
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
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,
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,
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 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,
We are using systemextension for network and now we try to turn on SIP and install/uninstall systemextension.
Current status is that: with SIP on, systemextension can be installed correctly, but cannot be uninstalled.
The install/uninstall code is like below. Calling installSystemExtension() from the entrance of ProxyManger.swift:loadProxyManager returns success:
activation request succeeded
And systemextension list common shows the newly installed sysExt.
But calling uninstallSystemExtension() from the entrance of ProxyManger.swift:remove() results in error:
deactivation request failed authorization: unauthorized
And systemextension list common shows no difference.
@available(macOS 11.0, *)
private func installSystemExtension() {
log.info("[LogApp] will submit activation request")
let request = OSSystemExtensionRequest.activationRequest(
forExtensionWithIdentifier: "com.familyzone.macappproxy.fzmacappproxy",
queue: .main
)
request.delegate = self
OSSystemExtensionManager.shared.submitRequest(request)
log.info("[LogApp] did submit activation request")
}
// MARK: - Unload System Extension
@available(macOS 11.0, *)
public func uninstallSystemExtension() {
log.info("[LogApp] will submit deactivation request")
let request = OSSystemExtensionRequest.deactivationRequest(
forExtensionWithIdentifier: "com.familyzone.macappproxy.fzmacappproxy",
queue: .main
)
request.delegate = self
OSSystemExtensionManager.shared.submitRequest(request)
log.info("[LogApp] did submit deactivation request")
}
Thanks in advance for any suggestion.
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,
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