From: Juliana Fajardini Date: Fri, 26 Aug 2022 20:52:46 +0000 (-0300) Subject: userguide: update defrag settings options X-Git-Tag: suricata-6.0.7~32 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=374e4879a1345e970acac2d5c58e4bbff3338ecc;p=thirdparty%2Fsuricata.git userguide: update defrag settings options We were still mentioning that there were only three options. (cherry picked from commit 3c74e443bdd6e666692b1c1da1d0389268b0eec7) --- diff --git a/doc/userguide/configuration/suricata-yaml.rst b/doc/userguide/configuration/suricata-yaml.rst index 9096c59a44..d6574560b7 100644 --- a/doc/userguide/configuration/suricata-yaml.rst +++ b/doc/userguide/configuration/suricata-yaml.rst @@ -928,19 +928,21 @@ a component of Suricata; the defragment-engine. After a fragmented packet is reconstructed by the defragment-engine, the engine sends on the reassembled packet to rest of Suricata. -There are three options within defrag: max-frags, prealloc and -timeout. At the moment Suricata receives a fragment of a packet, it +At the moment Suricata receives a fragment of a packet, it keeps in memory that other fragments of that packet will appear soon to complete the packet. However, there is a possibility that one of the fragments does not appear. To prevent Suricata for keeping waiting for that packet (thereby using memory) there is a timespan after which -Suricata discards the fragments. This occurs by default after 60 +Suricata discards the fragments (timeout). This occurs by default after 60 seconds. :: defrag: - max-frags: 65535 + memcap: 32mb + hash-size: 65536 + trackers: 65535 # number of defragmented flows to follow + max-frags: 65535 # number of fragments do keep (higher than trackers) prealloc: yes timeout: 60