IPv6 MTU bug?

[Mark Santcroos]

[ moved to net@; current@ bcc'ed ]

Hi Craig,

I think I saw the same behaviour while developing a path-mtu discovery
tool. As I'm quite busy right now I didn't really dig into it, but I will
at some point.

I took the liberty to reply to freebsd-net@, because this is not only a
-CURRENT problem.

Mark

On Wed, Apr 02, 2003 at 11:31:02AM -0600, Craig Boston wrote:
> I was trying some network diagnostics yesterday and needed to generate a
> continuous stream of small packets going across a few routers.  So I
> used ifconfig to set my MTU to some very low values (100, 300, 500, and
> a few others).  I know there's probably a better way to accomplish that,
> but couldn't think of any at the time so that's what I did :)
> 
> Anyway, when I was done, I reset the MTU on my ethernet interface back
> to 1500.  IPv4 is working fine, but IPv6 is still acting like I have a
> low MTU set.  All IPv6 TCP connections are limiting the MSS to around 28
> bytes of data per packet, and ping6 complains with ping sizes more than
> around 50.
> 
> I think I've tracked down the problem to this code in nd6.c,
> specifically in nd6_setmtu(ifp).
> 
> Note that at this point ndi->maxmtu has just been set to
> MIN([user-requested MTU], [biggest MTU possible for this interface
> type]).  ndi->linkmtu hasn't been touched yet and is still set to
> whatever the previous linkmtu was.
> 
> if (ndi->linkmtu == 0 ||
>     ndi->maxmtu < ndi->linkmtu) {
>         ndi->linkmtu = ndi->maxmtu;
>         /* also adjust in6_maxmtu if necessary. */
>         if (oldlinkmtu == 0) {
>             /*
>              * XXX: the case analysis is grotty, but
>              * it is not efficient to call in6_setmaxmtu()
>              * here when we are during the initialization
>              * procedure.
>              */
>             if (in6_maxmtu < ndi->linkmtu)
>                     in6_maxmtu = ndi->linkmtu;
>         } else
>                 in6_setmaxmtu();
> }
> 
> It looks to me that in the case of raising an interface's MTU,
> ndi->maxmtu will be >= ndi->linkmtu, causing linkmtu to never get
> reset.  I may be missing something, but I can't quite figure out the
> logical reason for that test.
> 
> Luckily I had a kernel.debug lying around so I used gdb to peek into the
> kernel memory.  In the nd_ifinfo for that interface, linkmtu=100 and
> maxmtu=1500.  Once I manually reset linkmtu to 1500, IPv6 started
> working properly again, without having to sacrifice my uptime :)
> 
> Anyway, the behavior looks like a bug, but the code makes it look like
> this may be an intentional effect.  Any kernel networking gurus care to
> comment?
> 
> Thanks,
> Craig
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"

-- 
Mark Santcroos                    RIPE Network Coordination Centre
http://www.ripe.net/home/mark/    New Projects Group/TTM