Duplicate IP address, and permissions problems on Windows
David Woodhouse
dwmw2 at infradead.org
Sat Apr 10 09:25:38 UTC 2021
On Thu, 2021-04-08 at 10:53 -0700, Daniel Lenski wrote:
> On Thu, Apr 8, 2021 at 9:59 AM David Woodhouse <dwmw2 at infradead.org> wrote:
> > Hm, your description doesn't match the code I see at that link.
> >
> > You're using GetAdaptersAddresses() which gives you the UP/DOWN status
> > as well as the addresses, and you iterate over those. The loop is
> >
> > ∀ adapter, ∀ Unicast address on that adapter:
> > Check if it's our Legacy IP or IPv6 address.
> >
> > That isn't O(n²), is it? It's still O(n) of the total number of unicast
> > addresses in the system?
>
> It's O(n²) the number of unicast addresses, because there's an extra layer…
>
> ∀ adapter, ∀ Unicast address on that adapter (iterating via
> GetAdaptersAddresses)
> 1. Check if it's using our Legacy IP or IPv6 address.
> 2. If yes, then check if the other adapter is UP or non-UP
> 3. If non-UP, then…
> ∀ Unicast address on the system (iterating via
> GetUnicastIpAddressTable(), since the other one maddeningly lacks an
> API to delete addresses)
> 2. If non-UP, then steal/delete/reclaim the desired address from it.
Nah, that doesn't make it O(n²) because anything after step 1 doesn't
actually happen for *every* address. It only happens for the one or two
addresses which match our Legacy IP or IPv6 address. And we *know*
there can be only one match for each because that's the whole point of
this exercise, right?
So it's O(n) for checking all the addresses in the system against our
own address(es), then O(n) for each of up to two addresses that get
matches. O(3n) is still O(n).
And I still think you can fix it just to be O(1n) this way anyway,
can't you:
> > Alternatively, can't we start with GetUnicastIpAddressTable() as my
> > original code did, and if we want to check whether an interface is down
> > before we steal the address from it, use GetIfEntry2() to find out?
> >
> > Using GetIfEntry2() is probably a saner way to find the InterfaceIndex
> > for the Wintun itself, which I was dredging the registry for manually.
> Let's save the OpenConnect-specific decisions, but…
>
> It seems to me that we've identifying a couple of tasks that many
> users of Wintun would need, and which are (in my opinion) quite
> tedious to implement robustly in Windows:
>
> 1. Identifying the “interface index” of the newly-created adapter (for
> use with 'netsh', etc.).
> 2. Reclaiming desired Layer3 (IP) addresses from other non-UP adapters
> to which they may already be assigned.
>
> If the Wintun developers are amenable to it, these both seem like they
> could be useful additions to Wintun itself.
Along with the driver extension to add headroom/tailroom to TUN_PACKET,
I agree. I'd be interested to hear Jason's and Simon's thoughts about
those in principle, before we rephrase those suggestions in the form of
a pull request.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5174 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210410/16beeb09/attachment.bin>
More information about the WireGuard
mailing list