I am trying to get ports used by processes. It can be done via lsof on macOS, i am trying to do it via libproc. #include <iostream> #include <libproc.h> int main(int argc, const char * argv[]) { pid_t pids[3072]; int count = proc_listpids(PROC_ALL_PIDS, 0, pids, sizeof(pids)); for (int i = 0; i < count; i++) { char buffer[1024]; for (int j = 1; j < 50000; j++) { //port range int ret = proc_pidfileportinfo(pids[i], j, PROC_PIDFILEPORTVNODEPATHINFO, buffer, sizeof(buffer)); if(ret != 0) { printf("proc_pidfileportinfo returned %d bytes of data\n", ret); printf("%s\n", name); } } } return 0; } proc_pidfileportinfo function is not working for any port, i tried iterating till 50K. What i am doing wrong with proc_pidfileportinfo? how to properly use proc_pidfileportinfo?

As per : TN3120: Expected use cases for Network Extension packet tunnel providers | Apple Developer Documentation It is clear that Packets that are read from NEPacketTunnelFlow are meant to be sent over a tunnel connection to a remote server for injection into a remote network. They are not meant to be dropped or re-injected back into the system. In my usecase: NEPacketTunnelProvider is separate process. which reads the packet using packetFlow.readPacketObjects Send it over to other process i.e privileged helper(Non-bundle/command line tool/non sandboxed) via UDS IPC. Helpers send to to remote tunnel and return back the packet to NEPacketTunnelFlow via same IPC. NEPacketTunnelProvider uses packetFlow.writePacketObjects to inject packets. Things works fine. We don't distribute it via Appstore. We are now attempting to implement a on device bypass mechanism from helper tool side. Could you please suggest if there is any approach I could try, even if it involves proceeding at my own risk?

Hello, I have created raw socket as below rawSockfd = socket(AF_INET,SOCK_RAW,IPPROTO_IP) Added flag 5 sec SO_RCVTIMEO, IP_HDRINCL to 1 via setsockopt. Sending IP Packet as below: struct sockaddr_in connection = getSockAddr(dstIPAddress);  long bytes = sendto(rawSockfd, (uint8_t *)packet, size, 0, (struct sockaddr *)&connection, sizeof(struct sockaddr)); I am trying to receive as below: long rsize = recvfrom(rawSock, buffer, size, 0, (struct sockaddr *)&connection, (socklen_t *)&addrlen); This works fine for ICMP, UDP. recvfrom able to read packet back. We are facing issue during TCP. recvfrom returns error: Resource temporarily unavailable after 5 sec timeout. If we remove timeout flag SO_RCVTIMEO then it gets stuck forever. TCPdump shows following logs on destination. Instead of SYN ACK it's getting Reset: 09:21:03.972632 IP 10.215.179.1.54745 > 10.207.134.154.8181: Flags [SEW], seq 358899317, win 65535, options [mss 1380,nop,wscale 6,nop,nop,TS val 426499980 ecr 0,sackOK,eol], length 0 09:21:03.972755 IP 10.207.134.154.8181 > 10.215.179.1.54745: Flags [R.], seq 0, ack 358899318, win 0, length 0 is this something macOS not sending TCP response back to rawsocket or something is wrong in my code?

Hi, This is how we create ipv4Settings, then we add includedRoutes, excludedRoutes. let ipv4Settings = NEIPv4Settings(addresses: addresses, subnetMasks: subnetMask) In my case, Packet Tunnel Provider reads the packet like this - packetFlow.readPacketObjects, sends packets to C++ module which takes care of sending it to wireguard tunnel, returns packet back to Packet Tunnel Provider for writing. C++ Module does everything related to wireguard tunnel. As per my understanding, any unique private ipv4, ipv6 address should be fine for creating NEIPv4Settings, NEIPv6Settings. is that correct? or is there anything else i need to consider for setting Utun addresses as of now i have harcoded it to 10.10.10.10/32 and 2001:db8::/128, will it cause any problem?

Hi, We are observing few NEPacketTunnelNetworkSettings excludedRoutes ip's in PacketTunnel even-though it is added in exclude routes. As you can see in network setting where we have added destinationAddress = 239.255.255.0 destinationSubnetMask = 255.255.255.0 in exclude route, still traffic of IP 239.255.255.250 coming to packet tunnel. We also observing other IP's traffic that is not added in include route such as: 20.192.170.9 //Network Settings for Packet Tunnel IPv4Settings = { configMethod = PPP addresses = ( 10.10.10.10, ) subnetMasks = ( 255.255.255.255, ) includedRoutes = ( { destinationAddress = 10.10.10.10 destinationSubnetMask = 255.255.255.255 gatewayAddress = 10.10.10.10 }, ) excludedRoutes = ( { destinationAddress = 192.168.0.0 destinationSubnetMask = 255.255.0.0 }, { destinationAddress = 10.0.0.0 destinationSubnetMask = 255.0.0.0 }, { destinationAddress = 127.0.0.1 destinationSubnetMask = 255.255.255.255 }, { destinationAddress = 172.16.0.0 destinationSubnetMask = 255.240.0.0 }, { destinationAddress = 239.255.255.0 destinationSubnetMask = 255.255.255.0 }, ) am i doing something wrong in setting NEPacketTunnelNetworkSettings?

I am trying to pause NEFilterFlow and then resuming NEFilterFlow from function **handleInboundData** let goingToApply = someFunctionWithClosure { applied in if applied { let verdict: NEFilterNewFlowVerdict = .allow() self.resumeFlow(flow, with: verdict) } } if goingToApply == true { return .pause() } The line self.resumeFlow(flow, with: verdict) crashing with following exception: terminating with uncaught exception of type NSException *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NEFilterNewFlowVerdict passBytes]: unrecognized selector sent to instance 0x10b8662a0' Crash dump showing below logs: Thread 3 Crashed:: Dispatch queue: NEFilterExtensionProviderContext queue 0 libsystem_kernel.dylib 0x1b7aa6d78 __pthread_kill + 8 1 libsystem_pthread.dylib 0x1b7adbee0 pthread_kill + 288 2 libsystem_c.dylib 0x1b7a16340 abort + 168 3 libc++abi.dylib 0x1b7a96b18 abort_message + 132 4 libc++abi.dylib 0x1b7a86a54 demangling_terminate_handler() + 336 5 libobjc.A.dylib 0x1b797c320 _objc_terminate() + 144 6 libc++abi.dylib 0x1b7a95eb4 std::__terminate(void (*)()) + 20 7 libc++abi.dylib 0x1b7a95e50 std::terminate() + 64 8 libdispatch.dylib 0x1b79181c8 _dispatch_client_callout + 40 9 libdispatch.dylib 0x1b791f8a8 _dispatch_lane_serial_drain + 668 10 libdispatch.dylib 0x1b7920404 _dispatch_lane_invoke + 392 11 libdispatch.dylib 0x1b792ac98 _dispatch_workloop_worker_thread + 648 12 libsystem_pthread.dylib 0x1b7ad8360 _pthread_wqthread + 288 13 libsystem_pthread.dylib 0x1b7ad7080 start_wqthread + 8 Why this exception is occurring for .allow() verdict only. For .drop() it is not crashing. No where i'm calling passBytes method on NEFilterNewFlowVerdict

Hi, we have c++ module inside Network Extension which does rest call. we want to do http rest call in test environment, but it's not responding. status code is 0. https working fine. I tried adding NSAppTransportSecurity -> NSAllowsArbitraryLoads -> true, but it's crashing because of it. how can we make http request from Network Extension in test enviroment?

I have an app which hosts network extensions(Packet Tunnel, Filter). I am facing uninstallation issue in scenario 2. Uninstall API: OSSystemExtensionRequest.deactivationRequest Scenarion 1: app version 1.0.0.1, extension inside app bundle version 1.0.0.1 Installed extension -> version 1.0.0.1 Uninstallation works fine. Scenarion 2: app version 1.0.0.2, extension inside app bundle version 1.0.0.2 Installed extension -> version 1.0.0.1 Uninstallation fails with below error: deactivation failed for client: /Applications/Remo Security Endpoint Client/ep-client.app/Contents/MacOS/ep-client, error: Error Domain=OSSystemExtensionErrorDomain Code=4 "(null)" Question 1: is this by design or we can do something to make uninstall works in case application upgraded and tries to uninstall previous extension version. Snippet from Apple Doc for API: OSSystemExtensionRequest.deactivationRequest A deactivation request may require a restart before deactivating the extension. If the request succeeds but requires a restart to complete, the extension may still appear operational until the next restart. Question 2: How do we know if restart needed or not?

On Ventura - We have a network extension(Transparent Proxy) which blocks IPv6 traffic as below. override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool { //Ipv6 gets blocks by below code let error = NSError(domain: "", code: 0, userInfo: [NSLocalizedDescriptionKey : "Connection Refused"]) flow.closeReadWithError(error) flow.closeWriteWithError(error) On IPv6 enabled client machine, when a client application(Browser, curl, Teams etc), try to send HTTP/s requests, first they try to send the request over IPv6 and if it fails, they try with IPv4 (Happy eyeballs Algorithm) In our case, as network extension blocks IPv6 traffic, client applications will fail to establish connection over IPv6 and fallback to IPv4 as per Happy eyeballs Algorithm The above scenario works fine till MacOS Ventura. For Sonoma, this behaviour seems to have changed When our network extension blocks IPv6 traffic, client applications do not fallback to IPv4. They simply fail without trying IPv4. We tested with curl, Google chrome browser, Microsoft Teams. All these fail to load pages on Sonoma and they work fine on Ventura. Note : No change in our network extension code, curl and browser versions. Only change is MacOS version Please find attached screenshots with Ventura and with Sonoma, running curl One other difference seen here is the error code received by client applications with Ventura and Sonoma. On Ventura, when IPv6 is blocked, error is Network is down and client application establishes connection with IPv4. On Sonoma, error code is 22 : Invalid arguments and client application does not retry with IPv4. Curl_Ventura.jpg Curl_Sonoma.png

I have a Network extension contains App Proxy and Content Filter. After installation, extension process is not getting auto launch. We want to execute some code in main.swift. extension process is getting launch on enabling either App Proxy or Content Filter. how to launch network extension process after installation? Installations Sample code: let activationRequest = OSSystemExtensionRequest.activationRequest(forExtensionWithIdentifier: id, queue: .main) OSSystemExtensionManager.shared.submitRequest(activationRequest)

NETransparentProxyProvider have below method: override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool This method is blocking. Until we returns value from this method, next flow will be blocked, macOS doesn’t calls it on new thread. for example: if we take 10 second to check what to do with this flow, whether to handle it(true) or return to kernel(false), another flow will be block for 10 sec. how to not block future flow while it is taking longer to process current flow?

NETransparentProxyProvider having these two methods: override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool override func handleNewUDPFlow( _ flow: NEAppProxyUDPFlow, initialRemoteEndpoint remoteEndpoint: NWEndpoint ) -> Bool During initial days when NETransparentProxyProvider was introduced, We used handleNewFlow to handle NEAppProxyTCPFlow and handleNewUDPFlow to handle NEAppProxyUDPFlow . Since handleNewUDPFlow is now deprecated, is it just okay to use handleNewFlow to handle both NEAppProxyTCPFlow & NEAppProxyUDPFlow? will this works always or there are some scenario where keeping handleNewUDPFlow will be usefull?

I have a process [command line cpp application] which i want to run always such as it should relaunch after a crash, after device startup etc. I created a launchd Property List File with KeepAlive true and placed under /Library/LaunchDaemons. Problem Statements: I have a bash script to start and stop this process. start using: launchctl bootstrap. stop involve these two steps: send SIGTERM signal and wait untill process stops after doing some cleanups launchctl bootout [It doesn't sends SIGTERM] during steps 1 - Process is getting stop, but also getting immediate relaunch by launchctl during step 2 - it getting stop again. is there a proper way so that we can disable KeepAlive temporarily so that process will not launch during step 1? or suggest other ways to handle this?

We want to ressolve dns for predefined sets of private app domains. We've added this rule: NENetworkRule(destinationHost: NWHostEndpoint(hostname: Private Domain1(example.com), port: 53), protocol: .UDP) As per apple documentation: A rule that matches all DNS queries/responses for hosts in the example.com domain. do you think it will work i.e it will forward DNS requests UDP flow to transparent provider in all the cases? or do you think the text is a bit misleading. it should instead say: "A rule that matches all DNS queries/responses for nameservers in the example.com domain"? This rule that look for port 53 of that domain only works if the system really asks a nameserver of that specific domain, right? So, what if a local DNS server or a different nameserver are taking care of the resolution?

NEAppProxyUDPFlow contains below property: open var localEndpoint: NWEndpoint? { get } Why is localEndpoint not available for NEAppProxyTCPFlow? Is there a way to determine the source port of a flow of type NEAppProxyTCPFlow within the following method of NETransparentProxyProvider? override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool {