doc: Correct typos

doc/userguide/capture-hardware/ebpf-xdp.rst

@@ -229,7 +229,7 @@ With any logic implemented in the eBPF filter. The value returned by the functio
 tagged with the ``loadbalancer`` section is used with a modulo on the CPU count to know in
 which socket the packet has to be send.
 
-An implementation of a simple symetric IP pair hashing function is provided in the ``lb.bpf``
+An implementation of a simple symmetric IP pair hashing function is provided in the ``lb.bpf``
 file.
 
 Copy the resulting eBPF filter as needed ::

doc/userguide/capture-hardware/napatech.rst

@@ -198,7 +198,7 @@ Example Configuration - Manual Configuration
 For Manual Configuration the Napatech streams are created by running NTPL
 commands prior to running Suricata.
 
-Note that this option is provided primarily for legacy configuations as previously
+Note that this option is provided primarily for legacy configurations as previously
 this was the only way to configure Napatech products. Newer capabilities such as
 flow-awareness and inline processing cannot be configured manually.
 
@@ -268,15 +268,15 @@ upstream and downstream traffic E.g.::
 Note that these "port-pairings" are also required for IDS configurations as the hardware
 needs to know on which port(s) two sides of the connection will arrive.
 
-For configuations relying on optical taps the two sides of the pairing will typically
+For configurations relying on optical taps the two sides of the pairing will typically
 be different ports. For SPAN port configurations where both upstream and downstream traffic
 are delivered to a single port both sides of the "port-pair" will reference the same port.
 
-For example tap configuations have a form similar to this::
+For example tap configurations have a form similar to this::
 
       ports[0-1,2-3]
 
-Whereas SPAN port configuations it would look similar to this::
+Whereas SPAN port configurations it would look similar to this::
 
       ports[0-0,1-1,2-2,3-3]
 
@@ -326,7 +326,7 @@ pass traffic matching a given signature. For example, given the rule::
 
     pass tcp any 443 <> any any (msg: "SURICATA Test rule";  bypass; sid:1000001; rev:2;)
 
-Suricata will evaluate the inital packet(s) of the flow and program the flow
+Suricata will evaluate the initial packet(s) of the flow and program the flow
 into the hardware. Subsequent packets from the flow will be automatically be
 shunted from one port to it's peer.
 
@@ -358,7 +358,7 @@ On flow-aware products the following counters are also available:
 - napa_dispatch_drop.pkts, napa_dispatch_drop.byte:
 
   The total number of packets/bytes that were dropped at the hardware as
-  a result of a Suricata "drop" bypass rule or other ajudication by
+  a result of a Suricata "drop" bypass rule or other adjudication by
   Suricata that the flow packets should be dropped. These packets are not
   delivered to the application.
 
@@ -371,7 +371,7 @@ On flow-aware products the following counters are also available:
 
 - napa_bypass.active_flows:
 
-  The number of flows actively programmed on the hardware to be forwared or dropped.
+  The number of flows actively programmed on the hardware to be forwarded or dropped.
 
 - napa_bypass.total_flows:
 

doc/userguide/capture-hardware/netmap.rst

@@ -207,7 +207,7 @@ Inline IDS
 ----------
 
 The inline IDS is almost the same as the IPS setup above, but it will not
-enfore ``drop`` policies.
+enforce ``drop`` policies.
 
 ::
 

doc/userguide/configuration/suricata-yaml.rst

@@ -2171,7 +2171,7 @@ Finally, if ``encrypt-handling`` is set to ``full``, Suricata will process the
 flow as normal, without inspection limitations or bypass.
 
 The option has replaced the ``no-reassemble`` option. If ``no-reassemble`` is
-present, and ``encrypt-handling`` is not, ``false`` is intepreted as
+present, and ``encrypt-handling`` is not, ``false`` is interpreted as
 ``encrypt-handling: default`` and ``true`` is interpreted as
 ``encrypt-handling: bypass``.
 

doc/userguide/file-extraction/file-extraction.rst

@@ -98,7 +98,7 @@ stored file to be closed and ``<ID>`` is a unique ID for the runtime
 of the Suricata instance. These values should not be depended on, and
 are simply used to ensure uniqueness.
 
-These ``fileinfo`` records are idential to the ``fileinfo`` records
+These ``fileinfo`` records are identical to the ``fileinfo`` records
 logged to the ``eve`` output.
 
 See :ref:`suricata-yaml-file-store` for more information on

doc/userguide/lua/lua-functions.rst

@@ -175,7 +175,7 @@ HttpGetRequestBody and HttpGetResponseBody.
 Make normalized body data available to the script through
 HttpGetRequestBody and HttpGetResponseBody.
 
-There no guarantees that all of the body will be availble.
+There no guarantees that all of the body will be available.
 
 Example:
 
@@ -798,7 +798,7 @@ init function:
  end
 
 Here we define a `tls-cnt` Flowint that can now be used in output or in a
-signature via dedicted functions. The access to the Flow variable is done by
+signature via dedicated functions. The access to the Flow variable is done by
 index so in our case we need to use 0.
 
 ::

doc/userguide/lua/lua-usage.rst

@@ -2,7 +2,7 @@ Lua usage in Suricata
 =====================
 
 Lua scripting can be used in two components of Suricata. The first is in
-output an the second one in rules in the detection engine.
+output and the second one in rules in the detection engine.
 
 Both features are using a list of functions to access to data extracted by
 Suricata. You can get the list of functions in the :ref:`lua-functions` page.

doc/userguide/performance/analysis.rst

@@ -111,7 +111,7 @@ There are several advanced steps and corner cases when it comes to a deep dive
 into the traffic.
 
 If VLAN QinQ (IEEE 802.1ad) is used be very cautious if you use **cluster_qm**
-in combinatin with Intel drivers and AF_PACKET runmode. While the RFC expects
+in combination with Intel drivers and AF_PACKET runmode. While the RFC expects
 ethertype 0x8100 and 0x88A8 in this case (see
 https://en.wikipedia.org/wiki/IEEE_802.1ad) most implementations only add
 0x8100 on each layer. If the first seen layer has the same VLAN tag but the

doc/userguide/rules/differences-from-snort.rst

@@ -550,7 +550,7 @@ Fast Pattern
 -  Using Hyperscan as the MPM matcher (``mpm-algo`` setting) for Suricata
    can greatly improve performance, especially when it comes to fast pattern
    matching.  Hyperscan will also take in to account depth and offset
-   when doing fast pattern matching, something the other algorithims and
+   when doing fast pattern matching, something the other algorithms and
    Snort do not do.
 
 -  :ref:`rules-keyword-fast_pattern`

doc/userguide/upgrade.rst

@@ -21,7 +21,7 @@ this means passing the same ``--prefix``, ``--sysconfdir``,
 Configuration Updates
 ~~~~~~~~~~~~~~~~~~~~~
 
-New versions of Suricata will occationally include updated config files:
+New versions of Suricata will occasionally include updated config files:
 ``classification.config`` and ``reference.config``. Since the Suricata
 installation will not overwrite these if they exist, they should be manually
 updated. If there are no local modifications they can simply be overwritten