https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287229
Timo Voelker <timo.voel...@fh-muenster.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |timo.voel...@fh-muenster.de
--- Comment #10 from Timo Voelker <timo.voel...@fh-muenster.de> ---
Hi Lucas,
In cooperation with Michael, I built a setup for your minimal testing tool. I
executed a couple of runs and saw the same issue: the results of the runs
differ. It looks like the FreeBSD machine is running against an IP fragment
limit.
For IP reassembly, FreeBSD uses a hash table. For each hash value (bucket), it
holds a list of reassembly entries. In each entry, it holds the fragments of
one packet until all data has arrived (and reassembly can be completed) or a
timeout (after 30s by default).
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.
The value for maxfragbucketsize is set based on the available memory. Usually
on a 2 GB machine, like your FreeBSD VM, this value is set to 7, which seems
enough to not run into this issue. However, in /boot/loader.conf of your
FreeBSD VM, the size of the kernel memory is reduced:
vm.kmem_size="200M"
vm.kmem_size_max="200M"
After commenting out these two lines and a reboot, maxfragbucketsize is 7 and
the results of multiple runs are the same.
For the sake of completeness, these are other limits that might be relevant
here:
net.inet.ip.maxfragpackets
net.inet.ip.maxfrags
Timo
--
You are receiving this mail because:
You are on the CC list for the bug.
