From owner-freebsd-net@FreeBSD.ORG Thu Feb 19 16:16:23 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97D8A974 for ; Thu, 19 Feb 2015 16:16:23 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E5D6AB0 for ; Thu, 19 Feb 2015 16:16:23 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t1JGGNJt076051 for ; Thu, 19 Feb 2015 16:16:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 197059] network locks up with IPv6 udp traffic Date: Thu, 19 Feb 2015 16:16:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ae@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 16:16:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197059 --- Comment #4 from Andrey V. Elsukov --- Created attachment 153179 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=153179&action=edit On output path send IPV6_PATHMTU ancillary data only to the socket, that had initiated an error (In reply to Robert Watson from comment #3) > A further note on the problem: > > A good question is whether the current behaviour actually makes sense: do we > really need to notify all sockets of a change in MTU discovered by one > socket on transmit? Or can we just let the others sockets discover the > change on demand as they next try to transmit? > > (I don't take a strong view on the answer, except to point out that it would > be simpler if, as in IPv4, we didn't try to notify all sockets of the event.) I think this was implemented according to what RFC3542 says (p. 11.3):" Note that this also means an application that sets the option may receive an IPV6_MTU ancillary data item for each ICMP too big error the node receives, including such ICMP errors caused by other applications on the node." But this doesn't mean we should send these ancillary data, when message size exceeds link MTU. So, I propose the following patch for testing -- You are receiving this mail because: You are on the CC list for the bug.