[PATCH 0/1] MR10553: iphlpapi: Prefer adapters with valid MAC in GetAdaptersInfo.

[Nikolai Abdusamatov (＠n-abdusamatov)]

### What this changes

- Adds a MAC validity predicate for adapter entries.
- In GetAdaptersInfo, counts adapters with valid physical MAC.
- If valid adapters exist, excludes entries with invalid MAC from returned list.

### Why

On macOS, pseudo interfaces without usable physical address can appear before real hardware adapters. Legacy clients that pick the first adapter may send empty MAC and fail auth.

### Scope

- Module: iphlpapi
- API path: GetAdaptersInfo
- Platform impact: mainly macOS-like interface layouts with pseudo/tunnel adapters exposed early.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59614

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/10553

[PATCH 1/1] iphlpapi: Prefer adapters with valid MAC in GetAdaptersInfo.

[Nikolai Abdusamatov]

From: Nikolai Abdusamatov <[e-mail]>

On macOS, pseudo/tunnel interfaces may be returned before hardware interfaces
and can have empty or all-zero physical addresses. Applications that rely on
GetAdaptersInfo and first-adapter heuristics may propagate an empty MAC and
fail authentication.

When at least one adapter has a valid physical address, filter out entries with
invalid MAC in GetAdaptersInfo enumeration so first returned entries are usable.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59614
---
 dlls/iphlpapi/iphlpapi_main.c | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/dlls/iphlpapi/iphlpapi_main.c b/dlls/iphlpapi/iphlpapi_main.c
index fe2de41c4a3..b9a50bad885 100644
--- a/dlls/iphlpapi/iphlpapi_main.c
+++ b/dlls/iphlpapi/iphlpapi_main.c
@@ -585,6 +585,21 @@ static void ip_addr_string_init( IP_ADDR_STRING *s, const IN_ADDR *addr, const I
     s->Context = ctxt;
 }
 
+static BOOL mac_address_is_zero( const BYTE *addr, ULONG len )
+{
+    ULONG i;
+
+    for (i = 0; i < len; i++) if (addr[i]) return FALSE;
+    return TRUE;
+}
+
+static BOOL adapter_has_valid_mac( const struct nsi_ndis_ifinfo_rw *rw, ULONG max_len )
+{
+    return rw->phys_addr.Length > 0 &&
+           rw->phys_addr.Length <= max_len &&
+           !mac_address_is_zero( rw->phys_addr.Address, rw->phys_addr.Length );
+}
+
 /******************************************************************
  *    GetAdaptersInfo (IPHLPAPI.@)
  *
@@ -596,7 +611,7 @@ static void ip_addr_string_init( IP_ADDR_STRING *s, const IN_ADDR *addr, const I
  */
 DWORD WINAPI GetAdaptersInfo( IP_ADAPTER_INFO *info, ULONG *size )
 {
-    DWORD err, if_count, if_num = 0, uni_count, fwd_count, needed, wins_server_count;
+    DWORD err, if_count, if_num = 0, if_num_valid = 0, uni_count, fwd_count, needed, wins_server_count;
     DWORD len, i, uni, fwd;
     NET_LUID *if_keys = NULL;
     struct nsi_ndis_ifinfo_rw *if_rw = NULL;
@@ -620,8 +635,12 @@ DWORD WINAPI GetAdaptersInfo( IP_ADAPTER_INFO *info, ULONG *size )
     {
         if (if_stat[i].type == IF_TYPE_SOFTWARE_LOOPBACK) continue;
         if_num++;
+        if (adapter_has_valid_mac( &if_rw[i], sizeof(info->Address) ))
+            if_num_valid++;
     }
 
+    if (if_num_valid) if_num = if_num_valid;
+
     if (!if_num)
     {
         err = ERROR_NO_DATA;
@@ -655,6 +674,8 @@ DWORD WINAPI GetAdaptersInfo( IP_ADAPTER_INFO *info, ULONG *size )
     for (i = 0; i < if_count; i++)
     {
         if (if_stat[i].type == IF_TYPE_SOFTWARE_LOOPBACK) continue;
+        if (if_num_valid && !adapter_has_valid_mac( &if_rw[i], sizeof(info->Address) ))
+            continue;
 
         info->Next = info + 1;
         info->ComboIndex = 0;
-- 
GitLab

https://gitlab.winehq.org/wine/wine/-/merge_requests/10553

[Paul Gofman (＠gofman)]

Won't that filter out loopback adapters? Also, I have wireguard interface here, it also doesn't have MAC address, maybe there are more cases.

Such sort of filtering, if done correctly, should be performed in nsiproxy.sys and not in iphlpapi. I hope there should be a better way to detect the adapters we are not interested in (possibly Mac specific, there is a lot of Mac specific handling in nsirpoxy.sys). Another possibility is that those pseudo adapters should not be filtered out but maybe instead sorted properly so they don't appear first. This should be confirmed on Windows how such pseudo adapters looks like and if that is the sort order and not their presence which is actually different from Windows.

If there is no obvious difference another potential possibility is that the affected app is also broken on Windows if VPN adapters are present and we don't have anything to fix here.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/10553#note_134955