Re: nd6_setmtu0: new link MTU on iwn0 (576) is too small for IPv6 which needs 1280

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 3 Dec 2014 14:42:17 -0500
    From:        christos%zoulas.com@localhost (Christos Zoulas)
    Message-ID:  <20141203194217.A406717FDA3%rebar.astron.com@localhost>

  | Perhaps we should ask kre@ for his patch, or recreate it.

If there is serious interest, I could update it (whatever is required)
to match current as it is now (that thing was done years ago, certainly
no more recent that NetBSD 5 - might have been 4) and send it.

There would be two possibilities - a fairly simple patch that just
disables a protocol stack, or a slightly more complicated one that
allows more selective disabling of protocol functions - it would be
interesting to know which would be preferred (if any).

That being said, I doubt that disabling IPv6 would have any effect at
all on the problem in question (other than the console noise, of course) - it
just happens (as it does in some other cases) that IPv6 makes noise when it
discovers something odd.  That noise doesn't cause (much of) a problem - and
if other things were working, would probably just be ignored.   It isn't
causing the other failures, and disabling it is very unlikely to fix them,
there is some other problem.

Second, I doubt that disabling PMTUD on the NetBSD host will fix anything
either - even though the symptoms suggest a PMTUD problem.   If NetBSD
(for whatever reason) believes that the MTU is 576, then it won't be
sending bigger packets than that, and doesn't need PMTUD to be working
to discover that.   On the other hand, when the peer sends packets, it
is probably attempting to send larger than 576 - if the MTU on your local
link has somehow been reduced to 576, and if the peer is using PMTUD, then
the peer needs it to work (for the ICMP packets to be transmitted, and not
filtered).   That is, if you wanted to test disabling PMTUD to see if
that works around the other problem, it would be on the peer that you'd
need to do it, not on your local system.

If it is just your NetBSD that believes the MTU is 576, and it is
rejecting incoming frames bigger than that, then disabling PMTUD won't
help wherever it is done - the NetBSD host wouldn't be attempting to
send any ICMP message - the frame is dropped at the link layer, ICMP
is only ever sent if the packet makes it to the IP layer, which wouldn't
be happening.  This should only occur if the local router (and/or other
local hosts) believe that the MTU on the link is bigger than the NetBSD
host believes - this value needs to be consistent for everything on the
link.

For the lowering of the MTU, look at DHCP - dhcpcd has been known to
lower the MTU when it gets told by the server to do so.  A DHCP server
sending mtu=576 would not amaze me at all - you can config dhcpcd to
ignore that option, and leave the MTU alone I believe, but better would be
to change the DHCP server (whatever that is in your case) to not send
such a low value (or not send any value at all).

The only relationship with wpa_supplicant is likely to be that after the
supplicant gets the link attached, dhcp immediately runs to get an IP
address - usually all this happens so quickly that it can appear as if
wpa_supplicant is doing things that dhcpcd is really doing.

kre