Date: Thu, 19 Feb 2015 16:16:23 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 197059] network locks up with IPv6 udp traffic Message-ID: <bug-197059-2472-VmJqY4LAZV@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-197059-2472@https.bugs.freebsd.org/bugzilla/> References: <bug-197059-2472@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197059 --- Comment #4 from Andrey V. Elsukov <ae@FreeBSD.org> --- 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-197059-2472-VmJqY4LAZV>