Re: [Bro-Dev] attributes & named types
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
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
> 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
> 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
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
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
> 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
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