Hi, On Wed, Oct 17, 2018 at 8:07 AM Gert Doering <g...@greenie.muc.de> wrote:
> Hi, > > On Tue, Oct 16, 2018 at 05:48:29PM -0400, Selva Nair wrote: > > Going through patchworks noticed this. > > > > Thankfully this never got committed so here goes a retraction. > > > > On Sun, Jan 21, 2018 at 1:45 PM Selva Nair <selva.n...@gmail.com> wrote: > > > > > Hi, > > > > > > I'm on a reviewing spree (doing my penance), so here goes.. > > > > > > Thanks for the patch > > > > > > On Tue, Jan 9, 2018 at 2:16 AM, Eyal Birger <eyal.bir...@gmail.com> > wrote: > > > > Address prefix length defaults to /64 on Windows. This change allows > > > using > > > > Windows clients in setups that use a different prefix length. > > I had this on "I need to do more testing with this", which is why it > never proceeded - there might be unintended side effects, so I wanted > to do more detailed testing with "netsh" and with "iservice" backends, > and different prefix lengths etc. > > Also, I had the suspicion that if we actually set a prefix length, it > will lead to local ND traffic which the tap driver won't answer (it > will only answer fe80::8) thus causing a "black hole route" for the > tap subnet... > Aha, that explains why it lingered in that state for long :) However, we do currently set the prefix-length while using the service (that->netbits_ipv6 is passed as prefix_len to the ip helper API), don't we? Selva
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
