zeek-dev September 2018

zeek-dev@lists.zeek.org

10 discussions

by Vern Paxson

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.

2 years, 9 months

[Bro-Dev] "bro" name is non-inclusive? (Contribution is rejected based )

by Vitaly Repin

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

2 years, 11 months

[Bro-Dev] Module prefix in sending and receiving Broker events

by Matthias Vallentin

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

2 years, 11 months

[Bro-Dev] S7Comm/S7CommPlus Analyzer

by DW

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

2 years, 12 months

[Bro-Dev] 2.6-beta build error

by Michael Dopheide

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

3 years

[Bro-Dev] 2.6-beta and 2.7 parallel development

by Jon Siwek

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

3 years

[Bro-Dev] JIRA to GitHub ticket migration plan

by Jon Siwek

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

3 years

[Bro-Dev] Bro 2.6-beta plans

by Jon Siwek

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

3 years

[Bro-Dev] How to use Broker::Data in an event handler?

by Matthias Vallentin

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.)

3 years

[Bro-Dev] switch/case type recognition

by Matthias Vallentin

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

3 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

zeek-dev September 2018