Date: Thu, 19 Jun 2025 01:20:51 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 287229] IP reassembly issue in FreeBSD 14.1 Message-ID: <bug-287229-7501-1mlJFU8ROe@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-287229-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-287229-7501@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=287229 Rodney W. Grimes <rgrimes@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rgrimes@FreeBSD.org --- Comment #14 from Rodney W. Grimes <rgrimes@FreeBSD.org> --- (In reply to Timo Voelker from comment #10) The number of list entries (net.inet.ip.maxfragbucketsize) seems relevant here. Out of the box, your FreeBSD VM has set maxfragbucketsize=1. This means if the FreeBSD VM must insert a new entry (i.e., when the first fragment of a packet has been received) in a bucket that already contains an entry, it removes this one first. In consequence, FreeBSD is probably unable to reassemble that packet with the removed fragments. So I believe the "relevant bug" here is that maxfrqgbucksize is allowed to go to 1, there should be a clamp on the calculation to prevent this absurd value that would lead to the behavior uncovered by artificially reducing kernel memory space. There are many values that we calculate based on tuning parameters and those values should have reasonable clamps on them, if they lead to bad behavior when they go to low or two high. -- 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-287229-7501-1mlJFU8ROe>