Re: [Bro-Dev] attributes & named types

2018-09-06 Thread Jon Siwek
On Wed, Sep 5, 2018 at 6:47 PM Vern Paxson  wrote:
>
> > 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 ...
>
> Huh, turns out there's already a "TypeType", which is the equivalent.
> All I need to do, I believe, is allow these to have attributes.

My recollection is TypeType is the type that a value gets when the
stored-value is actually just a type and doesn't quite fit what's
needed here.

Take the original example:

type a: table[count] of count &default = 5;
type b: a &read_expire = 1 min;

Declaring a variable of type 'a' or type 'b' doesn't mean that the
values stored in that variable are types themselves, they're still
just storing values of the table-type (but with different attributes
depending on 'a' or 'b').

Other ideas I'm having for solving the overall problem are:

(1) 'a' and 'b' need to actually be distinct BroType's.  Instead of
'b' being a reference/alias to 'a' with extended attributes, just
create it as it's own BroType by first cloning 'a', then adding any
additional attributes.

(2) BroType could somehow store a mapping of identifier -> attributes
so that on declaring a variable of either 'a' or 'b', we can choose
which attributes apply.  But this is relying on the idea that you have
to push the desired attributes into each new Val because you can't
mutate the underlying the BroType since multiple Vals of either type
'a' or 'b' are going to be referencing it.

- Jon
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev


Re: [Bro-Dev] Bro 2.6-beta plans

2018-09-06 Thread Jon Siwek
On Wed, Sep 5, 2018 at 5:43 PM Michael Dopheide  wrote:
>
> To be clear, Cluster::relay_rr() is gone forever?  I’ll need to rewrite some 
> policies, but also update the blog to be correct.

Yes.

- Jon

___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev


Re: [Bro-Dev] Bro 2.6-beta plans

2018-09-06 Thread Azoff, Justin S

> On Sep 5, 2018, at 6:35 PM, Jon Siwek  wrote:
> 
> 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
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

I just got 2 clusters upgraded from 

fa7fa5aa to
452eb0cb

And now everything is broken..

cpu and memory are through the roof across the board, as well as network 
traffic, but it's not logging much.

I may have created a message loop replacing the relay_rr stuff, but it's kind 
of hard to tell.

I'll do some more testing but so far this is the first issue I've ran into in 
months.

I guess one observation is that it is really hard to tell what bro/broker are 
doing.   Before you could minimally
tcpdump the communication and see what events were being sent back and forth, 
but now that is encrypted.



— 
Justin Azoff


___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev


Re: [Bro-Dev] Bro 2.6-beta plans

2018-09-06 Thread Azoff, Justin S

> On Sep 6, 2018, at 3:41 PM, Azoff, Justin S  wrote:
> 
> I just got 2 clusters upgraded from 
> 
> fa7fa5aa to
> 452eb0cb
> 
> 
> I may have created a message loop replacing the relay_rr stuff, but it's kind 
> of hard to tell.
> 
> I'll do some more testing but so far this is the first issue I've ran into in 
> months.
> 

I tested an almost stock local.bro (a few additional things disabled) and saw 
the same thing.

fa7fa5aa is fine, but with 452eb0cb everything is working really hard to do 
something.

The most noticeable thing is the network traffic on the manager changing from 
being almost idle at

300KiB TX and 3MiB RX and jumping to
20MiB TX and 12MiB RX

— 
Justin Azoff


___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev


Re: [Bro-Dev] Bro 2.6-beta plans

2018-09-06 Thread Jon Siwek
On Thu, Sep 6, 2018 at 2:47 PM Azoff, Justin S  wrote:

> I just got 2 clusters upgraded from
>
> fa7fa5aa to
> 452eb0cb
>
> And now everything is broken..
>
> cpu and memory are through the roof across the board, as well as network 
> traffic, but it's not logging much.
>
> I may have created a message loop replacing the relay_rr stuff, but it's kind 
> of hard to tell.

The recent forwarding changes would be my main suspicion and, at least
in the default scripts, there's no communication patterns that
actually make use of the automatic forwarding, so can you check if
adding "redef Broker::forward_messages = F;" to site/local.bro makes a
difference?

If it does fix things, then yeah, either I missed a forwarding loop in
the default scripts or potentially you introduced one when replacing
relay_rr (feel free to point me at stuff to look over).

(Generally may want to just leave message forwarding turned off due to
these types of dangers if that's what it turns out to be...).

> I guess one observation is that it is really hard to tell what bro/broker are 
> doing.   Before you could minimally
> tcpdump the communication and see what events were being sent back and forth, 
> but now that is encrypted.

You can redef Broker::disable_ssl=T.  I don't recall how readable the
non-encrypted communications are, but I think I did it at least once
or twice and still was able to spot event names.

- Jon
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev


Re: [Bro-Dev] Bro 2.6-beta plans

2018-09-06 Thread Jon Siwek
On Thu, Sep 6, 2018 at 3:14 PM Azoff, Justin S  wrote:


> I tested an almost stock local.bro (a few additional things disabled) and saw 
> the same thing.
>
> fa7fa5aa is fine, but with 452eb0cb everything is working really hard to do 
> something.

Thanks for that, I'll start looking into it, but still would be
helpful if you could try disabling message forwarding (or disable ssl
+ look at some captured traffic to see if you can understand what
might be happening).  Thanks.

- Jon
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev


Re: [Bro-Dev] Bro 2.6-beta plans

2018-09-06 Thread Azoff, Justin S

> On Sep 6, 2018, at 4:19 PM, Jon Siwek  wrote:
> 
> On Thu, Sep 6, 2018 at 3:14 PM Azoff, Justin S  wrote:
> 
> 
>> I tested an almost stock local.bro (a few additional things disabled) and 
>> saw the same thing.
>> 
>> fa7fa5aa is fine, but with 452eb0cb everything is working really hard to do 
>> something.
> 
> Thanks for that, I'll start looking into it, but still would be
> helpful if you could try disabling message forwarding (or disable ssl
> + look at some captured traffic to see if you can understand what
> might be happening).  Thanks.
> 
> - Jon

Yeah, that fixed it!

I re-enabled that and then disabled ssl and I am looking at the comm stuff 
going to the logger, which should just be logs


This seems to work for basic quick analysis:

[root@bro40-dev ~]# tcpdump  -n -i em1 port 47761 -A|sed 
"s/\.\.\.\.\./\n/g"|egrep -io  broker.* |head -n 1|sort|uniq  -c|sort -nr
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1, link-type EN10MB (Ethernet), capture size 262144 bytes
tcpdump: Unable to write output: Broken pipe
   8842 
broker::topic+broker::internal_comma...@u32.bro/known/certs/<$>/data/clone
   1124 
broker::topic+broker::internal_comma...@u32.bro/known/hosts/<$>/data/clone
  8 broker::internal_comma...@u32.bro/known/certs/<$>/data/clone
  5 broker::topic+broker::internal_command+@




— 
Justin Azoff


___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev


Re: [Bro-Dev] Bro 2.6-beta plans

2018-09-06 Thread Jon Siwek
On Thu, Sep 6, 2018 at 3:40 PM Azoff, Justin S  wrote:

>8842 
> broker::topic+broker::internal_comma...@u32.bro/known/certs/<$>/data/clone

Thanks, there was an unintended forwarding loop in data store
communication.  It's fixed in master now, but I've also just reverted
to generally disabling the forwarding mechanisms by default (any
specific/advanced use-cases can always choose to selectively enable
it, but the default cluster config doesn't need it for anything
currently).

For anyone doing testing, please pull the latest change from master
and give feedback on that version.

- Jon
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev