From owner-freebsd-bugs@FreeBSD.ORG Thu Oct 24 09:20:00 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C141F39A for ; Thu, 24 Oct 2013 09:20:00 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A0D5A2A51 for ; Thu, 24 Oct 2013 09:20:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9O9K0PV023585 for ; Thu, 24 Oct 2013 09:20:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9O9K0RG023583; Thu, 24 Oct 2013 09:20:00 GMT (envelope-from gnats) Resent-Date: Thu, 24 Oct 2013 09:20:00 GMT Resent-Message-Id: <201310240920.r9O9K0RG023583@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Luc Revardel Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0BAA8D8E for ; Thu, 24 Oct 2013 09:14:44 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ED9312916 for ; Thu, 24 Oct 2013 09:14:43 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id r9O9EhA3045028 for ; Thu, 24 Oct 2013 09:14:43 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id r9O9EhGK044930; Thu, 24 Oct 2013 09:14:43 GMT (envelope-from nobody) Message-Id: <201310240914.r9O9EhGK044930@oldred.freebsd.org> Date: Thu, 24 Oct 2013 09:14:43 GMT From: Luc Revardel To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: kern/183265: ICMP6_PACKET_TOO_BIG doesn't create an entry in hostcache if multifib is active X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 09:20:00 -0000 >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 >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Oct 24 09:20:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Luc Revardel >Release: 8.2 >Organization: NVidia >Environment: Linux 2.6.24-24-generic #1 SMP Fri Jul 24 22:46:06 UTC 2009 i686 GNU/Linux >Description: 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. >How-To-Repeat: 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. >Fix: 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: icmp6_mtudisc_update() [...] 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)) return; if (mtu < tcp_maxmtu6(&inc, NULL)) { tcp_hc_updatemtu(&inc, mtu); ICMP6STAT_INC(icp6s_pmtuchg); } [...] >Release-Note: >Audit-Trail: >Unformatted: