Re: NFS boot fails with ip_output.c rev 1.261 Re: NFS boot fails with ip_output.c rev 1.261

[Rin Okuyama]

On 2016/09/20 23:31, Roy Marples wrote:

Thanks both for testing as I don't have any NFS mounts.
I've just comitted a very slightly modified version of the patch to
improve comments and add increament IPv6 dropped packet stats.


ip_output.c rev 1.263 works just fine for me.
Thank you very much for your fix!

Rin

Re: NFS boot fails with ip_output.c rev 1.261 Re: NFS boot fails with ip_output.c rev 1.261

[Roy Marples]

On 20/09/2016 12:58, Rin Okuyama wrote:
> On 2016/09/17 21:09, Roy Marples wrote:
>> When I first proposed it offlist, we thought the current
>> implementation was the correct thing.
>> Here is a patch to just do as you suggest.
>> http://www.netbsd.org/~roy/ip_output_tentative.patch
>>
>> Can the OP test it and see if NFS booting then works?
> 
> On 2016/09/20 16:15, John D. Baker wrote:
>> I'm not the OP, but applying the patch restores NFS root mounting for
>> me.  I'll test evbmips-mip64el, sparc, macppc, and i386 soon-ish.
> 
> It also works for me on RB800 (powerpc/booke) and ERLITE (evbmips64-eb).

Thanks both for testing as I don't have any NFS mounts.
I've just comitted a very slightly modified version of the patch to
improve comments and add increament IPv6 dropped packet stats.

Roy

Re: NFS boot fails with ip_output.c rev 1.261 Re: NFS boot fails with ip_output.c rev 1.261

[Rin Okuyama]

Sorry for the late reply.

On 2016/09/17 21:09, Roy Marples wrote:

When I first proposed it offlist, we thought the current implementation was the 
correct thing.
Here is a patch to just do as you suggest.
http://www.netbsd.org/~roy/ip_output_tentative.patch

Can the OP test it and see if NFS booting then works?


On 2016/09/20 16:15, John D. Baker wrote:

I'm not the OP, but applying the patch restores NFS root mounting for
me.  I'll test evbmips-mip64el, sparc, macppc, and i386 soon-ish.


It also works for me on RB800 (powerpc/booke) and ERLITE (evbmips64-eb).

Thanks,
Rin

Re: NFS boot fails with ip_output.c rev 1.261 Re: NFS boot fails with ip_output.c rev 1.261 Re: NFS boot fails with ip_output.c rev 1.261 Re: NFS boot fails with ip_output.c rev 1.261

[Michael van Elst]

On Sat, Sep 17, 2016 at 07:45:43PM +0700, Robert Elz wrote:

> The new patch looks like it will probably work (but I don't have
> anything that can or would NFS boot, so I can't test that) but I think
> it would be better to just treat tentative addresses like validated ones
> (just as disabling DAD would do) - that is not test the IFF_TENTATIVE case
> at all.

For IPv6 there is RFC 4429 that describes an 'optimistic DAD'. But IPv4
uses a different DAD mechanism and I haven't found something equivalent
to RFC 4429.


-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: NFS boot fails with ip_output.c rev 1.261 Re: NFS boot fails with ip_output.c rev 1.261 Re: NFS boot fails with ip_output.c rev 1.261 Re: NFS boot fails with ip_output.c rev 1.261

[Robert Elz]

Date:Sat, 17 Sep 2016 13:09:45 +0100
From:Roy Marples 
Message-ID:  


  | > That isn't disabling the IFF_TENTATIVE handling, it is dosabling DAD, 
  | The end result should be the same.

For this purpose (if it were possible to achieve), yes, but disabling
DAD means no verification that the addr is not a duplicate, rather than
just assuming it probably isn't for the interim (and usually being right.)

Certainly if you believe that disabling DAD is acceptable (leading to
unverified addresses) sending from tentative addresses must also be
acceptable, since they're effectively the same thing.

The new patch looks like it will probably work (but I don't have
anything that can or would NFS boot, so I can't test that) but I think
it would be better to just treat tentative addresses like validated ones
(just as disabling DAD would do) - that is not test the IFF_TENTATIVE case
at all.

kre

Re: NFS boot fails with ip_output.c rev 1.261 Re: NFS boot fails with ip_output.c rev 1.261

[Roy Marples]

On 2016-09-17 03:31, Robert Elz wrote:

Date:Fri, 16 Sep 2016 23:37:40 +0100
From:Roy Marples 
Message-ID:  <03a78e8605c842d9d032ee3ed3a59...@mail.marples.name>

  | > The IN_IFF_TENTATIVE handling just breaks lots of old code.
  |
  | You can disable it by setting the appropriate sysctl to zero.
  |
  | $ sysctl -a | grep dad
  | net.inet.ip.dad_count = 3
  | net.inet6.ip6.dad_count = 1

That isn't disabling the IFF_TENTATIVE handling, it is dosabling DAD, 
which

is a different thing entirely.


The end result should be the same.

As I understand it, the reason for the change in 1.261 was to prevent 
sending
from invalid addresses (which is a good thing) - but tentative 
addresses are
not invalid, they just have not been proved valid yet, which is a 
different
thing entirely.   99.9% (or more) of all tentative addresses are valid, 
and
will remain valid, and there's no good reason not to send from them 
(what's
more, it is require that we do so in the case that the same address is 
being
claimed by 2 nodes at the same time - both are performing DAD together, 
in

order for DAD to work properly - the ARP/ND requests must be answered.)

I think I would drop the assumption that tentative addresses are 
invalid,
and just allow sending from them.   But if that isn't done, then UDP 
should
be treated the same as TCP, and packets just "lost" rather than 
returning

a transmit error.


When I first proposed it offlist, we thought the current implementation 
was the correct thing.

Here is a patch to just do as you suggest.
http://www.netbsd.org/~roy/ip_output_tentative.patch

Can the OP test it and see if NFS booting then works?

Roy

Re: NFS boot fails with ip_output.c rev 1.261 Re: NFS boot fails with ip_output.c rev 1.261

[Robert Elz]

Date:Fri, 16 Sep 2016 23:37:40 +0100
From:Roy Marples 
Message-ID:  <03a78e8605c842d9d032ee3ed3a59...@mail.marples.name>

  | > The IN_IFF_TENTATIVE handling just breaks lots of old code.
  | 
  | You can disable it by setting the appropriate sysctl to zero.
  | 
  | $ sysctl -a | grep dad
  | net.inet.ip.dad_count = 3
  | net.inet6.ip6.dad_count = 1

That isn't disabling the IFF_TENTATIVE handling, it is dosabling DAD, which
is a different thing entirely.

As I understand it, the reason for the change in 1.261 was to prevent sending
from invalid addresses (which is a good thing) - but tentative addresses are
not invalid, they just have not been proved valid yet, which is a different
thing entirely.   99.9% (or more) of all tentative addresses are valid, and
will remain valid, and there's no good reason not to send from them (what's
more, it is require that we do so in the case that the same address is being
claimed by 2 nodes at the same time - both are performing DAD together, in
order for DAD to work properly - the ARP/ND requests must be answered.)

I think I would drop the assumption that tentative addresses are invalid,
and just allow sending from them.   But if that isn't done, then UDP should
be treated the same as TCP, and packets just "lost" rather than returning
a transmit error.

kre