- "nsiproxy.sys: Only enumerate active routes in ipv6_forward_enumerate_all() on Linux.": a trigger for that patch was some route present here in /proc/net/ipv6_route: ``` 00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 00000000 00200200 lo ``` This is a route on loopback interface with metric 0xffffffff with network mask suggesting default route. That breaks forward table matching. I am not sure what this is for and where it comes from but this route doesn't have RTF_UP flag. I guess we should not enumerate any routes without RTF_UP, we don't seem to have an obvious way to return "non-up" routes in forward table;
- "nsiproxy.sys: Improve loopback detection in ipv6_forward_enumerate_all() on Linux.": the current logic never correctly flags loopback interface (due to erroneous prefix_len == 32 check); checking for MIB_IPPROTO_LOCAL also looks arbitrary to me. There is just one loopback reserved address for IPv6, I guess we may safely check the prefix address;
- "iphlpapi: Fully zero init address in unicast_row_fill().": currently there are some garbage values in the part of the address structure in the unicast address table; that was breaking my tests comparing addresses with memcmp() (while that works on Windows);
- "iphlpapi: Try to disambiguate addresses in GetBestRoute2() ...": that matters only in case of more complex network configurations when there are multiple source addresses attached to interfaces or multiple network interfaces advertising overlapping forward rules. That can easily configured at least on Linux. Linux has, e. g, explicit preferred source address in ip route table (for which I am not immediately finding a way to relay that through NSI tables). Resolving overlapping destination ambiguity is also complicated (and might probably be implementation specific). When there is a choice we should ideally return the route which matches what the underlying system would actually decide to use, so probing through a socket looks most straightforward to me. In case of any errors on that path it will fallback to finding some route based purely on the NSI forward and unicast tables.
There is also GetBestRoute() which is already implemented and which I didn't touch. It is not immediately straightforward to use GetBestRoute2() from it because it returns (and probably is based on) MIB_IPFORWARD_TABLE (vs MIB_IPFORWARD_TABLE2 in GetBestRoute2). There is seemingly no one to one correspondence between the two. While we have a test which suggests that number of entires in the two tables (in testGetIpForwardTable) is the same that test fails on up to date Windows 11 for me (the actual number of entires is different). So I left GetBestRoute() untouched for now.