User Profile

I've noticed that the OS stops consulting the VPN extension for DNS after a delayed response.We want to use split-tunnel, but handle all of the DNS. We have our DNS settings for our Packet Tunnel Provider set as described here:https://forums.developer.apple.com/message/122209#122209With an empty match domain. That works Ok, but if we receive any significantly (~3 seconds) delayed response to a DNS query the OS starts sending all DNS queries out the wireless interface instead of over the VPN.It doesn't try again right away, but continues to use the wireless interface instead of the VPN interface. It will try again at intervals and things can recover, but this causes serious issues for the VPN.Does anyone know of a way to tweak the settings that determine when the system falls back to the system DNS resoluton instead of the VPN DNS resolution, and how it retries?We have to support macOS versions older than 10.15, so we can't use the DNS proxy provider.Kevin

I have an XCTest case which is trying to enter text into a text field.let app = XCUIApplication() let query = app.tables query.staticTexts[“New..."].tap() let serverAddress = query.cells.containing(.cell, identifier:"serverTableViewCell").textFields.element if serverAddress.exists { serverAddress.tap() serverAddress.typeText(server) }This has to run on a physical device, because the application is a Network Extension VPN.It generally works fine, but every now and then it starts failing. When it fails everything looks like it's succeeding.I can find the fieldI can tap on the field, and I see the text cursorI can call typeText()No errors, messages, informative output... But nothing appears in the text field.This appears to happen after there's been some sort of system dialog on the device (not entirely sure it's related, but the correlation is strong) but even once that dialog is gone the test continues to fail.Things are complicated because the device is in the office--and we aren't allowed to go into the office at the moment. I can't re-start the device, because I'm pretty sure that will require physical presence at the device to unlock it again.I *can* alter settings on the device using teh XCTest interfaces to control System Settings. I tried disabling all notifications, but things are still failing.I saw a similar question with the same symptoms, but it was on a simulator, and the solution was to reset the simulator. Not an option in this case: https://forums.developer.apple.com/thread/125010Is it possible that once the system dialog/alert/notification is apparently gone that it's still hogging keyboard input? If that is the case, anyone know how I could clear it? Without being physically present at the device?Any other suggestions would be great.

We have a case where we need to send, and receive, an ICMP packet from a Network Extension. Not *tunnel* an ICMP packet--that works fine--but send an ICMP packet from the NE that's not going through the tunnel.The send is fine. I create a datagram socket with a protocol of IPPROTO_ICMP, and I can send the ICMP packet. I see it on the wire, I see the response on the wire.When I call recvfrom() on the socket I get a permission error. I can see that there are 84 bytes waiting to be read, but I can't read them... Same fd I just sent from.I tried binding the socket, but get a permission error when I try to bind(). I've tried bind() with address set to 0, INADDR_ANY, and to the local physical address, always a permission error.Is the problem the lack of bind()? If so, does anyone have an idea about why bind() might be failing?If the problem isn't lack of bind(), does anyone have an idea what could be happening here? Could it be a limitation on what can be done from a Network Extension?

I'm seeing a crash in applicationWillFinishLaunching on Catalina when I attempt to debug one of our apps.It happens with Xcode 10.2 and with the Xcode 11 beta. It doesn't happen on earlier versions of macOS.This is what appears to cause it:SetSystemUIMode(kUIModeNormal, 0);But if I comment that out I get a crash in NSApplicationMain,so there's probably some deeper problem. If I build the application and run it outside the debugger it works (except for a problem I raised in another thread).This happens with both Xcode 10.2 and with the Xcode 11 beta, so it appears to be some interaction between Xcode and the OS.Has anyone been running into this? Any ideas?Kevin

On Mojave & earlier our NE VPN works fine. On Catalina the VPN starts, and traffic is being tunneled, but the sendProviderMessage:messageData:returnErr:ResponseHandler: method isn't working.- I don't get back an error on the call- I do get back nil for the data in the response handler- I don't see a call to the extension's handleAppMessage:completionHandler: entry point.Has anyone else been seeing this? I haven't seen anything from Apple yet about changes to the NE framework.

I asked this over in Networking and was pointed here as a more likely plae to find an answer.We see that the TLS handshake for Safari connections is sending different sets of ciphers in the CLIENT_HELLO message for connections to the same URL from the same device.Sometimes the set of cipher suites doesn't include the ciphers accepted by the back end server and sometimes it does. This shows up to the user as intermittent connection failures.So why isn't the handshake always sending the same list of cipher suites? I can sort of imagine that the system is doing some arcane calculation about what cipher suites to send in the CLIENT_HELLO for a particular URL, but I'd expect the result to always be the same for that URL.There's a post in the community forums about a similar (but not quite the same) issue which didn't get any real answer: Safari sends different list of supported ciphers for two URLs on the same domainIn that case it was different URLs, in this case it's the exact same URL.We're seeing this on iOS 12, and it appears to also be happening on iOS 11. Haven't checked earlier versions yet. It happens on both iPad and iPhone.For example, here are two sets of cipher suites for two sequential connections to the same back end server. These are sequential connections (no other traffic from the device between these two connections). Both handshakes succeeded in this example, so why different cipher suites?:Cipher Suites (14 suites) Cipher Suite: Unknown (0x5a5a) Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)Cipher Suites (22 suites) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

We see that the TLS handshake is sending different sets of ciphers in the CLIENT_HELLO message for connections to the same URL from the same device.Sometimes the set of cipher suites doesn't include the ciphers accepted by the back end server and sometimes it does. This shows up to the user as intermittent connection failures that users are blaming on the server.So why isn't teh handshake always sending the same list of cipher suites? I can sort of imagine that the system is doing some arcane calculation about what cipher suites to send in the CLIENT_HELLO for a particular URL, but I'd expect the result to always be the same for that URL.There's a post in the community forums about a similar (but not quite the same) issue which didn't get any real answer: Safari sends different list of supported ciphers for two URLs on the same domainIn that case it was different URLs, in this case it's the exact same URL.We're seeing this on iOS 12, and it appears to also be happening on iOS 11. Haven't checked earlier versions yet. It happens on both iPad and iPhone.Kevin