[Bro-Dev] Draft API for new communication library
I have been mulling over how an API for a new communication library could look like. In short, the idea is to (1) overhaul Bro's current communication model to make it more flexible and easier to control; and (2) provide the new functionality in the form of a C library that replaces Broccoli yet will also be used by Bro itself (i.e., we;ll no longer have two independent implementations of the same protocol to maintain). Draft is here: http://www.bro.org/development/projects/comm-ng-v2.html Feedback welcome. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * ro...@icir.org ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.org/robin ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1091) Broctl config.py handling of [manager] header is brittle
Bob created BIT-1091: Summary: Broctl config.py handling of [manager] header is brittle Key: BIT-1091 URL: https://bro-tracker.atlassian.net/browse/BIT-1091 Project: Bro Issue Tracker Issue Type: Problem Components: BroControl Affects Versions: 2.2 Environment: RHEL6 Reporter: Bob $prefix/lib/broctl/BroControl/config.py (line 159, in nodes()) special cases the manager node of the etc/node.cfg config and checks it by the attribute n.name, as opposed to all of the other types that are handled earlier in the function, which get checked by the attribute n.type. This means that anyone who might try to set a more descriptive manager name, like [broproductionmanager] or [brotestmanager], will break broctl to disastrous effect: [root@bro-testmgr bro-2.2-beta]# /opt/bro/bin/broctl install removing old policies in /var/bro/spool/installed-scripts-do-not-touch/site ... done. removing old policies in /var/bro/spool/installed-scripts-do-not-touch/auto ... done. creating policy directories ... done. installing site policies ... done. generating local-networks.bro ... done. Traceback (most recent call last): File /opt/bro/bin/broctl, line 980, in module loop.onecmd(line) File /usr/lib64/python2.6/cmd.py, line 219, in onecmd return func(arg) File /opt/bro/bin/broctl, line 202, in do_install result = install.install(local) File /opt/bro/lib/broctl/BroControl/install.py, line 112, in install util.force_symlink(manager.cwd(), current) AttributeError: 'NoneType' object has no attribute 'cwd' abnormal termination, saving state ... This should be cleaned up to make this field user-modifiable as the others are, or at the very least we should implement a warning to users that they should not change the name of the field. -- This message was sent by Atlassian JIRA (v6.1-OD-09-WN#6144) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Draft API for new communication library
http://www.bro.org/development/projects/comm-ng-v2.html Feedback welcome. Would something like Cap'n Proto or Protocol Buffers help in defining/maintaining a serialization format? Never used either, just had a good impression from skimming their docs. - Jon http://kentonv.github.io/capnproto/ https://code.google.com/p/protobuf/ https://code.google.com/p/protobuf-c/ ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Draft API for new communication library
On Thu, Oct 17, 2013 at 21:54 +, you wrote: Would something like Cap'n Proto or Protocol Buffers help in defining/maintaining a serialization format? I didn't know Cap’n Proto so far but I have been wondering about using Protocol Buffers already as well. We'd have to add another dependency but it would make this stuff quite a bit less cumbersome. Do you know if their C version is well maintained? It looks rather old compared to the standard protobuf distribution. Does Cap'n Proto have a C API? Robin -- Robin Sommer * Phone +1 (510) 722-6541 * ro...@icir.org ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.org/robin ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Draft API for new communication library
FWIW, nanopb is a lightweight (read: targeted at embedded devices) C library that is compatible with protobuf. http://koti.kapsi.fi/~jpa/nanopb/ --Gilbert From: bro-dev-boun...@bro.org [bro-dev-boun...@bro.org] On Behalf Of Robin Sommer [ro...@icir.org] Sent: Thursday, October 17, 2013 6:03 PM To: Siwek, Jonathan Luke Cc: bro-dev@bro.org Subject: Re: [Bro-Dev] Draft API for new communication library On Thu, Oct 17, 2013 at 21:54 +, you wrote: Would something like Cap'n Proto or Protocol Buffers help in defining/maintaining a serialization format? I didn't know Cap’n Proto so far but I have been wondering about using Protocol Buffers already as well. We'd have to add another dependency but it would make this stuff quite a bit less cumbersome. Do you know if their C version is well maintained? It looks rather old compared to the standard protobuf distribution. Does Cap'n Proto have a C API? Robin -- Robin Sommer * Phone +1 (510) 722-6541 * ro...@icir.org ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.org/robin ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
