I use eapolcfg in Apple's open source eap8021x repository to connect to the enterprise network. 1.https://github.com/gfleury/eap8021x-debug https://opensource.apple.com/source/eap8021x/eap8021x-304.100.1/ Our enterprise network authentication is PEAP. So far, I have created a profile using the following commands and have done the access. ./eapolcfg createProfile --authType PEAP --SSID myssid --securityType WPA2 --userDefinedName MyProfile ./eapolcfg setPasswordItem --password mypassword --name myname --SSID myssid ./eapolcfg startAuthentication --interface en0 --SSID myssid After I performed this series of operations, I passed BOOL success = [self.interface associateToEnterpriseNetwork:network identity:nil username:username password:password error:&error]; Connection will pop up the following pop-up window, sometimes associateToEnterpriseNetwork will fail. I don't know what went wrong, is it that I missed some steps through the eapolcfg [tool?] This function also reports the following error：Error Domain=com.apple.coreWLAN.EAPOL.error Code=1 "(null)" Please answer my questions. Thank you very much

I am looking for inputs to better understand MacOS entitlements. I ask this in context of OpenJDK project, which builds and ships the JDK. The build process makes uses of make tool and thus doesn't involving building through the XCode product. The JDK itself is a Java language platform providing applications a set of standard APIs. The implementation of these standard APIs internally involves calling platform specific native library functions. In this discussion, I would like to focus on the networking functions that the implementation uses. Almost all of these networking functions and syscalls that the internal implementation uses are BSD socket related. Imagine calls to socket(), connect(), getsockopt(), setsockopt(), getaddrinfo(), sendto(), listen(), accept() and several such. The JDK that's built through make is then packaged and made available for installation. The packaging itself varies, but for this discussion, I'll focus on the .tar.gz archived packaging. Within this archive there are several executables (for example: java, javac and others) and several libraries. My understanding, based on what I have read of MacOS entitlements is that, the entitlements are set on the executable and any libraries that would be loaded and used by that executable will be evaluated against the entitlements of the executable (please correct me if I misunderstand). Reading through the list of entitlements noted here https://developer.apple.com/documentation/bundleresources/entitlements, the relevant entitlements that an executable (like "java") which internally invokes BSD socket related syscalls and library functions, appear to be: com.apple.security.network.client - https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.network.client com.apple.security.network.server - https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.network.server com.apple.developer.networking.multicast - https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.developer.networking.multicast Is my understanding correct that these are the relevant ones for MacOS? Are there any more entitlements that are of interest? Would it then mean that the executables (java for example) would have to enroll for these entitlements to be allowed to invoke those functions at runtime? Reading through https://developer.apple.com/documentation/bundleresources/entitlements, I believe that even when an executable is configured with these entitlements, when the application is running if that executable makes use of any operations for which it has an entitlement, the user is still prompted (through a UI notification) whether or not to allow the operation. Did I understand it right? The part that isn't clear from that documentation is, if the executable hasn't been configured with a relevant entitlement, what happens when the executable invokes on such operation. Will the user see a UI notification asking permission to allow the operation (just like if an entitlement was configured)? Or does that operation just fail in some behind the scenes way? Coming back to the networking specific entitlements, I found a couple of places in the MacOS documentation where it is claimed that the com.apple.developer.networking.multicast entitlement is only applicable on iOS. In fact, the entitlement definition page for it https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.developer.networking.multicast says: "Your app must have this entitlement to send or receive IP multicast or broadcast on iOS. It also allows your app to browse and advertise arbitrary Bonjour service types." Yet, that same page, a few lines above, shows "macOS 10.0+". So, is com.apple.developer.networking.multicast entitlement necessary for an executable running on MacOS which deals with multicasting using BSD sockets? As a more general comment about the documentation, I see that the main entitlements page here https://developer.apple.com/documentation/bundleresources/entitlements categorizes some of these entitlements under specific categories, for example, notice how some entitlements are categorized under "App Clips". I think it would be useful if there was a category for "BSD sockets" and under that it would list all relevant entitlements that are applicable, even if it means repeating the entitlement names across different categories. I think that will make it easier to identify the relevant entitlements. Finally, more as a long term question, how does one watch or keep track of these required entitlements for these operations. What I mean is, is it expected that application developers keep visiting the macos documentation, like these pages, to know that a new entitlement is now required in a new macos (update) release? Or are there other ways to keep track of it? For example, if a newer macos requires a new entitlement, then when (an already built) executable is run on that version of macos, perhaps generate a notification or some kind of explicit error which makes it clear what entitlement is missing? I have read through https://developer.apple.com/documentation/bundleresources/diagnosing-issues-with-entitlements but that page focuses on identifying such issues when a executable is being built and doesn't explain the case where an executable has already been shipped with X entitlements and a new Y entitlement is now required to run on a newer version of macos.

I'm facing an issue where if a WiFi network is turned off and back on within a short time frame (2-4 seconds), iOS still shows the device as connected but does not send a new DHCP request. This causes a problem for my network device, which relies on the DHCP request to assign an IP address. Without the request, the device is unable to establish a socket connection properly. Is there any way to force iOS to send a DHCP request immediately when reconnecting to the network in this scenario? Are there any known workarounds or configurations that might help ensure the DHCP process is re-triggered? Any insights would be appreciated. Thanks!

Dear Apple： We found that after mirroring an iPhone and a Mac, calling the NEHotspotConfigurationManager applyConfiguration interface on the iPhone fails to connect to Wi-Fi. Are there any restrictions on using this interface in mirror mode?

We've observed intermittent crashes in our production environment, pls help to take a look at this, thx

Hi we want to use CONNECT-IP extension within the MASQUE protocol suite. we want to be able to reroute ICMP packets from our machine and redirect them to our MASQUE proxy. we want to avoid a creation of virtual interface or modifying the routing tables. is it possible, if so, how can it be achieved. thanks

I was trying to call getsockopt(fd, SOL_LOCAL, LOCAL_PEERCRED, ...), and by mistake passed a wrong value for the second parameter where it should be SOL_LOCAL. But the call still succeeded. Then I did more experiments and passed more random values for the second parameter, all succeeded. It seems there is a lack of parameter check in the implementation of getsockopt() , where it should return errors if people pass invalid parameters instead of succeeding silently. Hope the Apple engineers can help to validate and fix it.

I am writing to seek clarification on two technical issues related to iOS frameworks (CoreBluetooth and NetworkExtension). These observations are critical for optimizing our app's performance, and I would appreciate any official guidance or documentation references. CoreBluetooth Scanning Frequency and Cycle Issue: We noticed inconsistent BLE device discovery times (ranging from 0.5s to 1.5s) despite the peripheral advertising at 2Hz (500ms interval). Questions: Does iOS regulate the BLE scan interval or duty cycle internally? If yes, what factors affect this behavior (e.g., foreground/background state, connected devices)? Are there recommended practices to reduce discovery latency for peripherals with fixed advertising intervals? Is there a way to configure scan parameters (e.g., scan window/interval) programmatically, similar to Android's BluetoothLeScanner? Test Context: Device: iPhone 13 mini (iOS 17.6.1) Code: CBCentralManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true]) NEHotspotConfigurationManager Workflow and Latency Issue: Using NEHotspotConfigurationManager.shared.apply(_:) to connect to Wi-Fi occasionally takes up to 8 seconds to complete. Questions: What is the internal workflow of the apply method? Does it include user permission checks, SSID scanning, authentication, or IP assignment steps? Are there known scenarios where this method would block for extended periods (e.g., waiting for user interaction, network timeouts)? Is the latency related to system-level retries or radio coexistence with other wireless activities (e.g., Bluetooth)? Test Context: Configuration: NEHotspotConfiguration(ssid: "TestSSID") Behavior: Delay occurs even when the Wi-Fi network is in range and credentials are correct.

I am writing to seek clarification on two technical issues related to iOS frameworks (CoreBluetooth and NetworkExtension). These observations are critical for optimizing our app's performance, and I would appreciate any official guidance or documentation references. CoreBluetooth Scanning Frequency and Cycle Issue: We noticed inconsistent BLE device discovery times (ranging from 0.5s to 1.5s) despite the peripheral advertising at 2Hz (500ms interval). Questions: Does iOS regulate the BLE scan interval or duty cycle internally? If yes, what factors affect this behavior (e.g., foreground/background state, connected devices)? Are there recommended practices to reduce discovery latency for peripherals with fixed advertising intervals? Is there a way to configure scan parameters (e.g., scan window/interval) programmatically, similar to Android's BluetoothLeScanner? Test Context: Device: iPhone 13 mini (iOS 17.6.1) Code: CBCentralManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true]) NEHotspotConfigurationManager Workflow and Latency Issue: Using NEHotspotConfigurationManager.shared.apply(_:) to connect to Wi-Fi occasionally takes up to 8 seconds to complete. Questions: What is the internal workflow of the apply method? Does it include user permission checks, SSID scanning, authentication, or IP assignment steps? Are there known scenarios where this method would block for extended periods (e.g., waiting for user interaction, network timeouts)? Is the latency related to system-level retries or radio coexistence with other wireless activities (e.g., Bluetooth)? Test Context: Configuration: NEHotspotConfiguration(ssid: "TestSSID") Behavior: Delay occurs even when the Wi-Fi network is in range and credentials are correct.

I am developing an App based on Network Extension that lets all network requests on device access the Internet through a private Relay. I created an empty iOS App and only the entitlements file and ViewController.swift(Main.storyboard) file have been modified. The code was copied from the official video https://developer.apple.com/videos/play/wwdc2023/10002/ But, running the App on iPhone, the saveToPreferences API reported Error Domain=NERelayErrorDomain Code=3 "(null)" and the App doesn't look like it's changed at all (it doesn't jump to the Settings - VPN&Relay). Does anyone know why？Any reply would be greatly appreciated. The contents of the entitlements file: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.networking.networkextension</key> <array> <string>relay</string> </array> </dict> </plist> ViewController.swift: import UIKit import NetworkExtension class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view. } @IBAction func tap(_ sender: Any) { let newRelay = NERelay() let relayURL = URL(string: "https://relay.example.com:443/") newRelay.http3RelayURL = relayURL newRelay.http2RelayURL = relayURL newRelay.additionalHTTPHeaderFields = ["Authorization" : "PrivateToken=123"] let manager = NERelayManager.shared() manager.relays = [newRelay] manager.matchDomains = ["internal.example.com"] manager.isEnabled = false manager.saveToPreferences { err in print(err) } } }

I have a question regarding /etc/pf.conf. If I use this rule, rdr pass on bridge100 inet proto tcp from 192.168.2.104 to any port {80, 443, 8883} -> 127.0.0.1 port 8080 all other traffic on bridge100 will not function properly, even the traffic that is not destined for 192.168.2.104. Additionally, the hotspot generated through bridge100 will also become unavailable. Even if I comment out this rule and run sudo pfctl -e -f /etc/pf.conf, the problem still persists. The situation will only return to normal when I restart my Mac. my macos:15.3.2 my /etc/pf.conf # scrub-anchor "com.apple/*" nat-anchor "com.apple/*" rdr-anchor "com.apple/*" rdr pass on bridge100 inet proto tcp from 192.168.2.104 to any port {80, 443, 8883} -> 127.0.0.1 port 8080 dummynet-anchor "com.apple/*" anchor "com.apple/*" load anchor "com.apple" from "/etc/pf.anchors/com.apple"

Hi there, I'm trying to build a MacOS VPN application from scratch. My VPN application is slightly from normal ones, It will include an authentication token and underlying process information (pid, application path etc.) in each connection made to the VPN gateway. Consider it a poor man's zerotrust implementation. NetworkExtension and PacketTunnel is a must, thus to retrieve process information via audit tokens. However, I'm unable to find any working examples that can be built on MacOS 15.X. I tried to open an TSI case but didn't receive anything useful. Anyone?

I am working on a macos application that uses NetworkExtension and works fine in the debug environment. However, when I use the Release package, I am always prompted that my description file does not contain NetworkExtension. I am sure that my description file does contain NetworkExtension. How to solve this problem

We use Boost ***** (1.86.0) for WebSockets in an iOS application using a self-signed certificate. The ***** WebSocket client works fine on iOS 18.1 and every other OS (Windows, Android, Linux, etc...) but not iOS 18.3.1 and possibly versions before 18.3.1 but later than iOS 18.1. Has anyone else ran into this issue and how did you resolve? What could have changed after iOS 18.1 that would prevent a WSS Websocket from connecting that works fine on iOS 18.1?

I have a question regarding /etc/pf.conf. If I use this rule, rdr pass on bridge100 inet proto tcp from 192.168.2.104 to any port {80, 443, 8883} -> 127.0.0.1 port 8080 all other traffic on bridge100 will not function properly, even the traffic that is not destined for 192.168.2.104. Additionally, the hotspot generated through bridge100 will also become unavailable. Even if I comment out this rule and run sudo pfctl -e -f /etc/pf.conf, the problem still persists. The situation will only return to normal when I restart my Mac. my macos:15.3.2 my /etc/pf.conf # scrub-anchor "com.apple/*" nat-anchor "com.apple/*" rdr-anchor "com.apple/*" rdr pass on bridge100 inet proto tcp from 192.168.2.104 to any port {80, 443, 8883} -> 127.0.0.1 port 8080 dummynet-anchor "com.apple/*" anchor "com.apple/*" load anchor "com.apple" from "/etc/pf.anchors/com.apple"

We're experiencing an issue with Local Network Permission. When trying to connect to a socket, the Local Network Permission alert pops up. To trigger the permission request at the start of the app, we used the following code to ask for permission and receive a callback on whether it's granted. However, this approach doesn't always trigger the permission alert, or it gets automatically dismissed after 30 seconds, only to reappear later. What could be causing this inconsistent behavior? func checkLocalNetworkPermission(_ completed: Optional&lt;(Bool) -&gt; Void&gt; = .none) { DispatchQueue.global(qos: .userInitiated).async { let hostName = ProcessInfo.processInfo.hostName let isGranted = hostName.contains(".local") if let completed { DispatchQueue.main.async { completed(isGranted) } } } }

Please consider this very trivial C code, which was run on 15.3.1 of macos: #include <stdio.h> #include <stdlib.h> #include <netinet/in.h> #include <arpa/inet.h> #include "sys/socket.h" #include <string.h> #include <unistd.h> #include <ifaddrs.h> #include <net/if.h> // prints out the sockaddr_in6 void print_addr(const char *msg_prefix, struct sockaddr_in6 sa6) { char addr_text[INET6_ADDRSTRLEN] = {0}; printf("%s%s:%d, addr family=%u\n", msg_prefix, inet_ntop(AF_INET6, &sa6.sin6_addr, (char *) &addr_text, INET6_ADDRSTRLEN), sa6.sin6_port, sa6.sin6_family); } // creates a datagram socket int create_dgram_socket() { const int fd = socket(AF_INET6, SOCK_DGRAM, 0); if (fd < 0) { perror("Socket creation failed"); return -1; } return fd; } int main() { printf("current process id:%ld parent process id: %ld\n", (long) getpid(), (long) getppid()); // // hardcode a link-local IPv6 address of a interface which is down // ifconfig: // ,,, // awdl0: flags=8822<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500 // options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM> // ... // inet6 fe80::34be:50ff:fe14:ecd7%awdl0 prefixlen 64 scopeid 0x10 // nd6 options=201<PERFORMNUD,DAD> // media: autoselect (<unknown type>) // status: inactive // const char *ip6_addr_str = "fe80::34be:50ff:fe14:ecd7"; // link-local ipv6 address from above ifconfig output // parse the string literal to in6_addr struct in6_addr ip6_addr; int rv = inet_pton(AF_INET6, ip6_addr_str, &ip6_addr); if (rv != 1) { fprintf(stderr, "failed to parse ipv6 addr %s\n", ip6_addr_str); exit(EXIT_FAILURE); } // create a AF_INET6 SOCK_DGRAM socket const int sock_fd = create_dgram_socket(); if (sock_fd < 0) { exit(EXIT_FAILURE); } printf("created a socket, descriptor=%d\n", sock_fd); // create a destination sockaddr which points to the above // ipv6 link-local address and an arbitrary port const int dest_port = 12345; struct sockaddr_in6 dest_sock_addr; memset((char *) &dest_sock_addr, 0, sizeof(struct sockaddr_in6)); dest_sock_addr.sin6_addr = ip6_addr; dest_sock_addr.sin6_port = htons(dest_port); dest_sock_addr.sin6_family = AF_INET6; dest_sock_addr.sin6_scope_id = 0x10; // scopeid from the above ifconfig output // now sendto() to that address, whose network interface is down. // we expect sendto() to return an error print_addr("sendto() to ", dest_sock_addr); const char *msg = "hello"; const size_t msg_len = strlen(msg) + 1; rv = sendto(sock_fd, msg, msg_len, 0, (struct sockaddr *) &dest_sock_addr, sizeof(dest_sock_addr)); if (rv == -1) { perror("sendto() expectedly failed"); close(sock_fd); exit(EXIT_FAILURE); } printf("sendto() unexpectedly succeeded\n"); // should not reach here, we expect sendto() to return an error return 0; } It creates a SOCK_DGRAM socket and attempts to sendto() to a link-local IPv6 address of a local network interface which is not UP. The sendto() is expected to fail with a "network is down" (or at least fail with some error). Let's see how it behaves. Copy that code to a file called netdown.c and compile it as follows: clang netdown.c Now run the program: ./a.out That results in the following output: current process id:29290 parent process id: 21614 created a socket, descriptor=3 sendto() to fe80::34be:50ff:fe14:ecd7:14640, addr family=30 sendto() unexpectedly succeeded (To reproduce this locally, replace the IPv6 address in that code with a link-local IPv6 address of an interface that is not UP on your system) Notice how the sendto() returned successfully without any error giving an impression to the application code that the message has been sent. In reality, the message isn't really sent. Here's the system logs from that run: PID Type Date & Time Process Message debug 2025-03-13 23:36:36.830147 +0530 kernel Process (a.out) allowed via dev tool environment (/System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal) debug 2025-03-13 23:36:36.833054 +0530 kernel [SPI][HIDSPI] TX: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 RX: 20 02 00 00 00 00 38 00 10 02 00 17 00 00 2E 00 26700 error 2025-03-13 23:36:36.838607 +0530 nehelper Failed to get the signing identifier for 29290: No such process 26700 error 2025-03-13 23:36:36.838608 +0530 nehelper Failed to get the code directory hash for 29290: No such process default 2025-03-13 23:36:36.840070 +0530 kernel cfil_dispatch_attach_event:3507 CFIL: Failed to get effective audit token for <sockID 22289651233205710 <4f3051d7ec2dce>> 26700 error 2025-03-13 23:36:36.840678 +0530 nehelper Failed to get the signing identifier for 29290: No such process 26700 error 2025-03-13 23:36:36.840679 +0530 nehelper Failed to get the code directory hash for 29290: No such process default 2025-03-13 23:36:36.841742 +0530 kernel cfil_hash_entry_log:6082 <CFIL: Error: sosend_reinject() failed>: [29290 ] <UDP(17) out so 891be95f39bd0385 22289651233205710 22289651233205710 age 0> lport 60244 fport 12345 laddr fe80::34be:50ff:fe14:ecd7 faddr fe80::34be:50ff:fe14:ecd7 hash D7EC2DCE default 2025-03-13 23:36:36.841756 +0530 kernel cfil_service_inject_queue:4466 CFIL: sosend() failed 50 Notice the last line where it states the sosend() (and internal impl detail of macos) failed with error code 50, which corresponds to ENETDOWN ("Network is down"). However, like I noted, this error was never propagated back to the application from the sendto() system call. The documentation of sendto() system call states: man sendto ... Locally detected errors are indicated by a return value of -1. ... RETURN VALUES Upon successful completion, the number of bytes which were sent is returned. Otherwise, -1 is returned and the global variable errno is set to indicate the error. So I would expect sendto() to return -1, which it isn't. The 15.3.1 source of xnu hasn't yet been published but there is the 15.3 version here https://github.com/apple-oss-distributions/xnu/tree/xnu-11215.81.4 and looking at the corresponding function cfil_service_inject_queue, line 4466 (the one which is reported in the logs) https://github.com/apple-oss-distributions/xnu/blob/xnu-11215.81.4/bsd/net/content_filter.c#L4466, the code there logs this error and the cfil_service_inject_queue function then returns back the error. However, looking at the call sites of the call to cfil_service_inject_queue(...), there are several places within that file which don't track the return value (representing an error value) and just ignore it. Is that intentional and does that explain this issue? Does this deserve to be reported as a bug through feedback assistant?

I created a self signed CA and use it to generate/sign a client cert using openssl. Then I use the self signed client cert to do TLS client authentication with my server (which also uses the self signed CA). The issue I have is when I validate the self signed CA, by calling SecTrustEvaluateAsyncWithError, it always complains this error “'DigiCert Global Root G3' certificate is not trusted". However that CA (DigiCert Global Root G3) is not my self signed CA (my CA is 'MQTTSampleCA' and I attached a dump of the my CA cert in the PR in the end of this post), so I'm confused why the API keeps complaining that CA. After some researching, I see that is a well known CA so I download its cert from https://www.digicert.com/kb/digicert-root-certificates.htm, install and trust it on my iOS device, but that doesn't help and I still get the same error. I provide all the repro steps in this PR: https://github.com/liumiaojq/EmCuTeeTee/pull/1, including how I generate the certs and the source codes of a test app that I used to do cert validation. I appreciate if anyone can share insights how to resolve this error.

In TN3179 under "macOS considerations" there are a set of instances where local network privacy does not apply: macOS automatically allows local network access by: Any daemon started by launchd Any program running as root Command-line tools run from Terminal or over SSH, including any child processes they spawn I am running some tests in my app that use the local network, attempting to run them from both the terminal app and from a VScode terminal and I am getting permissions prompts. After allowing these pop ups, some of the tests still fail as if networking was blocked.

Hey! We are investigating a problem pf rules being ignored by some processes. Despite blocking all traffic, some outgoing unicast packets can be seen in tcpdump. Issue is present in MacOS 15.0.0 - 15.3.1 (Newest at the time of writing). I tested MacOS 14.7.4 and pf rules there behaved as expected. Steps to reproduce the issue: $ cat pf.conf block all $ sudo pfctl -e -F all -f ./pf.conf Password: pfctl: Use of -f option, could result in flushing of rules present in the main ruleset added by the system at startup. See /etc/pf.conf for further details. No ALTQ support in kernel ALTQ related functions disabled rules cleared nat cleared dummynet cleared 0 tables deleted. 196 states cleared source tracking entries cleared pf: statistics cleared pf: interface flags reset pfctl: pf already enabled After executing these commands MacOS 14 will block all outgoing unicast traffic, and on MacOS 15 data can be sent to arbitrary addresses: $ ifconfig en0 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM> ether b6:5e:a5:c5:1e:db inet6 fe80::1090:9c8:4325:329a%en0 prefixlen 64 secured scopeid 0xe inet 192.168.50.144 netmask 0xffffff00 broadcast 192.168.50.255 nd6 options=201<PERFORMNUD,DAD> media: autoselect status: active $ sudo tcpdump -k A -i any -n src 192.168.50.144 tcpdump: data link type PKTAP tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type PKTAP (Apple DLT_PKTAP), snapshot length 524288 bytes 12:05:12.673472 (en0, proc com.apple.geod:1286:, svc BE, out, ch, flowid 0x0, ttag 0x0, dlt 0x1, cmpgc 0x0) IP 192.168.50.144.52012 > 17.253.15.196.443: Flags [P.], seq 1888882378:1888882402, ack 3554898220, win 2048, options [nop,nop,TS val 2752050055 ecr 1291585385], length 24 12:05:13.793937 (en0, proc com.apple.WebKit:974:, eproc Safari:804:, svc BE, out, ch, flowid 0x0, ttag 0x0, dlt 0x1, cmpgc 0x0) IP 192.168.50.144.52024 > 3.65.102.105.443: Flags [P.], seq 2011312019:2011312073, ack 673002582, win 2048, options [nop,nop,TS val 777228223 ecr 484269939], length 54 Was there any change in the way pfctl is used or is this a bug? This issue affects negatively privacy features of our product.