Is there an answer in another thread, or is this just being ignored? With remote work requirements due to the pandemic this is a big issue for us. We don't have someone there to physically check the device a couple of times a day.

Hi Matt. We're not gathering configuration information when we see the error message I included. That's when we're trying to open the actual VPN connection to the Gateway. How are we supposed to open the socket that's going to carry the gateway traffic in this case? That is, what Network Extension calls need to be completed before it will let us communicate with the Gateway? Kevin

includeAllNetworks covers a lot more than setting the default route. We need the extra assurance that all traffic will be handled, and that the tunnel won't leak. Defining it at config definition time is a pain, but I can work around that. The main issue I see at this point is that when I define includeAllNetworks and it takes effect, I can no longer connect to the gateway, even by IP address.

This happens when I try a connection using raw BSD socket() calls as well. What am I missing here?

The main problem is UI testing with XCTest, although it also happens with plain debugging. I've set a symbolic breakpoint on NSApplicationMain, and am runniing process handle -s false SIGCONT with an automatic continue. It works the first time, but if I stop and re-run the application it will occasionally still break with a SIGCONT, which is a little odd. Much, much, less frequent though.

Well, if I set process handle -s false SIGCONT At application load, then the test continues without entering the debugger. That doesn't help by itself because it still requires manual intervention at multiple points during the test suite. I haven't found any good documentation on custom LLDB settings, especially settings that take effect after the process is running. I've verified that .lldbinit is read on start of the testing and again when the process enters the SIGCONT break point. The problem is that the process handle . . . command is target-specific, and can't be run without a target. Even when breaking for SIGCONT I get an error about an invalid target for that command. Is there any documentation on how to override LLDB behavior from a configuration file, including commands which only take effect in a specific process? For example "when LLDB attaches to a target do X". A way to change global LLDB behavior would also be good if one exists.

For example, with debug & info logging on we see a lot of activity related to the VPN extension (1,2,3,5 for example), but in this case the log entry on line 21 at 00:05:05.631066+0530 is the last reference we see to the VPN extension. No further information in the log, and it's apparently unloaded. We see that it's written to our log file, and that it's been doing things on the network, then it's just... gone. No crash, no other messages. info 00:05:05.625658+0530 VPNExtension nw_endpoint_flow_setup_protocols [C1.1 IPv4#56bf189d:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en0, ipv4, dns)] setup flow id FA94FBB5-6CF0-4974-854F-D52073CD57DB\ debug 00:05:05.625719+0530 VPNExtension nw_endpoint_flow_attach_protocols [C1.1 IPv4#56bf189d:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en0, ipv4, dns)]\ debug 00:05:05.625817+0530 VPNExtension nw_endpoint_flow_attach_protocols_block_invoke [C1.1 IPv4#56bf189d:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en0, ipv4, dns)] Attached application protocol: CFNetworkConnection-3468823992\ debug 00:05:05.628068+0530 syspolicyd choosing ^.* (1,0x0)\ debug 00:05:05.626591+0530 VPNExtension nw_endpoint_flow_attach_protocols_block_invoke [C1.1 IPv4#56bf189d:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en0, ipv4, dns)] Attached application protocol: tls\ debug 00:05:05.628211+0530 syspolicyd open(/Applications/Linphone.app/Contents/Resources/lib/pango/1.8.0/modules/pango-indic-lang.so,0x0,0x1b6) = 21\ default 00:05:05.626090+0530 mDNSResponder [R1747->Q12734] AnswerQuestionByFollowingCNAME: 0x7f8581022c60 <mask.hash: 'Tye7PNEDcRS8vCdYY7aIwQ=='> (HTTPS) following CNAME referral 0 for <mask.hash: 'xOOjGbd0MZFsgiiKyCIgGg=='>\ debug 00:05:05.628257+0530 syspolicyd 21 fcntl(48,0x1) = 0\ default 00:05:05.626158+0530 mDNSResponder [R1747->Q48033] Question for <mask.hash: 'wPu924/4LYJ1WNVfDCsVAQ=='> (HTTPS) assigned DNS service 5\ default 00:05:05.626240+0530 mDNSResponder [R1747->Q26989] AnswerQuestionByFollowingCNAME: 0x7f858100d800 <mask.hash: 'Tye7PNEDcRS8vCdYY7aIwQ=='> (Addr) following CNAME referral 0 for <mask.hash: 'xOOjGbd0MZFsgiiKyCIgGg=='>\ default 00:05:05.626291+0530 mDNSResponder [Q26989] Keeping orphaned querier for up to 5 seconds\ default 00:05:05.626410+0530 mDNSResponder [Q26989] Received acceptable 138-byte response from <IPv4:BBJscklP> over UDP via en0/4 -- id: 0x297C (10620), flags: 0x8180 (R/Query, RD, RA, NoError), counts: 1/2/0/0, BBpqXFvf IN A?, 13 IN CNAME BBHoWxpi, 9 IN A BBLOAuUq\ default 00:05:05.626619+0530 mDNSResponder [R1747->Q12298] Question for <mask.hash: 'wPu924/4LYJ1WNVfDCsVAQ=='> (Addr) assigned DNS service 5\ debug 00:05:05.629787+0530 syspolicyd 21 end of data\ debug 00:05:05.630037+0530 syspolicyd close(21) err: 0\ debug 00:05:05.630111+0530 syspolicyd Resources/lib/pango/1.8.0/modules/pango-indic-lang.so added simple (rule 0x7ff149432610)\ debug 00:05:05.630162+0530 syspolicyd file /Applications/Linphone.app/Contents/Resources/lib/pango/1.8.0/modules/pango-basic-fc.so\ debug 00:05:05.630208+0530 syspolicyd test Resources/lib/pango/1.8.0/modules/pango-basic-fc.so\ default 00:05:05.630497+0530 mDNSResponder [R1747->Q48033] getaddrinfo result -- event: add, ifindex: 0, name: <mask.hash: 'wPu924/4LYJ1WNVfDCsVAQ=='>, type: HTTPS, rdata: <none> (mortal)\ debug 00:05:05.630250+0530 syspolicyd try ^MacOS/Linphone$ default 00:05:05.631066+0530 kernel memorystatus: assertion priority 14 overrides priority 0 for VPNExtension:11870\ debug 00:05:05.632297+0530 powerd Global levels set to 0x1\ info 00:05:05.628648+0530 mDNSResponder [Q26989] Querier concluded -- reason: response\ debug 00:05:05.632371+0530 powerd getUserInactiveDuration: rdActive:1 hidActive:1 assertionActivityValid:1 now:0x55a4a&#9;hid_ts:0x559e4 assertion_ts:0x55a4a\

Hi Matt. I see the initial steps (manually allowing app to run), but once it's approved we can see that the binary is loaded The class initializer for PacketTunnelProvider runs. There's log output from the class initializer, so we know that the VPN extension has been loaded successfully The entry point (startTunnelWithOptions:completionHandler:) is never called The VPN extension exits There's no crash log I'd think that a signing problem would result in the binary not being loaded, right?

Well, I still don't know why I wasn't seeing the cookies properly in the response I was tracing, but it looks like my case is Ok at this point. There was also a redirect issue, where the URLSession was following redirects because I wasn't returning the right value from     func urlSession(_ session: URLSession,                     task: URLSessionTask,                     willPerformHTTPRedirection response: HTTPURLResponse,                     newRequest request: URLRequest, completionHandler: @escaping (URLRequest?) -> Void) When I broke in that function to see what was going on I saw all of the cookies... The "Set-Cookie" value was an array of header values, and when I blocked the redirects I started seeing the correctly formatted Set-Cookie in the HTTPURLResponse. So although I don't know why the behavior was wrong in the first case I was seeing, the case I need it OK.

There appear to be some problems with that. Is there any sample code that demonstrates the transition from URLSessionDataTask to URLSessionStreamTask with reads & writes afterwards? What I'm seeing is that in     func urlSession(_ session: URLSession,                     dataTask: URLSessionDataTask,                     didBecome streamTask: URLSessionStreamTask) everything looks fine. Stream task is suspended initially. I call resume() on the stream task. That seems to be Ok. But, when I try to call func readData(ofMinLength minBytes: Int, &#9;&#9;maxLength maxBytes: Int, &#9;&#9;&#9;timeout: TimeInterval, completionHandler: @escaping (Data?, Bool, Error?) -> Void) on that task I immediately see a call to func urlSession(_ session: URLSession, readClosedFor streamTask: URLSessionStreamTask) In that delegate call I see that the task is now in the NSURLSessionTaskStateRunning state, with nothing pending, but according to the docs it looks like that call means no more reads can be done. Similarly when I call: func write(_ data: Data, &#9; timeout: TimeInterval, completionHandler: @escaping (Error?) -> Void) it never returns, and no data is written. Looking at network traces on the peer, everything looks normal--it just doesn't see any more traffic.

The Feedback number is FB8895731

Thanks Quinn. That looks like what I needed. I'll check it out.

Yes, I've seen the list. No, there's no feedback #. Back at the beginning of the beta I read that some things would continue to be enabled during the beta, so I didn't think it odd that the KEXT still loaded. We don't use a lot of calls to the sock_* interfaces--we're basically an interface filter--but for example we do use: sock_socket(PF_SYSTEM, SOCK_RAW, SYSPROTO_EVENT, . . .) to open a system control socket. Works fine. Expected behavior if not supported: KEXT fails to load. Actual behavior: KEXT loads & runs. I'll see about filing feedback from one of the beta systems.

Once upon a time, in the long ago when the app was just coming into being, a plist value was set that told the OS that it was an agent app. It shouldn’t normally be visible, and we didn’t want a dock icon for it. Eons later, when there were bugs filed about the lack of a dock item, the problem was fixed not by removing that plist value but by adding code that forced a dock icon, and forced the app to the foreground. A side effect of this code was that the menus were not usable until the app went to the background and came back the to foreground. So basically removing the LSUIElement value and all the extra code above fixed the issue. I think that whoever added the code was unaware that it was the plist value causing the problem in the first place.

main.m is the same also. Calls NSApplicationMain(argc,argv) to kick things off.