Re: [Bro-Dev] Queueing in Broker?

On Tue, Feb 13, 2018 at 10:35 AM, Robin Sommer wrote: > One more Broker idea: I'm thinking we should add a queuing mechanism > to Broker that buffers outgoing messages for a while when a peer goes > down. Once it comes back up, we'd pass them on. That way an endpoint > could

Re: [Bro-Dev] Queueing in Broker?

On 13 Feb 2018, at 11:35, Robin Sommer wrote: > One more Broker idea: I'm thinking we should add a queuing mechanism > to Broker that buffers outgoing messages for a while when a peer goes > down. Once it comes back up, we'd pass them on. That way an endpoint > could restart for example without

Re: [Bro-Dev] Shipping CAF with Broker?

On Tue, Feb 13, 2018 at 10:31 AM, Robin Sommer wrote: > I was wondering the other day if we could add CAF as submodule to > Broker Sounds fine to me. Also means one less variable (CAF version) to get under control when troubleshooting/debugging reported issues. - Jon

Re: [Bro-Dev] Shipping CAF with Broker?

On 13 Feb 2018, at 8:36, Seth Hall wrote: > On 13 Feb 2018, at 11:31, Robin Sommer wrote: > >> We could even go a step further and compile CAF statically into >> libbroker, so that in the end from a user's perspective all they deal >> with is Broker: if they link against it, they get everything

Re: [Bro-Dev] 'async' update and proposal

On 13 Feb 2018, at 7:44, Robin Sommer wrote: > On Thu, Feb 08, 2018 at 10:01 -0800, Johanna wrote: > >> I just wanted to quickly chime in here to say that I generally like >> the >> idea of having these contexts. > > Sounds like we all like that idea. Now the question is if we want to > wait

Re: [Bro-Dev] 'async' update and proposal

On Tue, Feb 13, 2018 at 9:44 AM, Robin Sommer wrote: > Sounds like we all like that idea. Now the question is if we want to > wait for that to materialize (which will take quite a bit more > brainstorming and then implementation, obviously), or if we want to > get async in in the

Re: [Bro-Dev] Shipping CAF with Broker?

> On Feb 13, 2018, at 11:36 AM, Seth Hall wrote: > > > > On 13 Feb 2018, at 11:31, Robin Sommer wrote: > >> We could even go a step further and compile CAF statically into >> libbroker, so that in the end from a user's perspective all they deal >> with is Broker: if they

[Bro-Dev] Queueing in Broker?

One more Broker idea: I'm thinking we should add a queuing mechanism to Broker that buffers outgoing messages for a while when a peer goes down. Once it comes back up, we'd pass them on. That way an endpoint could restart for example without us loosing data. I'm not immediately sure how/where

Re: [Bro-Dev] Shipping CAF with Broker?

On 13 Feb 2018, at 11:31, Robin Sommer wrote: > We could even go a step further and compile CAF statically into > libbroker, so that in the end from a user's perspective all they deal > with is Broker: if they link against it, they get everything they > need. > > Would that make sense? I think

[Bro-Dev] Shipping CAF with Broker?

I was wondering the other day if we could add CAF as submodule to Broker, and then just start compiling it along with everything else. A long time ago we decided generally against shipping dependencies along with Bro, but in this case it might make people's lives quite a bit easier, as hardly any

Re: [Bro-Dev] 'async' update and proposal

On Thu, Feb 08, 2018 at 10:01 -0800, Johanna wrote: > I just wanted to quickly chime in here to say that I generally like the > idea of having these contexts. Sounds like we all like that idea. Now the question is if we want to wait for that to materialize (which will take quite a bit more

Re: [Bro-Dev] Logging TCP server banners

Hi, On Tue, Feb 13, 2018 at 09:15:21AM +0100, Bencteux Jeffrey wrote: > A solution could be to blacklist such connections, i-e if there is data > sent by the client, then do not log: > > if (! is_orig && seq == 1 && c$orig$num_pkts == 2 && c$orig$size == > > 0) > > Another thing that

Re: [Bro-Dev] Logging TCP server banners

Hi, On Mon, Feb 12, 2018 at 05:18:05PM -0500, Seth Hall wrote: > This fits with a feature that I've been talking to several people > about for quite a while which would make a bit of the beginning of > each direction of a connection available in script-land. I think that would be great! > That

[Bro-Dev] Fuzzing

Hi bro team, Do you have plans to integrate oss-fuzz ? like https://github.com/google/oss-fuzz/issues/624 All the best, Philippe signature.asc Description: Message signed with OpenPGP ___ bro-dev

Re: [Bro-Dev] Logging TCP server banners

> Another thing that comes to me is what if you miss the SYN or the > SYN-ACK segment sent by your client? I meant SYN or ACK (third one in the handshake) segment sent by the client. Sorry. Regards, ___ bro-dev mailing list bro-dev@bro.org

Re: [Bro-Dev] Logging TCP server banners

> I call "TCP server banner" the first chunk of data a server sends, > before the client has sent data (if the client sends data before the > server, I don't want to log anything). A solution could be to blacklist such connections, i-e if there is data sent by the client, then do not log: >