Ah ha! Ok, that makes sense.

The responses do not have to come from the destinations. Consider, if you will, a UDP-based bit-torrent service: you send a datagram to one particular node, saying "gimme this file." That node then broadcasts that around. You then start getting datagrams from thousands of different nodes, none of which you'd actually sent a message to in the first place. That is only possible if the application did not use connect(). If, however, the application did use connect()... then it should only get responses from that particular node. How is the transparent proxy supposed to be able to tell what the application is expecting?

Interestingly, I don't have that method -- both TCP and UDP flows come via handleNewFlow(_:) (since that's the one the documentation says to override; I'll try overriding that one and see what happens). The local endpoint is, as far as I can tell, always filled out with the hostname being the interface's IP address, and port being 0. I wrote a small program to open two UDP sockets and connect one, and that did not provide any difference in behaviour that I could see -- I did that before asking. 😄

I get the same results with both overridden methods -- many things have a local port of 0, but some have been bound. eg 2023-03-20 09:39:59.799074+0000 0x16431f5 Debug 0x0 71647 0 com.kithrup.NETest.NETestTunnel: [com.kithrup:NETestTuennel] Got UDP Flow UDP io.tailscale.ipn.macos.network-extension[{length = 20, bytes = 0x9aa36e7f0ce1e8c94d16d312b51d6b8820b52ff4}] local port 52711 interface en0(bound) remoteHostName <none> localEndpoint 192.168.1.58:52711

(Ok, I found librproc.h but that seems ... questionable, so is there a less questionable way?)

FYI, I had filed FB12006678 a while back, and just updated it to mention this issue as well.

Weird, I don't get notifications for comments, only replies. For various reasons, we have our own WKWebView window for authentication. We'd like to be able to support yubikeys et al. However... it doesn't look like that's actually possible? Because the WebAuthN support is only provided to full web browsers (and, on macOS [which is all I care about for now 😄], only for the user's default web browser)? As for what we're seeing, when trying to use a Yubikey, our WKWebView window, which is loaded with a google URL, says that it's not supported.

See below, hopefully it's clearer?

As I said, for various reasons, we're using our own window for it. This seems to match my conclusion that we can't do it, yes? Thanks. 😄

As I said: I added code to the containing app to periodically try to communicate with the extension, and if it can't, it then unloads and reloads it. This does fix it -- at the cost of having multiple GUI prompts.

My best guess is that launchd is confused about something, and can't map the name to the right port. Unloading the extension and reloading it causes launchd to reset the port, and thus seems to fix it. So simply stopping doesn't do the trick. I've had no responses on my FB. Perhaps filing new ones and referencing mine might help?

Dual-booting isn't largely effective for me -- as I said, I don't have spare machines as I'm used to having, so the ones I have are dedicated to various purposes. However! I found the problem! The problem is... VMware just doesn't care about macOS it seems. Parallels, on the other hand, was able to create a VM for me for both Intel Silicon and Apple Silicon. Which means I'll be buying a license for it and using my Mac Pro harder now. And... now I have a justification for getting a Mac Studio... 😄

Yes, after a year we got it, and are now distributing and it is AWESOME and there is nothing as fun as debugging an ESF-using process and getting distracted for a few minutes. 😄

Created by us, using the 3rd party libevent library, as well as a few others.

Yes, I'm not sure where the thread creation code is. Traditionally, I might use dtrace to look at fork and vfork, would bsdthread_create be sufficient here? I could possibly set a breakpoint & log command in pthread_create? There doesn't seem to be an Instrument for checking when thread creation and exit happens.