I am facing same behavior however I can see Apple allows to unlock the keychain login without modal window by using below API from Security framework:let theResult1 = SecKeychainSetUserInteractionAllowed(false) let theResult2 = SecKeychainUnlock(theChain, 10, "password", true)so can we do something like above API to silently supply the admin username and password to by pass the modal window(without requiring same user approval everytime) to fetch the WiFi Password?...Thanks & Regards,Mohmad Vasim

Thanks for your provided help eskimo!

Thanks for your quick response, Eskimo! Is that right? If so, how do the failing systems differ from the working systems? You’ve already said that the failing systems include both Intel and Apple silicon machines. Are these other differences? Yes, you are correct. There is no other difference we found. we just know that its fresh partition where its failing. Are the working systems also running macOS 12.4? yes. its correct. Do all the systems have SIP enabled? Yes, SIP is enabled in all system. We are trying to find the problem but we don't know how to proceed. I hope when we are trying to install System Extension, OS internally checks notarisation status of extension using Apple Server and if it gets failed then it returns OSSystemExtensionErrorCodeSignatureInvalid so is there any server that we can check its ping-able/reachable or not in affected machine or there is any log that will help us to know the problem. Thanks & Regards, Mohmad Vasim

Hi Meaton, Apologies for Network Extension . Its Security framework, SSLRead Secure Transport related problem that we are facing.

Thanks for your response Meaton! The Secure Transport APIs have been deprecated for some time now. Okay understood. Do you still see these issues if you use Network Framework and the TLS Security Options for Network Framework? We are pretty much new to use Network framework. Could you please help us if there is any sample that we can use to do Handshake with server and implement the POP3 SSL port 995 specification like Handshake with server with port 995 Send CAPA command to server and receive the server data Send other SSL command like STAT, UIDL, LIST and RETR command and read their response from server Thanks & Regards, Mohmad Vasim

Thanks for your response Matteon! Is this happening on when the data is sent on the connection or when nw_connection_start is called? Its happening once connection is in ready state and because of BoringSSL issue, unable to proceed for send command. Thanks & Regards, Mohmad Vasim

Thanks for your response Meaton! if app pause UDP flow more than 10 seconds and we see "Ignoring resume command for flow 3c8faf3c4a9f7 which does not exist" does any property of NEFilterFlow say remoteEndpoint or some other property is set to nil which we can check before invoking resumeFlow call. We have removed monitoring of UDP flow but still we are seeing the issue intermittently. In addition, we have nil check for the flow. Below is the way that we are using to check the flow whether its nil or not before calling resumeFlow if (flow.identifier != nil ) {       [self resumeFlow:flow withVerdict:[NEFilterNewFlowVerdict dropVerdict]]; } But still we can see OS exception in console streaming log and because of this we are thinking that there is delay in opening websites. Here is the OS exception: error 10:46:45.714736+0530 trustd __nwlog_err_simulate_crash simulate crash already simulated "nw_parameters_copy_context called with null parameters" error 10:46:45.715296+0530 trustd nw_parameters_copy_context called with null parameters, dumping backtrace: [x86_64] libnetcore-2750.120.19.0.1 0 libnetwork.dylib 0x00007ff8101bc7f8 __nw_create_backtrace_string + 120 1 libnetwork.dylib 0x00007ff80f9c79aa nw_parameters_copy_context + 250 2 libnetwork.dylib 0x00007ff8100e6658 nw_protocol_ipv4_connected + 88 3 libnetwork.dylib 0x00007ff80fe97ea9 nw_channel_connect + 105 4 libusrtcp.dylib 0x00007ff818d44477 nw_protocol_tcp_connect + 935 5 libnetworkextension.dylib 0x00007ff81c9e1793 ne_filter_protocol_connect + 388 6 libnetworkextension.dylib 0x00007ff81c9e381f ne_filter_process_verdict + 2832 7 libnetworkextension.dylib 0x00007ff81c9eabc6 __ne_filter_data_protocol_send_new_flow_block_invoke.65 + 148 8 libdispatch.dylib 0x00007ff80b73c0cc _dispatch_call_block_and_release + 12 9 libdispatch.dylib 0x000<…> Please check and help us if there is any other way to check whether flow is nil or not before calling resumeFlow API or any other way to avoid such error/exception.

Hi, We have raised bug with sample along with sysdiagnose and system information report and also mentioned exact date and time as requested in bug. Here is the feedback link for more information. [https://feedbackassistant.apple.com/feedback/11357055] Thanks & Regards, Mohmad Vasim

Thanks for your response Meaton! Apologise for delay in response, will check and will share the details here. Thanks & Regards, Mohmad Vasim

I have checked where it was giving BoringSSL error but now with above changes BoringSSL is not getting generated however its stuck in Preparing state itself .

Hi Meaton, So it sounds like you are no longer getting the errors, but the connection cannot setup, correct? Yes, correct. If you use the example.com host / port endpoint that I provided and then the string based HTTP request, does this work? Yes, tried this too and its intermittent, sometime getting null string and sometime incomplete html string. Thanks & Regards, Mohmad Vasim

Hi Meaton, This error looks to me like the flow's nw_paramater_t value is not being set correct when trustd is trying to access it. I would like to update you that its not only happening with trustd, its also happening with other process too. Here are couple of process log that we collected from console streaming: error 10:34:17.607954+0530 com.apple.WebKit.Networking __nwlog_err_simulate_crash simulate crash already simulated "nw_path_copy_flow_registration called with null context" error 10:34:17.608175+0530 com.apple.WebKit.Networking nw_path_copy_flow_registration called with null context, dumping backtrace:         [arm64] libnetcore-2750.120.19.0.1     0   libnetwork.dylib                    0x000000019b292f94 __nw_create_backtrace_string + 192     1   libnetwork.dylib                    0x000000019aad9c84 nw_path_copy_flow_registration + 484     2   libnetwork.dylib                    0x000000019b1b4644 nw_protocol_ipv4_connected + 108     3   libnetwork.dylib                    0x000000019af1dde8 nw_channel_connect + 128     4   libusrtcp.dylib                     0x00000001a3935a18 nw_protocol_tcp_connect + 208     5   libnetworkextension.dylib           0x00000001a7751bbc ne_filter_protocol_connect + 156     6   libnetworkextension.dylib           0x00000001a77537d0 ne_filter_process_verdict + 1632     7   libnetworkextension.dylib           0x00000001a775a1bc __ne_filter_data_protocol_send_new_flow_block_invoke.72 + 160     8   libdispatch.dylib                   0x000000019664a5f0 _dispatch_call_block_and_release + 32     9   libdispatch.dylib                <…> error 10:34:17.615360+0530 nsurlsessiond nw_parameters_copy_context called with null parameters, dumping backtrace:         [arm64] libnetcore-2750.120.19.0.1     0   libnetwork.dylib                    0x000000019b292f94 __nw_create_backtrace_string + 192     1   libnetwork.dylib                    0x000000019a9ef808 nw_parameters_copy_context + 340     2   libnetwork.dylib                    0x000000019b1b4638 nw_protocol_ipv4_connected + 96     3   libnetwork.dylib                    0x000000019af1dde8 nw_channel_connect + 128     4   libusrtcp.dylib                     0x00000001a3935a18 nw_protocol_tcp_connect + 208     5   libnetworkextension.dylib           0x00000001a7751bbc ne_filter_protocol_connect + 156     6   libnetworkextension.dylib           0x00000001a77537d0 ne_filter_process_verdict + 1632     7   libnetworkextension.dylib           0x00000001a775a1bc __ne_filter_data_protocol_send_new_flow_block_invoke.72 + 160     8   libdispatch.dylib                   0x000000019664a5f0 _dispatch_call_block_and_release + 32     9   libdispatch.dylib                   0x0000<…> fault 10:34:17.615843+0530 nsurlsessiond nw_path_copy_flow_registration called with null context error 10:47:42.210335+0530 Sourcetree __nwlog_err_simulate_crash simulate crash already simulated "nw_parameters_copy_context called with null parameters" error 10:47:42.210628+0530 Sourcetree nw_parameters_copy_context called with null parameters, dumping backtrace:         [arm64] libnetcore-2750.120.19.0.1     0   libnetwork.dylib                    0x000000019b292f94 __nw_create_backtrace_string + 192     1   libnetwork.dylib                    0x000000019a9ef808 nw_parameters_copy_context + 340     2   libnetwork.dylib                    0x000000019b1b4638 nw_protocol_ipv4_connected + 96     3   libnetwork.dylib                    0x000000019af1dde8 nw_channel_connect + 128     4   libusrtcp.dylib                     0x00000001a3935a18 nw_protocol_tcp_connect + 208     5   libnetworkextension.dylib           0x00000001a7751bbc ne_filter_protocol_connect + 156     6   libnetworkextension.dylib           0x00000001a77537d0 ne_filter_process_verdict + 1632     7   libnetworkextension.dylib           0x00000001a775a1bc __ne_filter_data_protocol_send_new_flow_block_invoke.72 + 160     8   libdispatch.dylib                   0x000000019664a5f0 _dispatch_call_block_and_release + 32     9   libdispatch.dylib                   0x0000<…> error 10:47:42.210757+0530 Sourcetree __nwlog_err_simulate_crash simulate crash already simulated "nw_path_copy_flow_registration called with null context" error 10:47:42.210993+0530 Sourcetree nw_path_copy_flow_registration called with null context, dumping backtrace:         [arm64] libnetcore-2750.120.19.0.1     0   libnetwork.dylib                    0x000000019b292f94 __nw_create_backtrace_string + 192     1   libnetwork.dylib                    0x000000019aad9c84 nw_path_copy_flow_registration + 484     2   libnetwork.dylib                    0x000000019b1b4644 nw_protocol_ipv4_connected + 108     3   libnetwork.dylib                    0x000000019af1dde8 nw_channel_connect + 128     4   libusrtcp.dylib                     0x00000001a3935a18 nw_protocol_tcp_connect + 208     5   libnetworkextension.dylib           0x00000001a7751bbc ne_filter_protocol_connect + 156     6   libnetworkextension.dylib           0x00000001a77537d0 ne_filter_process_verdict + 1632     7   libnetworkextension.dylib           0x00000001a775a1bc __ne_filter_data_protocol_send_new_flow_block_invoke.72 + 160     8   libdispatch.dylib                   0x000000019664a5f0 _dispatch_call_block_and_release + 32     9   libdispatch.dylib                <…>  Is this flow being altered in any way for a particular path? No, we are not altering flow, we just check whether flow needs to be allowed or block and based on that we call resumeFlow with verdicts. Could you please help us to know if there is any way or API to check whether flow is valid before calling resumeFlow . Another question we have is that, is there any way we can check the state of flow, whether it's in pause state or not. Thanks & Regards, Mohmad Vasim

Thanks for quick response Meaton! with these client connections that are causing __nwlog_err_simulate_crash, are they going away on the client before the provider has a chance to process the NEFilterDataVerdict? it seems Yes. Please see the console streaming log, its getting printed once we call resumeFlow . default 10:34:17.607249+0530 com.xyz.networkapp.systemextension ***: handleNewFlow: id:(81B3B366-F3AF-4BB2-A9FB-E0D8C7BF0F78) After ScanURLScheme host = (api.bitbucket.org) whetherToDrop = (0). and flow is not nil and allowVerdict and invoking resumeFlow call. error 10:34:17.607645+0530 com.apple.WebKit.Networking __nwlog_err_simulate_crash simulate crash already simulated "nw_parameters_copy_context called with null parameters" error 10:34:17.607916+0530 com.apple.WebKit.Networking nw_parameters_copy_context called with null parameters, dumping backtrace:         [arm64] libnetcore-2750.120.19.0.1     0   libnetwork.dylib                    0x000000019b292f94 __nw_create_backtrace_string + 192     1   libnetwork.dylib                    0x000000019a9ef808 nw_parameters_copy_context + 340     2   libnetwork.dylib                    0x000000019b1b4638 nw_protocol_ipv4_connected + 96     3   libnetwork.dylib                    0x000000019af1dde8 nw_channel_connect + 128     4   libusrtcp.dylib                     0x00000001a3935a18 nw_protocol_tcp_connect + 208     5   libnetworkextension.dylib           0x00000001a7751bbc ne_filter_protocol_connect + 156     6   libnetworkextension.dylib           0x00000001a77537d0 ne_filter_process_verdict + 1632     7   libnetworkextension.dylib           0x00000001a775a1bc __ne_filter_data_protocol_send_new_flow_block_invoke.72 + 160     8   libdispatch.dylib                   0x000000019664a5f0 _dispatch_call_block_and_release + 32     9   libdispatch.dylib                   0x0000<…> Thanks & Regards, Mohmad Vasim

Hi Meaton, Are you seeing this behavior for all client request or only certain ones? Once issue generated, we are seeing this behaviour for all client request post that and Internet stops working but after sometime(10 -15 minutes) it gets resumed, browsing start working. No, client is not cancelling the request before provider resume the flow.

Thanks for your response, Meaton! We have opened a Feedback and here is the feedback link - https://feedbackassistant.apple.com/feedback/11523930 and all required details are mentioned in feedback. Thanks & Regards, Mohmad Vasim