kern/183265: ICMP6_PACKET_TOO_BIG doesn't create an entry in hostcache if multifib is active

Luc Revardel lrevardel at
Thu Oct 24 09:20:00 UTC 2013

>Number:         183265
>Category:       kern
>Synopsis:       ICMP6_PACKET_TOO_BIG doesn't create an entry in hostcache if multifib is active
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Oct 24 09:20:00 UTC 2013
>Originator:     Luc Revardel
>Release:        8.2
Linux 2.6.24-24-generic #1 SMP Fri Jul 24 22:46:06 UTC 2009 i686 GNU/Linux
This issue occurs when running in multifib (MAXROUTES=11)

Upon reception of an ICMP6 PACKET_TOO_BIG, the hostcache isn't updated with the MTU provided by the ICMP error message.
Subsequent IPv6 packet are not fragmented according to the new MTU value as they should be.
Ensure the kernel is compiled with MAXROUTES>1.

Ping a remote destination on the internet using large ping packets (>1500). The route to the destination should contain a segment on which the MTU is smaller than 1500 (say X) in order to reproduce the problem.

First ping packet (IPv6 fragment)should be emitted with a size of 1500.
The host shold receive an ICMP6 packet with a smaller MTU (X).
Next ping packet will be re-emitted with a size of 1500 instead of X.

It looks like the fibnum isn't managed by icmp6_mtudisc_update.
tcp_macmtu6 doesn't find a route matching the searched address.

Fixing inc.inc_fibnum in icmp6_mtudisc_update() seems to solve the problem:

	bzero(&inc, sizeof(inc));
	inc.inc_flags |= INC_ISIPV6;
	inc.inc6_faddr = *dst;
+	inc.inc_fibnum = M_GETFIB(ip6cp->ip6c_m);
	if (in6_setscope(&inc.inc6_faddr, m->m_pkthdr.rcvif, NULL))

	if (mtu < tcp_maxmtu6(&inc, NULL)) {
		tcp_hc_updatemtu(&inc, mtu);


More information about the freebsd-bugs mailing list