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=3D287229 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 h= ere. Out of the box, your FreeBSD VM has set maxfragbucketsize=3D1. This means i= f the FreeBSD VM must insert a new entry (i.e., when the first fragment of a pack= et has been received) in a bucket that already contains an entry, it removes t= his one first. In consequence, FreeBSD is probably unable to reassemble that pa= cket 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 val= ue 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. --=20 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>