[Bro-Dev] [Administrativa] Mailing list archives

[Robin Sommer]

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...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] reproducible segfault in master branch

[Michael Dopheide]

Excellent, thanks Jon!

-Dop

On Wed, Aug 15, 2018 at 11:18 AM, Jon Siwek  wrote:

> On Tue, Aug 14, 2018 at 10:26 PM Michael Dopheide  wrote:
> >
> > Somehow related to Broker stores and/or casting.
>
> You'll get a better error message/behavior now using:
>
> https://github.com/bro/bro/commit/f336c8c710bdeb41eb0aba88967ee90da24848b2
>
> But ultimately, you likely want to do something like this patch:
>
> ```
> --- known-hosts-with-dns.bro.orig 2018-08-15 11:07:41.0 -0500
> +++ known-hosts-with-dns.bro 2018-08-15 10:44:03.0 -0500
> @@ -113,7 +113,7 @@
>   for (ip in r$result as addr_set){
>   when ( local res = Broker::get(Known::host_store$store,ip)){
>
> - if(res?$result){
> + if(res$status == Broker::SUCCESS){
>   @if ( ! Cluster::is_enabled() )
>   Known::hosts[ip] = fmt("%s",res$result as string);
>   @else
> ```
>
> As for why some keys no longer exist in those lookups immediately
> after retrieving the full key set: my guess is they simply expired
> between those two points in time, but I didn't dig into it.  The main
> point would be to never assume the Broker::get() call succeeds, which
> was likely your intent, except "res?$result" is always true (another
> form of checking the data exists would be "res$result?$data").
>
> - Jon
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] reproducible segfault in master branch

[Jon Siwek]

On Tue, Aug 14, 2018 at 10:26 PM Michael Dopheide  wrote:
>
> Somehow related to Broker stores and/or casting.

You'll get a better error message/behavior now using:

https://github.com/bro/bro/commit/f336c8c710bdeb41eb0aba88967ee90da24848b2

But ultimately, you likely want to do something like this patch:

```
--- known-hosts-with-dns.bro.orig 2018-08-15 11:07:41.0 -0500
+++ known-hosts-with-dns.bro 2018-08-15 10:44:03.0 -0500
@@ -113,7 +113,7 @@
  for (ip in r$result as addr_set){
  when ( local res = Broker::get(Known::host_store$store,ip)){

- if(res?$result){
+ if(res$status == Broker::SUCCESS){
  @if ( ! Cluster::is_enabled() )
  Known::hosts[ip] = fmt("%s",res$result as string);
  @else
```

As for why some keys no longer exist in those lookups immediately
after retrieving the full key set: my guess is they simply expired
between those two points in time, but I didn't dig into it.  The main
point would be to never assume the Broker::get() call succeeds, which
was likely your intent, except "res?$result" is always true (another
form of checking the data exists would be "res$result?$data").

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