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:        Thu, 4 Dec 2014 09:08:15 +0000
    From:        Ottavio Caruso <ottavio2006-netbsd%yahoo.com@localhost>
    Message-ID:  <CAEJNuHwRtL-iUV=9yH6zu8KkeANjK_icgjVs+xjsNKTnwpfvRw%mail.gmail.com@localhost>

  | Nothing strange and no mention of mtu in the dump file:
  | 
  | # tcpdump -s1500 -i iwn0 -w /tmp/dump.txt
  | # tcpdump -r /tmp/dump.txt >>/tmp/dump.readable.txt
  | # grep -i mtu /tmp/dump.readable.txt

You won't find it that easily, tcpdump isn't that smart.  You'll need
to actually look at the dump, find where the interface is

  | > Try ip6mode=none.
  | /etc/rc: WARNING: invalid $ip6mode value "none"

The ip6mode=none was (I think) an option to implement that was
discussed as a possibility, but never actually done (or at least,
never committed) so that one really would do nothing useful.

  | I have forgotten to mention that I have this other error message:
  | rtsol: kernel is not configured to accept RAs

I really doubt that IPv6 has anything at all do do with your IPv4 related
problem, unless you actually need or use IPv6 just set ip6mode=host, and
disable rtsol and rtsold (and don't attempt to configure any kind of v6
addresses) - that's as close as it is currently possible to get (without
kernel recompilation) to disabling IPv6 completely (and should mostly work
just fine if you're willing to ignore the occasional error message that
might refer to IPv6 when the problem is really something else - that happens
because many things try v6 first, that will fail if you have none, then
try v4 - if that works, great, and you never even notice the v6 attempt, but
if it doesn't, some apps print the first detected error, which is the
v6 attempt failure rather than whatever caused the v4 attempt to fail.)

   | The only thing that works is to set the mtu to 1500 after running
  | wpa_gui. It is not a big effort, but yet it is an annoyance.

Yes, you should not need to do that - something is lowering the MTU,
my guess is still dhcpcd, though why it is happening in your case I
don't know.   What you should really do, is look see if you can find
any DHCP packets in the tcpdump output, try something like

	tcpdump -r /tmp/dump.txt -s 1500 -vvv -xx udp port 67 or udp port 68

and if you cannot decode the packets post that output here, one of the
people who dreams dhcp options will be able to see if there's an MTU
option in there.   Either that, or decode the dump using wireshark which
has much more detailed protocol decoders than tcpdump has.

kre