On Mon Apr 6 18:49:26 2026 +0000, Nikolai Abdusamatov wrote:
Regarding your question about interfaces: `gif0` and `stf0` are macOS tunnel interfaces (Generic Tunnel and 6to4). The `utun*` interfaces are used by macOS for system and third-party VPNs. These are macOS-specific interfaces that don't exist in Windows (as far as I can tell). Filtering them out in `nsiproxy.sys` would make the list of adapters more similar to what Windows would return on equivalent hardware, and would also reduce the likelihood that applications would encounter buffer size issues, given the typical number of adapters in Windows. I also considered filtering out these macOS-specific interfaces in `nsiproxy.sys`, but couldn’t find a reliable way to identify them. Hard-coding interface names such as gif0, stf0, and utun seems unreliable, and I don’t know of a better macOS-specific attribute that could be used. Maybe someone knows of one? I found a reliable way to identify these interfaces without hardcoding names, using `getifaddrs()` with `AF_LINK` to obtain BSD-level attributes: `sdl_type` from `sockaddr_dl` and `ifa_flags`. This identifies the problematic interfaces precisely:
* `gif0` → `IFT_GIF`: macOS generic tunnel interface, no Windows equivalent, no MAC address * `stf0` → `IFT_STF`: macOS 6-to-4 tunnel interface, no Windows equivalent, no MAC address * `utun*` → `IFT_OTHER` with `IFF_POINTOPOINT`: macOS userspace tunnel used for system and third-party VPNs, no Windows equivalent, no MAC address These macOS-specific interfaces inflate the NSI adapter table, which causes `GetAdaptersInfo` callers with fixed-size buffers to overflow and receive empty MAC addresses. The issue reproduces regardless of whether WireGuard or any other VPN is active — macOS creates `utun` interfaces unconditionally for system use. Testing was done against a local server, so IP-based rejections are ruled out; the empty MAC is the sole cause of the connection failure. Regarding Windows testing: I don't have a working Windows setup to test equivalent conditions (multiple adapters, VPN active). However, I'm not aware of any reports of this empty-MAC issue from Windows users, even those using VPN — which suggests the problem is macOS-specific and caused by these interfaces being present in the list. I’ll also attach some logs, such as the table of adapters and related information in `macOS_network_interfaces_(AF_LINK).md`, and `netdiag-compare.txt`, which compares the patch with the clean repository and shows how it removes unnecessary macOS-specific adapters, thereby fitting within the required buffer. [netdiag-compare.txt](/uploads/8c9c8b4b65dea31bef8197b1037868a8/netdiag-compare.txt) [macOS_network_interfaces\_(AF_LINK).md](/uploads/96d765b7fc2669d4fc24e3e4fdd7f761/macOS_network_interfaces__AF_LINK_.md) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10553#note_135917