For some scripting I'm doing, I'm running into the problem that
attributes associated with named types don't get propagated. For
example,
type a: table[count] of count &default = 5;
global c: a;
print c[9];
complains that c[9] isn't set, instead of returning the value 5.
Having dived[*] into this and examined some potential fixes, I've identified
that the problem is that (1) the attribute "&default = 5" in the above
example gets associated with the identifier 'a' rather than with a's type,
and (2) when the parser processes the second line, early in the process 'a'
gets converted to its underlying type, with the attributes lost at that
point since, internally, BroType's do not have attributes.
This is a pain to deal with. If we simply add attributes to BroType's and
for statements like the first line associate the attributes with the type,
then a sequence like:
type a: table[count] of count &default = 5;
type b: a &read_expire = 1 min;
will wind up changing the attributes associated with 'a' even though it
really shouldn't.
I think the right solution for this is to introduce a new BroType called
a NamedType. A NamedType has an identifier, an underlying BroType, and a
set of attributes. When a NamedType is constructed, for its attributes
it combines both the explicit attributes in its declaration (like the
&read_expire for 'b' above) and the implicit (i.e., it inherits/copies the
&default from 'a').
I plan to implement this soon, so please speak up if you have thoughts.
Vern
[*] The dive also exposed some other bugs in attribute processing, which
I'll enter into the tracker shortly.
Hello,
I would like to bring your attention to one strange and unexpected problem
I faced
while trying to include user agent parser for bro I have developed (plugin:
https://github.com/vitalyrepin/uap-bro ) into the list of uap
implementations https://github.com/ua-parser
The req
--
WBR & WBW, Vitaly
When I receive events from Bro via Broker, they have the prefix of the
enclosing module:
module Foo;
event foo() { ... }
event bar() { ... }
When I publish "foo" via Broker, it arrives as "Foo::foo". However, when
I publish an event "Foo::bar" from Broker, Bro doesn't recognize it. I
must published it as "bar" - without the module prefix. Is this
intentional?
Matthias
Hi there,
as a part of my master's thesis I wrote a protocol analyzer for the
Siemens protocols S7Comm and S7CommPlus.
I posted the code on my GitHub repository, which can be seen here:
https://github.com/dw2102/S7Comm-Analyzer
The S7Comm nearly covers all protocol functions and was tested on .pcap
files I generated with a Siemens S7-1204 and other files which I found
on other GitHub repositores.
The S7CommPlus analyzer isn't finished yet. It covers all base
functions, but without handeling the data of the packets. There is a lot
to do, like fragmentation, parsing of data, testing etc. which I
couldn't do, because it would have exceeded my time limit.
Feel free to use, modify or share it.
Dane
I'm hitting the same error when trying to build release/2.6 or master:
[ 99%] In file included from /usr/local/src/bro/src/Func.cc:702:0:
bro.bif: In constructor ‘MMDB::MMDB(const char*, stat)’:
bro.bif:3630:47: error: cannot convert ‘stat’ to ‘__dev_t {aka long
unsigned int}’ in initialization
CentOS Linux release 7.5.1804
Let me know if you need any other information. As a point of comparison,
bro-2.5-897 builds fine.
-Dop
Due to how our version tagging works and to prevent things destined
for 2.7 getting incorrectly labelled as part of 2.6-beta in CHANGES,
I'm going to start a dev/2.7 branch.
* Any new commits that should be included for final 2.6: merge to master
* Any new commits that are meant for 2.7: merge to dev/2.7
After a final 2.6 release is tagged, dev/2.7 can then be merged into master.
- Jon
A preview of what migrated issues will look like along with new labeling scheme:
https://github.com/jsiwek/test/issues
The selection strategy of which tickets to migrate is something like
"anything that is a reproducible bug or a simple/uncontroversial
enhancement". Any tickets not in that preview list will be left open
in JIRA, but frozen as read-only. Going forward, JIRA will serve as a
historical archive or Good Idea Backlog that we can occasionally pull
from, but that can be done manually whenever the situation comes up
(just create a GH issue and link to old JIRA ticket).
Remaining tasks:
* Perform the actual migration
* Update website/docs with new directions/process for issues
* Email bro + bro-dev mailing lists once tickets are migration
* Adapt workflow permissions for JIRA "BIT" project so it's read-only
I expect I'll do those next Monday unless there's objections or
feedback to address.
- Jon
There's no significant code changes/features planned to get added to
the master branch from now until the 2.6-beta gets released (maybe in
about a week). Until that happens, please help test the latest master
branch and provide any feedback about how it's working if you can.
- Jon
I'm trying to figure out if/how it is possible to use Broker::Data in an
event handler as follows:
event foo(x: Broker::Data)
{
print x;
}
I'm trying to send an event via the Python bindings:
event = broker.bro.Event("foo", broker.Data(42))
endpoint.publish("/test", event)
However, Bro complains:
warning: failed to convert remote event 'foo' arg #0, got integer, expected record
I tried both
event = broker.bro.Event("foo", 42)
and a wrapped version
event = broker.bro.Event("foo", broker.Data(42))
and even
event = broker.bro.Event("foo", broker.Data(broker.Data(42)))
but it seems that nesting is not possible.
The use case for having a Broker::Data in the Bro event handler is that
the structure of the data is varying at runtime (similar to JSON).
Matthias
(The code is a slightly adapted version from
https://github.com/bro/broker/issues/11.)
Consider this snippet:
function f(x: any)
{
switch (x)
{
case type any:
print "any";
break;
case type vector of any:
print "vector of any";
break;
}
}
event bro_init()
{
f(42);
}
I would have imagined that the two cases are considered different types,
but Bro doesn't think so:
error in ./test.bro, lines 9-10: duplicate case label (case type vector of any:{ print anybreak })
Adding a type alias for either type doesn't change the error message.
I am aware that this is a somewhat pathological case, because 'case type
any' is probably equivalent to the 'default' case.
Matthias