Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53175
Commit 910d58520a6d75cada82d992757ca013099d9345 (iphlpapi: Return ERROR_NO_DATA from GetIpNetTable() if no entries are found.) introduced a regression in Roon application. It looks like the app doesn't tolerate an error return from GetIpNetTable() if there are active interfaces found. The blamed patch still looks correct to me per se, that is, if number of entries ends up being zero Windows returns ERROR_NO_DATA. However, number of entries is never zero on Windows if there is any network adapter.
There are two things why Windows always has some arp entries and we do not: 1. We currently parse /proc/net/arp line on Linux a bit wrong and end up getting no entries from there (patch 1 fixes that); 2. With the patch patch 1 there Roon seems happy (at least as far as I could test it right at start), at least as long we have an entry in /proc/sys/net (which might not be necessarily the case if there is, e. g., no actual network connection). But that breaks SCP: Secret Laboratory again the same way as before 910d58520a6d75cada82d992757ca013099d9345. It turns out the latter game depends on GetIpNetTable() returning at least 4 entries when returning success (for some reason, I am not sure why but I think I saw that quite clearly). And both apps can actually work reliably on Windows as there are always at least 4 static arp entries if there is any network adaptere configured at all.
There are "224.0.0.22" and "239.255.255.250" static arp multicast entries which are always there for any interface on Windows, including loopback (starting from Win10; earlier versions might be missing "239.255.255.250" but have "224.0.0.22"). So adding those like on Windows should hopefully fix all those cases.
-- v3: iphlpapi: Sort by adapter index first in GetIpNetTable(). iphlpapi: Correctly index dynamic data array. nsiproxy.sys: Strip trailing end of line for iface name on Linux.