A no padding option is provided as a mode, as its a variant suitable
for encoding and decoding.
A padding optional function is added that is indifferent to padding
when decoding. This can be useful when you're not sure if padding
exists, and don't really care.
Example:
```
local packet = require "suricata.packet"
function init (args)
local needs = {}
return needs
end
function match (args)
p = packet.get()
payload = p:payload()
ts = p:timestring()
for line in payload:gmatch("([^\r\n]*)[\r\n]+") do
if line == "GET /index.html HTTP/1.0" then
ipver, srcip, dstip, proto, sp, dp = p:tuple()
SCLogNotice(string.format("%s %s->%s %d->%d (pcap_cnt:%d) match! %s", ts, srcip, dstip, sp, dp, p:pcap_cnt(), line));
return 1
end
end
return 0
end
```
Methods:
`get` creates the packet object.
`payload` returns the packet payload as a buffer
`packet` returns the whole packet (includes headers)
`pcap_cnt` returns the `pcap_cnt` (pcap file mode only)
`tuple` returns various fields: srcip, dstip, proto, sp, dp
`sp` returns source port
`dp` returns destination port
`timestamp` returns time as 2 numbers: seconds and microseconds
`timestring_legacy` returns a timestamp as a string (like fastlog)
`timestring_iso8601` returns a iso8601 compat timestring (like eve)
Ticket: #7488.
The configuration of this rule is the same as for ixgbe driver except
the hash function is not RTE_ETH_HASH_FUNCTION_DEFAULT but
RTE_ETH_HASH_FUNCTION_TOEPLITZ.
The syntax in dpdk-testpmd for this rule with attributes:
port index == 0
used rx queue indices == 0 1 2 3
<hash_key> == 6d5a symmetric hash key
is as follows:
"flow create 0 ingress pattern eth / end actions rss types ipv4 ipv6
end queues 0 1 2 3 end key <hash_key> key_len 40 func toeplitz / end"
Ticket: 7337
ice driver requires 2 rte_flow rules for matching and
redistributing incoming traffic with RSS.
The rules set up by iceDeviceSetRSSFlowIPv4() and
iceDeviceSetRSSFlowIPv6() are different only in the pattern
("pattern eth / ipv4 / end" or "pattern eth / ipv6 / end"
in dpdk-testpmd syntax) and in the hash type (ipv4 src dst / ipv6 src
dst). ice will match all ipv4 or ipv6 traffic independently of
following l4 protocol. The rules can not have queues configured,
implicitly they will use all queues available.
The hash function is set to RTE_ETH_HASH_FUNCTION_TOEPLITZ.
The hash key can not be set.
The syntax in dpdk-testpmd for rule to match all ipv4 traffic
with attributes:
port index == 0
is as follows:
"flow create 0 ingress pattern eth / ipv4 / end actions rss types ipv4
end queues end func toeplitz / end"
(queues need to be set to NULL)
Ticket: 7337
ixgbe driver requires different configuration of RSS rte_flow
rule than i40e, with just one generic rule matching all traffic.
The generic rule configured by DeviceCreateRSSFlowGeneric() has pattern
equivalent to "pattern eth / end" in dpdk-testpmd syntax. The rule must
have rx queues configured. The rule hashes traffic to different queues
based on ipv4 and ipv6 hash types (ipv4 src dst / ipv6 src dst).
The hash key is 40 bytes long symmetric hash key. ixgbe does not
support any other hash function than RTE_ETH_HASH_FUNCTION_DEFAULT.
The syntax in dpdk-testpmd for this rule with attributes:
port index == 0
used rx queue indices == 0 1 2 3
<hash_key> == 6d5a symmetric hash key
is as follows:
"flow create 0 ingress pattern eth / end actions rss types ipv4 ipv6
end queues 0 1 2 3 end key <hash_key> key_len 40 func default / end"
Ticket: 7337
Move and adjust the base of RSS configuration from util-dpdk-i40e.c to
a new file that can be later utilized by other cards.
RSS configuration can be configured via rte_flow rules. This is useful
for possible future features such as specific header offload
(vxlan, nvgre) also implemented via rte_flow rules, as rte_flow
rules can be chained via groups and priorities.
i40e uses multiple different rte_flow rules to setup RSS. At first,
function DeviceSetRSSFlowQueues() is used to setup rx queues.
This rule matches all types of traffic, so the equivalent
to dpdk-testpmd pattern would be "pattern end"
This rule can not contain hash types (ipv4, ipv6 etc.) nor hash key.
The hash function used here is RTE_ETH_HASH_FUNCTION_DEFAULT.
The syntax in dpdk-testpmd for this rule with attributes:
port index == 0
used rx queue indices == 0 1 2 3
is as follows:
"flow create 0 ingress pattern end actions rss queues 0 1 2 3 end
func default / end"
The other rules configured by i40eDeviceSetRSSFlowIPv4() and
i40eDeviceSetRSSFlowIPv6() match specific type of traffic by l4 protocol
(none, TCP, UDP, SCTP). For example, pattern to match l3 ipv4 with l4
tcp traffic in dpdk-testpmd syntax would be equivalent of
"pattern eth / ipv4 / tcp / end".
These rules can not have rx queues configured, but have hash types
(l3 src and dst address). This means that the traffic distribution
is affected only by l3 addresses, independent of the l4 specifics.
Also these pattern matching rules have symmetric 6d5a
hash key configured. The length of the key is dependent on DPDK version.
The hash function (either RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ or
RTE_ETH_HASH_FUNCTION_TOEPLITZ, depending on DPKD version) used
in these rules hashes symmetricaly due to the symmetric hash key.
The syntax in dpdk-testpmd for rule to match ipv4-tcp traffic with
attributes:
port index == 0
<hash_key> == 52 bytes long 6d5a symmetric hash key
is as follows:
"flow create 0 ingress pattern eth / ipv4 / tcp / end actions rss types
ipv4-tcp l3-src-only l3-dst-only end queues end key <hash_key>
key_len 52 func toeplitz / end"
(queues need to be set to NULL)
Ticket: 7337
Don't emmit generic error statements on things that are not errors. Instead,
for cases where (part of) the config is missing, use the defaults and log
only a more detailed explanation at the 'config' level.
Minor code cleanups.
Issue 7129
When configured with the existing "ethernet" switch, include the ether
type in the output.
This is most useful with anomaly records indicating unknown ethertypes.
Protocol detection code is simplified. Removed dependency on explicit
alproto constants from the common part of code that must not be aware of
the each specific protocol features.
Ticket - 7111
If `prefilter` is used it should override automatic fast pattern
selection.
Fixes: d6b56929d3 ("detect: set mpm/prefilter during signature parsing")
Ticket: #7523.
Jason Ish
Victor Julien
Eric Leblond
AlirezaPourchali
Alice Akaki
Philippe Antoine
Adam Kiripolsky
dependabot[bot]
Jeff Lucovsky
Ilya Bakhtin