This is meant to be used for a new 'X' code in the history in scenarios when
packets are knowingly not processed or an unexpected unknown situation
is recognized.
Usually, these situations are currently reported via weirds or analyzer violations,
but being able to include it in the history field allows them to be more visible.
Will be used for exceeding tunnel depths first.
While it seems interesting functionality, this hasn't been documented,
maintained or knowingly leveraged for many years.
There are various other approaches today, too:
* We track the number of event handler invocations regardless of
profiling. It's possible to approximate a load_sample event by
comparing the result of two get_event_stats() calls. Or, visualize
the corresponding counters in a Prometheus setup to get an idea of
event/s broken down by event names.
* HookCallFunction() allows to intercept script execution, including
measuring the time execution takes.
* The global call_stack and g_frame_stack can be used from plugins
(and even external processes) to walk the Zeek script stack at certain
points to implement a sampling profiler.
* USDT probes or more plugin hooks will likely be preferred over Zeek
builtin functionality in the future.
Relates to #3458
These can be significant if a lot of new connections and or events
are created for which an existing conn val needs updating and otherwise
things are very fast.
Packet::Init() is not so cheap as one might think: It computes a
timestamp from { 0, 0 } using double division. Just avoid this
by not initializing an empty Packet.
For deeply encapsulated connections (think AWS traffic mirroring format
like IP,UDP,GENEVE,IP,UDP,VXLAN,ETH,IP,TCP), the Dispatcher::Lookup()
method is fairly visible in profiles when running in bare mode.
This changes the Analyzer::Lookup() and Dispatcher::Lookup() return value
breaking the API in favor of the performance improvement.
Relates to zeek/zeek#3379.
This largely copies over Spicy's `.clang-format` configuration file. The
one place where we deviate is header include order since Zeek depends on
headers being included in a certain order.
The fuzzer generated input where data length left was 14 and the amsdu_len
field set to 14. That caused buffer overread due not taking into account
the amsdu header length of 14.
Using pcaps from https://interop.seemann.io/ as samples for QUIC protocol
data didn't produce a conn.log for the contained data. `tcpdump -r`
and Wireshark do show the contained IP/UDP packets. Teach Zeek how
to handle link type DLT_PPP 0x09 using a new PPP analyzer based on the
PPPSerial analyzer code.
Usual update to files/x509 baseline after adding new analyzer due
to enum values changing.
This is similar to GH-3206. There do not seem to be practical
consequences - but we should still fix it.
This also includes the udp-testcase that was forgotten in GH-3206.
We should not be passing the untrusted TCP header length into
DeliverPacket(). Also, DeliverPacket() cap len parameter should
be the capture length of the packet, not remaining data.
With packet->len representing the wire length and other places
relying on it, ensure it's updated for fragments as well. This
assumes non-truncated fragments right now. Otherwise we'd need
to teach the FragmentReassembler to somehow track this independently
but it would be a mess.
The protocol analyzers are prepared to receive truncated data and
this way we give analyzers a chance to look at data. We previously
allowed empty data being passed: When len ended up 0 and remaining
was 0 too.
This may happen with truncated packets and will cause asan builds to bail out
before the packet can be forwarded along. The TCP analyzer already has this
check, but it's missing for UDP.
This also fixes the GRE analyzer to forward into the IEEE 802.11 analyzer
if it encounters Aruba packets with the proper protocol types. This way
the QoS header can be handled correctly.
This fixes a bug for AYIYA, Geneve and VXLAN forwarding encapsulated
content only if it's longer than their header. A new weird is introduced
to indicate empty tunnels.
In #2464 the warning when overriding a packet analyzer mapping was
removed. While a warning seems indeed excessive, some info would still
be nice to have.
