We could actually already see these in traffic with people that use and
enabled them in chrome canary / firefox nightly builds. This change
includes the re-naming of a few names that were never formalli assigned
yet.
* Clean it up, make it more consistent, and add references to similar events.
* Commented out the smb2_set_info_request event, which wasn't being generated.
* Documented the SMB2 record types in init-bare
One more name change: version_num -> version_number
BIT-1707 #merged
* origin/topic/johanna/version:
Slight naming changes for Bro version information.
Add convenient way to access version information to Bro.
With the introduction of the package manager, it will get more common
that applications are able to get information about the currently
running version of Bro. With this commit, scripts can easily compare
which version of Bro they are running.
Commonly, this probably will either look like this (both lines check if
the current Bro version is greater or equal to 2.5)
@if ( Version::num >= 20500 )
or
@if ( Version::greater_equal("2.5") )
Version::info contains detailed information about the running version of
Bro, including beta flags, etc.
* origin/topic/seth/log-framework-ext:
Log extensions: series of small fixes and new tests.
Change the function for log extension to take a path only and update tests.
Final changes to log framework ext code.
Add logging framework metadata mechanism.
Add unrolling separator & field name map to logging framework.
The extensions now work with optional types, as well with complex types
(like subrecords). Not returning a record in the ext_func no longer
crashes bro.
The default_ext_func was switched to return void in
cases where no extension revord is defined (was bool).
I also got rid of the offsets in the indices - with the rest of the
implementation, that was not really necessary and made the code more
complex.
The "metadata" functionality has been renamed to "ext" to
represent that the logs are being extended. The function that
returns the record which is used to extend the log now receives
a log filter as it's single argument.
The field name "unrolling" is now renamed to "scope" so the variables
names now look like this: "Log::default_scope_sep"
If the analyzer is not found directly attached to the connection,
useless error messages are being output. There are now several
cases where analyzers are attached within other analyzers so the
connection itself doesn't know about the analyzer. This hides
these useless messages.
This adds the capability for the user to attach a reason when removing
or destroying a rule. The message will both be logged in netcontrol.log
and forwarded to the responsible plugins.
Addresses BIT-1655
* origin/topic/dnthayer/ticket1627:
Add a test for starting a cluster with a logger node
Update broctl submodule
Update broctl submodule to branch topic/dnthayer/ticket1627
Change how logger node is detected in cluster framework
Update test baselines for the new logger node type
Update docs for the new logger node type
Add a new node type for logging
Currently outstanding_global_views values are only decremented during
the end of epoch cleanup, but not when handle_end_of_result_collection
is called for the specific uid that actually triggered the result
collection (which is specifically NOT a cleanup event).
This changes outstanding_global_views values to be a set of outstanding
uids, instead of a count. This allows handle_end_of_result_collection
to remove any uids from the set as it sees them.
Previously, recent_global_view_keys was only tracked on workers causing
a popular key to be sent up and handled by the manager once for each
worker.
This records the key inside recent_global_view_keys on the manager after
the first update, making the rest of the updates no-ops.
Additionally, since the counter value was never used, it has been
changed from a table to a set.
This adds an event that is raised once Catch & Release ceases the
block management for an IP address because the IP has not been seen in
traffic during the watch interval.
This allows users who use their own logic on the top of catch and
release know when they will have to start re-blocking the IP if it
occurs in traffic again.
This change introduces error events for Table and Event readers. Users
can now specify an event that is called when an info, warning, or error
is emitted by their input reader. This can, e.g., be used to raise
notices in case errors occur when reading an important input stream.
Example:
event error_event(desc: Input::TableDescription, msg: string, level: Reporter::Level)
{
...
}
event bro_init()
{
Input::add_table([$source="a", $error_ev=error_event, ...]);
}
For the moment, this converts all errors in the Asciiformatter into
warnings (to show that they are non-fatal) - the Reader itself also has
to throw an Error to show that a fatal error occurred and processing
will be abort.
It might be nicer to change this and require readers to mark fatal
errors as such when throwing them.
Addresses BIT-1181
