From jsiwek at ncsa.illinois.edu Mon Nov 1 14:25:04 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Mon, 1 Nov 2010 16:25:04 -0500 (CDT) Subject: [Bro-Dev] Configure Wrapper (Cmake for Bro) In-Reply-To: <20101018043815.GQ17675@icir.org> Message-ID: <8516738.249.1288646704177.JavaMail.jsiwek@tangent.ncsa.illinois.edu> I wanted to revisit wrapping the Bro CMake configuration into an autotools-like configure script: > > * require build options to be set via a BuildOptions.cmake file, to > > be copied into build directory by user and edited as desired. If > > non-existent in build directory, the top-level one can be copied > > automatically. > > Would that mean that setting any build option (even just --prefix) > involves editing the BuildOptions.cmake and copying it to the right > place? If so, I'm not sure I really like that, it sounds cumbersome > and quite non-standard. > > One alternative which I think wasn't discussed but I have seen with > other cmake-based projects is providing a "configure" wrapper script > with a standard autotools-like interface that then sets up the build > accordingly for cmake. I'm not quite sure how others are doing that, > but can't we just have such a wrapper *create* the > BuildOptions.cmake? The wrapper would essentially be just a big > switch-statement printing out the right values. As a developer testing different build configurations I definitely found it to be cumbersome to have to edit a file to change settings, so I'll agree that providing the configure wrapper has that added benefit (the major drawback still is that it's extra maintenance). But I've come to realize that having the wrapper write build options to an intermediate file is an unnecessary indirection and redundant since the CMakeCache.txt (CMake automatically generates this) serves pretty much the same purpose. Instead the wrapper can just directly interface with CMakeCache.txt by invoking `cmake -D :=` So I'm going to remove the intermediate BuildOptions.cmake file unless someone can think of legitimate uses for it. Leaving it seems like it will just add an extra point of confusion. - Jon From robin at icir.org Mon Nov 1 21:45:43 2010 From: robin at icir.org (Robin Sommer) Date: Mon, 1 Nov 2010 21:45:43 -0700 Subject: [Bro-Dev] Configure Wrapper (Cmake for Bro) In-Reply-To: <8516738.249.1288646704177.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <20101018043815.GQ17675@icir.org> <8516738.249.1288646704177.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20101102044543.GG91949@icir.org> On Mon, Nov 01, 2010 at 16:25 -0500, you wrote: > pretty much the same purpose. Instead the wrapper can just directly > interface with CMakeCache.txt by invoking `cmake -D > :=` Sounds good. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From seth at icir.org Wed Nov 3 14:08:53 2010 From: seth at icir.org (Seth Hall) Date: Wed, 3 Nov 2010 17:08:53 -0400 Subject: [Bro-Dev] skeleton script try #2 Message-ID: <644518D3-7EF7-473E-9652-458A517B5AFF@icir.org> I'm including the Apple "Pages" file and a rendered PDF for those without Pages. I split all of the comments intended for the script author out into comments along the left side and left the comments that the script author might write for the benefit of the script user or future developer inline in the script. I still have not addressed a style for variable and function documentation to be auto parsed yet. .Seth -------------- next part -------------- A non-text attachment was scrubbed... Name: Skeleton script with comments.pdf Type: application/pdf Size: 109206 bytes Desc: not available Url : http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20101103/f5901b70/attachment.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: Skeleton script with comments.pages Type: application/octet-stream Size: 89444 bytes Desc: not available Url : http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20101103/f5901b70/attachment.obj From robin at icir.org Wed Nov 3 20:36:40 2010 From: robin at icir.org (Robin Sommer) Date: Wed, 3 Nov 2010 20:36:40 -0700 Subject: [Bro-Dev] skeleton script try #2 In-Reply-To: <644518D3-7EF7-473E-9652-458A517B5AFF@icir.org> References: <644518D3-7EF7-473E-9652-458A517B5AFF@icir.org> Message-ID: <20101104033640.GC73655@icir.org> On Wed, Nov 03, 2010 at 17:08 -0400, you wrote: > I split all of the comments intended for the script > author out into comments along the left side and left the comments > that the script author might write for the benefit of the script > user or future developer inline in the script. This separation is very nice! That makes it visually very clear what's what. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From robin at icir.org Thu Nov 4 16:44:13 2010 From: robin at icir.org (Robin Sommer) Date: Thu, 4 Nov 2010 16:44:13 -0700 Subject: [Bro-Dev] Broccoli Python bindings In-Reply-To: <1917820091.839.1288912140016.JavaMail.confluence@wiki.ncsa.uiuc.edu> References: <1917820091.839.1288912140016.JavaMail.confluence@wiki.ncsa.uiuc.edu> Message-ID: <20101104234413.GA60474@icir.org> I'm just wondering whether we should split out the Broccoli Python bindings into their own package as well? Probably makes sense, and makes them easier to install. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From seth at icir.org Thu Nov 4 18:46:04 2010 From: seth at icir.org (Seth Hall) Date: Thu, 4 Nov 2010 21:46:04 -0400 Subject: [Bro-Dev] Broccoli Python bindings In-Reply-To: <20101104234413.GA60474@icir.org> References: <1917820091.839.1288912140016.JavaMail.confluence@wiki.ncsa.uiuc.edu> <20101104234413.GA60474@icir.org> Message-ID: On Nov 4, 2010, at 7:44 PM, Robin Sommer wrote: > I'm just wondering whether we should split out the Broccoli Python > bindings into their own package as well? Probably makes sense, and > makes them easier to install. How does it make them easier to install? I would guess that if the build system for Broccoli automatically detected the python header and library (or ruby for that matter) and installed the binding along with the library that would be easier. I don't know how the packager maintainers for various OSs feel about it though. .Seth From robin at icir.org Thu Nov 4 21:27:38 2010 From: robin at icir.org (Robin Sommer) Date: Thu, 4 Nov 2010 21:27:38 -0700 Subject: [Bro-Dev] Broccoli Python bindings In-Reply-To: References: <1917820091.839.1288912140016.JavaMail.confluence@wiki.ncsa.uiuc.edu> <20101104234413.GA60474@icir.org> Message-ID: <20101105042738.GG83668@icir.org> On Thu, Nov 04, 2010 at 21:46 -0400, you wrote: > How does it make them easier to install? Thas was ambigious, sorry: I meant easier for creating the build system. As it is, it needs to do a mix of the CMake installation for libbroccoli, and the Python setup.py for the bindings. The old autotools setup avoids that by just not installing the bindings by default, but that's not great, in particuar because broctl depends on them. > I don't know how the packager maintainers for various OSs feel about it though. That's another point, right. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From seth at icir.org Thu Nov 4 22:04:19 2010 From: seth at icir.org (Seth Hall) Date: Fri, 5 Nov 2010 01:04:19 -0400 Subject: [Bro-Dev] Broccoli Python bindings In-Reply-To: <20101105042738.GG83668@icir.org> References: <1917820091.839.1288912140016.JavaMail.confluence@wiki.ncsa.uiuc.edu> <20101104234413.GA60474@icir.org> <20101105042738.GG83668@icir.org> Message-ID: <33B278C2-A87D-43D4-90B7-BB9DC441811A@icir.org> On Nov 5, 2010, at 12:27 AM, Robin Sommer wrote: > Thas was ambigious, sorry: I meant easier for creating the build > system. Ah, ok. That makes sense I think. :) >> I don't know how the packager maintainers for various OSs feel about it though. > > That's another point, right. I was planning on merging the ruby bindings into broccoli at some point, but now it sounds like I shouldn't? .Seth From robin at icir.org Thu Nov 4 22:36:02 2010 From: robin at icir.org (Robin Sommer) Date: Thu, 4 Nov 2010 22:36:02 -0700 Subject: [Bro-Dev] Broccoli Python bindings In-Reply-To: <33B278C2-A87D-43D4-90B7-BB9DC441811A@icir.org> References: <1917820091.839.1288912140016.JavaMail.confluence@wiki.ncsa.uiuc.edu> <20101104234413.GA60474@icir.org> <20101105042738.GG83668@icir.org> <33B278C2-A87D-43D4-90B7-BB9DC441811A@icir.org> Message-ID: <20101105053602.GR83668@icir.org> On Fri, Nov 05, 2010 at 01:04 -0400, you wrote: > I was planning on merging the ruby bindings into broccoli at some point, but now it sounds like I shouldn't? Not sure yet, waiting for more opinions ... Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From slagell at ncsa.illinois.edu Fri Nov 5 07:53:12 2010 From: slagell at ncsa.illinois.edu (Adam Slagell) Date: Fri, 5 Nov 2010 09:53:12 -0500 (CDT) Subject: [Bro-Dev] Broccoli Python bindings In-Reply-To: <20101105053602.GR83668@icir.org> References: <1917820091.839.1288912140016.JavaMail.confluence@wiki.ncsa.uiuc.edu> <20101104234413.GA60474@icir.org> <20101105042738.GG83668@icir.org> <33B278C2-A87D-43D4-90B7-BB9DC441811A@icir.org> <20101105053602.GR83668@icir.org> Message-ID: <7F33E4E5-E9B1-44E3-A72E-03826850B3D5@ncsa.illinois.edu> Just got back into town and will talk with jon about this when he gets back Monday and give you our opinion from a packaging perspective. Sent from my mobile On Nov 5, 2010, at 12:36 AM, Robin Sommer wrote: > > On Fri, Nov 05, 2010 at 01:04 -0400, you wrote: > >> I was planning on merging the ruby bindings into broccoli at some point, but now it sounds like I shouldn't? > > Not sure yet, waiting for more opinions ... > > Robin > > -- > Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org > ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org > _______________________________________________ > bro-dev mailing list > bro-dev at bro-ids.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > From vallentin at icir.org Fri Nov 5 09:11:40 2010 From: vallentin at icir.org (Matthias Vallentin) Date: Fri, 5 Nov 2010 09:11:40 -0700 Subject: [Bro-Dev] Broccoli Python bindings In-Reply-To: <33B278C2-A87D-43D4-90B7-BB9DC441811A@icir.org> References: <1917820091.839.1288912140016.JavaMail.confluence@wiki.ncsa.uiuc.edu> <20101104234413.GA60474@icir.org> <20101105042738.GG83668@icir.org> <33B278C2-A87D-43D4-90B7-BB9DC441811A@icir.org> Message-ID: <20101105161140.GS34938@icsi.berkeley.edu> > I was planning on merging the ruby bindings into broccoli at some > point, but now it sounds like I shouldn't? It seems to me the language should ship together with Broccoli. When adding more new languages in the future, some "configure" script could help in selecting only a subset. But conceptionally, the bindings *are* Broccoli, yet merely offer a different interface. That said, my vote would be to ship them together. Matthias From jsiwek at ncsa.illinois.edu Fri Nov 5 15:35:51 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Fri, 5 Nov 2010 17:35:51 -0500 (CDT) Subject: [Bro-Dev] Broccoli Python bindings In-Reply-To: <20101105161140.GS34938@icsi.berkeley.edu> Message-ID: <489295009.6822.1288996551322.JavaMail.root@zimbra-1.ncsa.uiuc.edu> I see three major areas to think about (some thoughts may be applicable to more than just Broccoli bindings). Here's my decomposition: 1) The build system. I don't see an issue right now with integrating the Python setup.py into CMake -- it should basically involve adding a custom target that delegates the build to setup.py at "make" time and then also delegating to setup.py at "make install" time. So if we kept broccoli + bindings together, it seems like it's not hard for us to make it so that the bindings are built/installed by default (or selected) which differs from current autotools setup. Separating bindings would offer a little simplification to its build system -- it can assume that broccoli is already built/installed. 2) The standard package management system per OS. Seems like it's pretty standard for Debian packages to separate the bindings and library packages. I don't think it's incredibly harder to generate separate packages even if you're working from a single source tree, but it does seem that if they were separate to begin with, then it simplifies the packaging process a little and makes it easier to add optional bindings for other languages. 3) The git repo organization. If bindings are kept in their own repos, then don't we gain some flexibility on assigning maintainers that might differ from the broccoli maintainer? How useful may that be? The broccoli repo could also reference binding repos via git submodules so it's not like they're totally disconnected. I think we should plan on using submodules more generally to keep coherence between Bro and subcomponents. ----- In general, I think the goal is to decouple components that don't necessarily need to be maintained/developed as a whole unit while still appearing like a monolithic/coherent project to users. The later part is accomplished by "shipping" to users either a) via software repositories Here the package dependencies will be set up such that they get the right set of packages for what they want. (e.g. if they pick 'broctl' they should get 'libbroccoli', 'libbroccoli-python', 'bro-core' ...) b) via an all source tarball distributed on Bro web site. Here I think we have to ship source for all components and also supply a glue that makes the build system do the right thing for a user's chosen configuration. (This is where things might get tricky) ----- So to summarize: I'm leaning towards having the bindings in it's own repo + RPM/DEB package since there's minor benefits and also fits in with the spirit of what we're doing everywhere else. Maybe I'll have more thoughts Monday after talking with Adam, but I wanted to get these ramblings out there for others to challenge/discuss. - Jon From gregor at icir.org Fri Nov 5 18:26:50 2010 From: gregor at icir.org (Gregor Maier) Date: Fri, 05 Nov 2010 18:26:50 -0700 Subject: [Bro-Dev] Bro internal integers types. Use stdint.h Message-ID: <4CD4AEDA.5050206@icir.org> Hi, Currently Bro defines it's own integer types (uint32, uint64, bro_int_t, etc.) with the help of ifdefs and autoconf. Furthermore, Bro uses ifdef to decide which printf format to use for formatting 32 and 64 bit integers. As part of the planned event engine cleanup, I suggest that we a) make sure that everything that can potentially overflow (counters) are 64 bit wide (in addition to enabling --enable-int64) b) use the standard type uint64_t, int32_t, etc. from inttypes.h (*) c) use the PRI* macros for *printf formatting (also from inttypes.h) (*) inttypes.h is part of both, C99 and POSIX. See http://www.opengroup.org/onlinepubs/000095399/basedefs/inttypes.h.html Comments? cu Gregor -- Gregor Maier gregor at icir.org Int. Computer Science Institute (ICSI) gregor at icsi.berkeley.edu 1947 Center St., Ste. 600 http://www.icir.org/gregor/ Berkeley, CA 94704 USA From robin at icir.org Fri Nov 5 19:05:32 2010 From: robin at icir.org (Robin Sommer) Date: Fri, 5 Nov 2010 19:05:32 -0700 Subject: [Bro-Dev] Bro internal integers types. Use stdint.h In-Reply-To: <4CD4AEDA.5050206@icir.org> References: <4CD4AEDA.5050206@icir.org> Message-ID: <20101106020532.GU7155@icir.org> On Fri, Nov 05, 2010 at 18:26 -0700, you wrote: > As part of the planned event engine cleanup, I suggest that we > a) make sure that everything that can potentially overflow (counters) > are 64 bit wide (in addition to enabling --enable-int64) > b) use the standard type uint64_t, int32_t, etc. from inttypes.h (*) > c) use the PRI* macros for *printf formatting (also from inttypes.h) Ack. My only concern is that I think Vern and I have discussed something along these lines in the past and there was some road-block. Vern, do you remember anything in that regard? Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From vern at icir.org Sat Nov 6 13:21:42 2010 From: vern at icir.org (Vern Paxson) Date: Sat, 06 Nov 2010 13:21:42 -0700 Subject: [Bro-Dev] Bro internal integers types. Use stdint.h In-Reply-To: <20101106020532.GU7155@icir.org> (Fri, 05 Nov 2010 19:05:32 PDT). Message-ID: <20101106202142.0D5C436A4F2@taffy.ICSI.Berkeley.EDU> > My only concern is that I think Vern and I have discussed something > along these lines in the past and there was some road-block. Vern, > do you remember anything in that regard? It's not coming to mind ... Vern From jsiwek at ncsa.illinois.edu Sat Nov 6 18:34:46 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Sat, 6 Nov 2010 20:34:46 -0500 (CDT) Subject: [Bro-Dev] Broctl installation process clean up In-Reply-To: <1764677733.7721.1289091728777.JavaMail.root@zimbra-1.ncsa.uiuc.edu> Message-ID: <1279086782.7741.1289093686983.JavaMail.root@zimbra-1.ncsa.uiuc.edu> As part of the CMake porting process, I think it makes sense to clean up Broctl's initial installation process, which currently creates a dependence between some of the `broctl install` functionality and the Bro distribution source dir. That's not going to be compatible when we want to have Broctl packaged individually as a Bro optional/add-on package. I propose that we let CMake take care of the dependency checking (other Bro components need to be installed first) and initial installation of the Broctl files while `broctl install` would still be responsible for generating scripts from templates, updating to new version of .cfg and site policy files, and syncing to worker nodes (at least I think that's a summary of what broctl does). The specific functionality that would be lost is `broctl install --make` (used by current Makefile) and also the DevMode=1 feature that seems to basically turn `broctl install` into a `broctl install --make` in order to update the files from the distribution source. Instead, the `make install` target generated by CMake can accomplish that task and probably remind the user that they must also `broctl install` if they want to update scripts/config or sync to workers. I think I've nearly thought this all the way through and wrote the details down here, for the curious: https://wiki.ncsa.illinois.edu/display/BROWATERS/CMake+Porting+Progress#CMakePortingProgress-BroctlTasks%2FNotes Good plan or bad plan? - Jon From robin at icir.org Sun Nov 7 20:57:36 2010 From: robin at icir.org (Robin Sommer) Date: Sun, 7 Nov 2010 20:57:36 -0800 Subject: [Bro-Dev] Broctl installation process clean up In-Reply-To: <1279086782.7741.1289093686983.JavaMail.root@zimbra-1.ncsa.uiuc.edu> References: <1764677733.7721.1289091728777.JavaMail.root@zimbra-1.ncsa.uiuc.edu> <1279086782.7741.1289093686983.JavaMail.root@zimbra-1.ncsa.uiuc.edu> Message-ID: <20101108045736.GB73259@icir.org> > https://wiki.ncsa.illinois.edu/display/BROWATERS/CMake+Porting+Progress#CMakePortingProgress-BroctlTasks%2FNotes Very nice, good job! That all sounds good. A few more comments below. On Sat, Nov 06, 2010 at 20:34 -0500, you wrote: > As part of the CMake porting process, I think it makes sense to > clean up Broctl's initial installation process, Yes, definitly. > I propose that we let CMake take care of the dependency checking > (other Bro components need to be installed first) I agree. One reason for the current installation is to essentially get around the fact that there's no coherent way of installing all the pieces easily, and broctl's install tries to hide that as good as it can and just assembles what it needs. > and initial installation of the Broctl files while `broctl install` > would still be responsible for generating scripts from templates, > updating to new version of .cfg and site policy files, and syncing > to worker nodes (at least I think that's a summary of what broctl > does). That sounds good. The one additional thing we should think about (per earlier mails) is getting rid of generating scripts from templates. How much work do you think would it be to adapt the installation to (1) generate a single shell script, say broctl-config.sh[1], with all (relevant) configure options; and (2) use static versions for all the helper scripts which then source broctl-config.sh before doing anything else. That way, we should be able to get rid of (nearly?) all the Target/TargetDev entries in BroControl/install.py, leaving them to CMake instead. I'm thinking we need to do that anyway eventually, and doing so later would then again require to work on the installation. [1] Ideally, this would be generated on a per-system basis, so that nodes can be configured differently. However, that might turn out to be a bit tricky and I'm fine leaving that out for now. > The specific functionality that would be lost is `broctl install > --make` (used by current Makefile) No problem. > and also the DevMode=1 feature that seems to basically turn `broctl > install` into a `broctl install --make` in order to update the > files from the distribution source. That's ready to go anyway, it's mainly a relict from broctl's first version. > Good plan or bad plan? Excellent plan! > The policy files into $broctl_prefix/share/bro ? Better into a subdirectory of that, to keep them seperate from Bro's. One more thing: some easy way to change the default paths where the various broctl pieces go would be nice; seems distributions will need that (also, if it makes sense to change any of the default paths generally (for broctl, or also Bro itself), now would be the right time for that as well). Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From robin at icir.org Sun Nov 7 21:03:52 2010 From: robin at icir.org (Robin Sommer) Date: Sun, 7 Nov 2010 21:03:52 -0800 Subject: [Bro-Dev] Broccoli Python bindings In-Reply-To: <489295009.6822.1288996551322.JavaMail.root@zimbra-1.ncsa.uiuc.edu> References: <20101105161140.GS34938@icsi.berkeley.edu> <489295009.6822.1288996551322.JavaMail.root@zimbra-1.ncsa.uiuc.edu> Message-ID: <20101108050352.GC73259@icir.org> On Fri, Nov 05, 2010 at 17:35 -0500, you wrote: > I don't see an issue right now with integrating the Python setup.py > into CMake -- it should basically involve adding a custom target > that delegates the build to setup.py at "make" time and then also > delegating to setup.py at "make install" time. One question here for clarification: above you write that CMake delegates to setup.py; however your Wiki page mentions in the pysubnettree section: * Will probably have a thin CMake script to build extension and install module+extension * Keeping the setup.py around may be useful for packagers... not sure That sounds like replacing setup.py with CMake (rather than combining the two). So, I was wondering which of the two options you're planing to follow? I'd prefer to keep using the setup.py in both cases, as that's the standard way to build Python extensions and thus probably more robust. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From robin at icir.org Sun Nov 7 21:07:50 2010 From: robin at icir.org (Robin Sommer) Date: Sun, 7 Nov 2010 21:07:50 -0800 Subject: [Bro-Dev] Broccoli Python bindings In-Reply-To: <489295009.6822.1288996551322.JavaMail.root@zimbra-1.ncsa.uiuc.edu> References: <20101105161140.GS34938@icsi.berkeley.edu> <489295009.6822.1288996551322.JavaMail.root@zimbra-1.ncsa.uiuc.edu> Message-ID: <20101108050750.GE73259@icir.org> On Fri, Nov 05, 2010 at 17:35 -0500, you wrote: > So to summarize: I'm leaning towards having the bindings in it's own > repo + RPM/DEB package since there's minor benefits and also fits in > with the spirit of what we're doing everywhere else. Thanks for the summary. One additional advantage of having it separate is that installing Broccoli does not automatically pull in the bindings, which for various reasons may not be desired (for example, there's the problem that Python development headers are needed for compiling them, which is something we are currently running into with the broctl installation; their absense could autodetected, but that then introduces new complications when other packages assume the bindings have been installed). So, I think I'm following your leaning, though I'm still not really feeling strong either way. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From jsiwek at ncsa.illinois.edu Mon Nov 8 10:43:48 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Mon, 8 Nov 2010 12:43:48 -0600 (CST) Subject: [Bro-Dev] Broccoli Python bindings In-Reply-To: <20101108050352.GC73259@icir.org> Message-ID: <27519920.481.1289241824750.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > One question here for clarification: above you write that CMake > delegates to setup.py; however your Wiki page mentions in the > pysubnettree section: > > * Will probably have a thin CMake script to build extension and > install module+extension > * Keeping the setup.py around may be useful for packagers... not sure > > That sounds like replacing setup.py with CMake (rather than > combining the two). So, I was wondering which of the two options > you're planing to follow? Yeah, I vacillated over the weekend and found that it's pretty easy to have CMake completely handle the build/install of Python extensions, but... > I'd prefer to keep using the setup.py in both cases, as that's the > standard way to build Python extensions and thus probably more > robust. Yes, distutils would probably be the more standard/robust way if it were a completely independent component. But if we want to provide a "unification interface" to have it built as part of a larger Bro source distribution via CMake, then it would be even less standard to have CMake delegate to distutils rather than do it itself. It definitely "feels" like I would be abusing CMake by mixing it with a completely different build system. Maybe one way to go is to provide both a CMake build system and a distutils one (separated), so that people that need the extra robustness (e.g. developers/packagers) can still use the setup.py while people that just want to build Bro from source can follow our established CMake method. Not quite sure what the best option is for that use-case yet. - Jon From robin at icir.org Mon Nov 8 11:21:25 2010 From: robin at icir.org (Robin Sommer) Date: Mon, 8 Nov 2010 11:21:25 -0800 Subject: [Bro-Dev] Broccoli Python bindings In-Reply-To: <27519920.481.1289241824750.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <20101108050352.GC73259@icir.org> <27519920.481.1289241824750.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20101108192125.GJ10654@icir.org> On Mon, Nov 08, 2010 at 12:43 -0600, you wrote: > Maybe one way to go is to provide both a CMake build system and a > distutils one (separated), That sounds good. > just want to build Bro from source can follow our established CMake > method. Not quite sure what the best option is for that use-case > yet. Not sure what it is you're not sure about? :) Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From jsiwek at ncsa.illinois.edu Mon Nov 8 11:30:28 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Mon, 8 Nov 2010 13:30:28 -0600 (CST) Subject: [Bro-Dev] Broctl installation process clean up In-Reply-To: <20101108045736.GB73259@icir.org> Message-ID: <10646604.517.1289244623629.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > I agree. One reason for the current installation is to essentially > get around the fact that there's no coherent way of installing all > the pieces easily, and broctl's install tries to hide that as good > as it can and just assembles what it needs. While I was looking into it, I was thinking that the Python distutils could have done the broctl installation. Not saying that I want to go with distutils here, just wondering if you had considered it since (from broccoli bindings thread) it sounds like it may be desirable for Bro to maintain distutils build/installation of Python stuff as a standard. > > and initial installation of the Broctl files while `broctl install` > > would still be responsible for generating scripts from templates, > > updating to new version of .cfg and site policy files, and syncing > > to worker nodes (at least I think that's a summary of what broctl > > does). > > That sounds good. The one additional thing we should think about > (per earlier mails) is getting rid of generating scripts from > templates. How much work do you think would it be to adapt the > installation to (1) generate a single shell script, say > broctl-config.sh[1], with all (relevant) configure options; and (2) > use static versions for all the helper scripts which then source > broctl-config.sh before doing anything else. That way, we should be > able to get rid of (nearly?) all the Target/TargetDev entries in > BroControl/install.py, leaving them to CMake instead. I'm thinking > we need to do that anyway eventually, and doing so later would then > again require to work on the installation. That doesn't sound hard to do, but I'm not sure I understand completely (and don't know what earlier mails you're referencing). Do you mean that CMake installs something like a broctl-config.sh.in and that `broctl install` transforms it into the broctl-config.sh that the now-static scripts will source? Or that everything is now static, broctl-config.sh and also the scripts? > > The policy files into $broctl_prefix/share/bro ? > > Better into a subdirectory of that, to keep them seperate from > Bro's. Right; thanks. I see that they get put in $prefix/share/bro/broctl currently. > One more thing: some easy way to change the default paths where the > various broctl pieces go would be nice; seems distributions will > need that (also, if it makes sense to change any of the default > paths generally (for broctl, or also Bro itself), now would be the > right time for that as well). I'll try to anticipate as much as I can, but getting things perfect for packaging purposes will probably require another iteration after the basic CMake build is done (or else my head might explode). - Jon From jsiwek at ncsa.illinois.edu Mon Nov 8 11:39:53 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Mon, 8 Nov 2010 13:39:53 -0600 (CST) Subject: [Bro-Dev] Broccoli Python bindings In-Reply-To: <20101108192125.GJ10654@icir.org> Message-ID: <26951441.519.1289245190979.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > > just want to build Bro from source can follow our established CMake > > method. Not quite sure what the best option is for that use-case > > yet. > > Not sure what it is you're not sure about? :) Putting Humpty Dumpty back together again. For those that want an easy way to build/install all Bro components from source. I'm not sure if mixing in another build system w/ CMake will work well. - Jon From robin at icir.org Mon Nov 8 12:42:33 2010 From: robin at icir.org (Robin Sommer) Date: Mon, 8 Nov 2010 12:42:33 -0800 Subject: [Bro-Dev] Broctl installation process clean up In-Reply-To: <10646604.517.1289244623629.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <20101108045736.GB73259@icir.org> <10646604.517.1289244623629.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20101108204233.GK10654@icir.org> On Mon, Nov 08, 2010 at 13:30 -0600, you wrote: > I want to go with distutils here, just wondering if you had > considered it Initially I didn't do that as I didn't seen an easy way to get all the special stuff the install used to do integrated with distutils (perhaps I'm just not sufficiently familiar with it). Also, the installation setup grew kind of organically. But I wouldn't be opposed to switching to distutils, in fact I'd prefer it but don't know much work that is and whether it's worth it. What do you think? > That doesn't sound hard to do, but I'm not sure I understand > completely (and don't know what earlier mails you're referencing). (I think I discussed this briefly in earlier threads at least with Seth, but perhaps that wasn't on the mailing list; not sure). > Do you mean that CMake installs something like a broctl-config.sh.in > and that `broctl install` transforms it into the broctl-config.sh > that the now-static scripts will source? Yes, this is what I mean. There'd be only one dynamic file now, broctl-config.sh generated by "broctl install", and all the rest is static (much of the content of broctl-config.sh could be determined at CMake-time already, however there's some stuff in there that depends on broctl.cfg). > I'll try to anticipate as much as I can, but getting things perfect > for packaging purposes will probably require another iteration after > the basic CMake build is done (or else my head might explode). Yes, I see that. Just wanted to throw it out there. :) Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From jsiwek at ncsa.illinois.edu Mon Nov 8 13:16:57 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Mon, 8 Nov 2010 15:16:57 -0600 (CST) Subject: [Bro-Dev] Broctl installation process clean up In-Reply-To: <20101108204233.GK10654@icir.org> Message-ID: <31797872.533.1289251012918.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > > I want to go with distutils here, just wondering if you had > > considered it > > I wouldn't be opposed to switching to distutils, in fact I'd prefer it but don't > know much work that is and whether it's worth it. What do you think? You snipped my quote to make me say "I want to go with distutils here", but actually I'd rather just use CMake for now (mostly for consistency & comfort reasons). But a setup.py might still be considered later if it's more standard for packagers to use. > There'd be only one dynamic file now, > broctl-config.sh generated by "broctl install", and all the rest is > static (much of the content of broctl-config.sh could be determined > at CMake-time already, however there's some stuff in there that > depends on broctl.cfg). Ok, will do that refactor along with the other clean up. - Jon From robin at icir.org Mon Nov 8 13:19:17 2010 From: robin at icir.org (Robin Sommer) Date: Mon, 8 Nov 2010 13:19:17 -0800 Subject: [Bro-Dev] Broctl installation process clean up In-Reply-To: <31797872.533.1289251012918.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <20101108204233.GK10654@icir.org> <31797872.533.1289251012918.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20101108211917.GN10654@icir.org> On Mon, Nov 08, 2010 at 15:16 -0600, you wrote: > You snipped my quote to make me say "I want to go with distutils here" (... that was accidental, I didn't read it that way) > Ok, will do that refactor along with the other clean up. Ok, thanks. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From bro-dev at bro-ids.org Mon Nov 8 20:03:12 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 09 Nov 2010 04:03:12 -0000 Subject: [Bro-Dev] #247: Bro trunk build fails with OpenSSL stack error In-Reply-To: <047.50baac97db1997fb95f119eebf1fbebf@bro-ids.org> References: <047.50baac97db1997fb95f119eebf1fbebf@bro-ids.org> Message-ID: <056.09ee7f1bc378a3952cace4471ada78f7@bro-ids.org> #247: Bro trunk build fails with OpenSSL stack error ------------------------------+--------------------------------------------- Reporter: kreibich | Owner: kreibich Type: Patch | Status: assigned Priority: Normal | Component: Bro Version: 1.5.2-devel (svn) | Keywords: ------------------------------+--------------------------------------------- Comment(by gregor): The patch seems to work for openssl < 1.0. I tested it on a Debian with openssl0.9.8g-15+lenny6 However, there's a caveat: The check for the STACK type happens early. Later on configure.in modifies the include paths. On Mac the openssl that ships with Mac OS is 0.9.8, but I also have an openssl from MacPorts, that is 1.0.0. The problem is that when the test runs only the standard includes paths are enabled, so configure finds openssl 0.9.8. Later it adds the MacPort paths. When bro actually compiles the compiler finds the openssl 1.0.0 headers..... Solution: move the test towards the end of configure.in (at least after # OS-specific hacks and tweaks) Another option would be to just put a {{{ #ifndef STACK #define STACK _STACK #endif }}} into the appropriate files Otherwise: I think it would be really good if we could get this patch into the trunk quickly. cu gregor -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 8 21:42:01 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 09 Nov 2010 05:42:01 -0000 Subject: [Bro-Dev] #294: Autoconf trouble with autoconf >= 2.64 Message-ID: <045.af88d58ef5cb7463920bba891047248c@bro-ids.org> #294: Autoconf trouble with autoconf >= 2.64 --------------------+------------------------------------------------------- Reporter: gregor | Owner: Type: Problem | Status: new Priority: Normal | Component: Bro Version: 1.5.1 | Keywords: --------------------+------------------------------------------------------- Hi, yet another set of autoconf problems. The attached patch fixes them. Without it, autogen.sh will not run (correctly) on systems with autoconf >= 2.64 Fixes include: * `configure.in:33: warning: AC_REQUIRE: 'AC_PROG_CC' was expanded before it was required` ** which will lead to {{{ ./configure: line xxxx: syntax error near unexpected token `newline' ./configure: line xxxx: `yes:' }}} * warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body * Subtlety involving AC_CHECK_HEADER, that lead to {{{ ./configure: line 6779: ac_fn_c_check_header_compile: command not found }}} messages when running configure cu gregor -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 8 22:45:54 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 09 Nov 2010 06:45:54 -0000 Subject: [Bro-Dev] #247: Bro trunk build fails with OpenSSL stack error In-Reply-To: <047.50baac97db1997fb95f119eebf1fbebf@bro-ids.org> References: <047.50baac97db1997fb95f119eebf1fbebf@bro-ids.org> Message-ID: <056.5f6511650db5d3bb2c01125a90ad6205@bro-ids.org> #247: Bro trunk build fails with OpenSSL stack error ------------------------------+--------------------------------------------- Reporter: kreibich | Owner: kreibich Type: Patch | Status: assigned Priority: Normal | Component: Bro Version: 1.5.2-devel (svn) | Keywords: ------------------------------+--------------------------------------------- Comment(by gregor): After playing around with that whole mess, I think I might have found a cleaner solution. Found be chance after having a look at openssl/safestack.h {{{ /* SKM_sk_... stack macros are internal to safestack.h: * never use them directly, use sk__... instead */ }}} However, since I have no idea about programming with openssl, it would be good if somebody who knows openssl could verify that patch actually makes sense. Attaching, openssl-x509-stack-20101108.patch, which applies to trunk and should fix the problem across all openssl versions. Tested (aka compiles) with openssl-0.9.8g-15.lenny6, 1.0.0, and 1.??? (Fedora) -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 8 22:53:48 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 09 Nov 2010 06:53:48 -0000 Subject: [Bro-Dev] #294: Autoconf trouble with autoconf >= 2.64 In-Reply-To: <045.af88d58ef5cb7463920bba891047248c@bro-ids.org> References: <045.af88d58ef5cb7463920bba891047248c@bro-ids.org> Message-ID: <054.327038b3bba0da7a9fd428512dcb51d6@bro-ids.org> #294: Autoconf trouble with autoconf >= 2.64 ------------------------------+--------------------------------------------- Reporter: gregor | Owner: Type: Patch | Status: new Priority: Normal | Component: Bro Version: 1.5.2-devel (svn) | Keywords: ------------------------------+--------------------------------------------- Changes (by gregor): * version: 1.5.1 => 1.5.2-devel (svn) * type: Problem => Patch -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 8 22:57:55 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 09 Nov 2010 06:57:55 -0000 Subject: [Bro-Dev] #167: configure failes with syntax error In-Reply-To: <063.c16b30465215b86d7eb71fcd252ba7fc@bro-ids.org> References: <063.c16b30465215b86d7eb71fcd252ba7fc@bro-ids.org> Message-ID: <072.216bc2e61116126bbd0b6378bacf27c2@bro-ids.org> #167: configure failes with syntax error ---------------------------------------+------------------------------------ Reporter: anonymous@? | Type: Problem Status: closed | Priority: Normal Component: Bro | Version: Resolution: Invalid | Keywords: ---------------------------------------+------------------------------------ Comment(by gregor): The patch for ticket:294 should solve this problem -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 8 23:03:04 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 09 Nov 2010 07:03:04 -0000 Subject: [Bro-Dev] #173: Configure fails with autoconf-2.64 In-Reply-To: <043.1275ed6a7dbf16c16502a38cf6c986c6@bro-ids.org> References: <043.1275ed6a7dbf16c16502a38cf6c986c6@bro-ids.org> Message-ID: <052.acaaf8862c4ea6f5fc9f2b52ca1e9f8f@bro-ids.org> #173: Configure fails with autoconf-2.64 ------------------------------+--------------------------------------------- Reporter: seth | Owner: Type: Problem | Status: closed Priority: Normal | Component: Bro Version: 1.5.2-devel (svn) | Resolution: Solved Keywords: | ------------------------------+--------------------------------------------- Changes (by gregor): * status: seen => closed * resolution: => Solved Comment: The patch to ticket:294 should fix this issue and other autoconf related ones. The solution for this particular one was "borrowed" from libpcap (which ended up being more sophisticated than the here) -- Ticket URL: Bro Tracker Bro Issue Tracker From seth at icir.org Tue Nov 9 11:37:49 2010 From: seth at icir.org (Seth Hall) Date: Tue, 9 Nov 2010 14:37:49 -0500 Subject: [Bro-Dev] Bro and clang++ Message-ID: <3C6D2C0A-2F46-4CD6-BB87-A53399114AE7@icir.org> I haven't done any extensive testing with the resulting binary (although it appears to run). The cool part was that I built the full Bro binary in 1:47 with make -j2 on my laptop. .Seth From seth at icir.org Tue Nov 9 12:03:26 2010 From: seth at icir.org (Seth Hall) Date: Tue, 9 Nov 2010 15:03:26 -0500 Subject: [Bro-Dev] Bro and clang++ In-Reply-To: <3C6D2C0A-2F46-4CD6-BB87-A53399114AE7@icir.org> References: <3C6D2C0A-2F46-4CD6-BB87-A53399114AE7@icir.org> Message-ID: <2082E807-BC0F-4038-8FB3-153A97218C1E@icir.org> On Nov 9, 2010, at 2:37 PM, Seth Hall wrote: > I haven't done any extensive testing with the resulting binary (although it appears to run). The cool part was that I built the full Bro binary in 1:47 with make -j2 on my laptop. Nevermind. I thought that was pretty fast, but actually I guess with g++ I can build it in 1:39. At least Bro appears to build with clang++. :) .Seth From seth at icir.org Tue Nov 9 22:06:23 2010 From: seth at icir.org (Seth Hall) Date: Wed, 10 Nov 2010 01:06:23 -0500 Subject: [Bro-Dev] Bro and clang++ In-Reply-To: <2082E807-BC0F-4038-8FB3-153A97218C1E@icir.org> References: <3C6D2C0A-2F46-4CD6-BB87-A53399114AE7@icir.org> <2082E807-BC0F-4038-8FB3-153A97218C1E@icir.org> Message-ID: On Nov 9, 2010, at 3:03 PM, Seth Hall wrote: > Nevermind. I thought that was pretty fast, but actually I guess with g++ I can build it in 1:39. At least Bro appears to build with clang++. :) I ran Bro (just loading conn.bro) with a large mixed traffic trace file and the resulting binary was slightly slower than the g++ built binary but it was a near imperceptible slow down. This article seems to pretty accurately show speed differences between GCC compiled binaries and Clang (among other LLVM backed compilation techniques). http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_dragonegg28&num=1 .Seth From robin at icir.org Wed Nov 10 09:15:24 2010 From: robin at icir.org (Robin Sommer) Date: Wed, 10 Nov 2010 09:15:24 -0800 Subject: [Bro-Dev] Bro and clang++ In-Reply-To: References: <3C6D2C0A-2F46-4CD6-BB87-A53399114AE7@icir.org> <2082E807-BC0F-4038-8FB3-153A97218C1E@icir.org> Message-ID: <20101110171524.GB43081@icir.org> On Wed, Nov 10, 2010 at 01:06 -0500, you wrote: > I ran Bro (just loading conn.bro) with a large mixed traffic trace > file and the resulting binary was slightly slower than the g++ built > binary but it was a near imperceptible slow down. That sounds promising. Can you try with loading the http-* scripts? > http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_dragonegg28&num=1 Nice, I need to read that more carefully. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From seth at icir.org Wed Nov 10 09:42:03 2010 From: seth at icir.org (Seth Hall) Date: Wed, 10 Nov 2010 12:42:03 -0500 Subject: [Bro-Dev] Bro and clang++ In-Reply-To: <20101110171524.GB43081@icir.org> References: <3C6D2C0A-2F46-4CD6-BB87-A53399114AE7@icir.org> <2082E807-BC0F-4038-8FB3-153A97218C1E@icir.org> <20101110171524.GB43081@icir.org> Message-ID: <0896F06D-6523-462A-9871-6FAE6909F46F@icir.org> On Nov 10, 2010, at 12:15 PM, Robin Sommer wrote: > That sounds promising. Can you try with loading the http-* scripts? [seth at Blake tmp]$ time ~/bro/bro.git/src/bro.clang++ -r ~/tracefiles/my.trace -f "ip" enable-ext-logging http http-reply http-request http-ext weird alarm real 1m0.284s user 0m57.373s sys 0m1.478s [seth at Blake tmp]$ time ~/bro/bro.git/src/bro.gcc -r ~/tracefiles/my.trace -f "ip" enable-ext-logging http http-reply http-request http-ext weird alarm real 0m59.266s user 0m55.851s sys 0m1.547s Once again, slower, but just barely. .Seth From robin at icir.org Thu Nov 11 09:24:52 2010 From: robin at icir.org (Robin Sommer) Date: Thu, 11 Nov 2010 09:24:52 -0800 Subject: [Bro-Dev] Bro and clang++ In-Reply-To: <0896F06D-6523-462A-9871-6FAE6909F46F@icir.org> References: <3C6D2C0A-2F46-4CD6-BB87-A53399114AE7@icir.org> <2082E807-BC0F-4038-8FB3-153A97218C1E@icir.org> <20101110171524.GB43081@icir.org> <0896F06D-6523-462A-9871-6FAE6909F46F@icir.org> Message-ID: <20101111172452.GH4324@icir.org> On Wed, Nov 10, 2010 at 12:42 -0500, you wrote: > user 0m57.373s > user 0m55.851s Likewise promising! Thanks, Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From jsiwek at ncsa.illinois.edu Fri Nov 12 08:06:30 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Fri, 12 Nov 2010 10:06:30 -0600 (CST) Subject: [Bro-Dev] Broccoli Python bindings In-Reply-To: <20101108050750.GE73259@icir.org> Message-ID: <31211293.707.1289577987236.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > So, I think I'm following your leaning, though I'm still not really > feeling strong either way. Doesn't seem like anyone is strongly opposed, so I think we can commit to the decision to put bindings in their own repos, right? I can go ahead and try to follow our internal doc for creating a new repo, or let me know if you wanted to do it, Robin. - Jon From robin at icir.org Fri Nov 12 08:49:11 2010 From: robin at icir.org (Robin Sommer) Date: Fri, 12 Nov 2010 08:49:11 -0800 Subject: [Bro-Dev] Broccoli Python bindings In-Reply-To: <31211293.707.1289577987236.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <20101108050750.GE73259@icir.org> <31211293.707.1289577987236.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20101112164911.GA69671@icir.org> On Fri, Nov 12, 2010 at 10:06 -0600, you wrote: > I can go ahead and try to follow our internal doc for creating a new repo, or let me know if you wanted to do it, Robin. Yes, please go ahead; good test whether the doc has everything it needs ... :) Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From robin at icir.org Sun Nov 14 20:55:24 2010 From: robin at icir.org (Robin Sommer) Date: Sun, 14 Nov 2010 20:55:24 -0800 Subject: [Bro-Dev] [Bro-Commits-Internal] [git/admin] branch 'master' updated In-Reply-To: <201011150453.oAF4rHcp024003@envoy.icir.org> References: <201011150453.oAF4rHcp024003@envoy.icir.org> Message-ID: <20101115045524.GB82369@icir.org> On Sun, Nov 14, 2010 at 20:53 -0800, I wrote: > Tweaking notification script I hope this fixes the spamming ... Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From jsiwek at ncsa.illinois.edu Mon Nov 15 08:11:38 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Mon, 15 Nov 2010 10:11:38 -0600 (CST) Subject: [Bro-Dev] [Bro-Commits-Internal] [git/admin] branch 'master' updated In-Reply-To: <20101115045524.GB82369@icir.org> Message-ID: <7673557.750.1289837498749.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > > Tweaking notification script > > I hope this fixes the spamming ... Doesn't look like it. It's also seems pretty hard to tell from the commit email the difference between a branch creation and branch deletion. - Jon From robin at icir.org Mon Nov 15 08:49:52 2010 From: robin at icir.org (Robin Sommer) Date: Mon, 15 Nov 2010 08:49:52 -0800 Subject: [Bro-Dev] [Bro-Commits-Internal] [git/admin] branch 'master' updated In-Reply-To: <7673557.750.1289837498749.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <20101115045524.GB82369@icir.org> <7673557.750.1289837498749.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20101115164952.GA37355@icir.org> On Mon, Nov 15, 2010 at 10:11 -0600, you wrote: > Doesn't look like it. D'oh! I broke it again with a last minute change. Fix committed ... > It's also seems pretty hard to tell from the commit email the > difference between a branch creation and branch deletion. Yeah, I'll look into that later. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From bro-dev at bro-ids.org Mon Nov 15 11:57:53 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 19:57:53 -0000 Subject: [Bro-Dev] #295: Create prebuilt binary packages Message-ID: <043.5bb3b42886a93b64dbf0cb7215a12581@bro-ids.org> #295: Create prebuilt binary packages ---------------------+------------------------------------------------------ Reporter: seth | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | ---------------------+------------------------------------------------------ Prebuilt packages should be provided for Linux, FreeBSD, and MacOS X. Questions to answer: * Does it make sense to provide 32bit and 64bit variants for each OS? * Do we target a specific Linux version/distro? If so, which one? -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:12:44 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:12:44 -0000 Subject: [Bro-Dev] #296: Convert build process to CMake Message-ID: <043.2b75dde89b11f20f75673a8bcbafdc27@bro-ids.org> #296: Convert build process to CMake --------------------+------------------------------------------------------- Reporter: seth | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | --------------------+------------------------------------------------------- -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:14:10 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:14:10 -0000 Subject: [Bro-Dev] #297: Remove trace rewriter Message-ID: <043.f4e0eb0a9924070cf852ace700beb6bf@bro-ids.org> #297: Remove trace rewriter --------------------+------------------------------------------------------- Reporter: seth | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | --------------------+------------------------------------------------------- I think the agreement that was reached was that the trace rewriter would be removed, but a patch to add the feature back in would be maintained for a while. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:14:31 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:14:31 -0000 Subject: [Bro-Dev] #298: Automatic build tests on NMI testbed. Message-ID: <043.117bc47cd43283656aadb96286c21804@bro-ids.org> #298: Automatic build tests on NMI testbed. --------------------+------------------------------------------------------- Reporter: seth | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | --------------------+------------------------------------------------------- -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:14:58 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:14:58 -0000 Subject: [Bro-Dev] #299: Cleanup/update default policy scripts Message-ID: <043.6e03296c656395a4574fae748c21854e@bro-ids.org> #299: Cleanup/update default policy scripts --------------------+------------------------------------------------------- Reporter: seth | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | --------------------+------------------------------------------------------- -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:15:09 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:15:09 -0000 Subject: [Bro-Dev] #299: Cleanup/update default policy scripts In-Reply-To: <043.6e03296c656395a4574fae748c21854e@bro-ids.org> References: <043.6e03296c656395a4574fae748c21854e@bro-ids.org> Message-ID: <058.0cb2c6885989f89f13c0dd983e405c12@bro-ids.org> #299: Cleanup/update default policy scripts ---------------------+------------------------------------------------------ Reporter: seth | Owner: seth Type: Task | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by seth): * owner: => seth * status: new => assigned -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:16:36 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:16:36 -0000 Subject: [Bro-Dev] #300: Document default policy scripts Message-ID: <043.9b3b25d0ae8ee2368b2b397389a52829@bro-ids.org> #300: Document default policy scripts --------------------+------------------------------------------------------- Reporter: seth | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | --------------------+------------------------------------------------------- * Create a parse-able comment style for auto documenting scripts. * Document scripts. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:18:24 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:18:24 -0000 Subject: [Bro-Dev] #301: Switch to binary logging Message-ID: <043.495d3fa38ccf5577a30cf4b0e6f565a0@bro-ids.org> #301: Switch to binary logging -----------------------------+---------------------------------------------- Reporter: seth | Owner: Type: Feature Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | -----------------------------+---------------------------------------------- We may switch the default logging style to binary logs. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:18:43 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:18:43 -0000 Subject: [Bro-Dev] #302: New quick start guide Message-ID: <043.685a4d5495d67a9229110504cfc61113@bro-ids.org> #302: New quick start guide --------------------+------------------------------------------------------- Reporter: seth | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | --------------------+------------------------------------------------------- -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:19:29 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:19:29 -0000 Subject: [Bro-Dev] #303: Design new website. Message-ID: <043.9d976ec806d3cd9257b73f1b48f64a9e@bro-ids.org> #303: Design new website. ---------------------+------------------------------------------------------ Reporter: seth | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | ---------------------+------------------------------------------------------ -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:20:46 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:20:46 -0000 Subject: [Bro-Dev] #304: Unit tests for default scripts Message-ID: <043.7ce2202da31ccf8ec95f411f250e4f2b@bro-ids.org> #304: Unit tests for default scripts ---------------------+------------------------------------------------------ Reporter: seth | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | ---------------------+------------------------------------------------------ This is a possible item to get in for the 1.6 release. It may be bumped to 1.7. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:21:29 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:21:29 -0000 Subject: [Bro-Dev] #305: Replace communication system with 0mq Message-ID: <043.40694402c58225da14515b3c0a74bb6a@bro-ids.org> #305: Replace communication system with 0mq --------------------+------------------------------------------------------- Reporter: seth | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | --------------------+------------------------------------------------------- This may happen for the 1.6 release, but it's possible it may be bumped to the 1.7 release. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:21:47 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:21:47 -0000 Subject: [Bro-Dev] #303: Design new website. In-Reply-To: <043.9d976ec806d3cd9257b73f1b48f64a9e@bro-ids.org> References: <043.9d976ec806d3cd9257b73f1b48f64a9e@bro-ids.org> Message-ID: <058.dec5d1c01d92b33202c3bc17abc456b1@bro-ids.org> #303: Design new website. ---------------------+------------------------------------------------------ Reporter: seth | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by seth): * type: Problem => Task -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:22:06 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:22:06 -0000 Subject: [Bro-Dev] #304: Unit tests for default scripts In-Reply-To: <043.7ce2202da31ccf8ec95f411f250e4f2b@bro-ids.org> References: <043.7ce2202da31ccf8ec95f411f250e4f2b@bro-ids.org> Message-ID: <058.1520b858a56229e734b459b565668545@bro-ids.org> #304: Unit tests for default scripts ---------------------+------------------------------------------------------ Reporter: seth | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by seth): * type: Problem => Task -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:23:21 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:23:21 -0000 Subject: [Bro-Dev] #306: Write a new user manual Message-ID: <043.c3621fa0006d72fd7a76ba7be4b3ce5d@bro-ids.org> #306: Write a new user manual --------------------+------------------------------------------------------- Reporter: seth | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.7 Component: Bro | Version: Keywords: | --------------------+------------------------------------------------------- -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:23:48 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:23:48 -0000 Subject: [Bro-Dev] #307: Complete IPv6 support Message-ID: <043.df58449a8c325cf2fb466639789ca123@bro-ids.org> #307: Complete IPv6 support --------------------+------------------------------------------------------- Reporter: seth | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.7 Component: Bro | Version: Keywords: | --------------------+------------------------------------------------------- -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:30:25 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:30:25 -0000 Subject: [Bro-Dev] #294: Autoconf trouble with autoconf >= 2.64 In-Reply-To: <045.af88d58ef5cb7463920bba891047248c@bro-ids.org> References: <045.af88d58ef5cb7463920bba891047248c@bro-ids.org> Message-ID: <060.37c70bd949d1ff55cc606425a41e3dec@bro-ids.org> #294: Autoconf trouble with autoconf >= 2.64 ---------------------+------------------------------------------------------ Reporter: gregor | Owner: vern Type: Patch | Status: assigned Priority: Normal | Milestone: Component: Bro | Version: 1.5.2 Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by seth): * owner: => vern * status: new => assigned Comment: This patch worked for me but should be irrelevant for the next release due to move to CMake. Vern, could we go ahead and get it applied to the SVN HEAD to ease development until the switch to CMake? I'll apply it to the git fastpath branch and merge into devel as well. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:30:50 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:30:50 -0000 Subject: [Bro-Dev] #294: Autoconf trouble with autoconf >= 2.64 In-Reply-To: <045.af88d58ef5cb7463920bba891047248c@bro-ids.org> References: <045.af88d58ef5cb7463920bba891047248c@bro-ids.org> Message-ID: <060.36ab83b4a345f15ba7dc43c86e4a2508@bro-ids.org> #294: Autoconf trouble with autoconf >= 2.64 ---------------------+------------------------------------------------------ Reporter: gregor | Owner: vern Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by seth): * milestone: => Bro1.6 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 12:41:27 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 20:41:27 -0000 Subject: [Bro-Dev] #293: scripts/local-interfaces cannot find ifconfig In-Reply-To: <047.ac9986b0dbc785e69d293483a6ce99e7@bro-ids.org> References: <047.ac9986b0dbc785e69d293483a6ce99e7@bro-ids.org> Message-ID: <062.ee0b5969c0504e1a3897004ac8576afe@bro-ids.org> #293: scripts/local-interfaces cannot find ifconfig -------------------------+-------------------------------------------------- Reporter: vallenti | Owner: robin Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: 1.5.1 Resolution: | Keywords: -------------------------+-------------------------------------------------- Changes (by seth): * milestone: => Bro1.6 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 13:06:50 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 21:06:50 -0000 Subject: [Bro-Dev] #292: Cluttering of alarm.log with serialization messages In-Reply-To: <047.7dd189330e344b30c6d647cacb8d3cd8@bro-ids.org> References: <047.7dd189330e344b30c6d647cacb8d3cd8@bro-ids.org> Message-ID: <062.22894bd81c1748841d92e61e9a1b31c0@bro-ids.org> #292: Cluttering of alarm.log with serialization messages -------------------------+-------------------------------------------------- Reporter: vallenti | Owner: robin Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: 1.5.1 Resolution: | Keywords: -------------------------+-------------------------------------------------- Changes (by seth): * milestone: => Bro1.6 Comment: I just checked the code and it looks pretty straight forward to move this to another file. Any ideas for a file name to use for this type of logging message? Since the normal output is to stderr if the alarm log isn't open, maybe it makes sense to name the log file stderr.log? I can do development on this, it should just take a few minutes and I'd also like to have a different way to handle these messages. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 13:07:45 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 21:07:45 -0000 Subject: [Bro-Dev] #291: lookup_addr() only supports IPv4 addresses In-Reply-To: <044.ac2fb4cb11fcfbae75d1e9c96c3f1a02@bro-ids.org> References: <044.ac2fb4cb11fcfbae75d1e9c96c3f1a02@bro-ids.org> Message-ID: <059.d96ee1a3e19b492a746e5f75b8ee72d4@bro-ids.org> #291: lookup_addr() only supports IPv4 addresses ----------------------+----------------------------------------------------- Reporter: leres | Owner: Type: Problem | Status: seen Priority: Normal | Milestone: Bro1.7 Component: Bro | Version: 1.5.1 Resolution: | Keywords: ----------------------+----------------------------------------------------- Changes (by seth): * status: new => seen * milestone: => Bro1.7 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 13:47:03 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 21:47:03 -0000 Subject: [Bro-Dev] #289: Crash in broctl due to missing lockfile. In-Reply-To: <043.917fec1d31d25ef8a59f31d1c7cfc5d2@bro-ids.org> References: <043.917fec1d31d25ef8a59f31d1c7cfc5d2@bro-ids.org> Message-ID: <058.49f3f61f597a7a99687492b405f8c5aa@bro-ids.org> #289: Crash in broctl due to missing lockfile. -------------------------+-------------------------------------------------- Reporter: seth | Owner: robin Type: Patch | Status: new Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: 1.5.2 Resolution: | Keywords: -------------------------+-------------------------------------------------- Changes (by seth): * type: Problem => Patch * milestone: => Bro1.6 Comment: This is a patch to avoid the crash. IOError handles a problem with "open" failing and OSError handles problems with os.unlink failing. {{{ Index: util.py =================================================================== --- util.py (revision 7072) +++ util.py (working copy) @@ -102,7 +102,7 @@ os.unlink(config.Config.lockfile) return True - except IOError: + except (OSError, IOError): return False def _aquireLock(): }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 13:59:47 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 21:59:47 -0000 Subject: [Bro-Dev] #264: Experimental MPLS support. In-Reply-To: <044.b0b845d09cf6aeaf4acd749d0c4917c2@bro-ids.org> References: <044.b0b845d09cf6aeaf4acd749d0c4917c2@bro-ids.org> Message-ID: <059.8fae5dc6a4f571b5dc197d5e050c6865@bro-ids.org> #264: Experimental MPLS support. ---------------------+------------------------------------------------------ Reporter: robin | Owner: Type: Patch | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.1 Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by seth): * milestone: => Bro1.6 Comment: Current MPLS support is in the topic/seth/mpls branch in the git repository. The code could stand to be checked over by someone else before being merged, but it seems to be functional for me. It now builds appropriate bpf filters for capturing mpls and non-mpls traffic (which the previous patch didn't have automatic support for). It also supports ethernet which the previous patch didn't. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 14:03:56 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Mon, 15 Nov 2010 22:03:56 -0000 Subject: [Bro-Dev] #262: Hooked SSH Analyzer into the Analyzer Tree In-Reply-To: <049.2a53c91963a0785ed42c7a0a0db80e76@bro-ids.org> References: <049.2a53c91963a0785ed42c7a0a0db80e76@bro-ids.org> Message-ID: <064.dfdd47b7152ee5d4d2e6d00b0a9e3b91@bro-ids.org> #262: Hooked SSH Analyzer into the Analyzer Tree -------------------------+-------------------------------------------------- Reporter: brosenberg | Owner: Type: Patch | Status: closed Priority: Normal | Milestone: Component: Bro | Version: 1.5.2 Resolution: Solved | Keywords: -------------------------+-------------------------------------------------- Changes (by seth): * status: new => closed * resolution: => Solved -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 20:51:18 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 04:51:18 -0000 Subject: [Bro-Dev] #251: Bro 1.5.1 will not start In-Reply-To: <060.e79ec5a3807141341951c681b315626c@bro-ids.org> References: <060.e79ec5a3807141341951c681b315626c@bro-ids.org> Message-ID: <075.df9da829c59e4c59892bdd9527912bcc@bro-ids.org> #251: Bro 1.5.1 will not start ------------------------------------+--------------------------------------- Reporter: alan.meeks@? | Owner: Type: defect | Status: closed Priority: Normal | Milestone: Component: Bro | Version: 1.5.1 Resolution: Solved | Keywords: ------------------------------------+--------------------------------------- Changes (by seth): * status: new => closed * resolution: => Solved Comment: I believe this ticket can be closed. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 21:13:15 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 05:13:15 -0000 Subject: [Bro-Dev] #207: Small bug in file rotate+setbuf In-Reply-To: <045.779bbc363dd741be852d73b1db8681ec@bro-ids.org> References: <045.779bbc363dd741be852d73b1db8681ec@bro-ids.org> Message-ID: <060.e4f603a327b5b2b84122eaea52537acf@bro-ids.org> #207: Small bug in file rotate+setbuf ---------------------+------------------------------------------------------ Reporter: justin | Owner: vern Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: rotate buffer ---------------------+------------------------------------------------------ Changes (by seth): * owner: => vern * status: new => assigned * type: Problem => Patch * milestone: => Bro1.6 Comment: This looks like a pretty reasonable change. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 21:16:02 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 05:16:02 -0000 Subject: [Bro-Dev] #203: RemoteSerializer InternalCommError crashes manager In-Reply-To: <053.67817cab87c30add2f25ae45e821151f@bro-ids.org> References: <053.67817cab87c30add2f25ae45e821151f@bro-ids.org> Message-ID: <068.ed453891f7066995046a5b4f2d5ec9b9@bro-ids.org> #203: RemoteSerializer InternalCommError crashes manager -----------------------------+---------------------------------------------- Reporter: Tyler.Schoenke | Owner: Type: Problem | Status: seen Priority: Normal | Milestone: Component: Bro | Version: 1.5.2 Resolution: | Keywords: -----------------------------+---------------------------------------------- Comment (by seth): Have these problems been fixed for you? If they have been, do you recall all of the changes you made to your cluster to deal with it? Thanks. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 21:16:53 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 05:16:53 -0000 Subject: [Bro-Dev] #222: Patch to fix scaling factor in prettyPrintVal In-Reply-To: <043.c05e54f6c2d35bb4b8dd9e710044ca89@bro-ids.org> References: <043.c05e54f6c2d35bb4b8dd9e710044ca89@bro-ids.org> Message-ID: <058.42185a81a5d527e4b4f2a86d6bfeadec@bro-ids.org> #222: Patch to fix scaling factor in prettyPrintVal -------------------------+-------------------------------------------------- Reporter: seth | Owner: robin Type: Patch | Status: new Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: 1.5.2 Resolution: | Keywords: -------------------------+-------------------------------------------------- Changes (by seth): * milestone: => Bro1.6 Comment: Bumping patch and assigning it to the 1.6 milestone. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 21:19:35 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 05:19:35 -0000 Subject: [Bro-Dev] #213: Portability fixes for broctl on OpenBSD In-Reply-To: <054.60e6a9a9cc06771e42a1c013d763acee@bro-ids.org> References: <054.60e6a9a9cc06771e42a1c013d763acee@bro-ids.org> Message-ID: <069.6d301aea2fb3da75baf596dace629eb8@bro-ids.org> #213: Portability fixes for broctl on OpenBSD ------------------------------+--------------------------------------------- Reporter: kevlo@? | Owner: robin Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: ------------------------------+--------------------------------------------- Changes (by seth): * owner: => robin * status: needs information => assigned * milestone: => Bro1.6 Comment: Bumping patch, it looks reasonable to me. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 21:27:56 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 05:27:56 -0000 Subject: [Bro-Dev] #148: Crashing in the split1 BiF In-Reply-To: <043.a4c285c3e526f1516d055cb0b7c8a8a6@bro-ids.org> References: <043.a4c285c3e526f1516d055cb0b7c8a8a6@bro-ids.org> Message-ID: <058.cbd4ef56dbafc82aed11f235b3d317e3@bro-ids.org> #148: Crashing in the split1 BiF ----------------------+----------------------------------------------------- Reporter: seth | Owner: Type: Problem | Status: closed Priority: Normal | Milestone: Component: Bro | Version: branches-robin-work Resolution: Solved | Keywords: ----------------------+----------------------------------------------------- Changes (by seth): * status: seen => closed * resolution: => Solved Comment: This problem is addressed in the topic/seth/strings-without-checkstring branch. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 21:29:23 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 05:29:23 -0000 Subject: [Bro-Dev] #145: Bro linker error with newer OpenSSL versions In-Reply-To: <047.097ea0fff52e2e8fa51b4de765939ebf@bro-ids.org> References: <047.097ea0fff52e2e8fa51b4de765939ebf@bro-ids.org> Message-ID: <062.3c2b9a0b62d7bfa5ffb81fa5dedf948d@bro-ids.org> #145: Bro linker error with newer OpenSSL versions -----------------------+---------------------------------------------------- Reporter: vallenti | Owner: kreibich Type: Problem | Status: seen Priority: Low | Milestone: Component: Broccoli | Version: 1.5.2 Resolution: | Keywords: openssl, linker -----------------------+---------------------------------------------------- Comment (by seth): Is this ticket still valid? This is the only report of this issue that I have seen. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 21:31:04 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 05:31:04 -0000 Subject: [Bro-Dev] #72: Use 64Bit integers in Bro by default In-Reply-To: <045.e3497c69dfe36a4cddde29c01881d602@bro-ids.org> References: <045.e3497c69dfe36a4cddde29c01881d602@bro-ids.org> Message-ID: <060.fcd1ade32c0247bf1f93b12cf0927fef@bro-ids.org> #72: Use 64Bit integers in Bro by default ---------------------+------------------------------------------------------ Reporter: gregor | Owner: Type: Task | Status: seen Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: integer size, 64 bit ---------------------+------------------------------------------------------ Changes (by seth): * milestone: => Bro1.6 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 21:34:39 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 05:34:39 -0000 Subject: [Bro-Dev] #69: High volume traffic causes BRO crash In-Reply-To: <054.78a929133ae244303cbf161f4fa579af@bro-ids.org> References: <054.78a929133ae244303cbf161f4fa579af@bro-ids.org> Message-ID: <069.0aeda64d4d296a06a53f949c17853eb2@bro-ids.org> #69: High volume traffic causes BRO crash ------------------------------+--------------------------------------------- Reporter: rreitz@? | Owner: robin Type: Problem | Status: assigned Priority: Normal | Milestone: Component: Bro | Version: branches-robin-work Resolution: | Keywords: ------------------------------+--------------------------------------------- Comment (by seth): Anything new to add to this ticket? I'm going to close it soon unless I hear otherwise since it seems so closely related to other communications system related problems. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 21:42:35 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 05:42:35 -0000 Subject: [Bro-Dev] #26: case insensitive regular expressions In-Reply-To: <043.6cb0ef3de85a1510a96a0da805806f1f@bro-ids.org> References: <043.6cb0ef3de85a1510a96a0da805806f1f@bro-ids.org> Message-ID: <058.b18a24206a5f9a0ebd76e91008956dec@bro-ids.org> #26: case insensitive regular expressions ------------------------------+--------------------------------------------- Reporter: vern | Owner: Type: Feature Request | Status: seen Priority: Normal | Milestone: Component: Bro | Version: Resolution: | Keywords: ------------------------------+--------------------------------------------- Comment (by seth): The existing partial implementation of this is available in the topic/seth /case-insensitive-patterns branch in the git repository. Case insensitivity is enabled with an "i" flag at the end of the pattern. For example: {{{ global my_pattern = /abcdef/i; }}} would match "ABCDEF". The problem with it comes when you do a disjunction between patterns in your Bro script. Pattern disjunctions in Bro are currently done by extracting the text of the pattern and OR-ing them together as text then recreating the DFAs and NFAs but my current implementation of case insensitive patterns does the case insensitivity during construction of the NFAs. Apparently the disjunction can't properly be done with the NFAs alone because of issues with anchored patterns. (something Vern said, but I may have misunderstood it) -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 21:47:51 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 05:47:51 -0000 Subject: [Bro-Dev] #26: case insensitive regular expressions In-Reply-To: <043.6cb0ef3de85a1510a96a0da805806f1f@bro-ids.org> References: <043.6cb0ef3de85a1510a96a0da805806f1f@bro-ids.org> Message-ID: <058.321ff05936352d6f6f5afd8a7eee7bb4@bro-ids.org> #26: case insensitive regular expressions ------------------------------+--------------------------------------------- Reporter: vern | Owner: Type: Feature Request | Status: seen Priority: Normal | Milestone: Component: Bro | Version: Resolution: | Keywords: ------------------------------+--------------------------------------------- Comment (by seth): More thoughts I forgot to add. What I would like to see happen is something along these lines... {{{ const p = /abc/i &redef; redef p += /DEF/; }}} The result would be that /abc/ would be a case insensitive portion of the pattern "p" and /DEF/ would be case sensitive. Continuing... {{{ const p = /abc/ &redef &case_insensitive; redef p += /DEF/; }}} This could be another use case where /abc/ is case insensitive along with /DEF/. This could be useful for situations where a large number of disjunctions are being done or an original script writer wants all further patterns added to the pattern to be case insensitive without needing the user of the script to define all joined patterns as case insensitive. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 21:48:38 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 05:48:38 -0000 Subject: [Bro-Dev] #23: DNS log format is hard to parse In-Reply-To: <043.fe7eeb91269936c735fd40b78971c173@bro-ids.org> References: <043.fe7eeb91269936c735fd40b78971c173@bro-ids.org> Message-ID: <058.17d7c110ae442bd0999089319fc95b93@bro-ids.org> #23: DNS log format is hard to parse ------------------------------+--------------------------------------------- Reporter: vern | Owner: seth Type: Feature Request | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ------------------------------+--------------------------------------------- Changes (by seth): * owner: => seth * status: seen => assigned * milestone: => Bro1.6 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 21:50:16 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 05:50:16 -0000 Subject: [Bro-Dev] #6: Switching between plain ./configure and ./configure --enable-debug requires make clean In-Reply-To: <048.b280c131a6add31aac5771b25bfb1671@bro-ids.org> References: <048.b280c131a6add31aac5771b25bfb1671@bro-ids.org> Message-ID: <063.bf7d551238d45f0cb5acb2bc87f961bf@bro-ids.org> #6: Switching between plain ./configure and ./configure --enable-debug requires make clean ------------------------+--------------------------------------------------- Reporter: Christian | Owner: kreibich Type: Problem | Status: closed Priority: Normal | Milestone: Component: Bro | Version: Resolution: Solved | Keywords: ------------------------+--------------------------------------------------- Changes (by seth): * status: accepted => closed * resolution: => Solved Comment: Closing due to move to CMake. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 21:53:00 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 05:53:00 -0000 Subject: [Bro-Dev] #51: make install-brolite does not install all required files In-Reply-To: <044.455271dab31f9c70d2fb3788b192da85@bro-ids.org> References: <044.455271dab31f9c70d2fb3788b192da85@bro-ids.org> Message-ID: <059.28650276689a28feb145c29a2ced6ef5@bro-ids.org> #51: make install-brolite does not install all required files ----------------------+----------------------------------------------------- Reporter: robin | Owner: robin Type: Problem | Status: closed Priority: Normal | Milestone: Component: Bro | Version: 1.4 Resolution: Solved | Keywords: ----------------------+----------------------------------------------------- Changes (by seth): * status: needs information => closed * resolution: => Solved Comment: Brolite is completely deprecated and this ticket is really old, but the patch will remain here in case anyone needs it. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 21:54:24 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 05:54:24 -0000 Subject: [Bro-Dev] #68: BroV6 support -- memory usage In-Reply-To: <045.e32da8a5a8b128ef16e7ead9e3bd7deb@bro-ids.org> References: <045.e32da8a5a8b128ef16e7ead9e3bd7deb@bro-ids.org> Message-ID: <060.00610204f02f2405d2ca2c0b6e666310@bro-ids.org> #68: BroV6 support -- memory usage ---------------------+------------------------------------------------------ Reporter: gregor | Owner: Type: Task | Status: seen Priority: Normal | Milestone: Bro1.7 Component: Bro | Version: 1.5.2 Resolution: | Keywords: BroV6, binpac++, HILTI ---------------------+------------------------------------------------------ Changes (by seth): * milestone: => Bro1.7 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 22:02:18 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 06:02:18 -0000 Subject: [Bro-Dev] #283: Bro should support mixed MPLS and non-MPLS traffic In-Reply-To: <044.24649684e17527d36edb517ec058a51a@bro-ids.org> References: <044.24649684e17527d36edb517ec058a51a@bro-ids.org> Message-ID: <059.1767acb72d2f8fbf55ae8975cff3e25e@bro-ids.org> #283: Bro should support mixed MPLS and non-MPLS traffic ------------------------------+--------------------------------------------- Reporter: robin | Owner: Type: Feature Request | Status: closed Priority: Normal | Milestone: Component: Bro | Version: 1.5.1 Resolution: Solved | Keywords: ------------------------------+--------------------------------------------- Changes (by seth): * status: new => closed * resolution: => Solved Comment: I updated the experimental patch with this support. More information is in comment number 4 attach to ticket #264. Pcapr.net also has mixed MPLS/non-MPLS tracefiles available for testing. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 22:04:16 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 06:04:16 -0000 Subject: [Bro-Dev] #272: Patch to fix do_split function In-Reply-To: <043.1e378c2cf2d2f272b054d3bd5b2f44d9@bro-ids.org> References: <043.1e378c2cf2d2f272b054d3bd5b2f44d9@bro-ids.org> Message-ID: <058.5e383bcc266ee5f0fabae43b202b0cba@bro-ids.org> #272: Patch to fix do_split function ---------------------+------------------------------------------------------ Reporter: seth | Owner: seth Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by seth): * milestone: => Bro1.6 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 22:06:08 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 06:06:08 -0000 Subject: [Bro-Dev] #265: Entropy testing BiFs In-Reply-To: <043.8e334b34bdf23f9d7b102b8c4e3da6bd@bro-ids.org> References: <043.8e334b34bdf23f9d7b102b8c4e3da6bd@bro-ids.org> Message-ID: <058.40407f6c9cbd476141ce3024e9dc6f20@bro-ids.org> #265: Entropy testing BiFs ---------------------+------------------------------------------------------ Reporter: seth | Owner: Type: Patch | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by seth): * milestone: => Bro1.6 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 22:10:01 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 06:10:01 -0000 Subject: [Bro-Dev] #257: Commandline flag to enable BRO_FAKE_DNS In-Reply-To: <049.463a3aa2505ed0b2731a01396c4cbef8@bro-ids.org> References: <049.463a3aa2505ed0b2731a01396c4cbef8@bro-ids.org> Message-ID: <064.9305f2d0244c327b4760ab0f1709ee83@bro-ids.org> #257: Commandline flag to enable BRO_FAKE_DNS -------------------------+-------------------------------------------------- Reporter: brosenberg | Owner: vern Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: -------------------------+-------------------------------------------------- Changes (by seth): * owner: => vern * status: new => assigned * milestone: => Bro1.6 Comment: This seems like a reasonable patch to me. The only thing that may need changed is the help string since it's not very obvious what it's doing. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 22:10:35 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 06:10:35 -0000 Subject: [Bro-Dev] #267: Patch to fix internal log_encryption_key handling In-Reply-To: <043.efcd269209695b49b3d8f0ada56409ce@bro-ids.org> References: <043.efcd269209695b49b3d8f0ada56409ce@bro-ids.org> Message-ID: <058.4e82b12037b70230130b6aa218f395e7@bro-ids.org> #267: Patch to fix internal log_encryption_key handling ---------------------+------------------------------------------------------ Reporter: seth | Owner: Type: Patch | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by seth): * milestone: => Bro1.6 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 22:11:23 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 06:11:23 -0000 Subject: [Bro-Dev] #254: Build fails without openssl In-Reply-To: <044.6b28c8d8227cee16edbf83a190a62137@bro-ids.org> References: <044.6b28c8d8227cee16edbf83a190a62137@bro-ids.org> Message-ID: <059.1431ea48cae0d6b5528688b8ef7e09be@bro-ids.org> #254: Build fails without openssl ----------------------+----------------------------------------------------- Reporter: matti | Owner: Type: Problem | Status: closed Priority: Low | Milestone: Component: Bro | Version: 1.5.2 Resolution: Solved | Keywords: openssl, broccoli ----------------------+----------------------------------------------------- Changes (by seth): * status: new => closed * resolution: => Solved Comment: These will be legacy issues soon due to the move to CMake. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 22:13:02 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 06:13:02 -0000 Subject: [Bro-Dev] #247: Bro trunk build fails with OpenSSL stack error In-Reply-To: <047.50baac97db1997fb95f119eebf1fbebf@bro-ids.org> References: <047.50baac97db1997fb95f119eebf1fbebf@bro-ids.org> Message-ID: <062.70862257dee21aaa10db9a454fd07e5c@bro-ids.org> #247: Bro trunk build fails with OpenSSL stack error -----------------------+---------------------------------------------------- Reporter: kreibich | Owner: kreibich Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: -----------------------+---------------------------------------------------- Changes (by seth): * milestone: => Bro1.6 Comment: This patch seems to work for me too. It would be good to get this included in SVN HEAD and devel in git. Is this something appropriate for fastpath integration in git? -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 22:15:50 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 06:15:50 -0000 Subject: [Bro-Dev] #243: Changes to broctl In-Reply-To: <044.307ed58dbf28e3c18c0ca0f890ff32c3@bro-ids.org> References: <044.307ed58dbf28e3c18c0ca0f890ff32c3@bro-ids.org> Message-ID: <059.6dce0b6148567eff36f50c83ea97a279@bro-ids.org> #243: Changes to broctl -------------------------+-------------------------------------------------- Reporter: robin | Owner: robin Type: Patch | Status: assigned Priority: Normal | Milestone: Component: BroControl | Version: 1.5.2 Resolution: | Keywords: -------------------------+-------------------------------------------------- Comment (by seth): This can be applied now, right? It looks like the change that you said needed to be applied before this one has now been merged. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 22:20:50 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 06:20:50 -0000 Subject: [Bro-Dev] #236: Fix for typo in util.py In-Reply-To: <056.eb400f5c720fcbc89b84a3666efcf50d@bro-ids.org> References: <056.eb400f5c720fcbc89b84a3666efcf50d@bro-ids.org> Message-ID: <071.5f38c1b4c93ba411bc929d7b4870e3ef@bro-ids.org> #236: Fix for typo in util.py --------------------------------+------------------------------------------- Reporter: mccreary@? | Owner: Type: Patch | Status: closed Priority: Normal | Milestone: Component: Bro | Version: 1.5.2 Resolution: Duplicate | Keywords: --------------------------------+------------------------------------------- Changes (by seth): * status: new => closed * resolution: => Duplicate -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 22:22:04 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 06:22:04 -0000 Subject: [Bro-Dev] #260: Updated policy/ssh.bro to track ssh server ports In-Reply-To: <049.3e61c2f4af9c9ac3a15007175516f2d0@bro-ids.org> References: <049.3e61c2f4af9c9ac3a15007175516f2d0@bro-ids.org> Message-ID: <064.eee2f739164f1a7bc51af00f1ef6f734@bro-ids.org> #260: Updated policy/ssh.bro to track ssh server ports -------------------------+-------------------------------------------------- Reporter: brosenberg | Owner: Type: Patch | Status: closed Priority: Normal | Milestone: Component: Bro | Version: 1.5.2 Resolution: Solved | Keywords: -------------------------+-------------------------------------------------- Changes (by seth): * status: new => closed * resolution: => Solved Comment: The SSH script is being heavily rewritten for the next release. Thanks! -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 22:26:26 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 06:26:26 -0000 Subject: [Bro-Dev] #235: libssl detection problem In-Reply-To: <056.04e69612eb9f293baef1460df4a1e845@bro-ids.org> References: <056.04e69612eb9f293baef1460df4a1e845@bro-ids.org> Message-ID: <071.621ef67c4f8f9a476b3924271ff6a752@bro-ids.org> #235: libssl detection problem --------------------------------+------------------------------------------- Reporter: mccreary@? | Owner: Type: Patch | Status: closed Priority: Normal | Milestone: Component: Bro | Version: 1.5.1 Resolution: Solved | Keywords: --------------------------------+------------------------------------------- Changes (by seth): * status: new => closed * resolution: => Solved Comment: This problem won't exist after the move to CMake. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Mon Nov 15 22:27:29 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 06:27:29 -0000 Subject: [Bro-Dev] #234: RPM spec for BRO In-Reply-To: <060.c786c37f0467ab3a10e097503e3b7462@bro-ids.org> References: <060.c786c37f0467ab3a10e097503e3b7462@bro-ids.org> Message-ID: <075.0faa5ea499668530b4c52650a6211c68@bro-ids.org> #234: RPM spec for BRO ------------------------------------+--------------------------------------- Reporter: brad.doctor@? | Owner: Type: Patch | Status: seen Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: rpm spec ------------------------------------+--------------------------------------- Changes (by seth): * status: new => seen * milestone: => Bro1.6 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Tue Nov 16 06:26:30 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 14:26:30 -0000 Subject: [Bro-Dev] #69: High volume traffic causes BRO crash In-Reply-To: <054.78a929133ae244303cbf161f4fa579af@bro-ids.org> References: <054.78a929133ae244303cbf161f4fa579af@bro-ids.org> Message-ID: <069.22a658ac023471b9264129502f98a5a5@bro-ids.org> #69: High volume traffic causes BRO crash -------------------------------+-------------------------------------------- Reporter: rreitz@? | Owner: robin Type: Problem | Status: closed Priority: Normal | Milestone: Component: Bro | Version: branches-robin-work Resolution: Feedback Missing | Keywords: -------------------------------+-------------------------------------------- Changes (by seth): * status: assigned => closed * resolution: => Feedback Missing Comment: From rreitz: {{{ I have nothing to add. Please close the ticket. Thanks, Randy }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Tue Nov 16 06:35:17 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 14:35:17 -0000 Subject: [Bro-Dev] #224: Patch to make cluster events redef-able In-Reply-To: <043.6a95a8887f1a2a867594821e13021bb6@bro-ids.org> References: <043.6a95a8887f1a2a867594821e13021bb6@bro-ids.org> Message-ID: <058.67c989b80b3569de8b65a8d133f1475b@bro-ids.org> #224: Patch to make cluster events redef-able -------------------------+-------------------------------------------------- Reporter: seth | Owner: robin Type: Patch | Status: new Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: 1.5.2 Resolution: | Keywords: -------------------------+-------------------------------------------------- Changes (by seth): * milestone: => Bro1.6 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Tue Nov 16 06:37:02 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 14:37:02 -0000 Subject: [Bro-Dev] #208: broctl netstats broken on cluster In-Reply-To: <045.45796dd3abfdc9eb556105893bafacf5@bro-ids.org> References: <045.45796dd3abfdc9eb556105893bafacf5@bro-ids.org> Message-ID: <060.13d25f5ece4648227ea41cad1ca6fc7f@bro-ids.org> #208: broctl netstats broken on cluster -------------------------+-------------------------------------------------- Reporter: justin | Owner: robin Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: 1.5.2 Resolution: | Keywords: netstats cluster -------------------------+-------------------------------------------------- Changes (by seth): * status: new => assigned * milestone: => Bro1.6 Comment: Patch looks correct to me. -- Ticket URL: Bro Tracker Bro Issue Tracker From rreitz at fnal.gov Tue Nov 16 06:04:50 2010 From: rreitz at fnal.gov (Randolph Reitz) Date: Tue, 16 Nov 2010 08:04:50 -0600 Subject: [Bro-Dev] #69: High volume traffic causes BRO crash In-Reply-To: <069.0aeda64d4d296a06a53f949c17853eb2@bro-ids.org> References: <054.78a929133ae244303cbf161f4fa579af@bro-ids.org> <069.0aeda64d4d296a06a53f949c17853eb2@bro-ids.org> Message-ID: <5D1A2007-0921-4EA1-BA0C-29DFAE4A36E0@fnal.gov> I have nothing to add. Please close the ticket. Thanks, Randy On Nov 15, 2010, at 11:34 PM, Bro Tracker wrote: > #69: High volume traffic causes BRO crash > ------------------------------+--------------------------------------------- > Reporter: rreitz@? | Owner: robin > Type: Problem | Status: assigned > Priority: Normal | Milestone: > Component: Bro | Version: branches-robin-work > Resolution: | Keywords: > ------------------------------+--------------------------------------------- > > Comment (by seth): > > Anything new to add to this ticket? I'm going to close it soon unless I > hear otherwise since it seems so closely related to other communications > system related problems. > > -- > Ticket URL: > Bro Tracker > Bro Issue Tracker From bro-dev at bro-ids.org Tue Nov 16 07:49:14 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 15:49:14 -0000 Subject: [Bro-Dev] #203: RemoteSerializer InternalCommError crashes manager In-Reply-To: <053.67817cab87c30add2f25ae45e821151f@bro-ids.org> References: <053.67817cab87c30add2f25ae45e821151f@bro-ids.org> Message-ID: <068.8ed83d85230bac0a41226b5c518d2478@bro-ids.org> #203: RemoteSerializer InternalCommError crashes manager -----------------------------+---------------------------------------------- Reporter: Tyler.Schoenke | Owner: Type: Problem | Status: seen Priority: Normal | Milestone: Component: Bro | Version: 1.5.2 Resolution: | Keywords: -----------------------------+---------------------------------------------- Comment (by Tyler.Schoenke): Yes, the error was due to too much logging from the workers to the manager. Running capstats shows that I was using 17 to 25 mbps. After filtering some of the most verbose worker logging in local.bro, the rates dropped to between 5 and 11 mbps. The RemoteSerializer error hasn't shown up since. You gave me some patches to RemoteSerializer.cc to try. The patches may have helped a little, but reducing the logging rate is really what cleared up the error. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Tue Nov 16 07:58:45 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 15:58:45 -0000 Subject: [Bro-Dev] #203: RemoteSerializer InternalCommError crashes manager In-Reply-To: <053.67817cab87c30add2f25ae45e821151f@bro-ids.org> References: <053.67817cab87c30add2f25ae45e821151f@bro-ids.org> Message-ID: <068.5494b2904f08b6b93ceb6f9a5cd80a9f@bro-ids.org> #203: RemoteSerializer InternalCommError crashes manager -----------------------------+---------------------------------------------- Reporter: Tyler.Schoenke | Owner: Type: Problem | Status: closed Priority: Normal | Milestone: Component: Bro | Version: 1.5.2 Resolution: Duplicate | Keywords: -----------------------------+---------------------------------------------- Changes (by seth): * status: seen => closed * resolution: => Duplicate Comment: Thanks for the follow up. I'm closing this ticket now since we have other tickets about the communication system overloading issue. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Tue Nov 16 08:12:38 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 16:12:38 -0000 Subject: [Bro-Dev] #308: Test123 Message-ID: <051.882eb40810285dc8370e3cdc20993fe7@bro-ids.org> #308: Test123 --------------------------+------------------------------------------------- Reporter: basv@? | Type: defect Status: new | Priority: Normal Component: Bro | --------------------------+------------------------------------------------- {{{ Test1234 Test1234 -- -- ******************************************************************** * * * Bas van der Vlies e-mail: basv at sara.nl * * SARA - Academic Computing Services phone: +31 20 592 8012 * * Kruislaan 415 fax: +31 20 6683167 * * 1098 SJ Amsterdam * * * ******************************************************************** }}} {{{ test123 test1234 }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Tue Nov 16 08:15:14 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 16:15:14 -0000 Subject: [Bro-Dev] #308: Test123 In-Reply-To: <051.882eb40810285dc8370e3cdc20993fe7@bro-ids.org> References: <051.882eb40810285dc8370e3cdc20993fe7@bro-ids.org> Message-ID: <066.70a01de3ef66cf07731a216c1878f66f@bro-ids.org> #308: Test123 ---------------------------+------------------------------------------------ Reporter: basv@? | Owner: Type: defect | Status: closed Priority: Normal | Milestone: Component: Bro | Version: Resolution: Rejected | Keywords: ---------------------------+------------------------------------------------ Changes (by seth): * status: new => closed * resolution: => Rejected Comment: Manually tested installation of email2trac. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Tue Nov 16 09:12:28 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 17:12:28 -0000 Subject: [Bro-Dev] #292: Cluttering of alarm.log with serialization messages In-Reply-To: <047.7dd189330e344b30c6d647cacb8d3cd8@bro-ids.org> References: <047.7dd189330e344b30c6d647cacb8d3cd8@bro-ids.org> Message-ID: <062.08979512923407cf67b5abb789cab2c2@bro-ids.org> #292: Cluttering of alarm.log with serialization messages -------------------------+-------------------------------------------------- Reporter: vallenti | Owner: robin Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: 1.5.1 Resolution: | Keywords: -------------------------+-------------------------------------------------- Comment (by gregor): I don't like using "stderr.log" as a filename! I often redirect stderr to exactly that file and I think other people do too! So, opening stderr.log from bro would cause confusion. How about serialize.log? -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Tue Nov 16 09:22:38 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 17:22:38 -0000 Subject: [Bro-Dev] #26: case insensitive regular expressions In-Reply-To: <043.6cb0ef3de85a1510a96a0da805806f1f@bro-ids.org> References: <043.6cb0ef3de85a1510a96a0da805806f1f@bro-ids.org> Message-ID: <058.8c1f5ef354f29b45781a4d01648a15ea@bro-ids.org> #26: case insensitive regular expressions ------------------------------+--------------------------------------------- Reporter: vern | Owner: Type: Feature Request | Status: seen Priority: Normal | Milestone: Component: Bro | Version: Resolution: | Keywords: ------------------------------+--------------------------------------------- Comment (by gregor): How about using pythons regex syntax for case-insensitivity? (E.g., (?iABC) ) -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Tue Nov 16 09:24:38 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 17:24:38 -0000 Subject: [Bro-Dev] #23: DNS log format is hard to parse In-Reply-To: <043.fe7eeb91269936c735fd40b78971c173@bro-ids.org> References: <043.fe7eeb91269936c735fd40b78971c173@bro-ids.org> Message-ID: <058.0ef88fffb91a3407221650be1c079854@bro-ids.org> #23: DNS log format is hard to parse ------------------------------+--------------------------------------------- Reporter: vern | Owner: seth Type: Feature Request | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ------------------------------+--------------------------------------------- Comment (by gregor): I general, it might also be worth considering whether the events the analyzer generates should be cleaned up. Currently the analyzer generates one event per RR and one has to have a handler for each in order to analyze the whole DNS reply. Maybe something for the binpac++ DNS analyzer. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Tue Nov 16 09:32:33 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 17:32:33 -0000 Subject: [Bro-Dev] #292: Cluttering of alarm.log with serialization messages In-Reply-To: <047.7dd189330e344b30c6d647cacb8d3cd8@bro-ids.org> References: <047.7dd189330e344b30c6d647cacb8d3cd8@bro-ids.org> Message-ID: <062.09923d25e6a2aadc94ee0559fbce0c3f@bro-ids.org> #292: Cluttering of alarm.log with serialization messages -------------------------+-------------------------------------------------- Reporter: vallenti | Owner: robin Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: 1.5.1 Resolution: | Keywords: -------------------------+-------------------------------------------------- Comment (by seth): I don't like the name stderr.log either. I just felt like it was better to suggest something rather than nothing. What if we send those logs to syslog by default if no filename is assigned? It sort of makes sense since it's information about the Bro process and not really related to what Bro is doing. You could still get those logs in a file with the other Bro logs if you assign a filename to some variable. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Tue Nov 16 09:33:29 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Tue, 16 Nov 2010 17:33:29 -0000 Subject: [Bro-Dev] #26: case insensitive regular expressions In-Reply-To: <043.6cb0ef3de85a1510a96a0da805806f1f@bro-ids.org> References: <043.6cb0ef3de85a1510a96a0da805806f1f@bro-ids.org> Message-ID: <058.a8f3d0e33958333e7cc9a6777e6fd444@bro-ids.org> #26: case insensitive regular expressions ------------------------------+--------------------------------------------- Reporter: vern | Owner: Type: Feature Request | Status: seen Priority: Normal | Milestone: Component: Bro | Version: Resolution: | Keywords: ------------------------------+--------------------------------------------- Comment (by seth): Why that over the trailing "i"? Using that syntax still doesn't solve the problem of how the disjunction is done between patterns. -- Ticket URL: Bro Tracker Bro Issue Tracker From seth at icir.org Tue Nov 16 13:53:26 2010 From: seth at icir.org (Seth Hall) Date: Tue, 16 Nov 2010 16:53:26 -0500 Subject: [Bro-Dev] Yet another thing to detect Message-ID: <89EBB880-A0A4-4109-9AFC-B42B411EDA22@icir.org> This should be easy to write a detection script for... http://chaptersinwebsecurity.blogspot.com/2010/11/universal-http-dos-are-you-dead-yet.html It's a tool that implements the recently discussed slow POST http DoS attack. The client sends a long-ish Content-Length header (maybe even just 1000) and then every 15 seconds or so, sends a byte of data. It takes a long time to send the entire 1000 bytes and the web server will sit there waiting for all of the data so it's very easy to exhaust resources on the server. .Seth From bro-dev at bro-ids.org Tue Nov 16 16:57:12 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Wed, 17 Nov 2010 00:57:12 -0000 Subject: [Bro-Dev] #309: test ticket Message-ID: <043.1ed61cbe59b18e33e6bb18e701250a6d@bro-ids.org> #309: test ticket ------------------+--------------------------------------------------------- Reporter: seth | Type: defect Status: new | Priority: Normal Component: Bro | ------------------+--------------------------------------------------------- {{{ This is a test ticket }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From seth at icir.org Tue Nov 16 17:00:01 2010 From: seth at icir.org (Seth Hall) Date: Tue, 16 Nov 2010 20:00:01 -0500 Subject: [Bro-Dev] #309: test ticket In-Reply-To: <043.1ed61cbe59b18e33e6bb18e701250a6d@bro-ids.org> References: <043.1ed61cbe59b18e33e6bb18e701250a6d@bro-ids.org> Message-ID: <90FE0095-1592-47EB-BF4B-F85261B9F984@icir.org> Comment? On Nov 16, 2010, at 7:57 PM, Bro Tracker wrote: > #309: test ticket > ------------------+--------------------------------------------------------- > Reporter: seth | Type: defect > Status: new | Priority: Normal > Component: Bro | > ------------------+--------------------------------------------------------- > {{{ > This is a test ticket > > > }}} > > -- > Ticket URL: > Bro Tracker > Bro Issue Tracker > From bro-dev at bro-ids.org Tue Nov 16 17:00:03 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Wed, 17 Nov 2010 01:00:03 -0000 Subject: [Bro-Dev] #310: Re: #309: test ticket Message-ID: <043.40124dddcfdc4c30aa95af47ea45de86@bro-ids.org> #310: Re: #309: test ticket ------------------+--------------------------------------------------------- Reporter: seth | Type: defect Status: new | Priority: Normal Component: Bro | ------------------+--------------------------------------------------------- {{{ Comment? On Nov 16, 2010, at 7:57 PM, Bro Tracker wrote: > #309: test ticket > ------------------+--------------------------------------------------------- > Reporter: seth | Type: defect > Status: new | Priority: Normal > Component: Bro | > ------------------+--------------------------------------------------------- > {{{ > This is a test ticket > > > }}} > > -- > Ticket URL: > Bro Tracker > Bro Issue Tracker > }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Tue Nov 16 17:01:04 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Wed, 17 Nov 2010 01:01:04 -0000 Subject: [Bro-Dev] #309: test ticket In-Reply-To: <043.1ed61cbe59b18e33e6bb18e701250a6d@bro-ids.org> References: <043.1ed61cbe59b18e33e6bb18e701250a6d@bro-ids.org> Message-ID: <058.0fae6b900ff6c8b7ae32f6b0afe40ffa@bro-ids.org> #309: test ticket -----------------------+---------------------------------------------------- Reporter: seth | Owner: Type: defect | Status: closed Priority: Normal | Milestone: Component: Bro | Version: Resolution: Rejected | Keywords: -----------------------+---------------------------------------------------- Changes (by seth): * status: new => closed * resolution: => Rejected -- Ticket URL: Bro Tracker Bro Issue Tracker From bro-dev at bro-ids.org Tue Nov 16 17:01:20 2010 From: bro-dev at bro-ids.org (Bro Tracker) Date: Wed, 17 Nov 2010 01:01:20 -0000 Subject: [Bro-Dev] #310: Re: #309: test ticket In-Reply-To: <043.40124dddcfdc4c30aa95af47ea45de86@bro-ids.org> References: <043.40124dddcfdc4c30aa95af47ea45de86@bro-ids.org> Message-ID: <058.58129293f80efccfd6fa82fa4ccb5f45@bro-ids.org> #310: Re: #309: test ticket -----------------------+---------------------------------------------------- Reporter: seth | Owner: Type: defect | Status: closed Priority: Normal | Milestone: Component: Bro | Version: Resolution: Rejected | Keywords: -----------------------+---------------------------------------------------- Changes (by seth): * status: new => closed * resolution: => Rejected -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Tue Nov 16 17:58:02 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 01:58:02 -0000 Subject: [Bro-Dev] #311: yet another test ticket Message-ID: <043.595c063c2eff25d1c0c9de5b941aa2e1@tracker.icir.org> #311: yet another test ticket ------------------+--------------------------------------------------------- Reporter: seth | Type: defect Status: new | Priority: Normal Component: Bro | ------------------+--------------------------------------------------------- {{{ Body for the test ticket. }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Tue Nov 16 18:09:57 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 02:09:57 -0000 Subject: [Bro-Dev] #312: test ticket Message-ID: <043.4e3115d6c4ceae742c313dbeab2358df@tracker.icir.org> #312: test ticket ------------------+--------------------------------------------------------- Reporter: seth | Type: defect Status: new | Priority: Normal Component: Bro | ------------------+--------------------------------------------------------- {{{ Yet another test ticket }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Tue Nov 16 18:15:02 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 02:15:02 -0000 Subject: [Bro-Dev] #313: more testing Message-ID: <043.8a8f6ae36405ad25c812c26322b8b806@tracker.icir.org> #313: more testing ---------------------+------------------------------------------------------ Reporter: seth | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Component: Bro | Version: Keywords: | ---------------------+------------------------------------------------------ test -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Tue Nov 16 18:17:52 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 02:17:52 -0000 Subject: [Bro-Dev] #314: test Message-ID: <043.525039ed3fa0bd44413bc67fe10d1cb9@tracker.icir.org> #314: test ------------------+--------------------------------------------------------- Reporter: seth | Type: defect Status: new | Priority: Normal Component: Bro | ------------------+--------------------------------------------------------- {{{ sigh }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Tue Nov 16 18:26:56 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 02:26:56 -0000 Subject: [Bro-Dev] #313: more testing In-Reply-To: <043.8a8f6ae36405ad25c812c26322b8b806@tracker.icir.org> References: <043.8a8f6ae36405ad25c812c26322b8b806@tracker.icir.org> Message-ID: <058.21c0d72effa10d3d44b079d70b91f76b@tracker.icir.org> #313: more testing ----------------------+----------------------------------------------------- Reporter: seth | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Component: Bro | Version: Resolution: | Keywords: ----------------------+----------------------------------------------------- Comment (by seth): {{{ What does this do? On Nov 16, 2010, at 9:15 PM, Bro Tracker wrote: > #313: more testing > ---------------------+------------------------------------------------------ > Reporter: seth | Owner: > Type: Problem | Status: new > Priority: Normal | Milestone: > Component: Bro | Version: > Keywords: | > ---------------------+------------------------------------------------------ > test > > -- > Ticket URL: > Bro Tracker > Bro Issue Tracker > }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Tue Nov 16 18:28:40 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 02:28:40 -0000 Subject: [Bro-Dev] #314: test In-Reply-To: <043.525039ed3fa0bd44413bc67fe10d1cb9@tracker.icir.org> References: <043.525039ed3fa0bd44413bc67fe10d1cb9@tracker.icir.org> Message-ID: <058.db62aad6ee70736330ad9bbf94d460af@tracker.icir.org> #314: test -----------------------+---------------------------------------------------- Reporter: seth | Owner: Type: defect | Status: closed Priority: Normal | Milestone: Component: Bro | Version: Resolution: Rejected | Keywords: -----------------------+---------------------------------------------------- Changes (by seth): * status: new => closed * resolution: => Rejected -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Tue Nov 16 18:29:00 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 02:29:00 -0000 Subject: [Bro-Dev] #313: more testing In-Reply-To: <043.8a8f6ae36405ad25c812c26322b8b806@tracker.icir.org> References: <043.8a8f6ae36405ad25c812c26322b8b806@tracker.icir.org> Message-ID: <058.ed52d3716f544fc1827f23f49993b563@tracker.icir.org> #313: more testing -----------------------+---------------------------------------------------- Reporter: seth | Owner: Type: Problem | Status: closed Priority: Normal | Milestone: Component: Bro | Version: Resolution: Rejected | Keywords: -----------------------+---------------------------------------------------- Changes (by seth): * status: new => closed * resolution: => Rejected -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Tue Nov 16 18:29:17 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 02:29:17 -0000 Subject: [Bro-Dev] #312: test ticket In-Reply-To: <043.4e3115d6c4ceae742c313dbeab2358df@tracker.icir.org> References: <043.4e3115d6c4ceae742c313dbeab2358df@tracker.icir.org> Message-ID: <058.2e9ff1fc73b13f2150bb2762d123ce48@tracker.icir.org> #312: test ticket -----------------------+---------------------------------------------------- Reporter: seth | Owner: Type: defect | Status: closed Priority: Normal | Milestone: Component: Bro | Version: Resolution: Rejected | Keywords: -----------------------+---------------------------------------------------- Changes (by seth): * status: new => closed * resolution: => Rejected -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Tue Nov 16 18:29:31 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 02:29:31 -0000 Subject: [Bro-Dev] #311: yet another test ticket In-Reply-To: <043.595c063c2eff25d1c0c9de5b941aa2e1@tracker.icir.org> References: <043.595c063c2eff25d1c0c9de5b941aa2e1@tracker.icir.org> Message-ID: <058.e8db5fbddbbdad93478ee2471feb3851@tracker.icir.org> #311: yet another test ticket -----------------------+---------------------------------------------------- Reporter: seth | Owner: Type: defect | Status: closed Priority: Normal | Milestone: Component: Bro | Version: Resolution: Rejected | Keywords: -----------------------+---------------------------------------------------- Changes (by seth): * status: new => closed * resolution: => Rejected -- Ticket URL: Bro Tracker Bro Issue Tracker From seth at icir.org Tue Nov 16 18:46:40 2010 From: seth at icir.org (Seth Hall) Date: Tue, 16 Nov 2010 21:46:40 -0500 Subject: [Bro-Dev] #309: test ticket In-Reply-To: <90FE0095-1592-47EB-BF4B-F85261B9F984@icir.org> References: <043.1ed61cbe59b18e33e6bb18e701250a6d@bro-ids.org> <90FE0095-1592-47EB-BF4B-F85261B9F984@icir.org> Message-ID: <24C2653D-A359-431C-BF76-8B46ABB6F160@icir.org> On Nov 16, 2010, at 8:00 PM, Seth Hall wrote: > Comment? Whoops. Sending to bro-dev was an accident. Tomorrow I'll document how to work with the new tracker email interface. :) .Seth From bro at icir.org Wed Nov 17 06:34:57 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 14:34:57 -0000 Subject: [Bro-Dev] #315: test ticket Message-ID: <043.e817cef6a612c71f43793dbad39f1879@tracker.icir.org> #315: test ticket ------------------+--------------------------------------------------------- Reporter: seth | Type: defect Status: new | Priority: Normal Component: Bro | ------------------+--------------------------------------------------------- {{{ testing }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Wed Nov 17 06:42:40 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 14:42:40 -0000 Subject: [Bro-Dev] #316: test Message-ID: <043.7897d26a2583ecbb72157541e677ee8e@tracker.icir.org> #316: test ------------------+--------------------------------------------------------- Reporter: seth | Type: defect Status: new | Priority: Normal Component: Bro | ------------------+--------------------------------------------------------- {{{ more testing }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Wed Nov 17 06:45:28 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 14:45:28 -0000 Subject: [Bro-Dev] #317: test Message-ID: <043.ee562b6bc90cf14df481ceb9e051d535@tracker.icir.org> #317: test ------------------+--------------------------------------------------------- Reporter: seth | Type: defect Status: new | Priority: Normal Component: Bro | ------------------+--------------------------------------------------------- {{{ test ticket }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Wed Nov 17 07:31:46 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 15:31:46 -0000 Subject: [Bro-Dev] #315: test Message-ID: <053.7d9b04e69f25ff1692040dece8e3aeeb@tracker.icir.org> #315: test ----------------------------+----------------------------------------------- Reporter: seth@? | Type: defect Status: new | Priority: Normal Component: Bro | ----------------------------+----------------------------------------------- {{{ test ticket }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Wed Nov 17 08:11:04 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 16:11:04 -0000 Subject: [Bro-Dev] #315: test Message-ID: <053.7d9b04e69f25ff1692040dece8e3aeeb@tracker.icir.org> #315: test ----------------------------+----------------------------------------------- Reporter: seth@? | Type: defect Status: new | Priority: Normal Component: Bro | ----------------------------+----------------------------------------------- test -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Wed Nov 17 08:37:16 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 16:37:16 -0000 Subject: [Bro-Dev] #315: test Message-ID: <053.7d9b04e69f25ff1692040dece8e3aeeb@tracker.icir.org> #315: test ----------------------------+----------------------------------------------- Reporter: seth@? | Type: defect Status: new | Priority: Normal Component: Bro | ----------------------------+----------------------------------------------- test -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Wed Nov 17 08:44:40 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 16:44:40 -0000 Subject: [Bro-Dev] #315: test Message-ID: <053.7d9b04e69f25ff1692040dece8e3aeeb@tracker.icir.org> #315: test ----------------------------+----------------------------------------------- Reporter: seth@? | Type: defect Status: new | Priority: Normal Component: Bro | ----------------------------+----------------------------------------------- test -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Wed Nov 17 08:46:31 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 16:46:31 -0000 Subject: [Bro-Dev] #316: test blah Message-ID: <053.a5dfcddab5570448647d761fa50d9e1f@tracker.icir.org> #316: test blah ----------------------------+----------------------------------------------- Reporter: seth@? | Type: defect Status: new | Priority: Normal Component: Bro | ----------------------------+----------------------------------------------- blah -- Ticket URL: Bro Tracker Bro Issue Tracker From robin at icir.org Wed Nov 17 10:14:28 2010 From: robin at icir.org (Robin Sommer) Date: Wed, 17 Nov 2010 10:14:28 -0800 Subject: [Bro-Dev] Tarballs Message-ID: <20101117181428.GA24922@icir.org> Here's a proposal for tar-balls to offer for download in the future, in terms of which repos are in there: bro-a.b.c.tgz bro.git binpac.git bro-aux.git broccoli-d.e.f.tgz broccoli.git broccoli-python.git broctl-g.h.i.tgz broctl.git capstats.git trace-summary.git pysubnettree.git broccoli.git broccoli-python.git bro-scripts-.tgz [1] bro-scripts.git bro-all-a.b.c.tgz (using Bro's version number). All repos (except bro-scripts.git I guess) When untar'ing, they'd all extract into the directories the super module lays out for them (which means it doesn't matter whether one gets broccoli-x.y.z.tgz on top of broctl-x.y.z.tgz). We could do our binary packages along a similar structure.[2 Thoughts? Robin [1] I see the main way to distribute these as indvidually via the web server. However, seems there's nothign wrong with also offering them all at once for download. [2] Distributions will want it separeately per repo, but for, e.g., an MacOS package, it seems more convinient to have few pieces to download/install). -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From bro at icir.org Wed Nov 17 10:33:40 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 18:33:40 -0000 Subject: [Bro-Dev] #326: final test ticket Message-ID: <043.c81793b2ea7d7e668ee1258f54818f37@tracker.icir.org> #326: final test ticket ------------------+------------------- Reporter: seth | Type: defect Status: new | Priority: Normal Component: Bro | ------------------+------------------- I promise this is the last one. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at icir.org Wed Nov 17 10:40:11 2010 From: bro at icir.org (Bro Tracker) Date: Wed, 17 Nov 2010 18:40:11 -0000 Subject: [Bro-Dev] #209: small patch SSLv3 for detect Extensions Length in bro v1.5.1 In-Reply-To: <044.7c191d0120e9467534546d45a5a29a54@tracker.icir.org> References: <044.7c191d0120e9467534546d45a5a29a54@tracker.icir.org> Message-ID: <059.0443375fe351dbfa45f77b13c68619b1@tracker.icir.org> #209: small patch SSLv3 for detect Extensions Length in bro v1.5.1 ---------------------+---------------------------- Reporter: rmkml | Owner: Type: Patch | Status: seen Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: ssl extensions ---------------------+---------------------------- Changes (by seth): * status: new => seen * milestone: => Bro1.6 Comment: I want to get this patch in for the next Bro release, but I want to go a little further with it and actually extract the server_name used. Maybe it is worthwhile to get this patch in as-is in the case that we don't get around to extracting the server_name though. -- Ticket URL: Bro Tracker Bro Issue Tracker From seth at icir.org Wed Nov 17 10:43:35 2010 From: seth at icir.org (Seth Hall) Date: Wed, 17 Nov 2010 13:43:35 -0500 Subject: [Bro-Dev] Ticket tracker Message-ID: Sorry about all of the bogus ticket emails, there was a small bug in the email2trac script that I had to track down and fix so that we could reject email from anyone that doesn't have a tracker account. I'll send out some documentation on how to work with the email interface to the tracker soon. .Seth From bro at tracker.icir.org Wed Nov 17 18:43:40 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 18 Nov 2010 02:43:40 -0000 Subject: [Bro-Dev] #309: Work with Endace to get their code back in Message-ID: <044.3a3dbbce862eefefe6168d74b94b6a54@tracker.icir.org> #309: Work with Endace to get their code back in -------------------+------------------- Reporter: robin | Type: defect Status: new | Priority: Normal Component: Bro | -------------------+------------------- Endace has offered to provide patches for getting DAG support back in, and also to extend the code for leveraging separate input streams. Let's get back to Endace when things are in a more stable state. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Nov 17 18:44:56 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 18 Nov 2010 02:44:56 -0000 Subject: [Bro-Dev] #309: Work with Endace to get their code back in In-Reply-To: <044.3a3dbbce862eefefe6168d74b94b6a54@tracker.icir.org> References: <044.3a3dbbce862eefefe6168d74b94b6a54@tracker.icir.org> Message-ID: <059.9183bfd390742c582afd19f93e2917a9@tracker.icir.org> #309: Work with Endace to get their code back in ---------------------+-------------------- Reporter: robin | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ---------------------+-------------------- Changes (by robin): * type: defect => Task * milestone: => Bro1.6 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Nov 17 18:46:33 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 18 Nov 2010 02:46:33 -0000 Subject: [Bro-Dev] #310: Higher time resolution? Message-ID: <044.7460fcc6db76bc50e1c99fbfe25e8c9b@tracker.icir.org> #310: Higher time resolution? -------------------+------------------- Reporter: robin | Type: defect Status: new | Priority: Normal Component: Bro | -------------------+------------------- Something to discuss: do we need timestamps with higher resolution (if the NIC provides them, like the DAGs for example). -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Nov 17 18:46:58 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 18 Nov 2010 02:46:58 -0000 Subject: [Bro-Dev] #310: Higher time resolution? In-Reply-To: <044.7460fcc6db76bc50e1c99fbfe25e8c9b@tracker.icir.org> References: <044.7460fcc6db76bc50e1c99fbfe25e8c9b@tracker.icir.org> Message-ID: <059.068e5de16f75996ae3703fb74b3586ca@tracker.icir.org> #310: Higher time resolution? ------------------------------+-------------------- Reporter: robin | Owner: Type: Feature Request | Status: new Priority: Normal | Milestone: Bro1.7 Component: Bro | Version: Resolution: | Keywords: ------------------------------+-------------------- Changes (by robin): * type: defect => Feature Request * milestone: => Bro1.7 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Nov 17 21:02:27 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 18 Nov 2010 05:02:27 -0000 Subject: [Bro-Dev] #311: DPD mistakenly thinking HTTP is IRC Message-ID: <043.90a5ac5e20d03e51c8bb9508f3c07153@tracker.icir.org> #311: DPD mistakenly thinking HTTP is IRC ---------------------+----------------- Reporter: vern | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Component: Bro | Version: Keywords: | ---------------------+----------------- When running on the attached trace using '''-f tcp detect- protocols{,-http} dpd http irc mt''' (no doubt some of that is unneeded), DPD decides it's seeing IRC due to the responder returning the string "Server" fairly late in the connection. Ideally DPD would have had a "this is definitely me" sort of response from HTTP, ruling out a later decision regarding IRC; at a minimum, HTTP shouldn't have given up on it, and Bro should have reported a hit for multiple protocols. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Nov 18 15:41:34 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 18 Nov 2010 23:41:34 -0000 Subject: [Bro-Dev] #312: I'm doing some testing as well ... Message-ID: <044.ed0001c4cdbc60dccd031918fe6410ec@tracker.icir.org> #312: I'm doing some testing as well ... -------------------+------------------- Reporter: robin | Type: defect Status: new | Priority: Normal Component: Bro | -------------------+------------------- #!rst FooBar Header ============= reStructuredText is **nice**. It has its own webpage_. A table: ===== ===== ====== Inputs Output ------------ ------ A B A or B ===== ===== ====== False False False True False True False True True True True True ===== ===== ====== RST TracLinks ------------- See also ticket `#42`:trac:. .. _webpage: http://docutils.sourceforge.net/rst.html -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Nov 18 15:42:56 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 18 Nov 2010 23:42:56 -0000 Subject: [Bro-Dev] #312: I'm doing some testing as well ... In-Reply-To: <044.ed0001c4cdbc60dccd031918fe6410ec@tracker.icir.org> References: <044.ed0001c4cdbc60dccd031918fe6410ec@tracker.icir.org> Message-ID: <059.85e7c953fd9baf2f4f164f401866a8ba@tracker.icir.org> #312: I'm doing some testing as well ... ---------------------+----------------- Reporter: robin | Owner: Type: defect | Status: new Priority: Normal | Milestone: Component: Bro | Version: Resolution: | Keywords: ---------------------+----------------- Old description: > #!rst > FooBar Header > ============= > reStructuredText is **nice**. It has its own webpage_. > > A table: > > ===== ===== ====== > Inputs Output > ------------ ------ > A B A or B > ===== ===== ====== > False False False > True False True > False True True > True True True > ===== ===== ====== > > RST TracLinks > ------------- > > See also ticket `#42`:trac:. > > .. _webpage: http://docutils.sourceforge.net/rst.html New description: {{{ #!rst FooBar Header ============= reStructuredText is **nice**. It has its own webpage_. A table: ===== ===== ====== Inputs Output ------------ ------ A B A or B ===== ===== ====== False False False True False True False True True True True True ===== ===== ====== RST TracLinks ------------- See also ticket `#42`:trac:. .. _webpage: http://docutils.sourceforge.net/rst.html }}} -- Comment (by robin): Cool. Rest works! -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Nov 18 15:43:26 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 18 Nov 2010 23:43:26 -0000 Subject: [Bro-Dev] #312: I'm doing some testing as well ... In-Reply-To: <044.ed0001c4cdbc60dccd031918fe6410ec@tracker.icir.org> References: <044.ed0001c4cdbc60dccd031918fe6410ec@tracker.icir.org> Message-ID: <059.8110c9e8db5d1d7f98087d3e8b854144@tracker.icir.org> #312: I'm doing some testing as well ... ----------------------+-------------------- Reporter: robin | Owner: Type: defect | Status: closed Priority: Normal | Milestone: Component: Bro | Version: Resolution: Invalid | Keywords: ----------------------+-------------------- Changes (by robin): * status: new => closed * resolution: => Invalid -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Nov 18 17:35:34 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 01:35:34 -0000 Subject: [Bro-Dev] #292: Cluttering of alarm.log with serialization messages In-Reply-To: <047.7dd189330e344b30c6d647cacb8d3cd8@tracker.icir.org> References: <047.7dd189330e344b30c6d647cacb8d3cd8@tracker.icir.org> Message-ID: <062.bb8817ea617a22bd622b43ca90ea547c@tracker.icir.org> #292: Cluttering of alarm.log with serialization messages -------------------------+-------------------- Reporter: vallenti | Owner: robin Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: 1.5.1 Resolution: | Keywords: -------------------------+-------------------- Comment (by robin): I suggest that as the quick fix we just remove this output altogether. It's not really useful for anybody I guess The real solution would be a more general framwork for logging non-traffic related stuff. Seth, is that actually something that could be integrated into the new logging framework? -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Nov 18 17:37:11 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 01:37:11 -0000 Subject: [Bro-Dev] #297: Remove trace rewriter In-Reply-To: <043.f4e0eb0a9924070cf852ace700beb6bf@tracker.icir.org> References: <043.f4e0eb0a9924070cf852ace700beb6bf@tracker.icir.org> Message-ID: <058.1ce3bb5765b9ee5c4ceedd71885ebd6d@tracker.icir.org> #297: Remove trace rewriter ---------------------+-------------------- Reporter: seth | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ---------------------+-------------------- Comment (by robin): We'll make sure the patch applies cleanly to the next release to recreate the current state, but we won't maintain the patch further. -- Ticket URL: Bro Tracker Bro Issue Tracker From robin at icir.org Thu Nov 18 17:41:02 2010 From: robin at icir.org (Robin Sommer) Date: Thu, 18 Nov 2010 17:41:02 -0800 Subject: [Bro-Dev] Milestone 1.6 tickets Message-ID: <20101119014102.GB80288@icir.org> I've gone through all the tickets currently assigned to 1.6 and they all make sense for the next release. Very helpful, Seth, thanks! Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From bro at tracker.icir.org Thu Nov 18 18:06:26 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 02:06:26 -0000 Subject: [Bro-Dev] #313: DPD: ProtocolConfirmation, ProtocolViolation revamp Message-ID: <045.9a5ac01c4fdb7d22ac13818c767e7024@tracker.icir.org> #313: DPD: ProtocolConfirmation, ProtocolViolation revamp -----------------------------+----------------- Reporter: gregor | Owner: Type: Feature Request | Status: new Priority: Normal | Milestone: Component: Bro | Version: Keywords: | -----------------------------+----------------- A while ago (2yrs) Robin and me discussed the ProtocolConfirmation() and ProtcolViolation semantics and found that they don't have crisp definitions and that they are used inconsistently. We came up with the following proposal, however, we never followed up. So, I'm proposing it again. Proposal can be found here: http://bro.icir.org/devel/projects/violation-confirmation.html (ask bro-dev at ... if you want access to the above website) -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Nov 18 18:07:39 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 02:07:39 -0000 Subject: [Bro-Dev] #311: DPD mistakenly thinking HTTP is IRC In-Reply-To: <043.90a5ac5e20d03e51c8bb9508f3c07153@tracker.icir.org> References: <043.90a5ac5e20d03e51c8bb9508f3c07153@tracker.icir.org> Message-ID: <058.a213b409d92b433e6eb98776d00ddee3@tracker.icir.org> #311: DPD mistakenly thinking HTTP is IRC ----------------------+----------------- Reporter: vern | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Component: Bro | Version: Resolution: | Keywords: ----------------------+----------------- Comment (by gregor): See also #313 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Nov 18 18:07:59 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 02:07:59 -0000 Subject: [Bro-Dev] #313: DPD: ProtocolConfirmation, ProtocolViolation revamp In-Reply-To: <045.9a5ac01c4fdb7d22ac13818c767e7024@tracker.icir.org> References: <045.9a5ac01c4fdb7d22ac13818c767e7024@tracker.icir.org> Message-ID: <060.0516f9d61baccf88d14ac93e5c27352d@tracker.icir.org> #313: DPD: ProtocolConfirmation, ProtocolViolation revamp ------------------------------+----------------- Reporter: gregor | Owner: Type: Feature Request | Status: new Priority: Normal | Milestone: Component: Bro | Version: Resolution: | Keywords: ------------------------------+----------------- Comment (by gregor): See also #311 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Nov 18 19:16:54 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 03:16:54 -0000 Subject: [Bro-Dev] #314: Bro integer type cleanup Message-ID: <045.a21699cff17448dda8803245b4098fc1@tracker.icir.org> #314: Bro integer type cleanup ---------------------+-------------------- Reporter: gregor | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | ---------------------+-------------------- {{{ #!rst In addition to enabling 64bit (`#72`:trac:) integers by defaults, we should also look into the following issues with integers: * Use ``inttypes.h`` for fixed width integer types instead of using self-made #ifdefs. (E.g., uint64_t, int32_t). inttypes.h is a C99 and POSIX standard. Check for possible roadblock when doing so * Make sure that everything that can potentially overflow (counters) is 64 bit wide (in addition to --enable-int64) I already found the following problems: + HTTP C++ analyzer: ``HTTP_Entity::body_length`` and ``HTTP_Message::body_length`` are defined as ``int`` and can overflow (and indeed did). Don't forget to change the getter method too. + I am quite sure, that there are more such problems around. * Use ``PRI*`` macros for ``Xprintf()`` formatting (also defined in ``inttypes.h``) * Which integer type to use? Bro defines a bro_int_t, which is set to 32 or 64 bit wide (according to --enable-int64). However, it is only sparsely used (most importantly for policy layer data types). Use bro_int_t consistently for event engine too or use custom integer types for event engine (i.e., ``int64_t``, ``uint64_t``)? Or leave as is. Setting this to as 1.6 milestone as it is related to `#72`:trac:, but could also be pushed to a later release. }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From seth at icir.org Thu Nov 18 19:28:21 2010 From: seth at icir.org (Seth Hall) Date: Thu, 18 Nov 2010 22:28:21 -0500 Subject: [Bro-Dev] Milestone 1.6 tickets In-Reply-To: <20101119014102.GB80288@icir.org> References: <20101119014102.GB80288@icir.org> Message-ID: <51113AE6-534F-49B1-8B64-38685B4B7838@icir.org> On Nov 18, 2010, at 8:41 PM, Robin Sommer wrote: > I've gone through all the tickets currently assigned to 1.6 and they > all make sense for the next release. Very helpful, Seth, thanks! I haven't finished going through all of the tickets yet either. There are a lot more tickets that need assigned to milestones or closed. :) .Seth From bro at tracker.icir.org Fri Nov 19 06:11:00 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 14:11:00 -0000 Subject: [Bro-Dev] #292: Cluttering of alarm.log with serialization messages In-Reply-To: <047.7dd189330e344b30c6d647cacb8d3cd8@tracker.icir.org> References: <047.7dd189330e344b30c6d647cacb8d3cd8@tracker.icir.org> Message-ID: <062.56e5eb43ad984e0b14a6201ddb292e5f@tracker.icir.org> #292: Cluttering of alarm.log with serialization messages -------------------------+-------------------- Reporter: vallenti | Owner: robin Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: 1.5.1 Resolution: | Keywords: -------------------------+-------------------- Comment (by seth): > The real solution would be a more general framwork for logging non- traffic > related stuff. Seth, is that actually something that could be integrated > into the new logging framework? I'll think about this some more. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 19 08:04:19 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 16:04:19 -0000 Subject: [Bro-Dev] #277: broctl install failed In-Reply-To: <072.a24d4ef9528d99012116b5ef1806c557@tracker.icir.org> References: <072.a24d4ef9528d99012116b5ef1806c557@tracker.icir.org> Message-ID: <087.0bdf3223c28cd43462aecac473074acf@tracker.icir.org> #277: broctl install failed ------------------------------------------------+-------------------- Reporter: Ar Kar Oo | Owner: robin Type: Problem | Status: closed Priority: Normal | Milestone: Component: BroControl | Version: 1.5.1 Resolution: Feedback Missing | Keywords: ------------------------------------------------+-------------------- Changes (by seth): * status: new => closed * resolution: => Feedback Missing Comment: This ticket doesn't have enough information to even make an assessment. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 19 08:06:58 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 16:06:58 -0000 Subject: [Bro-Dev] #229: make test should be skipped if ../testing is not present In-Reply-To: <045.8c9e93809c86fcd45e1ff50c1fa4ff69@tracker.icir.org> References: <045.8c9e93809c86fcd45e1ff50c1fa4ff69@tracker.icir.org> Message-ID: <060.948f60a3b74f61873f2edf91385ee9d3@tracker.icir.org> #229: make test should be skipped if ../testing is not present -----------------------+-------------------- Reporter: justin | Owner: Type: Problem | Status: closed Priority: Low | Milestone: Component: Bro | Version: 1.5.1 Resolution: Rejected | Keywords: test -----------------------+-------------------- Changes (by seth): * status: new => closed * resolution: => Rejected Comment: We're migrating to CMake and packages for Debian won't be reattempted until the next release so I'm going to close this ticket. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 19 08:10:03 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 16:10:03 -0000 Subject: [Bro-Dev] #163: Bro/Broccoli problem with class. In-Reply-To: <043.0c2302248e867329f8914c3cea6272b8@tracker.icir.org> References: <043.0c2302248e867329f8914c3cea6272b8@tracker.icir.org> Message-ID: <058.22e18fc4d710084e9c97d1bb73840a5d@tracker.icir.org> #163: Bro/Broccoli problem with class. -------------------------------+-------------------- Reporter: seth | Owner: Type: Problem | Status: closed Priority: Normal | Milestone: Component: Bro | Version: 1.5.2 Resolution: Feedback Missing | Keywords: -------------------------------+-------------------- Changes (by seth): * status: seen => closed * resolution: => Feedback Missing Comment: Unable to confirm this currently. I'm closing it. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 19 08:11:29 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 16:11:29 -0000 Subject: [Bro-Dev] #54: Undefined value as a SCALAR reference in /site-report.pl In-Reply-To: <044.0eafe23e75e091df152facda70d4eb4e@tracker.icir.org> References: <044.0eafe23e75e091df152facda70d4eb4e@tracker.icir.org> Message-ID: <059.6cb7cb8b712b5c3a769c00d3dd5e9e74@tracker.icir.org> #54: Undefined value as a SCALAR reference in /site-report.pl ----------------------+------------------ Reporter: robin | Owner: Type: Problem | Status: seen Priority: Normal | Milestone: Component: Bro | Version: 1.4 Resolution: | Keywords: ----------------------+------------------ Comment (by seth): (Mostly directed at Robin) Are we going to be shipping the site-report.pl script with the next release? I don't even know what it does. -- Ticket URL: Bro Tracker Bro Issue Tracker From robin at icir.org Fri Nov 19 08:27:06 2010 From: robin at icir.org (Robin Sommer) Date: Fri, 19 Nov 2010 08:27:06 -0800 Subject: [Bro-Dev] #54: Undefined value as a SCALAR reference in /site-report.pl In-Reply-To: <059.6cb7cb8b712b5c3a769c00d3dd5e9e74@tracker.icir.org> References: <044.0eafe23e75e091df152facda70d4eb4e@tracker.icir.org> <059.6cb7cb8b712b5c3a769c00d3dd5e9e74@tracker.icir.org> Message-ID: <20101119162706.GD9969@icir.org> On Fri, Nov 19, 2010 at 16:11 -0000, you wrote: > (Mostly directed at Robin) Are we going to be shipping the site-report.pl > script with the next release? I don't even know what it does. It's part of Bro Lite. No, that's going to be removed. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From bro at tracker.icir.org Fri Nov 19 09:34:41 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 17:34:41 -0000 Subject: [Bro-Dev] #54: Undefined value as a SCALAR reference in /site-report.pl In-Reply-To: <044.0eafe23e75e091df152facda70d4eb4e@tracker.icir.org> References: <044.0eafe23e75e091df152facda70d4eb4e@tracker.icir.org> Message-ID: <059.752eff274770a1aa454b574b1c67c9bf@tracker.icir.org> #54: Undefined value as a SCALAR reference in /site-report.pl ----------------------+------------------ Reporter: robin | Owner: Type: Problem | Status: seen Priority: Normal | Milestone: Component: Bro | Version: 1.4 Resolution: | Keywords: ----------------------+------------------ Comment (by robin): On Fri, Nov 19, 2010 at 16:11 -0000, you wrote: > (Mostly directed at Robin) Are we going to be shipping the site- report.pl > script with the next release? I don't even know what it does. It's part of Bro Lite. No, that's going to be removed. Robin -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 19 09:42:02 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 17:42:02 -0000 Subject: [Bro-Dev] #54: Undefined value as a SCALAR reference in /site-report.pl In-Reply-To: <044.0eafe23e75e091df152facda70d4eb4e@tracker.icir.org> References: <044.0eafe23e75e091df152facda70d4eb4e@tracker.icir.org> Message-ID: <059.c0f6e293a6f734be03596141094e34d6@tracker.icir.org> #54: Undefined value as a SCALAR reference in /site-report.pl ----------------------+------------------ Reporter: robin | Owner: Type: Problem | Status: seen Priority: Normal | Milestone: Component: Bro | Version: 1.4 Resolution: | Keywords: ----------------------+------------------ Comment (by seth): > It's part of Bro Lite. No, that's going to be removed. Are we even going to bother fixing problems like this in another final point release of 1.5? Just wondering if I should close the ticket or not. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 19 09:45:44 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 17:45:44 -0000 Subject: [Bro-Dev] #54: Undefined value as a SCALAR reference in /site-report.pl In-Reply-To: <044.0eafe23e75e091df152facda70d4eb4e@tracker.icir.org> References: <044.0eafe23e75e091df152facda70d4eb4e@tracker.icir.org> Message-ID: <059.0c7e3aecc3c10c58808b2d715628b1d3@tracker.icir.org> #54: Undefined value as a SCALAR reference in /site-report.pl ----------------------+------------------ Reporter: robin | Owner: Type: Problem | Status: seen Priority: Normal | Milestone: Component: Bro | Version: 1.4 Resolution: | Keywords: ----------------------+------------------ Comment (by robin): On Fri, Nov 19, 2010 at 17:42 -0000, you wrote: > Are we even going to bother fixing problems like this in another final > point release of 1.5? Just wondering if I should close the ticket or not. Just close it. I'm wondering whether we should indeed do another 1.5.x, but even if so, I don't want to spend time on fixing things we'll be throwing out anyway. If we do 1.5, then it will be pretty much what's in SVN now, perhaps with a few more patches back-ported from git depending on when we do it. Robin PS: I'm sure I could close this ticket somehow already with this mail into the tracker? -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 19 10:48:05 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 18:48:05 -0000 Subject: [Bro-Dev] #54: Undefined value as a SCALAR reference in /site-report.pl In-Reply-To: <044.0eafe23e75e091df152facda70d4eb4e@tracker.icir.org> References: <044.0eafe23e75e091df152facda70d4eb4e@tracker.icir.org> Message-ID: <059.fcea3f666906b35f7b65275336abee3c@tracker.icir.org> #54: Undefined value as a SCALAR reference in /site-report.pl ----------------------+------------------ Reporter: robin | Owner: Type: Problem | Status: seen Priority: Normal | Milestone: Component: Bro | Version: 1.4 Resolution: | Keywords: ----------------------+------------------ Comment (by gregor): The openssl-fix might be nice to have released soonish as Bro doesn't compile with openssl>=1.0 right now... cu gregor -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 19 13:21:43 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 21:21:43 -0000 Subject: [Bro-Dev] #64: DNS lookup routines may return either string or addr In-Reply-To: <042.186833ee72fe92a4fd6c0065470ea748@tracker.icir.org> References: <042.186833ee72fe92a4fd6c0065470ea748@tracker.icir.org> Message-ID: <057.e6a46e9a691cc391aeaa17cbbd892b3a@tracker.icir.org> #64: DNS lookup routines may return either string or addr ----------------------+---------------------- Reporter: mej | Owner: robin Type: Problem | Status: accepted Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.4 Resolution: | Keywords: ----------------------+---------------------- Changes (by seth): * milestone: => Bro1.6 Comment: Has this patch been integrated? I thought it was but perhaps not. I'll go ahead and set it as a milestone for the 1.6 release for now. -- Ticket URL: Bro Tracker Bro Issue Tracker From seth at icir.org Fri Nov 19 13:24:07 2010 From: seth at icir.org (Seth Hall) Date: Fri, 19 Nov 2010 16:24:07 -0500 Subject: [Bro-Dev] broccoli.conf Message-ID: Jon, something to keep in mind for the CMake change over... http://tracker.icir.org/bro/ticket/84 I'm closing the ticket now. .Seth From bro at tracker.icir.org Fri Nov 19 13:24:54 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 21:24:54 -0000 Subject: [Bro-Dev] #84: Don't clobber existing broccoli.conf on install In-Reply-To: <044.e2fcf78b44dabc95911f04189b08b069@tracker.icir.org> References: <044.e2fcf78b44dabc95911f04189b08b069@tracker.icir.org> Message-ID: <059.9bf486ae41bd008a30b40f5107349631@tracker.icir.org> #84: Don't clobber existing broccoli.conf on install -----------------------+---------------------- Reporter: leres | Owner: kreibich Type: Problem | Status: closed Priority: Normal | Milestone: Component: Broccoli | Version: 1.4 Resolution: Solved | Keywords: -----------------------+---------------------- Changes (by seth): * status: seen => closed * resolution: => Solved Comment: We're moving to CMake so this change has been deprecated. -- Ticket URL: Bro Tracker Bro Issue Tracker From seth at icir.org Fri Nov 19 13:28:05 2010 From: seth at icir.org (Seth Hall) Date: Fri, 19 Nov 2010 16:28:05 -0500 Subject: [Bro-Dev] #54: Undefined value as a SCALAR reference in /site-report.pl In-Reply-To: <059.fcea3f666906b35f7b65275336abee3c@tracker.icir.org> References: <044.0eafe23e75e091df152facda70d4eb4e@tracker.icir.org> <059.fcea3f666906b35f7b65275336abee3c@tracker.icir.org> Message-ID: On Nov 19, 2010, at 1:48 PM, Bro Tracker wrote: > The openssl-fix might be nice to have released soonish as Bro doesn't > compile with openssl>=1.0 right now... With the bro at tracker email address now functioning you will want to start being careful replying to tickets without modifying the recipient list. You comment is in the tracker attached to the site-report.pl ticket. ;) http://tracker.icir.org/bro/ticket/54#comment:8 .Seth From bro at tracker.icir.org Fri Nov 19 13:29:04 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 21:29:04 -0000 Subject: [Bro-Dev] #54: Undefined value as a SCALAR reference in /site-report.pl In-Reply-To: <044.0eafe23e75e091df152facda70d4eb4e@tracker.icir.org> References: <044.0eafe23e75e091df152facda70d4eb4e@tracker.icir.org> Message-ID: <059.dd3b100a27454ba03d6e70c1d8bbee12@tracker.icir.org> #54: Undefined value as a SCALAR reference in /site-report.pl -----------------------+-------------------- Reporter: robin | Owner: Type: Problem | Status: closed Priority: Normal | Milestone: Component: Bro | Version: 1.4 Resolution: Rejected | Keywords: -----------------------+-------------------- Changes (by seth): * status: seen => closed * resolution: => Rejected Comment: Site-report.pl is part of brolite which is deprecated. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 19 13:31:19 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 21:31:19 -0000 Subject: [Bro-Dev] #80: Checking for the existance keys in multi-dimensional tables gives error message In-Reply-To: <047.6bd4d488fbb7e8257db796fd9c1a6386@tracker.icir.org> References: <047.6bd4d488fbb7e8257db796fd9c1a6386@tracker.icir.org> Message-ID: <062.158c0c1518680cc9945c733e9d2348a5@tracker.icir.org> #80: Checking for the existance keys in multi-dimensional tables gives error message -----------------------+------------------ Reporter: bernhard | Owner: Type: Problem | Status: seen Priority: Normal | Milestone: Component: Bro | Version: 1.4 Resolution: | Keywords: -----------------------+------------------ Comment (by seth): This is a known weakness with Bro's parser (Vern documented it somewhere I think). Does anyone know how hard it would be to implement this? Reasonable for 1.6? Personally I would really like to see it fixed as I've encountered the need to do this several times. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 19 14:48:12 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 19 Nov 2010 22:48:12 -0000 Subject: [Bro-Dev] #80: Checking for the existance keys in multi-dimensional tables gives error message In-Reply-To: <047.6bd4d488fbb7e8257db796fd9c1a6386@tracker.icir.org> References: <047.6bd4d488fbb7e8257db796fd9c1a6386@tracker.icir.org> Message-ID: <062.5e738108e3297d549ba3c66714461921@tracker.icir.org> #80: Checking for the existance keys in multi-dimensional tables gives error message -----------------------+------------------ Reporter: bernhard | Owner: Type: Problem | Status: seen Priority: Normal | Milestone: Component: Bro | Version: 1.4 Resolution: | Keywords: -----------------------+------------------ Comment (by robin): My guess is that should be fixable without too much effort by inspecting the expressing more closely. The trick is decide when it's a list and when a record ctor. 1.6 sounds reasonable. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 19 17:27:10 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Sat, 20 Nov 2010 01:27:10 -0000 Subject: [Bro-Dev] #80: Checking for the existance keys in multi-dimensional tables gives error message In-Reply-To: <047.6bd4d488fbb7e8257db796fd9c1a6386@tracker.icir.org> References: <047.6bd4d488fbb7e8257db796fd9c1a6386@tracker.icir.org> Message-ID: <062.e5b94141e0b2bc4d9dd11eb103165003@tracker.icir.org> #80: Checking for the existance keys in multi-dimensional tables gives error message -----------------------+-------------------- Reporter: bernhard | Owner: Type: Problem | Status: seen Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.4 Resolution: | Keywords: -----------------------+-------------------- Changes (by seth): * milestone: => Bro1.6 Comment: Setting the milestone. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Sat Nov 20 15:24:02 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Sat, 20 Nov 2010 23:24:02 -0000 Subject: [Bro-Dev] #247: Bro trunk build fails with OpenSSL stack error In-Reply-To: <047.50baac97db1997fb95f119eebf1fbebf@tracker.icir.org> References: <047.50baac97db1997fb95f119eebf1fbebf@tracker.icir.org> Message-ID: <062.357f33a939b356fcb7e1f128915a57f7@tracker.icir.org> #247: Bro trunk build fails with OpenSSL stack error -----------------------+---------------------- Reporter: kreibich | Owner: kreibich Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: -----------------------+---------------------- Comment (by vallenti): Replying to [comment:8 seth]: > This patch seems to work for me too. It works fine for me as well. > Is this something appropriate for fastpath integration in git? I would say so because it is a relatively small and self-contained patch the should be quickly available upstream. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Sat Nov 20 15:43:18 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Sat, 20 Nov 2010 23:43:18 -0000 Subject: [Bro-Dev] #247: Bro trunk build fails with OpenSSL stack error In-Reply-To: <047.50baac97db1997fb95f119eebf1fbebf@tracker.icir.org> References: <047.50baac97db1997fb95f119eebf1fbebf@tracker.icir.org> Message-ID: <062.870108fc4a722209757b12cb34a60f34@tracker.icir.org> #247: Bro trunk build fails with OpenSSL stack error -----------------------+---------------------- Reporter: kreibich | Owner: vern Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: -----------------------+---------------------- Changes (by seth): * owner: kreibich => vern Comment: Assigning to Vern to get the patch into svn. -- Ticket URL: Bro Tracker Bro Issue Tracker From robin at icir.org Sun Nov 21 20:22:27 2010 From: robin at icir.org (Robin Sommer) Date: Sun, 21 Nov 2010 20:22:27 -0800 Subject: [Bro-Dev] 1.5.1? (Re: #247: Bro trunk build fails with OpenSSL stack error) In-Reply-To: <062.870108fc4a722209757b12cb34a60f34@tracker.icir.org> References: <047.50baac97db1997fb95f119eebf1fbebf@tracker.icir.org> <062.870108fc4a722209757b12cb34a60f34@tracker.icir.org> Message-ID: <20101122042227.GB8052@icir.org> On Sat, Nov 20, 2010 at 23:43 -0000, you wrote: > #247: Bro trunk build fails with OpenSSL stack error > Assigning to Vern to get the patch into svn. Just noticed that the "patches for next release" query on the tracker home page doesn't work anymore, though I'm not sure right now why. But that probably means that Vern won't find it ... Should we do a 1.5.1 release sometime soon to get the final changes in SVN pushed out? Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From bro at tracker.icir.org Mon Nov 22 11:48:06 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 22 Nov 2010 19:48:06 -0000 Subject: [Bro-Dev] #315: TCP Reassemblier type inconsistency Message-ID: <045.eb2831cf26d415f4258ea6bd44ffe69f@tracker.icir.org> #315: TCP Reassemblier type inconsistency ----------------------+------------------------ Reporter: gregor | Owner: Type: Problem | Status: new Priority: Low | Milestone: Component: Bro | Version: git/master Keywords: inttypes | ----------------------+------------------------ {{{ #!rst The TCP Reassembler (and the general Reassembler which is the base class) have a type inconsitency: internally they define the sequence numbers as ``int``. When they have to compare seq numbers, they call ``seq_delta()`` which takes two ``uint32``. The reassemblers should also use ``uint32_t`` internally. }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 22 11:48:42 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 22 Nov 2010 19:48:42 -0000 Subject: [Bro-Dev] #72: Use 64Bit integers in Bro by default In-Reply-To: <045.e3497c69dfe36a4cddde29c01881d602@tracker.icir.org> References: <045.e3497c69dfe36a4cddde29c01881d602@tracker.icir.org> Message-ID: <060.b5f6f1d07bf856bc2aaa8515680bf68d@tracker.icir.org> #72: Use 64Bit integers in Bro by default ---------------------+-------------------------------------------- Reporter: gregor | Owner: Type: Task | Status: seen Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: integer size, 64 bit, inttypes ---------------------+-------------------------------------------- Changes (by gregor): * keywords: integer size, 64 bit => integer size, 64 bit, inttypes -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 22 12:03:36 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 22 Nov 2010 20:03:36 -0000 Subject: [Bro-Dev] #316: Bro integer type cleanup meta ticket Message-ID: <045.9e22375634fe45f0cbaef9e349273ece@tracker.icir.org> #316: Bro integer type cleanup meta ticket ----------------------+-------------------- Reporter: gregor | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: inttypes | ----------------------+-------------------- {{{ #!rst This is a meta-ticket for the integer type cleanup. I.e., All thickets related to this should have the keyword ``inttypes``! These tickets can be found through Report `{13}`:trac: * Changing to 64 bit integeres by default were it makes sense. * Find places that might overflow and change to wider types * Use standard integer types (``inttypes.h``) * Find and change type inconsitencies * ... Setting milestone to Bro 1.6 but can also be pushed to 1.7 for some of the issues. }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 22 13:12:00 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 22 Nov 2010 21:12:00 -0000 Subject: [Bro-Dev] #317: Analyzer::Undelivered should use relative sequence numbers (and go to 64bit) Message-ID: <045.958e8ad1a89ce34c09add70439e6e92a@tracker.icir.org> #317: Analyzer::Undelivered should use relative sequence numbers (and go to 64bit) ----------------------+------------------------ Reporter: gregor | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Keywords: inttypes | ----------------------+------------------------ {{{ #!rst ``Analyzer::Undelivered(int seq, int len)`` is called with absolute TCP sequence from the TCP reassambler. However, since the analyzer framework should work on abstract byte streams, it should return *realtive* sequence numbers. In addition, it should use 64 bit integers! Note, that Undelivered is not really used. The HTTP.cc analyzer uses it, but ``seq`` is to generate a mime_content_gap event. It does seem that HTTP.cc assumes the seq number is relative.... }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 22 13:51:30 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 22 Nov 2010 21:51:30 -0000 Subject: [Bro-Dev] #318: Use inttypes.h instead of home-made ifdefs Message-ID: <045.88735bcfdba109ea208b3a5820e31694@tracker.icir.org> #318: Use inttypes.h instead of home-made ifdefs ----------------------+------------------------ Reporter: gregor | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Keywords: inttypes | ----------------------+------------------------ * Use inttypes.h for fixed width integer types instead of using self-made #ifdefs. (E.g., uint64_t, int32_t). Cf. util.[ch] * Replace old ``uint32`` et al. with standard ``uint32_t`` et al. inttypes.h is a C99 and POSIX standard. Check for possible roadblock when doing so -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 22 13:52:16 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 22 Nov 2010 21:52:16 -0000 Subject: [Bro-Dev] #315: TCP Reassemblier type inconsistency In-Reply-To: <045.eb2831cf26d415f4258ea6bd44ffe69f@tracker.icir.org> References: <045.eb2831cf26d415f4258ea6bd44ffe69f@tracker.icir.org> Message-ID: <060.3a923a2503ac737f5928726578923c2b@tracker.icir.org> #315: TCP Reassemblier type inconsistency ----------------------+------------------------ Reporter: gregor | Owner: Type: Problem | Status: new Priority: Low | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: | Keywords: inttypes ----------------------+------------------------ Changes (by gregor): * milestone: => Bro1.6 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 22 13:52:59 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 22 Nov 2010 21:52:59 -0000 Subject: [Bro-Dev] #316: Bro integer type cleanup meta ticket In-Reply-To: <045.9e22375634fe45f0cbaef9e349273ece@tracker.icir.org> References: <045.9e22375634fe45f0cbaef9e349273ece@tracker.icir.org> Message-ID: <060.d644a146bd44d8d4305fa6b409ad1ab0@tracker.icir.org> #316: Bro integer type cleanup meta ticket ---------------------+---------------------- Reporter: gregor | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.7 Component: Bro | Version: Resolution: | Keywords: inttypes ---------------------+---------------------- Changes (by gregor): * milestone: Bro1.6 => Bro1.7 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 22 14:05:36 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 22 Nov 2010 22:05:36 -0000 Subject: [Bro-Dev] #319: Changes Xprintf() formats to use PRIxyz, e.g., PRIu64, PRIx32 Message-ID: <045.48d6fe6e9203210c71977a92e0b469cc@tracker.icir.org> #319: Changes Xprintf() formats to use PRIxyz, e.g., PRIu64, PRIx32 ----------------------+-------------------- Reporter: gregor | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: inttypes | ----------------------+-------------------- {{{ #!rst Change all *X*\ printf(), fmt(), etc. format strings to use ``PRIxyz`` macros to specify how to print fixed-width integer types like uint64_t. These are defined in ``stdint.h`` C.f. http://www.opengroup.org/onlinepubs/000095399/basedefs/inttypes.h.html They are a C99 and POSIX standard and using them should get rid of a lot of warnings related to format specifiers. }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 22 14:10:34 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 22 Nov 2010 22:10:34 -0000 Subject: [Bro-Dev] #320: Check for counters, length fields, etc. that can overflow and change to 64 bit Message-ID: <045.d39fed6bb68e716c96a3eecfc7624047@tracker.icir.org> #320: Check for counters, length fields, etc. that can overflow and change to 64 bit ----------------------+------------------------ Reporter: gregor | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.7 Component: Bro | Version: git/master Keywords: inttypes | ----------------------+------------------------ {{{ #!rst * Check the source code and analyzers for cases in which 32 bit integers are used for length fields and counters that can potentially overflow. * Find cases in which ``int`` or ``unsigned`` (without length specifiers) are used, in particular for counters for length fields, tha could overflow, and change them to integer types with widths (e.g., int32_t, uint64_t). }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 22 14:11:53 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 22 Nov 2010 22:11:53 -0000 Subject: [Bro-Dev] #314: Bro integer type cleanup In-Reply-To: <045.a21699cff17448dda8803245b4098fc1@tracker.icir.org> References: <045.a21699cff17448dda8803245b4098fc1@tracker.icir.org> Message-ID: <060.54fbdea9eac417bbd00f5f82777a0938@tracker.icir.org> #314: Bro integer type cleanup ------------------------+-------------------- Reporter: gregor | Owner: Type: Problem | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: Duplicate | Keywords: ------------------------+-------------------- Changes (by gregor): * status: new => closed * resolution: => Duplicate Comment: After chatting with Robin create meta-ticket (#316) and single tickets for individual tasks. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 22 14:12:27 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 22 Nov 2010 22:12:27 -0000 Subject: [Bro-Dev] #319: Changes Xprintf() formats to use PRIxyz, e.g., PRIu64, PRIx32 In-Reply-To: <045.48d6fe6e9203210c71977a92e0b469cc@tracker.icir.org> References: <045.48d6fe6e9203210c71977a92e0b469cc@tracker.icir.org> Message-ID: <060.f8c70e93a9e1f3e5facff7da428f55fe@tracker.icir.org> #319: Changes Xprintf() formats to use PRIxyz, e.g., PRIu64, PRIx32 ---------------------+---------------------- Reporter: gregor | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: inttypes ---------------------+---------------------- Changes (by gregor): * type: Problem => Task -- Ticket URL: Bro Tracker Bro Issue Tracker From gregor at icir.org Mon Nov 22 14:26:28 2010 From: gregor at icir.org (Gregor Maier) Date: Mon, 22 Nov 2010 14:26:28 -0800 Subject: [Bro-Dev] Bro svn commit error message Message-ID: <4CEAEE14.9050403@icir.org> Hi, When I tried to commit something in my bro-svn branch, I got the following error message. Presumably that's due to the tracker having switched over to git. ----8<------------------------------------ gregor at ashcloud:~/projects/bro-work/src$ svn ci Sending src/ContentLine.cc Sending src/ContentLine.h Sending src/HTTP.cc Sending src/HTTP.h Sending src/util.cc Sending src/util.h Transmitting file data ...... Committed revision 7124. Warning: post-commit hook failed (exit code 1) with output: Traceback (most recent call last): File "/da/trac/bin/trac-post-commit-hook", line 209, in CommitHook() File "/da/trac/bin/trac-post-commit-hook", line 145, in __init__ repos.sync() AttributeError: 'NoneType' object has no attribute 'sync' ------->8------------------ cu Gregor -- Gregor Maier gregor at icir.org Int. Computer Science Institute (ICSI) gregor at icsi.berkeley.edu 1947 Center St., Ste. 600 http://www.icir.org/gregor/ Berkeley, CA 94704 USA From robin at icir.org Mon Nov 22 18:24:39 2010 From: robin at icir.org (Robin Sommer) Date: Mon, 22 Nov 2010 18:24:39 -0800 Subject: [Bro-Dev] Thoughts on documenting scripts Message-ID: <20101123022439.GA63257@icir.org> I've added a page on how we might use Sphinx to auto-generate Bro script documentation to the projects list, see http://bro.icir.org/devel/projects/autodoc.html This includes a mock-up of how Sphinx input and output could look like. What do you guys think? Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From seth at icir.org Mon Nov 22 19:47:41 2010 From: seth at icir.org (Seth Hall) Date: Mon, 22 Nov 2010 22:47:41 -0500 Subject: [Bro-Dev] Bro svn commit error message In-Reply-To: <4CEAEE14.9050403@icir.org> References: <4CEAEE14.9050403@icir.org> Message-ID: <0840A1FC-F72D-46AF-A7D1-7E0BCF6C8619@icir.org> On Nov 22, 2010, at 5:26 PM, Gregor Maier wrote: > When I tried to commit something in my bro-svn branch, I got the > following error message. Presumably that's due to the tracker having > switched over to git. Oops, Matti told me about this last week and it slipped away from me. It was actually due to the upgrade to Trac. They changed their script that integrates with svn and I didn't realize it. It should work now. Thanks. .Seth From vallentin at icir.org Mon Nov 22 19:59:18 2010 From: vallentin at icir.org (Matthias Vallentin) Date: Mon, 22 Nov 2010 19:59:18 -0800 Subject: [Bro-Dev] Thoughts on documenting scripts In-Reply-To: <20101123022439.GA63257@icir.org> References: <20101123022439.GA63257@icir.org> Message-ID: <20101123035918.GA877@icsi.berkeley.edu> > What do you guys think? Very nice, I like the overall setup, it looks like a smooth way to automate the documentation generation process for Bro scripts! A few comments: - How do you define a Public Interface? It seems to me that the sections before are also customizable by the user and thus constitute part of the "public" part of the script. - The role of DPD is not entirely clear from the HTML in the sections Packet Filter and Port Analysis. It reads as if FTP is only invoked for 21/tcp. How is that supposed to be read? - I am not sure if this would happen already, but it would be great if external types, such as the connection record, would also be links in the HTML generated by Sphinx. - I feels a bit too much to repeat the word Param in front of every event parameter. What about writing 'Parameters' once and then listing all parameters in bullet-point style (or just as is, in bold and then the description). - Have you considered only using the namespace prefix (FTP::) for handlers that are not part of the module and omitting it for functions and events that are inside the module? - In addition to the included children, it would also be nice to create a list of parents, i.e., the scripts that include the script whose documentation is currently being read. Matthias From seth at icir.org Tue Nov 23 05:08:38 2010 From: seth at icir.org (Seth Hall) Date: Tue, 23 Nov 2010 08:08:38 -0500 Subject: [Bro-Dev] Bro for Fedora? Message-ID: <3E643F26-15D0-4AFF-B36D-823732F7AB8A@icir.org> Has someone packaged Bro with Fedora? I'm downloading it now to find out. .Seth From seth at icir.org Tue Nov 23 05:10:52 2010 From: seth at icir.org (Seth Hall) Date: Tue, 23 Nov 2010 08:10:52 -0500 Subject: [Bro-Dev] Bro for Fedora? In-Reply-To: <3E643F26-15D0-4AFF-B36D-823732F7AB8A@icir.org> References: <3E643F26-15D0-4AFF-B36D-823732F7AB8A@icir.org> Message-ID: On Nov 23, 2010, at 8:08 AM, Seth Hall wrote: > Has someone packaged Bro with Fedora? I'm downloading it now to find out. https://bugzilla.redhat.com/show_bug.cgi?id=655704 .Seth From robin at icir.org Tue Nov 23 09:44:49 2010 From: robin at icir.org (Robin Sommer) Date: Tue, 23 Nov 2010 09:44:49 -0800 Subject: [Bro-Dev] Thoughts on documenting scripts In-Reply-To: <20101123035918.GA877@icsi.berkeley.edu> References: <20101123022439.GA63257@icir.org> <20101123035918.GA877@icsi.berkeley.edu> Message-ID: <20101123174449.GC87280@icir.org> On Mon, Nov 22, 2010 at 19:59 -0800, you wrote: > - How do you define a Public Interface? I'm thinking whatever the "export section" provides. The earlier sections are things the script configures, but they are part of *another* script's interface. > - The role of DPD is not entirely clear from the HTML in the sections > Packet Filter and Port Analysis. It reads as if FTP is only invoked > for 21/tcp. How is that supposed to be read? This is not for DPD, but for the port-based detection. The interpretation is: everything on port 21 will always be analyzed as FTP (while all other ports need a matching DPD pattern first). But there are probably nicer ways of phrasing this in the generated documentation that in my example. > - I am not sure if this would happen already, but it would be great if > external types, such as the connection record, would also be links in > the HTML generated by Sphinx. Yes, that's the plan. Everything would be extensively cross-linked, and in this case the link would go to bro.init's apge (which is a special case however, which we'll probably need to handle separately in some form). > - I feels a bit too much to repeat the word Param in front of every > event parameter. I totally agree. I had earlier suggested to do this implicitly, e.g., instead of ":param id: bla bla", write just "id: bla bla" and do some smart pattern matching to recognize that it's actually a parameter description. I'm still in favor of doing that but didn't want to load too many details onto the proposal. > What about writing 'Parameters' once and then listing all parameters > in bullet-point style (or just as is, in bold and then the > description). ... and that would be another good option of doing it. > - Have you considered only using the namespace prefix (FTP::) for > handlers that are not part of the module and omitting it for functions > and events that are inside the module? Yeah, I was unsure what's the best way for giving the namespaces. This could be indeed a good compromise. > - In addition to the included children, it would also be nice to create > a list of parents, i.e., the scripts that include the script whose > documentation is currently being read. I like that. However, Sphinx doesn't provide that directly so we'd need to assemble that information somehow (should be possible) Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From slagell at ncsa.illinois.edu Tue Nov 23 09:49:16 2010 From: slagell at ncsa.illinois.edu (Adam J. Slagell) Date: Tue, 23 Nov 2010 11:49:16 -0600 Subject: [Bro-Dev] Thoughts on documenting scripts In-Reply-To: <20101123035918.GA877@icsi.berkeley.edu> References: <20101123022439.GA63257@icir.org> <20101123035918.GA877@icsi.berkeley.edu> Message-ID: On Nov 22, 2010, at 9:59 PM, Matthias Vallentin wrote: >> What do you guys think? > > Very nice, I like the overall setup, it looks like a smooth way to > automate the documentation generation process for Bro scripts! A few > comments: BTW, how does this all fit with the one language to rule them all goal, i.e. ReST? Or is rest just for the web site, manual and Bro book? ------ Adam J. Slagell, CISSP Sr. Security Engineer National Center for Supercomputing Applications University of Illinois at Urbana-Champaign www.slagell.info 217.244.8965 From gregor at icir.org Tue Nov 23 10:00:45 2010 From: gregor at icir.org (Gregor Maier) Date: Tue, 23 Nov 2010 10:00:45 -0800 Subject: [Bro-Dev] Thoughts on documenting scripts In-Reply-To: References: <20101123022439.GA63257@icir.org> <20101123035918.GA877@icsi.berkeley.edu> Message-ID: <4CEC014D.1060800@icir.org> >> Very nice, I like the overall setup, it looks like a smooth way to >> automate the documentation generation process for Bro scripts! A few >> comments: > > BTW, how does this all fit with the one language to rule them all goal, i.e. ReST? Or is rest just for the web site, manual and Bro book? Sphinx is based on ReST. It defines additional rest directive to make writing code documentation easier. But the markup in the docstrings is ReST. cu gregor -- Gregor Maier gregor at icir.org Int. Computer Science Institute (ICSI) gregor at icsi.berkeley.edu 1947 Center St., Ste. 600 http://www.icir.org/gregor/ Berkeley, CA 94704 USA From gregor at icir.org Tue Nov 23 10:05:52 2010 From: gregor at icir.org (Gregor Maier) Date: Tue, 23 Nov 2010 10:05:52 -0800 Subject: [Bro-Dev] Thoughts on documenting scripts In-Reply-To: <20101123174449.GC87280@icir.org> References: <20101123022439.GA63257@icir.org> <20101123035918.GA877@icsi.berkeley.edu> <20101123174449.GC87280@icir.org> Message-ID: <4CEC0280.8060903@icir.org> >> - I feels a bit too much to repeat the word Param in front of every >> event parameter. > > I totally agree. > [cut] The 'param' in fron of every parameter also looks strange in the HTML output. But I also see, that having to put it in front of every parameter might be cumbersome, so I also like Robins idea here (note, that I was the one who said, we should put a directive in front of every parameter, but now I think that either way is fine). It might also be nice to repeat the parameters type in the HTML output. This way I can look at just one place and don't have to look back at the event/function definition to find the type. But YMMV. >> What about writing 'Parameters' once and then listing all parameters >> in bullet-point style (or just as is, in bold and then the >> description). > > ... and that would be another good option of doing it. I think that would be the way to go for HTML output cu Gregor -- Gregor Maier gregor at icir.org Int. Computer Science Institute (ICSI) gregor at icsi.berkeley.edu 1947 Center St., Ste. 600 http://www.icir.org/gregor/ Berkeley, CA 94704 USA From gregor at icir.org Tue Nov 23 10:21:15 2010 From: gregor at icir.org (Gregor Maier) Date: Tue, 23 Nov 2010 10:21:15 -0800 Subject: [Bro-Dev] Thoughts on documenting scripts In-Reply-To: <20101123022439.GA63257@icir.org> References: <20101123022439.GA63257@icir.org> Message-ID: <4CEC061B.1060705@icir.org> Hi, I've been thinking about documenting the public interface VS. documenting everything. It might be helpful to have a cross referenced documentation of everything if somebody wants to dig deeper. How this the following sound to you: * Per default only extract documentation for the public interface (i.e., the export section plus some globals) * However, also document the internal workings (which IMHO is good style anyway) * Have an option to extract and generate the full documentation. (We probably won't ship this documentation, but people who want to hack around in scripts can generate it for themselves) * This raises the question of documenting generated events VS. event handlers. I guess that bro should be able to distinguish them, since the definition of policy-generated event is presumably followed by a semicolon and no body while a handler always has a body, right? (Or could one define a policy-generated event with a header?) If bro can make that distinction, then it should be able to separate handlers from event definitions. cu gregor -- Gregor Maier gregor at icir.org Int. Computer Science Institute (ICSI) gregor at icsi.berkeley.edu 1947 Center St., Ste. 600 http://www.icir.org/gregor/ Berkeley, CA 94704 USA From robin at icir.org Tue Nov 23 13:40:29 2010 From: robin at icir.org (Robin Sommer) Date: Tue, 23 Nov 2010 13:40:29 -0800 Subject: [Bro-Dev] Thoughts on documenting scripts In-Reply-To: <4CEC061B.1060705@icir.org> References: <20101123022439.GA63257@icir.org> <4CEC061B.1060705@icir.org> Message-ID: <20101123214029.GJ93179@icir.org> On Tue, Nov 23, 2010 at 10:21 -0800, you wrote: > * However, also document the internal workings (which IMHO is good > style anyway) It's good style but I'd prefer to leave it informal how to do that. Enforcing consistent documentation of script internals increases the burden on the scritp writer quite a bit, without that much benefit actually (because often one will end up just reading the script code anyway; there's no better documention then that.) > * This raises the question of documenting generated events VS. event > handlers. I guess that bro should be able to distinguish them, since > the definition of policy-generated event is presumably followed by a > semicolon and no body while a handler always has a body, right? The easier way would be to look for uses of the "event" statement; that directly shows what events are raised. Independent of the question whether to generate docs for internals, I can see summarizing for which events a script has handlers, and which events it generates. That's quite interesting information as it introduces dependencies with other scripts. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From gregor at icir.org Wed Nov 24 07:38:33 2010 From: gregor at icir.org (Gregor Maier) Date: Wed, 24 Nov 2010 07:38:33 -0800 Subject: [Bro-Dev] min() and max() problem in util.h Message-ID: <4CED3179.6030200@icir.org> Hi, when fixing a 32 bit overflow in the HTTP analyzer, I cam across a problem with the min() and max() function defined (as inline) in util.h Their signature is int min (int,int), which fails for 64bit values and which will also fails for comparing uints. One could write a bunch of overloaded min/max function to handle all kinds of argument types correctly. However, I don't like overloading with too many too similar parameter types (bad experience with hard to find bugs). One way to solve this, would be to explicitly name the min/max functions according to their type, e.g., min_i32(), min_u32(), min_u64(), min_64().... Or, I can just replace the min/max function with a macro. However, then the problem is, that the expression that's passed to min/max will be evaluated twice, which is a problem if it has side effects..... Comments? Ideas? cu Gregor -- Gregor Maier gregor at icir.org Int. Computer Science Institute (ICSI) gregor at icsi.berkeley.edu 1947 Center St., Ste. 600 http://www.icir.org/gregor/ Berkeley, CA 94704 USA From gregor at icir.org Wed Nov 24 07:51:18 2010 From: gregor at icir.org (Gregor Maier) Date: Wed, 24 Nov 2010 07:51:18 -0800 Subject: [Bro-Dev] min() and max() problem in util.h In-Reply-To: <4CED3179.6030200@icir.org> References: <4CED3179.6030200@icir.org> Message-ID: <4CED3476.6050601@icir.org> > Or, I can just replace the min/max function with a macro. However, then > the problem is, that the expression that's passed to min/max will be > evaluated twice, which is a problem if it has side effects..... GCC's typeof() extension can solve this, however, then we'd have compiler dependent code :-( (http://en.wikipedia.org/wiki/Typeof) cu Gregor -- Gregor Maier gregor at icir.org Int. Computer Science Institute (ICSI) gregor at icsi.berkeley.edu 1947 Center St., Ste. 600 http://www.icir.org/gregor/ Berkeley, CA 94704 USA From robin at icir.org Wed Nov 24 08:06:43 2010 From: robin at icir.org (Robin Sommer) Date: Wed, 24 Nov 2010 08:06:43 -0800 Subject: [Bro-Dev] min() and max() problem in util.h In-Reply-To: <4CED3179.6030200@icir.org> References: <4CED3179.6030200@icir.org> <4CED3476.6050601@icir.org> <4CED3179.6030200@icir.org> Message-ID: <20101124160643.GD26590@icir.org> On Wed, Nov 24, 2010 at 07:38 -0800, you wrote: > One could write a bunch of overloaded min/max function to handle all > kinds of argument types correctly. Actually I think that's the best solution, and I don't really see how it would cause hard to find bugs? min/max seems simple enough, and as long as we don't provide versions with mixed argument types, I think we should be fine. Or am I missing something nasty? > min_i32(), min_u32(), min_u64(), min_64().... That looks pretty ugly, in particualr when overloading can solve the problem automatically. > Or, I can just replace the min/max function with a macro. I'd expect that to actually generate more bugs than the overloading. On Wed, Nov 24, 2010 at 07:51 -0800, you wrote: > GCC's typeof() extension can solve this, however, then we'd have > compiler dependent code :-( Yeah, not good. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From bro at tracker.icir.org Wed Nov 24 08:11:07 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 24 Nov 2010 16:11:07 -0000 Subject: [Bro-Dev] #200: broctl update resets/corrupts certain variables In-Reply-To: <045.eae4a7b497ce56be1e0345b61658246e@tracker.icir.org> References: <045.eae4a7b497ce56be1e0345b61658246e@tracker.icir.org> Message-ID: <060.0fe6ac80e9d7ecc8457d33ac8bb4b9b6@tracker.icir.org> #200: broctl update resets/corrupts certain variables -------------------------+--------------------------- Reporter: justin | Owner: seth Type: defect | Status: accepted Priority: Low | Milestone: Bro1.6 Component: BroControl | Version: 1.5.2 Resolution: | Keywords: broctl update -------------------------+--------------------------- Changes (by seth): * owner: robin => seth * status: seen => accepted * milestone: => Bro1.6 Comment: After digging around a little bit I figured out what's going on. The update command is generally broken for any values that are set within an event handler. Both of the problems being encountered by Justin are because values are being set within bro_init handlers. I can think of a couple of directions this could go. 1. The send-config.bro script could send the bro_init event to the workers which would solve most of the problems although there could still be some issues is people set values after that. That is mitigated by the fact that anything done after bro_init is almost certainly based on traffic analysis and presumably changes from time to time anyway and would be set to something soon after the update command was given. 2. Scripts are rewritten to more carefully use globals and consts. In that case, only redef-able consts would updated. It doesn't even really make sense to label a global as redef-able anyway since it can be changed at will within event handlers even if it's not specifically labeled as redef-able. Generally, weird issues like this will crop up where ever there is a redef-able global. Because consts can't be modified from within event handlers and globals without the &redef attribute won't be touched when doing "update", there won't be problems in those cases. I'm inclined to say that option 2 is the more viable option since sending the bro_init event to the workers could cause undefined issues due to assumptions (correctly) made by script writers that bro_init is *only* called at startup. I think we can do this for the 1.6 release since there likely aren't that many redef-able globals and we're going to be doing a lot of script work anyway. If anyone disagrees, feel free to bump it to 1.7 since the "update" feature isn't heavily used anyway. (of course, maybe it would be used more if it worked correctly) -- Ticket URL: Bro Tracker Bro Issue Tracker From vern at icir.org Wed Nov 24 09:22:41 2010 From: vern at icir.org (Vern Paxson) Date: Wed, 24 Nov 2010 09:22:41 -0800 Subject: [Bro-Dev] min() and max() problem in util.h In-Reply-To: <20101124160643.GD26590@icir.org> (Wed, 24 Nov 2010 08:06:43 PST). Message-ID: <20101124172241.B0EE53137D0@taffy.ICSI.Berkeley.EDU> > > One could write a bunch of overloaded min/max function to handle all > > kinds of argument types correctly. > > Actually I think that's the best solution That's my view too. Vern From gregor at icir.org Wed Nov 24 09:35:46 2010 From: gregor at icir.org (Gregor Maier) Date: Wed, 24 Nov 2010 09:35:46 -0800 Subject: [Bro-Dev] min() and max() problem in util.h In-Reply-To: <20101124160643.GD26590@icir.org> References: <4CED3179.6030200@icir.org> <4CED3476.6050601@icir.org> <4CED3179.6030200@icir.org> <20101124160643.GD26590@icir.org> Message-ID: <4CED4CF2.5050703@icir.org> On 11/24/10 8:06 , Robin Sommer wrote: > > On Wed, Nov 24, 2010 at 07:38 -0800, you wrote: > >> One could write a bunch of overloaded min/max function to handle all >> kinds of argument types correctly. > > Actually I think that's the best solution, and I don't really see > how it would cause hard to find bugs? min/max seems simple enough, > and as long as we don't provide versions with mixed argument types, > I think we should be fine. Or am I missing something nasty? Let's say we want to support: * int min(int,int) * int32_t min(int32_t, int32_t) * int64_t min(int64_t, int64_t) * (also for unsigned, alo for max) Depending on the architecture the int one and int32 and int64 will have the same signature and yield a compiler warning. We can probably just omit the int version though, right? Since either int32 or int64 would be a int (depending on the platform), right? What happens, if I pass an int32 and an int64 to min()? Will I get a compiler error or will the compiler to some coercion? Also, what happens, if somebody tries to compare unsigned and signed? Compiler error? (I know that gcc warns if you try to compare signed and unsigned, but I'm not sure what it would do when it tries to find a matching function signature) Finally, if one wants to use a constant in a min/max call, one should cast it to the right type, right? (If it's not casted it might cause compiler errors, if the a constant has different width on different platforms/compilers) (*) >> min_i32(), min_u32(), min_u64(), min_64().... > > That looks pretty ugly, in particualr when overloading can solve the > problem automatically. yeah. that's pretty ugly cu Gregor (*) Now that I think of it I can't reacall the details of my problems with overloaded functions. I remember though that I had a problem with an overloaded function that would pick the wrong function due to something strange with the function signature and the types I passed to the function.... However, I think that it involved polymorphism..... Long story short: I can't really come up with a case in which overloading min/max would be a problem, as long as we get compiler errors when somebody tries to use unsupported types. -- Gregor Maier gregor at icir.org Int. Computer Science Institute (ICSI) gregor at icsi.berkeley.edu 1947 Center St., Ste. 600 http://www.icir.org/gregor/ Berkeley, CA 94704 USA From vern at icir.org Wed Nov 24 09:43:01 2010 From: vern at icir.org (Vern Paxson) Date: Wed, 24 Nov 2010 09:43:01 -0800 Subject: [Bro-Dev] min() and max() problem in util.h In-Reply-To: <4CED4CF2.5050703@icir.org> (Wed, 24 Nov 2010 09:35:46 PST). Message-ID: <20101124174301.47DDF36A031@taffy.ICSI.Berkeley.EDU> > What happens, if I pass an int32 and an int64 to min()? What happens if you do so to min_int64? To a MIN macro? I think this thread is burning cycles on something that isn't particularly broken to begin with. Vern From robin at icir.org Wed Nov 24 10:09:58 2010 From: robin at icir.org (Robin Sommer) Date: Wed, 24 Nov 2010 10:09:58 -0800 Subject: [Bro-Dev] min() and max() problem in util.h In-Reply-To: <4CED4CF2.5050703@icir.org> References: <4CED3179.6030200@icir.org> <4CED3476.6050601@icir.org> <4CED3179.6030200@icir.org> <20101124160643.GD26590@icir.org> <4CED4CF2.5050703@icir.org> Message-ID: <20101124180958.GF26590@icir.org> To finish this, I think we can trust the compiler here to pick the right version, or to complain if it can't. I've had problems with overloading picking the wrong version in the past as well, but I think that always involved pointers of some form; there's some implicit cast that C++ does in that context that can cause trouble; don't remember the details either though. But I'm pretty sure for ints we are fine. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From bro at tracker.icir.org Wed Nov 24 11:17:10 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 24 Nov 2010 19:17:10 -0000 Subject: [Bro-Dev] #321: Load http.bro script from http-header Message-ID: <045.cdd32311ecb41b074829e56fad7216c2@tracker.icir.org> #321: Load http.bro script from http-header ---------------------+------------------------ Reporter: gregor | Owner: Type: Problem | Status: new Priority: Low | Milestone: Bro1.6 Component: Bro | Version: git/master Keywords: | ---------------------+------------------------ http-header.bro should load http.bro, as it uses functions defined there. (If other http-* scripts are loaded before http.bro, they'll pull in http.bro and thus works) -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Nov 24 13:46:35 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 24 Nov 2010 21:46:35 -0000 Subject: [Bro-Dev] #207: Small bug in file rotate+setbuf In-Reply-To: <045.779bbc363dd741be852d73b1db8681ec@tracker.icir.org> References: <045.779bbc363dd741be852d73b1db8681ec@tracker.icir.org> Message-ID: <060.3082f8d2d04b01edcce95dbe9fb76551@tracker.icir.org> #207: Small bug in file rotate+setbuf ---------------------+--------------------------- Reporter: justin | Owner: Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: rotate buffer ---------------------+--------------------------- Changes (by robin): * owner: vern => -- Ticket URL: Bro Tracker Bro Issue Tracker From robin at icir.org Wed Nov 24 16:17:55 2010 From: robin at icir.org (Robin Sommer) Date: Wed, 24 Nov 2010 16:17:55 -0800 Subject: [Bro-Dev] Merge Message-ID: <20101125001755.GM26590@icir.org> Jon, can I already go ahead and merge the cmake-port branches over to their masters? Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From jsiwek at ncsa.illinois.edu Wed Nov 24 16:36:12 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Wed, 24 Nov 2010 18:36:12 -0600 (CST) Subject: [Bro-Dev] Merge In-Reply-To: <20101125001755.GM26590@icir.org> Message-ID: <54762003.5885.1290645372649.JavaMail.root@zimbra-1.ncsa.uiuc.edu> > can I already go ahead and merge the cmake-port branches over to > their masters? I'm cool with it. I was too preoccupied/distracted this week to organize git/CMake documentation and port my task notes over to tracker, but I can finish that later and it doesn't block the merge from happening (unless you say it does). - Jon From robin at icir.org Wed Nov 24 21:17:23 2010 From: robin at icir.org (Robin Sommer) Date: Wed, 24 Nov 2010 21:17:23 -0800 Subject: [Bro-Dev] Merge In-Reply-To: <54762003.5885.1290645372649.JavaMail.root@zimbra-1.ncsa.uiuc.edu> References: <20101125001755.GM26590@icir.org> <54762003.5885.1290645372649.JavaMail.root@zimbra-1.ncsa.uiuc.edu> Message-ID: <20101125051723.GA49302@icir.org> On Wed, Nov 24, 2010 at 18:36 -0600, you wrote: > I was too preoccupied/distracted this week to organize git/CMake > documentation and port my task notes over to tracker, but I can > finish that later and it doesn't block the merge from happening > (unless you say it does). That's fine. Ok, I'll go ahead then. Note to all: this may make the masters unstable for a bit until I get everything into the right shape. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From robin at icir.org Wed Nov 24 21:50:27 2010 From: robin at icir.org (Robin Sommer) Date: Wed, 24 Nov 2010 21:50:27 -0800 Subject: [Bro-Dev] Merge In-Reply-To: <20101125051723.GA49302@icir.org> References: <20101125001755.GM26590@icir.org> <54762003.5885.1290645372649.JavaMail.root@zimbra-1.ncsa.uiuc.edu> <20101125051723.GA49302@icir.org> Message-ID: <20101125055027.GB49302@icir.org> On Wed, Nov 24, 2010 at 21:17 -0800, I wrote: > Note to all: this may make the masters unstable for a bit until I > get everything into the right shape. Ok, done; all cmake-ports are merged in. For a quick test, it seems work ok (except for the spamming ...). But I'll do some more testing later. I haven't deleted the topic branches yet. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From slagell at ncsa.illinois.edu Wed Nov 24 21:54:45 2010 From: slagell at ncsa.illinois.edu (Adam Slagell) Date: Wed, 24 Nov 2010 23:54:45 -0600 (CST) Subject: [Bro-Dev] Merge In-Reply-To: <20101125055027.GB49302@icir.org> References: <20101125001755.GM26590@icir.org> <54762003.5885.1290645372649.JavaMail.root@zimbra-1.ncsa.uiuc.edu> <20101125051723.GA49302@icir.org> <20101125055027.GB49302@icir.org> Message-ID: <1CFE4868-8AB9-4938-A78E-41BE6D2B3C71@ncsa.illinois.edu> Laying in bed with son. 3 year old listening to dualing ipad & iPhone emails: what's that daddy? Me: sounds like a git merge Son: no. That's silly. On Nov 24, 2010, at 11:50 PM, Robin Sommer wrote: > > On Wed, Nov 24, 2010 at 21:17 -0800, I wrote: > >> Note to all: this may make the masters unstable for a bit until I >> get everything into the right shape. > > Ok, done; all cmake-ports are merged in. For a quick test, it seems > work ok (except for the spamming ...). But I'll do some more testing > later. I haven't deleted the topic branches yet. > > Robin > > -- > Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org > ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org > _______________________________________________ > bro-dev mailing list > bro-dev at bro-ids.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > From bro at tracker.icir.org Fri Nov 26 12:24:17 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 26 Nov 2010 20:24:17 -0000 Subject: [Bro-Dev] #302: New quick start guide In-Reply-To: <043.685a4d5495d67a9229110504cfc61113@tracker.icir.org> References: <043.685a4d5495d67a9229110504cfc61113@tracker.icir.org> Message-ID: <058.bf51fdc4b5edf8a04f31137fddc27cb1@tracker.icir.org> #302: New quick start guide ---------------------+-------------------- Reporter: seth | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ---------------------+-------------------- Comment (by robin): The INSTALL files refers to the new quick-start guide already. Make sure it points to the right location. -- Ticket URL: Bro Tracker Bro Issue Tracker From robin at icir.org Fri Nov 26 12:39:21 2010 From: robin at icir.org (Robin Sommer) Date: Fri, 26 Nov 2010 12:39:21 -0800 Subject: [Bro-Dev] Cleanup: scripts Message-ID: <20101126203921.GM31168@icir.org> I'm cleaning up the Bro distribution to remove all the stuff we no longer need. Question: is there anything in the scripts/* directory that's still relevant? As far as I can see, there's only BroLite and Snort2Bro in there, both of which have been scheduled for removal for a while already. So, seems I can just delete the whole directory? Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From bro at tracker.icir.org Fri Nov 26 12:41:58 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 26 Nov 2010 20:41:58 -0000 Subject: [Bro-Dev] #322: Update Checklist-for-Release Message-ID: <044.08c9c7aa12a6fc10531f488a22cf5b97@tracker.icir.org> #322: Update Checklist-for-Release -------------------+-------------------- Reporter: robin | Type: Problem Status: new | Priority: Normal Component: Bro | -------------------+-------------------- This file is outdated and needs to be updated when the new process has been determined. milestone: Bro1.6 component: Bro -- Ticket URL: Bro Tracker Bro Issue Tracker From robin at icir.org Fri Nov 26 12:43:14 2010 From: robin at icir.org (Robin Sommer) Date: Fri, 26 Nov 2010 12:43:14 -0800 Subject: [Bro-Dev] Cleanup: example-attacks Message-ID: <20101126204314.GO31168@icir.org> I'm also tempted to remove the example-attacks directories, not sure how helpful the two traces in there still are for anybody. Opionions? Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From bro at tracker.icir.org Fri Nov 26 13:43:47 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 26 Nov 2010 21:43:47 -0000 Subject: [Bro-Dev] #323: State of paassive fingerprinting signatures? Message-ID: <044.f8d2454b5f4a85a5a9f8ea83a271e298@tracker.icir.org> #323: State of paassive fingerprinting signatures? -------------------+-------------------- Reporter: robin | Type: Problem Status: new | Priority: Normal Component: Bro | -------------------+-------------------- Does the content of sigs/p0fsyn.osf still apply? Do we at least need to update the file? milestone: Bro1.6 component: Bro -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 26 14:10:27 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 26 Nov 2010 22:10:27 -0000 Subject: [Bro-Dev] #322: Update Checklist-for-Release In-Reply-To: <044.08c9c7aa12a6fc10531f488a22cf5b97@tracker.icir.org> References: <044.08c9c7aa12a6fc10531f488a22cf5b97@tracker.icir.org> Message-ID: <059.9c25122cacd13dc78507953d35dc3074@tracker.icir.org> #322: Update Checklist-for-Release ---------------------+------------------------ Reporter: robin | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: | Keywords: ---------------------+------------------------ Changes (by robin): * version: => git/master * type: Problem => Task * milestone: => Bro1.6 Old description: > This file is outdated and needs to be updated when the new process > has been determined. > > milestone: Bro1.6 > component: Bro New description: This file is outdated and needs to be updated when the new process has been determined. -- -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 26 14:10:58 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 26 Nov 2010 22:10:58 -0000 Subject: [Bro-Dev] #323: State of passive fingerprinting signatures? (was: State of paassive fingerprinting signatures?) In-Reply-To: <044.f8d2454b5f4a85a5a9f8ea83a271e298@tracker.icir.org> References: <044.f8d2454b5f4a85a5a9f8ea83a271e298@tracker.icir.org> Message-ID: <059.94b8f89aa8537d3b41b8f3a3163000c8@tracker.icir.org> #323: State of passive fingerprinting signatures? ----------------------+------------------------ Reporter: robin | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: | Keywords: ----------------------+------------------------ Changes (by robin): * version: => git/master * milestone: => Bro1.6 Old description: > Does the content of sigs/p0fsyn.osf still apply? Do we at least need > to update the file? > > milestone: Bro1.6 > component: Bro New description: Does the content of sigs/p0fsyn.osf still apply? Do we at least need to update the file? -- -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 26 14:34:17 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 26 Nov 2010 22:34:17 -0000 Subject: [Bro-Dev] #324: Remove EXPIRE_DFA_STATES code Message-ID: <044.1d76ad3b3cc62054fae99370dccd0543@tracker.icir.org> #324: Remove EXPIRE_DFA_STATES code -------------------+----------------------- Reporter: robin | Type: Task Status: new | Priority: Normal Component: Bro | Version: git/master -------------------+----------------------- The configure options is already gone, let's not forget to remove the code as well. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 26 14:35:27 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 26 Nov 2010 22:35:27 -0000 Subject: [Bro-Dev] #324: Remove EXPIRE_DFA_STATES code In-Reply-To: <044.1d76ad3b3cc62054fae99370dccd0543@tracker.icir.org> References: <044.1d76ad3b3cc62054fae99370dccd0543@tracker.icir.org> Message-ID: <059.c13f605d7f2257c2c85e85ccd09ff61b@tracker.icir.org> #324: Remove EXPIRE_DFA_STATES code ---------------------+------------------------ Reporter: robin | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: | Keywords: ---------------------+------------------------ Changes (by robin): * milestone: => Bro1.6 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 26 14:35:34 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 26 Nov 2010 22:35:34 -0000 Subject: [Bro-Dev] #325: Remove ACTIVE_MAPPING code Message-ID: <044.35fa7a347d936d84e134297408ded21b@tracker.icir.org> #325: Remove ACTIVE_MAPPING code ------------------------+--------------------- Reporter: robin | Type: Problem Status: new | Priority: Normal Milestone: Bro1.6 | Component: Bro Version: git/master | ------------------------+--------------------- The configure option is already gone, let's not forget to remove the code as well. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Nov 26 14:35:54 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 26 Nov 2010 22:35:54 -0000 Subject: [Bro-Dev] #325: Remove ACTIVE_MAPPING code In-Reply-To: <044.35fa7a347d936d84e134297408ded21b@tracker.icir.org> References: <044.35fa7a347d936d84e134297408ded21b@tracker.icir.org> Message-ID: <059.7de7ad31d8e5f6882fe60fd7c5eb1eed@tracker.icir.org> #325: Remove ACTIVE_MAPPING code ---------------------+------------------------ Reporter: robin | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: | Keywords: ---------------------+------------------------ Changes (by robin): * type: Problem => Task -- Ticket URL: Bro Tracker Bro Issue Tracker From gregor at icir.org Sat Nov 27 10:16:39 2010 From: gregor at icir.org (Gregor Maier) Date: Sat, 27 Nov 2010 10:16:39 -0800 Subject: [Bro-Dev] Merge In-Reply-To: <20101125055027.GB49302@icir.org> References: <20101125001755.GM26590@icir.org> <54762003.5885.1290645372649.JavaMail.root@zimbra-1.ncsa.uiuc.edu> <20101125051723.GA49302@icir.org> <20101125055027.GB49302@icir.org> Message-ID: <4CF14B07.6080402@icir.org> On 11/24/10 21:50 , Robin Sommer wrote: > > On Wed, Nov 24, 2010 at 21:17 -0800, I wrote: > >> Note to all: this may make the masters unstable for a bit until I >> get everything into the right shape. > > Ok, done; all cmake-ports are merged in. For a quick test, it seems > work ok (except for the spamming ...). But I'll do some more testing > later. I haven't deleted the topic branches yet. bro master still contains the autoconf-related files (configure.in, Makefile.am, autogen.sh, etc.). Those should probably also be deleted once you are done. cu gregor -- Gregor Maier gregor at icir.org Int. Computer Science Institute (ICSI) gregor at icsi.berkeley.edu 1947 Center St., Ste. 600 http://www.icir.org/gregor/ Berkeley, CA 94704 USA From robin at icir.org Sat Nov 27 10:31:05 2010 From: robin at icir.org (Robin Sommer) Date: Sat, 27 Nov 2010 10:31:05 -0800 Subject: [Bro-Dev] Merge In-Reply-To: <4CF14B07.6080402@icir.org> References: <20101125001755.GM26590@icir.org> <54762003.5885.1290645372649.JavaMail.root@zimbra-1.ncsa.uiuc.edu> <20101125051723.GA49302@icir.org> <20101125055027.GB49302@icir.org> <4CF14B07.6080402@icir.org> Message-ID: <20101127183105.GA16632@icir.org> On Sat, Nov 27, 2010 at 10:16 -0800, you wrote: > Makefile.am, autogen.sh, etc.). Those should probably also be deleted > once you are done. Yes, I'm working on cleanup branches for all the repos, removing this and other stuff we don't need anymore (like BroLite, yeah! :) Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From vern at icir.org Sat Nov 27 11:40:42 2010 From: vern at icir.org (Vern Paxson) Date: Sat, 27 Nov 2010 11:40:42 -0800 Subject: [Bro-Dev] Cleanup: scripts In-Reply-To: <20101126203921.GM31168@icir.org> (Fri, 26 Nov 2010 12:39:21 PST). Message-ID: <20101127194042.976BC36A016@taffy.ICSI.Berkeley.EDU> > Question: is there anything in the scripts/* directory that's still > relevant? I don't see anything that strikes me as worth supporting. Vern From vern at icir.org Sat Nov 27 11:41:12 2010 From: vern at icir.org (Vern Paxson) Date: Sat, 27 Nov 2010 11:41:12 -0800 Subject: [Bro-Dev] Cleanup: example-attacks In-Reply-To: <20101126204314.GO31168@icir.org> (Fri, 26 Nov 2010 12:43:14 PST). Message-ID: <20101127194112.3201736A016@taffy.ICSI.Berkeley.EDU> > I'm also tempted to remove the example-attacks directories, not sure > how helpful the two traces in there still are for anybody. Opionions? Yeah, that's too feeble a collection to be worth it. If we could expand it, that would be quite useful, but I don't think it's worth the effort at this point. Vern From bro at tracker.icir.org Sat Nov 27 17:31:24 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Sun, 28 Nov 2010 01:31:24 -0000 Subject: [Bro-Dev] #326: HTTP Analyzer overflow on content-lengths > 2GB Message-ID: <045.82bf4b86731e1736daaef4caa8c63d05@tracker.icir.org> #326: HTTP Analyzer overflow on content-lengths > 2GB ----------------------+------------------------ Reporter: gregor | Owner: Type: Patch | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Keywords: inttypes | ----------------------+------------------------ {{{ #!rst The HTTP analyzer uses 32 bit signed ints to parse the content-length header, track body length etc. This causes overflow and for content lengths > 2GB. This effects the reported body length as well as parsing of pipelined or persistent connection. The overflow might also cause crashes. Changes in this patch: * Change the affected integers in to 64 bit wide * Overload min/max inline functions in util.h to work with different widths and signedness. * Explicitly cast parameters to min/max where in cases were the compiler complained. }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Sat Nov 27 19:41:23 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Sun, 28 Nov 2010 03:41:23 -0000 Subject: [Bro-Dev] #272: Patch to fix do_split function In-Reply-To: <043.1e378c2cf2d2f272b054d3bd5b2f44d9@tracker.icir.org> References: <043.1e378c2cf2d2f272b054d3bd5b2f44d9@tracker.icir.org> Message-ID: <058.462010d93e2dec8e098020f1cb07657d@tracker.icir.org> #272: Patch to fix do_split function ---------------------+---------------------- Reporter: seth | Owner: seth Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: ---------------------+---------------------- Comment (by robin): With this patch, I'm seeing a number of test-suite problem in devel, all in the SMTP analyzer and of the following kind: error: '<' not found in argument to RCPT: TO: Looking at smtp.bro, it seems like the split1 function has a problem. I'm backing the change out of devel for now. -- Ticket URL: Bro Tracker Bro Issue Tracker From robin at icir.org Sat Nov 27 20:47:44 2010 From: robin at icir.org (Robin Sommer) Date: Sat, 27 Nov 2010 20:47:44 -0800 Subject: [Bro-Dev] Masters updated Message-ID: <20101128044744.GB75232@icir.org> I've updated all the masters and devels to - integrate a round of cleanup removing files no longer necessary. - the latest changes from SVN. I've also adapted the test-suite (in bro-private) to work with the new setup, and it passes fine with all the changes (well, to be precise, it reports the same differences as svn trunk; seems it's not completely up to date). We should now see if master is working for everybody. If so, we'll have a stable base to work from. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From bro at tracker.icir.org Sun Nov 28 14:50:30 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Sun, 28 Nov 2010 22:50:30 -0000 Subject: [Bro-Dev] #257: Commandline flag to enable BRO_FAKE_DNS In-Reply-To: <049.463a3aa2505ed0b2731a01396c4cbef8@tracker.icir.org> References: <049.463a3aa2505ed0b2731a01396c4cbef8@tracker.icir.org> Message-ID: <064.1c17c79e1b62a95370b298b5469ed27b@tracker.icir.org> #257: Commandline flag to enable BRO_FAKE_DNS -------------------------+---------------------- Reporter: brosenberg | Owner: vern Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: -------------------------+---------------------- Comment (by vern): I wonder whether instead of adding command-line flags, we should move towards use of var=value, as is already supported, by exposing this functionality as a script variable. One then uses ''''''bro use_fake_dns=T'''''' rather than ''''''bro -N''''''. One downside is that ''''''bro --help'''''' won't display this. However, we could consider adding a framework where variables meant to be redefined on the command-line have text associated with them that ''''''bro --help'''''' displays. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Sun Nov 28 14:59:10 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Sun, 28 Nov 2010 22:59:10 -0000 Subject: [Bro-Dev] #207: Small bug in file rotate+setbuf In-Reply-To: <045.779bbc363dd741be852d73b1db8681ec@tracker.icir.org> References: <045.779bbc363dd741be852d73b1db8681ec@tracker.icir.org> Message-ID: <060.0eaa91ebfadc008ffb9d023ac88b8b3c@tracker.icir.org> #207: Small bug in file rotate+setbuf ---------------------+--------------------------- Reporter: justin | Owner: Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: rotate buffer ---------------------+--------------------------- Comment (by vern): Robin, you deleted me as owner from this. Can you add mention of why? Is it because you want to ensure this isn't part of the upcoming 1.5 update? -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Sun Nov 28 15:05:28 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Sun, 28 Nov 2010 23:05:28 -0000 Subject: [Bro-Dev] #187: Packet processing doesn't resume if remote Bro dies during state synchronization In-Reply-To: <043.97324d9e7c55b88a20b40eec2effc4a6@tracker.icir.org> References: <043.97324d9e7c55b88a20b40eec2effc4a6@tracker.icir.org> Message-ID: <058.772b7199719ca2b8f355a7d30cac6220@tracker.icir.org> #187: Packet processing doesn't resume if remote Bro dies during state synchronization ---------------------+-------------------- Reporter: seth | Owner: vern Type: Patch | Status: closed Priority: Normal | Milestone: Component: Bro | Version: 1.5.2 Resolution: Solved | Keywords: ---------------------+-------------------- Changes (by vern): * status: assigned => closed * resolution: => Solved Comment: Integrated in 1.5.2.10. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Sun Nov 28 15:05:53 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Sun, 28 Nov 2010 23:05:53 -0000 Subject: [Bro-Dev] #247: Bro trunk build fails with OpenSSL stack error In-Reply-To: <047.50baac97db1997fb95f119eebf1fbebf@tracker.icir.org> References: <047.50baac97db1997fb95f119eebf1fbebf@tracker.icir.org> Message-ID: <062.de7e1fdda6bb3d16bff2ea827fb4f546@tracker.icir.org> #247: Bro trunk build fails with OpenSSL stack error -----------------------+-------------------- Reporter: kreibich | Owner: vern Type: Patch | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: Solved | Keywords: -----------------------+-------------------- Changes (by vern): * status: assigned => closed * resolution: => Solved Comment: Integrated in 1.5.2.10. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Sun Nov 28 15:06:10 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Sun, 28 Nov 2010 23:06:10 -0000 Subject: [Bro-Dev] #294: Autoconf trouble with autoconf >= 2.64 In-Reply-To: <045.af88d58ef5cb7463920bba891047248c@tracker.icir.org> References: <045.af88d58ef5cb7463920bba891047248c@tracker.icir.org> Message-ID: <060.6208a8d94337d921adb71a3cc1d2885f@tracker.icir.org> #294: Autoconf trouble with autoconf >= 2.64 ---------------------+-------------------- Reporter: gregor | Owner: vern Type: Patch | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: Solved | Keywords: ---------------------+-------------------- Changes (by vern): * status: assigned => closed * resolution: => Solved Comment: Integrated in 1.5.2.10. -- Ticket URL: Bro Tracker Bro Issue Tracker From vern at icir.org Sun Nov 28 15:34:02 2010 From: vern at icir.org (Vern Paxson) Date: Sun, 28 Nov 2010 15:34:02 -0800 Subject: [Bro-Dev] 1.5.1? (Re: #247: Bro trunk build fails with OpenSSL stack error) In-Reply-To: <20101122042227.GB8052@icir.org> (Sun, 21 Nov 2010 20:22:27 PST). Message-ID: <20101128233401.ECA29369FE9@taffy.ICSI.Berkeley.EDU> > Just noticed that the "patches for next release" query on the > tracker home page doesn't work anymore, though I'm not sure right > now why. But that probably means that Vern won't find it ... FYI, it did show up for me. > Should we do a 1.5.1 release sometime soon to get the final changes > in SVN pushed out? Sounds good. (You mean 1.5.2, presumably.) Vern From robin at icir.org Mon Nov 29 08:17:42 2010 From: robin at icir.org (Robin Sommer) Date: Mon, 29 Nov 2010 08:17:42 -0800 Subject: [Bro-Dev] 1.5.1? (Re: #247: Bro trunk build fails with OpenSSL stack error) In-Reply-To: <20101128233401.ECA29369FE9@taffy.ICSI.Berkeley.EDU> References: <20101122042227.GB8052@icir.org> <20101128233401.ECA29369FE9@taffy.ICSI.Berkeley.EDU> Message-ID: <20101129161742.GD84349@icir.org> On Sun, Nov 28, 2010 at 15:34 -0800, you wrote: > FYI, it did show up for me. Because I had fixed it in the meantime :-) The version the query was asking for doesn't exist anymore. > Sounds good. (You mean 1.5.2, presumably.) (Correct). Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From bro at tracker.icir.org Mon Nov 29 08:26:45 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 29 Nov 2010 16:26:45 -0000 Subject: [Bro-Dev] #207: Small bug in file rotate+setbuf In-Reply-To: <045.779bbc363dd741be852d73b1db8681ec@tracker.icir.org> References: <045.779bbc363dd741be852d73b1db8681ec@tracker.icir.org> Message-ID: <060.f60b59732bccdc7bcbbed93bb4cb53ef@tracker.icir.org> #207: Small bug in file rotate+setbuf ---------------------+--------------------------- Reporter: justin | Owner: Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: rotate buffer ---------------------+--------------------------- Comment (by robin): On Sun, Nov 28, 2010 at 22:59 -0000, you wrote: > Robin, you deleted me as owner from this. Can you add mention of why? Is > it because you want to ensure this isn't part of the upcoming 1.5 update? Correct, Seth had changed the Milestone to 1.6 so I was assuming this shouldn't go into 1.5.2. It probably could go into 1.5.x as well if we wanted it to. However, I'm not sure where we want to draw the boundary what goes in and what doesn't. I'm thinking we should switch to git soon as the master version and would prefer to then potentially *backport* such changes to the 1.5 series where helpful (rather than the opposite way). Robin -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 29 08:31:47 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 29 Nov 2010 16:31:47 -0000 Subject: [Bro-Dev] #207: Small bug in file rotate+setbuf In-Reply-To: <045.779bbc363dd741be852d73b1db8681ec@tracker.icir.org> References: <045.779bbc363dd741be852d73b1db8681ec@tracker.icir.org> Message-ID: <060.1f5c266596dc5b820fd3711a351fa9df@tracker.icir.org> #207: Small bug in file rotate+setbuf ---------------------+--------------------------- Reporter: justin | Owner: Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: rotate buffer ---------------------+--------------------------- Comment (by seth): > Correct, Seth had changed the Milestone to 1.6 so I was assuming > this shouldn't go into 1.5.2. My thought was that we would just put those few changes into 1.5.2 that prevent Bro from compiling easily. I haven't heard a lot of people complaining about problems with this so it seemed like it would be ok to wait until 1.6. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 29 08:32:49 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 29 Nov 2010 16:32:49 -0000 Subject: [Bro-Dev] #327: Binding attributes to values/variables Message-ID: <044.e1cbe0d29a1893f9f36588b87ae33853@tracker.icir.org> #327: Binding attributes to values/variables ------------------------+--------------------- Reporter: robin | Type: Problem Status: new | Priority: Normal Milestone: Bro1.7 | Component: Bro Version: git/master | ------------------------+--------------------- From Vern: In abstract terms, we need to marry two notions: per-variable attributes (those introduced when defining the variable) and per-value attributes (those introduced when creating a value). These both exist under-the-hood, but the rules for propagating them are ad hoc. I'm attaching the follow-up email thread with further thoughts on streamlining this. Robin [attachment:"None"] Did we ever reach resolution regarding the appended thread (from, um, a year ago!), or at least put something in the Tracker so we don't lose sight of it? Vern [attachment:"None-1"] On Tue, Nov 03, 2009 at 17:25 -0800, you wrote: > In abstract terms, we need to marry two notions: per-variable attributes > (those introduced when defining the variable) and per-value attributes > (those introduced when creating a value). These both exist under-the- hood, > but the rules for propagating them are ad hoc. This is something I've wondered about a few times already what the right thing to do is. The keyword at the moment is indeed "ad-hoc": I remember that a number of times I've been running into problems with propagating (or not propagating) attributes, and while I was always able to fix the immediate problem in some way, we don't have a clear system at the moment when that happens and when not. That said, I'm not really sure that this should ideally look like. Intuitively, I'd actually say attributes belong to values, not variables, because transfer-on-assignment can lead to subtle effects (values are passed around, and what if the receiving function happens to assign the value to the wrong variable?. Also what if you assign a value with attribute X to a variable without X; shouldn't the value then be *deleted* for consistency reasons?). If we accept for a moment that attributes belong only to values, then we can think about how to set them. A global definition such as const log_file = open_log_file("foo") &rotate_interval can be interpreted as assigning the attribute to the value returned from the function (more generaly to whatever what the assigned expression yields). We can use the "add foo &raw_output" syntax you suggested for adding attributes to the value of foo dynamically. A declaration such as const foo = F &redef; can be interpreted as "we can rebind foo if it's current value has the &redef attribute". I haven't thought this through actually but I guess my question is whether we need per-variable attributes at all? Robin [attachment:"None-2"] On Nov 4, 2009, at 7:54 PM, Robin Sommer wrote: >That said, I'm not really sure that this should ideally look like. >Intuitively, I'd actually say attributes belong to values, not >variables, because transfer-on-assignment can lead to subtle effects >(values are passed around, and what if the receiving function >happens to assign the value to the wrong variable?. Also what if you >assign a value with attribute X to a variable without X; shouldn't >the value then be *deleted* for consistency reasons?). Attributes being attached to value really seems to make sense. >If we accept for a moment that attributes belong only to values, >then we can think about how to set them. A global definition such as > > const log_file = open_log_file("foo") &rotate_interval It works in this case, but this has typically been where trouble was encountered. What about cases where there isn't a value assigned yet? Something like... const bad_addrs_with_description: table[addr] of string &redef &write_expire=10mins; There isn't a value yet, but it has an attribute applied to it. Would that style still be supported? It would seem to conflict with having only value attributes. Even for my database backed variable stuff I'm working on, it created a stumbling block. What I'm doing internally is creating a copy of the value including attributes to a separate internal value when a query is being run. That value is then filled from the database and the script level variable is rebound to my newly filled internal value and the old value is deleted. I think that would be the right way to do it in this case even if only value attributes exist because it's an internal detail and the new value is being created internally, but it's certainly confusing sometimes. .Seth [attachment:"None-3"] On Wed, Nov 04, 2009 at 20:26 -0500, you wrote: > const bad_addrs_with_description: table[addr] of string &redef > &write_expire=10mins; > > There isn't a value yet, but it has an attribute applied to it. Actually there is: it's assigned an empty table. So, yes that would still work. What would be different however is a later assignment (redef for const [1]), which would ignore the &write_expire of the original definition and instead use the attributes from the assigned value. Robin [1] A "=" redef, not a "+=" redef which works on the original value. [attachment:"None-4"] On Nov 10, 2009, at 12:32 AM, Robin Sommer wrote: >What would be different however is a later assignment (redef for >const [1]), which would ignore the &write_expire of the original >definition and instead use the attributes from the assigned value. > >[1] A "=" redef, not a "+=" redef which works on the original value. Ah, ok. This is all coming together for me now. :) Another question I have is if the change was made to allow attribute additions and deletions at runtime, does it sort of violate the concept of const? const seems to tie together the value and variable together and make them unchangeable at runtime but it's a little confusing conceptually if you're able to still change the attributes of a const at runtime. Am I thinking about that right? .Seth [attachment:"None-5"] On Fri, Nov 13, 2009 at 13:24 -0500, you wrote: > Another question I have is if the change was made to allow attribute > additions and deletions at runtime, does it sort of violate the concept > of const? That's a good point, yes. Perhaps "const foo = xxx" should actually mean that the value xxx gets an (internal) attribute &const so that it's not changeable? And then assigning to a global with a current value that has the &const attribute would be prohibited as well. Does that make sense? Robin -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 29 08:36:16 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 29 Nov 2010 16:36:16 -0000 Subject: [Bro-Dev] #327: Binding attributes to values/variables In-Reply-To: <044.e1cbe0d29a1893f9f36588b87ae33853@tracker.icir.org> References: <044.e1cbe0d29a1893f9f36588b87ae33853@tracker.icir.org> Message-ID: <059.9b2481b189dafcf0b521570bf642af6a@tracker.icir.org> #327: Binding attributes to values/variables ----------------------+------------------------ Reporter: robin | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.7 Component: Bro | Version: git/master Resolution: | Keywords: ----------------------+------------------------ Comment (by robin): To clarify, the attached thread does not necessarily reflect a resolution we fully converged on. We will need to rediscuss the right approach before tackling this. Robin -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 29 08:43:22 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 29 Nov 2010 16:43:22 -0000 Subject: [Bro-Dev] #257: Commandline flag to enable BRO_FAKE_DNS In-Reply-To: <049.463a3aa2505ed0b2731a01396c4cbef8@tracker.icir.org> References: <049.463a3aa2505ed0b2731a01396c4cbef8@tracker.icir.org> Message-ID: <064.3e1628ef2dacd01ffed20e5e46630274@tracker.icir.org> #257: Commandline flag to enable BRO_FAKE_DNS -------------------------+---------------------- Reporter: brosenberg | Owner: vern Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: -------------------------+---------------------- Comment (by robin): On Sun, Nov 28, 2010 at 22:50 -0000, you wrote: > functionality as a script variable. One then uses ''''''bro > use_fake_dns=T'''''' rather than ''''''bro -N''''''. I agree that generally we should avoid the command line flags, the redef mechanism works fine. In this case, however, I'd actually prefer the command line option, as it's one of these things ones sometimes needs immediately (or at least wants to try quickly when something's not working), and then finding the right option takes time (assuming one even thinks about it). It's like -C, which has turned out to be quite handy to have. > we could consider adding a framework where variables meant to be redefined > on the command-line have text associated with them that ''''''bro > --help'''''' displays. Yes, that would help, I like the idea. However, it is worth it? How many options do we have that would be listed here? Also, it may be tough call which ones to list vs which not. Robin -- Ticket URL: Bro Tracker Bro Issue Tracker From jsiwek at ncsa.illinois.edu Mon Nov 29 08:49:28 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Mon, 29 Nov 2010 10:49:28 -0600 (CST) Subject: [Bro-Dev] Tarballs In-Reply-To: <20101117181428.GA24922@icir.org> Message-ID: <1825848.530.1291049368535.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > Here's a proposal for tar-balls to offer for download in the future, > > ... > > Thoughts? I think maybe the broctl source package wouldn't need to include broccoli since that's got it's own? What you outlined seems to make the most sense to me in the cases where broccoli or broctl come out with new releases that are yet included in a bro release -- then a user could try to upgrade those modules (hopefully) without affecting bro. Do you anticipate broccoli & broctl frequently having releases not in sync w/ bro? If not, I'm thinking it's easier to just have a bro-all and a bro-scripts source tarballs. Was there other benefits associated with having those extra source tarballs (broccoli, broctl) that you had in mind? > We could do our binary packages along a similar structure.[2] > > [2] Distributions will want it separeately per repo, but for, e.g., > an MacOS package, it seems more convinient to have few pieces to > download/install). Yeah, I think distributions will likely put finer grained packages in their repositories, but personally, if I were downloading a prebuilt package from the website, I'd rather just download a single RPM, DEB, OS X installer, etc, that has everything I should ever need. - Jon From robin at icir.org Mon Nov 29 09:02:09 2010 From: robin at icir.org (Robin Sommer) Date: Mon, 29 Nov 2010 09:02:09 -0800 Subject: [Bro-Dev] Tarballs In-Reply-To: <1825848.530.1291049368535.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <20101117181428.GA24922@icir.org> <1825848.530.1291049368535.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20101129170209.GK84349@icir.org> On Mon, Nov 29, 2010 at 10:49 -0600, you wrote: > I think maybe the broctl source package wouldn't need to include > broccoli since that's got it's own? Yeah, sounds right. > Do you anticipate broccoli & broctl frequently having releases not > in sync w/ bro? For broctl, yes, that I expect regular independent releases. As broctl sits mostly on top of the core Bro, it can be extended without touching Bro itself and there are number of things for broctl on our todo list. For broccoli, the reason is a different one: it's something that can be installed on systems that are not running Bro themselves but merely *talk* to a Bro system. For example, if some site wants to have all their syslogs to forward to Bro, they'll need t install Broccoli evyerywhere. Having a separate source distrubution for that seems useful. > Yeah, I think distributions will likely put finer grained packages > in their repositories, but personally, if I were downloading a > prebuilt package from the website, I'd rather just download a single > RPM, DEB, OS X installer, etc, that has everything I should ever > need. Same here, but I think the arguments above apply here as well: would be nice to be able to update broctl separately, and to install broccoli indepedently of anything else. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From jsiwek at ncsa.illinois.edu Mon Nov 29 10:53:34 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Mon, 29 Nov 2010 12:53:34 -0600 (CST) Subject: [Bro-Dev] Tarballs In-Reply-To: <20101129170209.GK84349@icir.org> Message-ID: <15825193.588.1291056809284.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > > I think maybe the broctl source package wouldn't need to include > > broccoli since that's got it's own? > > Yeah, sounds right. Alright. I think CMake/CPack can be made to behave and produce this package structure. > > I'd rather just download a single RPM, DEB, OS X installer, etc, that has > > everything I should ever need. > > Same here, but I think the arguments above apply here as well: would > be nice to be able to update broctl separately, and to install > broccoli indepedently of anything else. Sounds good; I'll agree that the binary packages can mimic the source ones. Want to decide what formats of binary packages to provide? I think I can claim that DEB, RPM, Mac PackageMaker, and tarball formats are possible by relying on CPack, but it looks a little ugly... For generating RPMs, it's difficult to get full control of package metadata (description, license, maintainer name/email), so the package might not look so professional. For generating DEBs, the package dependencies will not be set automatically, so CPack is basically unusable. As a workaround, "alien" can be used to generate a DEB from RPM w/ correct dependencies, but again it's difficult to get control of metadata. For Mac PackageMaker or tarball formats, one deficiency I remember is that you can't unpack to just any directory and have bro work because the default policy search dirs are set at compile time. Also, with tarballs we'd probably have to link all the dependencies statically; with PackageMaker, vanilla OS X comes with all required dependencies and I think it's sufficient to just ship the optional ones with the package. Given that description, how comfortable are you with relying on CPack to make RPMs (converted to DEBs via alien) and Mac PackageMaker binary packages? From robin at icir.org Mon Nov 29 11:43:38 2010 From: robin at icir.org (Robin Sommer) Date: Mon, 29 Nov 2010 11:43:38 -0800 Subject: [Bro-Dev] Tarballs In-Reply-To: <15825193.588.1291056809284.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <20101129170209.GK84349@icir.org> <15825193.588.1291056809284.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20101129194338.GE96774@icir.org> On Mon, Nov 29, 2010 at 12:53 -0600, you wrote: > I think I can claim that DEB, RPM, Mac PackageMaker, and tarball > formats are possible by relying on CPack, but it looks a little > ugly... By tarballs, you mean tarballs of binaries, right? I'm actually not sure we need those. Let's skip if nobody objects. Let's do just generic RPMs and Mac PackageMaker (and source tarballs of course). No problem if the RPMs don't look perfect as long as they *work* fine at least on a standard RedHat system. In addition, let's then work with others to tailor to distributions (and rely on their judgement in terms of what the best solution is build those packages): - Justin for DEB. - "Real" RPMs whenever we find somebody willing to do them for some distribution. - Craig Leres, of LBL, for FreeBSD ports. He has offered to help with that when I talked to him last week. I'll get you in touch with him when you think you are ready for that. > For Mac PackageMaker or tarball formats, one deficiency I remember > is that you can't unpack to just any directory and have bro work > because the default policy search dirs are set at compile time. Shouldn't be a problem for the Mac packages as they will install into a predefined location, won't they? > with PackageMaker, vanilla OS X comes with all required dependencies > and I think it's sufficient to just ship the optional ones with the > package. Sounds good. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From slagell at ncsa.illinois.edu Mon Nov 29 11:46:44 2010 From: slagell at ncsa.illinois.edu (Adam Slagell) Date: Mon, 29 Nov 2010 13:46:44 -0600 (CST) Subject: [Bro-Dev] Tarballs In-Reply-To: <20101129194338.GE96774@icir.org> References: <20101129170209.GK84349@icir.org> <15825193.588.1291056809284.JavaMail.jsiwek@tangent.ncsa.illinois.edu> <20101129194338.GE96774@icir.org> Message-ID: <2F91063C-7BD9-45B7-84FF-3BBA65D0CC4C@ncsa.illinois.edu> I think what was meant is source tarballs as opposed to getting source through git. Sent from my mobile On Nov 29, 2010, at 1:43 PM, Robin Sommer wrote: > > By tarballs, you mean tarballs of binaries, right? I'm actually not > sure we need those. Let's skip if nobody objects. From robin at icir.org Mon Nov 29 11:51:04 2010 From: robin at icir.org (Robin Sommer) Date: Mon, 29 Nov 2010 11:51:04 -0800 Subject: [Bro-Dev] Tarballs In-Reply-To: <2F91063C-7BD9-45B7-84FF-3BBA65D0CC4C@ncsa.illinois.edu> References: <20101129170209.GK84349@icir.org> <15825193.588.1291056809284.JavaMail.jsiwek@tangent.ncsa.illinois.edu> <20101129194338.GE96774@icir.org> <2F91063C-7BD9-45B7-84FF-3BBA65D0CC4C@ncsa.illinois.edu> Message-ID: <20101129195104.GG96774@icir.org> On Mon, Nov 29, 2010 at 13:46 -0600, you wrote: > I think what was meant is source tarballs as opposed to getting source through git. Oh, ok, but then I don't understand the point about static linking. Why would that matter for a source distribution? I must be missing something. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From bro at tracker.icir.org Mon Nov 29 12:09:46 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 29 Nov 2010 20:09:46 -0000 Subject: [Bro-Dev] #11: Remove global_attr from the script interpreter code In-Reply-To: <044.8ca53fddbbe56ab0f6995438eeb91750@tracker.icir.org> References: <044.8ca53fddbbe56ab0f6995438eeb91750@tracker.icir.org> Message-ID: <059.076320cbd3c75a2f25bbc985036a286e@tracker.icir.org> #11: Remove global_attr from the script interpreter code ---------------------+--------------------------------- Reporter: robin | Owner: robin Type: Task | Status: accepted Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: branches-robin-work Resolution: | Keywords: ---------------------+--------------------------------- Changes (by seth): * milestone: => Bro1.6 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 29 12:12:55 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 29 Nov 2010 20:12:55 -0000 Subject: [Bro-Dev] #30: Drop logic doesn't pass reason to external script In-Reply-To: <054.61132df179425195eaf6438893877fa1@tracker.icir.org> References: <054.61132df179425195eaf6438893877fa1@tracker.icir.org> Message-ID: <069.9213cd23d3f4b05347ff2f7af1b394fb@tracker.icir.org> #30: Drop logic doesn't pass reason to external script ------------------------------+------------------------------- Reporter: rreitz@? | Owner: Type: Problem | Status: seen Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: branch-robin-work Resolution: | Keywords: ------------------------------+------------------------------- Changes (by seth): * milestone: => Bro1.6 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 29 12:15:02 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 29 Nov 2010 20:15:02 -0000 Subject: [Bro-Dev] #33: Broccoli: race condition during concurrent connection intialization In-Reply-To: <047.1ee615ac6eaf308bdebdef0899f5f5fb@tracker.icir.org> References: <047.1ee615ac6eaf308bdebdef0899f5f5fb@tracker.icir.org> Message-ID: <062.32ca49d44182c43ce6fccd0ae530b24a@tracker.icir.org> #33: Broccoli: race condition during concurrent connection intialization -----------------------+---------------------- Reporter: vallenti | Owner: kreibich Type: Problem | Status: accepted Priority: Normal | Milestone: Component: Broccoli | Version: 1.4 Resolution: | Keywords: -----------------------+---------------------- Comment (by seth): Was this ever tested enough to safely merge? -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Nov 29 12:18:40 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 29 Nov 2010 20:18:40 -0000 Subject: [Bro-Dev] #263: --enable-int64 breaks bropipe In-Reply-To: <054.219dc84b03152af2576e2b066da16f7a@tracker.icir.org> References: <054.219dc84b03152af2576e2b066da16f7a@tracker.icir.org> Message-ID: <069.d83f05680a67347f3d3e1a74944b6032@tracker.icir.org> #263: --enable-int64 breaks bropipe ------------------------------+----------------------- Reporter: ssakai@? | Owner: christian Type: defect | Status: assigned Priority: Low | Milestone: Bro1.6 Component: Bro | Version: 1.5.1 Resolution: | Keywords: ------------------------------+----------------------- Changes (by seth): * owner: => christian * status: new => assigned * milestone: => Bro1.6 Comment: Assigning this ticket to Christian at the moment to see if he has time to make Broccoli support 64 bit ints. This change will **need** to happen for the 1.6 release of Bro since 1.6 will always have 64-bit ints enabled. -- Ticket URL: Bro Tracker Bro Issue Tracker From slagell at ncsa.illinois.edu Mon Nov 29 12:22:29 2010 From: slagell at ncsa.illinois.edu (Adam J. Slagell) Date: Mon, 29 Nov 2010 14:22:29 -0600 Subject: [Bro-Dev] Tarballs In-Reply-To: <20101129195104.GG96774@icir.org> References: <20101129170209.GK84349@icir.org> <15825193.588.1291056809284.JavaMail.jsiwek@tangent.ncsa.illinois.edu> <20101129194338.GE96774@icir.org> <2F91063C-7BD9-45B7-84FF-3BBA65D0CC4C@ncsa.illinois.edu> <20101129195104.GG96774@icir.org> Message-ID: <8821FC57-B5FF-4D6A-AF41-300C05EEAD1E@ncsa.illinois.edu> On Nov 29, 2010, at 1:51 PM, Robin Sommer wrote: >> >> I think what was meant is source tarballs as opposed to getting source through git. > > Oh, ok, but then I don't understand the point about static linking. > Why would that matter for a source distribution? I must be missing > something. I could be the confused one. I'll let Jon clarify, but I agree binary tarballs aren't needed. ------ Adam J. Slagell, CISSP Sr. Security Engineer National Center for Supercomputing Applications University of Illinois at Urbana-Champaign www.slagell.info 217.244.8965 From bro at tracker.icir.org Mon Nov 29 12:37:48 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 29 Nov 2010 20:37:48 -0000 Subject: [Bro-Dev] #33: Broccoli: race condition during concurrent connection intialization In-Reply-To: <047.1ee615ac6eaf308bdebdef0899f5f5fb@tracker.icir.org> References: <047.1ee615ac6eaf308bdebdef0899f5f5fb@tracker.icir.org> Message-ID: <062.783800ec90b15be87c679e6440c52e69@tracker.icir.org> #33: Broccoli: race condition during concurrent connection intialization -----------------------+---------------------- Reporter: vallenti | Owner: kreibich Type: Problem | Status: accepted Priority: Normal | Milestone: Component: Broccoli | Version: 1.4 Resolution: | Keywords: -----------------------+---------------------- Comment (by vallenti): I haven't had any trouble since that fix. AFAIK this change has already been merged into trunk. Is that right, Christian? -- Ticket URL: Bro Tracker Bro Issue Tracker From jsiwek at ncsa.illinois.edu Mon Nov 29 12:59:25 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Mon, 29 Nov 2010 14:59:25 -0600 (CST) Subject: [Bro-Dev] Tarballs In-Reply-To: <20101129194338.GE96774@icir.org> Message-ID: <15690416.646.1291064364634.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > By tarballs, you mean tarballs of binaries, right? I'm actually not > sure we need those. Let's skip if nobody objects. Right; I agree to skip. > Let's do just generic RPMs and Mac PackageMaker (and source tarballs > of course). No problem if the RPMs don't look perfect as long as > they *work* fine at least on a standard RedHat system. Ok. > > For Mac PackageMaker or tarball formats, one deficiency I remember > > is that you can't unpack to just any directory and have bro work > > because the default policy search dirs are set at compile time. > > Shouldn't be a problem for the Mac packages as they will install > into a predefined location, won't they? The user gets a choice if they have more than one volume. > > with PackageMaker, vanilla OS X comes with all required dependencies > > and I think it's sufficient to just ship the optional ones with the > > package. > > Sounds good. Instead of shipping optional libs w/ Mac package, this changed to linking statically for optional libs (libmagic, libgeoip, google perftools) as per other thread. - Jon From jsiwek at ncsa.illinois.edu Mon Nov 29 13:00:10 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Mon, 29 Nov 2010 15:00:10 -0600 (CST) Subject: [Bro-Dev] Tarballs In-Reply-To: <8821FC57-B5FF-4D6A-AF41-300C05EEAD1E@ncsa.illinois.edu> Message-ID: <28948544.648.1291064409209.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > I could be the confused one. I'll let Jon clarify, but I agree binary > tarballs aren't needed. I did mean binary tarballs. Sorry for the confusion; I just added them in for completeness. - Jon From robin at icir.org Mon Nov 29 13:11:45 2010 From: robin at icir.org (Robin Sommer) Date: Mon, 29 Nov 2010 13:11:45 -0800 Subject: [Bro-Dev] Tarballs In-Reply-To: <15690416.646.1291064364634.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <20101129194338.GE96774@icir.org> <15690416.646.1291064364634.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20101129211145.GA1593@icir.org> On Mon, Nov 29, 2010 at 14:59 -0600, you wrote: > The user gets a choice if they have more than one volume. Good point. We could: - move bro to, say, bro.bin, and do a wrapper script bro that presets BROPATH. - simply tell the user that it's configured for a standard location and the user needs to set BROPATH if he wants something else. Just the latter is probably fine if we can point that out easily somehow. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From jsiwek at ncsa.illinois.edu Mon Nov 29 14:00:22 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Mon, 29 Nov 2010 16:00:22 -0600 (CST) Subject: [Bro-Dev] Tarballs In-Reply-To: <20101129211145.GA1593@icir.org> Message-ID: <6714809.652.1291068019852.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > - simply tell the user that it's configured for a standard location > and the user needs to set BROPATH if he wants something else. > > Just the latter is probably fine if we can point that out easily > somehow. Ok, pointing it out on the website as well as in a specific README that gets displayed as part of the PackageMaker install process should probably cover it. - Jon From gregor at icir.org Mon Nov 29 14:44:47 2010 From: gregor at icir.org (Gregor Maier) Date: Mon, 29 Nov 2010 14:44:47 -0800 Subject: [Bro-Dev] #207: Small bug in file rotate+setbuf In-Reply-To: <060.1f5c266596dc5b820fd3711a351fa9df@tracker.icir.org> References: <045.779bbc363dd741be852d73b1db8681ec@tracker.icir.org> <060.1f5c266596dc5b820fd3711a351fa9df@tracker.icir.org> Message-ID: <4CF42CDF.10406@icir.org> > My thought was that we would just put those few changes into 1.5.2 that > prevent Bro from compiling easily. I haven't heard a lot of people > complaining about problems with this so it seemed like it would be ok to > wait until 1.6. ACK, but YMMV cu Gregor -- Gregor Maier gregor at icir.org Int. Computer Science Institute (ICSI) gregor at icsi.berkeley.edu 1947 Center St., Ste. 600 http://www.icir.org/gregor/ Berkeley, CA 94704 USA From bro at tracker.icir.org Mon Nov 29 14:51:03 2010 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 29 Nov 2010 22:51:03 -0000 Subject: [Bro-Dev] #263: --enable-int64 breaks bropipe In-Reply-To: <054.219dc84b03152af2576e2b066da16f7a@tracker.icir.org> References: <054.219dc84b03152af2576e2b066da16f7a@tracker.icir.org> Message-ID: <069.10266a257ff346bd8aa12abf74c07781@tracker.icir.org> #263: --enable-int64 breaks bropipe ------------------------------+----------------------- Reporter: ssakai@? | Owner: christian Type: defect | Status: assigned Priority: Low | Milestone: Bro1.6 Component: Bro | Version: 1.5.1 Resolution: | Keywords: inttypes ------------------------------+----------------------- Changes (by gregor): * keywords: => inttypes -- Ticket URL: Bro Tracker Bro Issue Tracker From gregor at icir.org Mon Nov 29 14:57:09 2010 From: gregor at icir.org (Gregor Maier) Date: Mon, 29 Nov 2010 14:57:09 -0800 Subject: [Bro-Dev] Tarballs In-Reply-To: <15825193.588.1291056809284.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <15825193.588.1291056809284.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <4CF42FC5.1050105@icir.org> > For generating RPMs, it's difficult to get full control of package metadata (description, license, maintainer name/email), so the package might not look so professional. > > For generating DEBs, the package dependencies will not be set automatically, so CPack is basically unusable. As a workaround, "alien" can be used to generate a DEB from RPM w/ correct dependencies, but again it's difficult to get control of metadata. I would think that once we have the meta-data framework for deb and rpm, we won't need to really touch them, right. So supporting deb and rpm even without CPack seems to be a do-once task, right? Or am I missing something? cu Gregor -- Gregor Maier gregor at icir.org Int. Computer Science Institute (ICSI) gregor at icsi.berkeley.edu 1947 Center St., Ste. 600 http://www.icir.org/gregor/ Berkeley, CA 94704 USA From jsiwek at ncsa.illinois.edu Mon Nov 29 16:07:38 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Mon, 29 Nov 2010 18:07:38 -0600 (CST) Subject: [Bro-Dev] Tarballs In-Reply-To: <4CF42FC5.1050105@icir.org> Message-ID: <2075984724.6136.1291075658761.JavaMail.root@zimbra-1.ncsa.uiuc.edu> > I would think that once we have the meta-data framework for deb and rpm, > we won't need to really touch them, right. So supporting deb and rpm > even without CPack seems to be a do-once task, right? > Or am I missing something? I think that's right, but don't quote me. Having CPack generate packages is just theoretically easier and less overall work (although that's debatable because it's poorly documented and hard to figure out sometimes) if you're not worried about fine-tuning things. So since it seems we want to delegate the worry of fine-tuning to per-platform maintainers and I already went through the pain of figuring out CPack, we might just go ahead and use it to create packages for our own purposes. Even if we went outside CPack to construct a meta-data framework, it's questionable how much of it would be re-usable by per-platform maintainers -- our binary packaging setup probably has too much clumped into each package (e.g. even broccoli python bindings might need to be split out into its own package, distinct from broccoli). - Jon From gregor at icir.org Mon Nov 29 17:02:09 2010 From: gregor at icir.org (Gregor Maier) Date: Mon, 29 Nov 2010 17:02:09 -0800 Subject: [Bro-Dev] FYI: Bro test suite fails with diff in FTP output Message-ID: <4CF44D11.3070903@icir.org> Hi, FYI: I just noticed that the bro test suite fails with the current trunk. Seems like the FTP analyzer output changed. cu gregor -- Gregor Maier gregor at icir.org Int. Computer Science Institute (ICSI) gregor at icsi.berkeley.edu 1947 Center St., Ste. 600 http://www.icir.org/gregor/ Berkeley, CA 94704 USA From vern at icir.org Mon Nov 29 17:06:57 2010 From: vern at icir.org (Vern Paxson) Date: Mon, 29 Nov 2010 17:06:57 -0800 Subject: [Bro-Dev] FYI: Bro test suite fails with diff in FTP output In-Reply-To: <4CF44D11.3070903@icir.org> (Mon, 29 Nov 2010 17:02:09 PST). Message-ID: <20101130010657.BD4C336A428@taffy.ICSI.Berkeley.EDU> > I just noticed that the bro test suite fails with the current trunk. You mean 1.5.2.10? It worked for me this weekend (I checked prior to committing the new stuff). What system are you running on? Vern From gregor at icir.org Mon Nov 29 17:12:55 2010 From: gregor at icir.org (Gregor Maier) Date: Mon, 29 Nov 2010 17:12:55 -0800 Subject: [Bro-Dev] FYI: Bro test suite fails with diff in FTP output In-Reply-To: <20101130010657.BD4C336A428@taffy.ICSI.Berkeley.EDU> References: <20101130010657.BD4C336A428@taffy.ICSI.Berkeley.EDU> Message-ID: <4CF44F97.7090207@icir.org> On 11/29/10 17:06 , Vern Paxson wrote: >> I just noticed that the bro test suite fails with the current trunk. > > You mean 1.5.2.10? yes. > It worked for me this weekend (I checked prior to > committing the new stuff). What system are you running on? That was on ashcloud. Do I need to use any particular configure options? I just used a "plain" configure without any options.... cu Gregor -- Gregor Maier gregor at icir.org Int. Computer Science Institute (ICSI) gregor at icsi.berkeley.edu 1947 Center St., Ste. 600 http://www.icir.org/gregor/ Berkeley, CA 94704 USA From vern at icir.org Mon Nov 29 17:16:33 2010 From: vern at icir.org (Vern Paxson) Date: Mon, 29 Nov 2010 17:16:33 -0800 Subject: [Bro-Dev] FYI: Bro test suite fails with diff in FTP output In-Reply-To: <4CF44F97.7090207@icir.org> (Mon, 29 Nov 2010 17:12:55 PST). Message-ID: <20101130011633.8E8F736A4EA@taffy.ICSI.Berkeley.EDU> > That was on ashcloud. > Do I need to use any particular configure options? I just used a "plain" > configure without any options.... You shouldn't. I'll take a look at this. Vern From vern at icir.org Mon Nov 29 19:20:08 2010 From: vern at icir.org (Vern Paxson) Date: Mon, 29 Nov 2010 19:20:08 -0800 Subject: [Bro-Dev] FYI: Bro test suite fails with diff in FTP output In-Reply-To: <4CF44F97.7090207@icir.org> (Mon, 29 Nov 2010 17:12:55 PST). Message-ID: <20101130032008.3332736A415@taffy.ICSI.Berkeley.EDU> > That was on ashcloud. > Do I need to use any particular configure options? I just used a "plain" > configure without any options.... Okay, I've tracked this down. The problem is that my Mac environments have support for libmagic, while ashcloud does not. So when the test suite was generated, it had file-type identification, but when run on ashcloud, the results don't. I'm inclined not to fix this right now, since I gather the plan is to revamp the whole testing framework. If I'm wrong about that, though, then we need to brainstorm about the best fix. Vern From robin at icir.org Mon Nov 29 22:05:17 2010 From: robin at icir.org (Robin Sommer) Date: Mon, 29 Nov 2010 22:05:17 -0800 Subject: [Bro-Dev] FYI: Bro test suite fails with diff in FTP output In-Reply-To: <20101130032008.3332736A415@taffy.ICSI.Berkeley.EDU> References: <4CF44F97.7090207@icir.org> <20101130032008.3332736A415@taffy.ICSI.Berkeley.EDU> Message-ID: <20101130060517.GH21444@icir.org> On Mon, Nov 29, 2010 at 19:20 -0800, you wrote: > I'm inclined not to fix this right now, since I gather the plan is to > revamp the whole testing framework. Yes, makes sense. A quick hack we could perhaps still do is add at least a warning flagging that Bro is running with a different configure set than when the baseline was generated. Shouldn't be too difficult by comparing relevant pieces of config.h . Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From vern at icir.org Mon Nov 29 22:54:54 2010 From: vern at icir.org (Vern Paxson) Date: Mon, 29 Nov 2010 22:54:54 -0800 Subject: [Bro-Dev] FYI: Bro test suite fails with diff in FTP output In-Reply-To: <20101130060517.GH21444@icir.org> (Mon, 29 Nov 2010 22:05:17 PST). Message-ID: <20101130065453.F032636A415@taffy.ICSI.Berkeley.EDU> > A quick hack we could perhaps still do is add at least a warning > flagging that Bro is running with a different configure set than > when the baseline was generated. Shouldn't be too difficult by > comparing relevant pieces of config.h . That's a good thought. These config-based differences can eat up a bunch of time if unrecognized as such. Vern From juhoon at net.t-labs.tu-berlin.de Tue Nov 30 04:24:26 2010 From: juhoon at net.t-labs.tu-berlin.de (Juhoon Kim) Date: Tue, 30 Nov 2010 13:24:26 +0100 Subject: [Bro-Dev] TCP RTT estimation Message-ID: <1291119866.13548.57.camel@jkim> Hi all, I'm planning to start a new branch in which I want to modify Katrina's rtt-branch. The reason is to measure RTT in a different way. The idea what I have about RTT is measuring a gap between the time a segment is seen and the time a segment directly after the corresponding ack is seen in the monitoring point. I'm wondering if somebody is working on this at the moment or anybody already tried this. Juhoon From vern at icir.org Tue Nov 30 08:01:40 2010 From: vern at icir.org (Vern Paxson) Date: Tue, 30 Nov 2010 08:01:40 -0800 Subject: [Bro-Dev] TCP RTT estimation In-Reply-To: <1291119866.13548.57.camel@jkim> (Tue, 30 Nov 2010 13:24:26 +0100). Message-ID: <20101130160140.33B8F36A4ED@taffy.ICSI.Berkeley.EDU> > The idea what I have about RTT is measuring a gap between the time a > segment is seen and the time a segment directly after the corresponding > ack is seen in the monitoring point. Can you sketch in more detail (with an example) what you have in mind? (I've been down this path in the past, and it gets pretty complex!) Also, what's your ultimate goal: path/performance characterization? Katrina's is more focused on trouble-shooting, so finding exceptional values rather than (for example) accurately tracking the RTO computation. Vern From jsiwek at ncsa.illinois.edu Tue Nov 30 13:47:31 2010 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Tue, 30 Nov 2010 15:47:31 -0600 (CST) Subject: [Bro-Dev] Masters updated In-Reply-To: <20101128044744.GB75232@icir.org> Message-ID: <1371758317.6239.1291153651929.JavaMail.root@zimbra-1.ncsa.uiuc.edu> > We should now see if master is working for everybody. If you want to merge topic/cmake-port across the board into master again there's fixes to add CMake 2.6 compatibility and remove the fiddling of install_name on optional darwin libs. - Jon From gregor at icir.org Tue Nov 30 14:33:46 2010 From: gregor at icir.org (Gregor Maier) Date: Tue, 30 Nov 2010 14:33:46 -0800 Subject: [Bro-Dev] NFS and portmapper Message-ID: <4CF57BCA.6060608@icir.org> Hi, I was wondering whether the Portmapper code can/will activate the NFS analyzer for dynamically negotiated NFS ports. Looking at portmap.bro and nfs.bro I don't see anything along those lines, but I would have expected it. Am I missing something or is this something that bro can't do? cu gregor -- Gregor Maier gregor at icir.org Int. Computer Science Institute (ICSI) gregor at icsi.berkeley.edu 1947 Center St., Ste. 600 http://www.icir.org/gregor/ Berkeley, CA 94704 USA From boris.nechaev at hiit.fi Tue Nov 30 19:42:05 2010 From: boris.nechaev at hiit.fi (Boris Nechaev) Date: Tue, 30 Nov 2010 19:42:05 -0800 Subject: [Bro-Dev] Weird behavior in Katrina's code. Message-ID: <4CF5C40D.9020108@hiit.fi> Hello, I've noticed weird behavior in Katrina's code. For the following connection (the format is ) 1266506673.653157 ip1 port1 ip2 port2 60 0 888448966 0 S 1266506673.653530 ip2 port2 ip1 port1 40 0 1921250427 888448967 RA 1266506676.651348 ip1 port1 ip2 port2 60 0 888448966 0 S 1266506676.651708 ip2 port2 ip1 port1 40 0 570721244 888448967 RA 1266506682.651195 ip1 port1 ip2 port2 60 0 888448966 0 S 1266506682.651622 ip2 port2 ip1 port1 40 0 1779909088 888448967 RA 1266506694.651297 ip1 port1 ip2 port2 60 0 888448966 0 S 1266506694.651669 ip2 port2 ip1 port1 40 0 2051408459 888448967 RA 1266506718.651252 ip1 port1 ip2 port2 60 0 888448966 0 S 1266506718.651676 ip2 port2 ip1 port1 60 0 3793171500 888448967 SA 1266506718.654752 ip1 port1 ip2 port2 52 0 888448967 3793171501 A 1266506722.256532 ip2 port2 ip1 port1 53 1 3793171501 888448967 PA 1266506722.259266 ip1 port1 ip2 port2 52 0 888448967 3793171502 A 1266506722.260621 ip1 port1 ip2 port2 53 1 888448967 3793171502 PA 1266506722.260981 ip2 port2 ip1 port1 52 0 3793171502 888448968 A 1266506722.261452 ip2 port2 ip1 port1 84 32 3793171502 888448968 PA 1266506722.300346 ip1 port1 ip2 port2 53 1 888448968 3793171534 PA 1266506722.307635 ip1 port1 ip2 port2 52 0 888448969 3793171534 FA 1266506722.340965 ip2 port2 ip1 port1 52 0 3793171534 888448970 A 1266506722.551004 ip2 port2 ip1 port1 52 0 3793171534 888448970 FA 1266506722.554092 ip1 port1 ip2 port2 52 0 888448970 3793171535 A Katrina's code with conn.bro script produces: 1266506673.653157 48.654478 ip1 ip2 port1 port2 tcp 2 1871921106 RSTR X SrrrrhAdDaFf While trunk Bro 1.5.1 produces the following (correct) output: 1266506673.653157 0.000373 ip1 ip2 other port1 port2 tcp ? ? REJ X Sr 1266506676.651348 0.000360 ip1 ip2 other port1 port2 tcp ? ? REJ X Sr 1266506682.651195 0.000427 ip1 ip2 other port1 port2 tcp ? ? REJ X Sr 1266506694.651297 0.000372 ip1 ip2 other port1 port2 tcp ? ? REJ X Sr 1266506718.651252 3.899752 ip1 ip2 other port1 port2 tcp 2 33 SF X ShAdDaFf In both cases connection compressor is off. The byte count 1871921106 in Katrina's case is the seq number in FIN packet 3793171534 minus seq number 1921250427 announced by ip2 in its first reset, i.e. the code somehow thinks that it's the same connection. Any thoughts on why this happens? -- Best regards, Boris Nechaev.