CAF port? If it's recent, Bro should be able
to link against that.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
f an error happens at that
> time, I'd say it's fine to completely abort -- it's unlikely or hard
> to say whether Bro would operate well if it proceeded after an error
> that early in initialization.
Yeah, that makes sense.
Robin
--
Robin Sommer * Corelight, Inc.
, as it will impact custom log files that people
create in their own scripts.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
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
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
ike the ones listed above.
Sounds good to me.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
ink there's a way just redirect a git client, but maybe we could get
some error message into the output or something? Not sure.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
h
On Fri, Sep 14, 2018 at 11:36 -0500, Jonathan Siwek wrote:
> I did some label tweaking and reduced some prefix names: "Component"
> -> "Area" and "Difficulty" -> "Pain".
Ok, thanks, makes sense.
Robin
--
Robin Sommer * Corel
ght? Doing it all at the same time could
avoid confusion ("everything is on github now" is an easier
statement), but would also make the process more complex. Maybe the
real question here is if we want to switch repositories before or
after 2.6?
Robin
--
Robin Sommer * Corelight, Inc. *
= 0; i < num; ++i) {
+auto ev = broker::bro::Event(std::string("event_1"),
+ std::vector{42, "test"});
+out.push(std::make_pair(topic_str, std::move(ev)));
+ }
global_count += num;
},
[=](c
alization that's the bottle-neck, then we'll need to come up with
something else indeed.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
ntly be used if one writes a Bro
> script that publishes plain events (message type 1 in bro.hh)?
Yes to that. Non-Bros can exchange events (assuming they know the
schema), but not logs.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * ww
and still needs to be addressed. As part of upgrading that, I think it
can make sense to think about documenting the format we end up
chosing.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-de
ly, so that it's easier
to synchronize with an ongoing stream.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
e diverse so that self-description doesn't really seem
feasible/useful. Republishing a relevant subset certainly sounds
better for that; or, if it's really a bulk feed that's desired, some
out-of-band mechanism to convey the schema information somehow.
Robin
--
Robin Sommer * Corelight,
ght? Logs have a
different wire format and they actually come with meta data describing
their columns.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.ber
Quick reminder: Please keep in mind that mails to the Bro mailing
lists are archived publically. We had a couple of cases recently where
internal information went to a list, ending up in the archive, where
it's difficult to remove from. Thanks,
Robin
--
Robin Sommer * Corelight, Inc. * ro
t's in fact also
an argument against my original thinking how this could help unify
scripts --- well, unless we'd go with Jan's thought of subtopics
(e.g., subscribe("bro/cluster/worker/intel", local_raise=T).
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.c
ing "real" routing in Broker
> right from the start.
In an ideal world, yes, that would certainly be nice to have. But it's
a larger task that I don't think we would be able to finish for 2.6
anymore. So, I'd put that on the list for later.
Robin
--
Robin Sommer * Corelight, Inc.
manually
> handle+forward the event on proxies.
Ok, let's make that change then, I think removing relay() will help
for sure making the API easier.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
/cluster/worker if both go to all workers? Or is it so that some
workers can decide not to receive the intel events?
(And technically, subscriptions are prefixed based, so anybody
subscribing to bro/cluster/worker automatically gets
bro/cluster/worker/intel as well; not sure if that helps
cing in the case of there being more than one
> route to a subscriber.
Yeah, I'm becoming more and more convinced that in the end we won't
get around adding a "real" routing layer that takes of such things
under the hood.
Robin
--
Robin Sommer *
hat would also make later changes easier &
centralized to how topics and connections are set up.
For other use cases, it should still be possible to configure things
independently, too, though (say, for talking to external Broker
applications).
Robin
--
Robin Sommer *
tandalone to raise the event
> directly if not being ran in a cluster.
Or we generally raise published events locally as well if the node is
subscribed to the destination topic. There are pros and cons for that
I think.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.co
f time and so there's
> inconsistencies to be expected) ? Or due to being a mishmash of both
> old and new?
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.b
at doesn't make it nice. ;-) It
makes it very hard to follow the logic; when reading through the
scripts I got lost multiple times because some "@if I-am-a-manager"
was somewhere half a page earlier, disabling the code I was currently
looking at for most nodes. We probably can't totally avo
ch consistency right now in how scripts
structure their communication. That's not surprising, given that we're
just starting to use all this, but it suggests that we have room for
improvement in our abstractions. :)
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.co
use
cases.)
I have another question about this specific case: we use relay_rr()
only for sending Intel::insert_indicator. Intel::remove_indicator gets
published normally through auto_publish(). Why the difference?
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.
relay(), and that's the one above.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
On Mon, Jul 30, 2018 at 13:30 -0500, Jonathan Siwek wrote:
> Seems clunky and could get dicey
Agreed. :) It'd just be a heuristic to catch some obvious errors. I
don't think there's more we can do, we can't really catch loops
statically by looking at the code.
Robin
--
Robin Som
ode send a message to all
subscribed topics, and watch for TTL violations?
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
function around that
> if they find it too verbose and always want to use certain defaults?
They could, but my general point is that it'd be nice to have a simple
API that covers the most common uses cases directly and intuitively.
Then let people change defaults if they have to and know what they are
ther to raise events
received on a given topic locally, or just forward). I think I can see
that either way.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
time plus another atomic<> counter
tracking if there are any pending message. And go into the locked case
only if the latter is non-zero?
> General changes/improvements in CAF itself may be warranted here
Yeah, sounds like it.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org *
ything.
I then ran it through oprofile. Output is attached. There's indeed
some locking showing up high in there, but I can't tell if that's just
expected idling in CAF. I am bit surprised to see a number of
std::chrono() methods showing rather prominently that I would expect
to be cheap.
Robin
--
gt; There's some mutex locking going on there, but w/o data stores
> involved there shouldn't be anyone competing for them.
>
> - Jon
>
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http:
's the trade-off between
performance and consistency. Where's the code that's doing this
blocking? Would it be possible to not block right away, but sync up
with Broker when events are flushed the next time? (Like we had
discussed before as a general mechanism for making async operations
consistent)
Robin
)
; Current master
# zcat 2009-M57-day11-18.trace.gz | time bro -r - tests/m57-long.bro
2191.59user 1606.69system 12:39.92elapsed 499%CPU (0avgtext+0avgdata
228400maxresident)
Bro must still be blocking somewhere when reading from trace files.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org
for folks. If things seem to
work, we should definitely also announce the merge more broadly.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
d and
resolved. We'll see. :)
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
ndard scripts
(and if not, please let us know!)
Many thanks to Jon Siwek for the recent integration work tying up all
the loose ends and getting Broker mergeable. Also thanks to those who
have tested it already from the actor-system branch.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.i
A tickets into GitHub. What do others think?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
we'd want a PR to be created
> against each individual repo?
Good point. Creating just one root PR that mentions the others sounds
good to me for such cases.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
d ones), they will just come
with a little bit of a delay (within 10-15 minutes should be
reasonable). And if we want we can trigger that through webbhooks,
too, for immediate notification, would just need a bit of work to get
it set up.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org
n way would be instead creating one event per
type of payload and then raising the corresponding event as you parse
packets and find out what's in there.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing lis
e kind of our version of methods). Same for Ruby. I
looked around for a few more minutes for other languages, but didn't
immediately find any that even have any set operators at all (only
methods/functions for union/intersection/etc.).
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.i
t, but at least it's explicit and we couldn't
come up with anything better if we want to have such operations as
operators. Might work for some other types as well.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-d
d IMO, unless it does actually prevent us from building
binary packages for RH, that would be a problem.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
ghts on the best way to proceed.
> >>
> >
> > Maybe delete the branch from the official git repo and push it to your own
> > github fork.
> >
> > - Jon
> >
> _______
> bro-dev mailing list
t a feasible compromise to allow cmake 2.8 if we don't need to
build CAF? So either people have cmake 3.0 or they need to build CAF
themselves and say --with-caf=...?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mail
ot; doesn't sound great to me :-). Is it just me feeling
that way?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
efined
This one I'm unsure about. The point about the order being undefined
seems odd. If I don't care about order, wouldn't I stay with a set?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
).
This has interesting implication for BIT-1431: if overloading worked
work, that could take the place of the attribute suggested
there.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing l
ts to insert the key
> with a sane default value (e.g. zero/empty) in those cases, otherwise,
> it's awkward/race-prone to require they do it themselves.
Agree with this as well, has always felt a bit awkward to me too.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
ich initialization that refers too,
may not be feasible.
Are there other differences with stores between online and offline
operation?
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@b
e if there's a middle-ground
that would give us the best of both worlds: easy of installation for
Bro users, while remaining flexible for external Broker/CAF usages.
But agree that this needs more thought before moving ahead with
anything. Thanks for bringing that up, Dominik.
Robin
--
Robin Sommer
uld be a problem
for some use cases, we might need to add way to recognizes duplicates.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
s; #=originator;
superlinear/policy//worm.bro:=0 _expire = 2
days _func=expi; # =originator;
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
On Tue, Feb 13, 2018 at 11:02 -0600, you wrote:
> On Tue, Feb 13, 2018 at 9:44 AM, Robin Sommer <ro...@icir.org>
think consumer-side is important? We already can not prevent a peer
from sending too much data during normal operation either.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.or
ill needs some thinking. I'm
getting the sense though that we'll need it for some applications,
osquery being the main one on my mind.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
% sure if that's straight-forward to do, but I
hope so ...
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
we'd integrate that. For outgoing
messages, we could add it to the transparent reconnect. However, for
incoming connections, where the local endpoint doesn't have a notion
of "that peer should be coming back", it might not be as straight
forward?
Robin
--
Robin Sommer * ICSI/LBNL * ro..
perspective all they deal
with is Broker: if they link against it, they get everything they
need.
Would that make sense?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http
t more
brainstorming and then implementation, obviously), or if we want to
get async in in the current state and then put that on the TODO list?
I can see arguments either way, curious what others think.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org
based subsets were the main use case
anways. Actually I'm not even sure anymore if there might have been a
custom execute-my-own-function scope as well, I'll see if I can find
the old code somewhere.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org
ff in flight.
On the other hand, I don't think this can be avoided though: either we
want dependencies or we don't. You can't have the cake and it eat it
too I guess. :)
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mail
ope" is the scheduling
granularity, e.g., "by connection". "context" is the current
instantiation of that scope (e.g., "1.2.3.4:1234,2.3.4.5:80" for
connection scope).
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
tion suspends, halt all handlers that
depend on the same context (e.g., same connection). More on that idea
in this paper: http://www.icir.org/robin/papers/ccs14-concurrency.pdf
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
a big deal for anything,
as the cases where the new behaviour may actually lead to significant
differences should be rare.
Thoughts?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
could use that infrastructure
for a yield keyword.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
where we want to get to).
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
ss IdentifierUpdate : public Message {
> public:
>IdentifierUpdate(std::string id_name, data id_value)
> -: Message(Message::Type::IdentifierUpdate, {id_name, id_value}) {
> +: Message(Message::Type::IdentifierUpdate, {std::move(id_name),
> +
On Fri, Dec 01, 2017 at 15:22 +, you wrote:
> Now I'm glad I never got it to work right :-)
Me too. :-)
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
h
d it also won't work for atomic values, at least not since
https://github.com/bro/bro/commit/5b889360705120c9061390214881ea376819c669
went in. :)
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro
>
> - Jon
>
> _______
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
On Mon, Nov 06, 2017 at 09:16 -0500, you wrote:
> versions of awk and they all support scientific notation
I'm wondering if that's true for other log parsers as well. The main
thing I'd want to avoid is breaking people's existing scripts. We
could make it an option?
Robin
--
Robin Som
broker
> endpoints originally being able to self-identify with the friendly
> names, so these new hello/bye events wouldn’t have been needed, but it
> didn’t seem like that functionality was around anymore.
I actually don't remember. If we had it, not sure what happened to it.
Robin
--
This is coming together quite nicely. Not sure if it's stable yet, but
I'll just go ahead with some feedback I noticed looking over the new
cluster API:
- One thing I can't quite tell is if this is still aiming to
maintain compatibility with the old communication system, like
by
et the redef approach. I was more
thinking about consistency with other script APIs. We use redef for
simple tuning (single-value options, timeouts, etc), but less these
days for more complex setups (see logging and input frameworks). I'd
be interested to hear what other people prefer.
Robin
--
efault_store_dir = "/home/jon/stores";
Can the default_store_dir be set to some standard location through
BroControl? Would be neat if this all just worked in the standard case
without any custom configuration at all.
> BroControl Example Usage
>
I'
For those tracking the new Broker version in the topic/actor-system
branch: A new CAF release 0.15.4 is out now that's incorporating
everything that code requires, so no need to use the CAF "develop"
branch anymore.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir
warranted over re-using
> ‘const’ for configuration values as the semantics are now blatantly different
> than what ‘const’ is expected to mean. i.e. config values are meant to
> change at run-time, but only via a restricted API and ‘const’ is still
> intended to never change at run-tim
nd we'd have Broxygen pick up on it too.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
oesn't, I don't know, that's part of why I keep looking for feedback.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
ot;async" works? (If you
can honestly answer "yes" in under 15 minutes, I buy you a beer. ;-)
Robin
PS: See the TODOs in that commit for the current state of the code.)
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
_
e. The downside for you might be a bit of wasted time
if discussion afterwards leads to a different approach. So feel free
to also ask for feedback upfront, whatever seems best. Either way,
getting it to work by applying the most straightforward approach is
definitely the right rule of thumb.
Robin
-
can even reuse that implementation later by making it more
generic.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
use for any given one.
> That's not possible because there's infinite ways you can create
> composite types (tables, sets, vectors, etc).
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
On Sat, May 13, 2017 at 00:28 -0500, you wrote:
> We'll look at upgrading our test cluster (and UIUC's test cluster) to
> master.
Sounds good, let us know how that is going.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org
Using
## the same value here will make the hashes compatible between independent
Bro
q## instances. If left unset, Bro will use a temporary local seed.
const global_hash_seed: string = ""
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * ww
s or if I am
> doing something not quite right.
Bloom filters should work over communication. What's the code for the
two sides? The error messages sound like these are filters of
different types.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www
don’t
> require/support poll-ability should also be possible to integrate.
I need to think about that argument ... Did you try reading from files
while also doing communication (that would be pseudo-realtime mode),
or was the pcap the only source of input?
Robin
--
Robin Sommer * ICSI/LBNL * ro
en before we'd
consider moving to a CAF-based loop?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
and FreeBSD for, say, the two most
recent major releases of each and also consider common alternative
capturing solutions (pfring, netmap, afnet?), I'd be pretty
comfortable switching.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
mption is that dynamic plugins are compiled
separately. It would indeed be nice to have the Bro CMake
configuration pick up further dynamic plugins to compile along.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
b
ce).
Yeah, that makes sense. We can switch back once we have something
better.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
ither way, a better
Bro-side UI for Broker is coming, we just need to get the various
pieces in place first that people are working on currently before we
can move forward.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-d
-plugins-2.3
topic/robin/pktsrc
topic/robin/plugin-updates
topic/robin/reader-writer-plugins
topic/vladg/homebrew-openssl
%% bro/master/src/3rdparty
topic/jsiwek/file-signatures
topic/jsiwek/libmagic-integration
topic/jsiwek/new-libmagic
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org
:)
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
could add some automatic way instead, like calling the
files __bare__.bro and have Bro find them automatically (but to
Johanna's point, not sure if that would cause load-order problems).
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org
g some code needing to be
thread-safe, while other parts break every rule in the book in that
regard, is also confusing; we have that challenge already with the
logging and input frameworks.))
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org
1 - 100 of 982 matches
Mail list logo
