[Zeek-Dev] Zeek and the myricom package plugin

[Justin Azoff]

Speaking of that, you made this commit:

https://github.com/J-Gras/bro-af_packet-plugin/commit/5a5d8bb74f162841111b26880137f51683e60ac1

which has the new changes(from the skeleton?) that allows it to be built
without the full source tree, but the myricom package is still using the
old cmake bits.

On Mon, Jul 15, 2019 at 9:57 AM Jan Grashöfer <jan.grashoefer at gmail.com>
wrote:

> So https://github.com/J-Gras/bro-af_packet-plugin/issues/11 isn't an
> issue anymore due to backwards compatible symlinks?
>
> On 13/07/2019 03:22, Michał Purzyński wrote:
> > We just migrated to master with the name change and the afpacket plugin,
> so I know the Zeek code is OK.
> >
> >
> >> On Jul 12, 2019, at 5:52 PM, Jon Siwek <jsiwek at corelight.com> wrote:
> >>
> >>
> >>
> >>> On Fri, Jul 12, 2019 at 3:46 PM Michael Dopheide <dopheide at es.net>
> wrote:
> >>> Background:  We like to run 'master', but with the name change it
> broke too many things and we had to stick to 2.6.2 for the time being.
> Since then, I've started trying to convert our ansible scripts and prepare
> to make the jump.  Today I discovered the bro-myricom package would fail to
> build.
> >>>
> >>> Has anyone attempted this yet?  I can get it to build with a couple
> minor changes:
> >>>
> >>>   src/Myricom.cc
> >>> @@ -1,4 +1,4 @@
> >>>     #include "bro-config.h"
> >>>     #include "zeek-config.h"
> >>>
> >>
> >> Can you give more info on how to reproduce this one?  The master branch
> should currently be installing "zeek-config.h" along with a symlink to it
> named "bro-config.h", with the ideal being that people wouldn't have to
> make this change.
> >>
> >> IIRC, since we changed our default install prefix from /usr/local/bro
> to /usr/local/zeek, there's also a bit different logic if we find someone
> is going to install over an old Bro installation that was still at the old
> prefix, so might be good to know if you're installing fresh or upgrading
> from the old version.
> >>
> >>
> >>>   tests/Scripts/get-bro-env
> >>> @@ -8,7 +8,7 @@ bro=`cat ${base}/../../build/CMakeCache.txt | grep
> BRO_DIST | cut -d = -f 2`
> >>>     if [ "$1" = "brobase" ]; then
> >>>         echo ${bro}
> >>>     elif [ "$1" = "bropath" ]; then
> >>>         ${bro}/build/bro-path-dev
> >>>         ${bro}/build/zeek-path-dev
> >>>
> >>
> >> This one just looks like an oversight on our end, we'll need to keep
> creating (or symlinking) that "build/bro-path-dev" file.
> >>
> >>>
> >>> Unfortunately, we end up with another problem:
> >>> zeek -N
> >>> internal error in /home/zeek/zeek-myricom/build/scripts/./init.bro,
> line 37: bad reference count [0]
> >>>
> >>> Line 37 is just SNF_RSS_IP:
> >>>          const snf_rss_mode: set[RssField] = {
> >>>                  SNF_RSS_IP,
> >>>                  SNF_RSS_SRC_PORT,
> >>>                  SNF_RSS_DST_PORT
> >>>          } &redef;
> >>
> >> This doesn't look related to the Bro-Zeek renaming, but possibly some
> enum optimizations we did that are being tickled by what this plugin is
> doing.  Particularly there's an enum being declared/defined twice:
> >>
> >>
> https://github.com/sethhall/bro-myricom/blob/89815d89e0ba6957149521cf99e608c0dc909f6d/src/myricom.bif#L9-L15
> >>
> >> and
> >>
> >>
> https://github.com/sethhall/bro-myricom/blob/89815d89e0ba6957149521cf99e608c0dc909f6d/scripts/init.bro#L26-L32
> >>
> >> Possibly old versions of Bro were fine with that happening, but not
> anymore.  Generally seems odd that we don't explicitly give an error
> message to indicate the same enum being defined in two separate places.
> >>
> >> I'll look more into what the proper fix is next week, but if you're
> just looking to try to get something working in the meantime, a workaround
> may be to comment out or remove the entire RssField enum definition inside
> the init.bro script.
> >>
> >>> Clearly I'm not gonna get lucky with an easy fix.  Doing a simple
> search/replace for bro/zeek across the whole tree doesn't seem viable as
> things like bro-bif.h haven't changed names.  Has anyone started digging
> into how plugin packages will need to be updated?
> >>
> >> Generally the idea is to be mostly backward compatible so people aren't
> forced to make any changes to external plugins, but looks like there's a
> couple small things we overlooked or had not tested that we'll want to fix
> before the 3.0 release, so thanks for the early feedback.
> >>
> >> - Jon
> >> _______________________________________________
> >> zeek-dev mailing list
> >> zeek-dev at zeek.org
> >> http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
> >
> >
> > _______________________________________________
> > zeek-dev mailing list
> > zeek-dev at zeek.org
> > http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
> >
> _______________________________________________
> zeek-dev mailing list
> zeek-dev at zeek.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
>


-- 
Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/zeek-dev/attachments/20190715/3210626c/attachment.html