https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330
--- Comment #13 from Kristof Provost ---
I've not yet been able to reproduce your second panic. As of r284260 things
appear to be working for me. Is this something you can easily reproduce?
Can you also explain your use case for 'fragment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330
--- Comment #14 from Danilo Egea Gondolfo ---
I was using this option in a low traffic network. The last panic happened after
some hours of uptime. Nothing special. My use case for "drop-ovl" is just
"testing", I don't need to use this opti
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330
--- Comment #15 from Kristof Provost ---
The problem I have with 'drop-ovl' (and the same applies to 'crop') is that
it's a bit misleading.
They don't actually reassemble the fragmented packet.
That means a far lower system load, but you
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330
--- Comment #16 from Danilo Egea Gondolfo ---
Yes, I was expecting that drop-ovl just drops packets with fragments that has
the field "fragment offset" overlapping other fragments. My question is: Can
(or should) "fragment reassemble" drop
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330
--- Comment #17 from Kristof Provost ---
'reassemble' does the right thing, in that it will fully reassemble the packet.
It handles overlaps, by discarding the (parts of) packets it's already seen.
Processing continues with the full packet
