wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: Alan Graham <alan@meshify.app>
To: Brad Spencer <bspencer@blackberry.com>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Wintun NeighborDiscoverySupported
Date: Fri, 10 Sep 2021 13:56:31 -0700	[thread overview]
Message-ID: <CAMeHLtwY4Gia=+tkKRYUE4HTz4RGvqwTVSuaxqw9LpVg0yrKTg@mail.gmail.com> (raw)
In-Reply-To: <c84c5f5f-6c47-e109-7592-cd7353761657@blackberry.com>

I mainly reached the conclusion that it's not growing indefinitely by
looking at the results in the arp table.  There weren't duplicates or
other errors which might suggest the arp table wasn't working
properly.  I believe it is, in that it should be aging out entries,
etc.  I also stopped and restarted the wireguard service and it
cleared the cache as it should.

I also noticed the Powershell Cmdlet used the wrong filter parameters
when trying to set NeighborDiscoverySupported, as you did.  My
expectation would be to get an error invalid parameter like with
NeighborUnreachabilityDetection, not that the filter returned zero
results because it used the wrong query.

Best regards,
Alan Graham

On Fri, Sep 10, 2021 at 10:19 AM Brad Spencer <bspencer@blackberry.com> wrote:
> On 2021-09-09 5:23 p.m., Alan Graham wrote:
> > Adding the (or ":::") to the config is what is causing some
> > growth of the arp table, but it is not growing indefinitely.  After
> > looking around for SupportsNeighborDiscovery and finding nothing, I
> > decided to check the repro.  When not routing all traffic through an
> > interface the arp cache is basically static:
> Thanks for looking into this, too.
> I also suspect having the gateway set like this is probably necessary
> for Windows to start adding ARP entries.  How were you able to determine
> that it is also sufficient?  My guess is that if it is possible to
> indicate to Windows that the interface does not support neighbour
> discovery in general, doing so likely prevents ARP entries regardless of
> the gateway values.
> BTW, how did you determine that it does not grow indefinitely?
> > So I tend to agree with Jason that this is "harmless" and shouldn't
> > cause any serious problems.  It would be nice for Microsoft to fix
> > Set-NetIPInterface, it looks like a bug that SupportsNeighborDiscovery
> > can't be set.
> One "harm" might be that the OS keeping an easy-to-query list of all
> (recent?) destinations in the ARP table, which could be undesirable.
> I'm not sure it's a bug, per se.  It seems by design that you cannot
> change the value of SupportsNeighborDiscovery after the interface is
> created.  The documentation for SetIpInterfaceEntry()[1] says:
> > The MaxReassemblySize, MinRouterAdvertisementInterval,
> > MaxRouterAdvertisementInterval , Connected, SupportsWakeUpPatterns,
> > SupportsNeighborDiscovery, SupportsRouterDiscovery, ReachableTime,
> > TransmitOffload, and ReceiveOffload members of the MIB_IPINTERFACE_ROW
> > structure pointed to by the Row are ignored when the
> > SetIpInterfaceEntry function is called. These members are set by the
> > network stack and cannot be changed using the SetIpInterfaceEntry
> > function.
> I noticed that the Cmdlet in PowerShell seems to treat the
> -NeighborDiscoverySupported option as an input filter vs. a value that
> you can set.  While this surprised me, it is at least consistent with
> the Win32 API docs.
> 1.
> https://docs.microsoft.com/en-us/windows/win32/api/netioapi/nf-netioapi-setipinterfaceentry#remarks
> --
> Brad Spencer

      reply	other threads:[~2021-09-10 20:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09 14:32 Brad Spencer
2021-09-09 17:42 ` Jason A. Donenfeld
2021-09-09 18:15   ` Brad Spencer
2021-09-09 20:23     ` Alan Graham
2021-09-10 17:19       ` Brad Spencer
2021-09-10 20:56         ` Alan Graham [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMeHLtwY4Gia=+tkKRYUE4HTz4RGvqwTVSuaxqw9LpVg0yrKTg@mail.gmail.com' \
    --to=alan@meshify.app \
    --cc=Jason@zx2c4.com \
    --cc=bspencer@blackberry.com \
    --cc=wireguard@lists.zx2c4.com \
    --subject='Re: Wintun NeighborDiscoverySupported' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).