From bro at tracker.icir.org Tue Jan 4 10:13:32 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 04 Jan 2011 18:13:32 -0000 Subject: [Bro-Dev] #296: Convert build process to CMake In-Reply-To: <043.2b75dde89b11f20f75673a8bcbafdc27@tracker.icir.org> References: <043.2b75dde89b11f20f75673a8bcbafdc27@tracker.icir.org> Message-ID: <058.67332f270051c8001eeb2b03596ae96c@tracker.icir.org> #296: Convert build process to CMake ---------------------+-------------------- Reporter: seth | Owner: Type: Task | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: Solved | Keywords: ---------------------+-------------------- Changes (by jsiwek): * status: new => closed * resolution: => Solved Comment: A working CMake build is available as of log:/bro at d24f7a6aade288e9f4856b8d1d4eaf9dfda2308 (on master branch) Key CHANGES: * Autotools build framework completely removed * aux/ components are all enabled for build/install by default, configure script provides --disable options * --disable-select-loop configure option removed as well as the code backing it * --enable-activemapping configure option removed (code not removed yet, see #325) * --enable-expire-dfa-states configure option removed (code not removed yet, see #324) * --with-dag configure option removed as well as the code backing it (see #309 about working w/ Endace to support this option again) * --disable-nbdns configure option removed as well as code backing it * --enable-int64 configure option removed (it will be on by default, see {13} for related tasks) * --enable-shippedpcap configure option removed and Bro no longer ships with pcap * ClamAV support removed (the API that Bro needed is now gone) * byacc support removed leaving bison as the only supported parser generator * OpenSSL is now a requirement to build Bro * Changes to Broctl to make its installation independent from the Bro and Broctl distribution source location * Running Bro from the build directory now requires an extra helper script to set the right BROPATH (see INSTALL or bro-path-dev.in files) -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 4 11:14:55 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 04 Jan 2011 19:14:55 -0000 Subject: [Bro-Dev] #344: Provide Source Packages via CMake/CPack Message-ID: <045.1859fda35d64b44f7d47cb8f7fd3d7f9@tracker.icir.org> #344: Provide Source Packages via CMake/CPack --------------------+-------------------- Reporter: jsiwek | Owner: jsiwek Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | --------------------+-------------------- For distribution on a webserver maintained by Bro developers, the following source (TGZ) packages should be possible to produce through CMake or CPack: * bro-a.b.c * bro.git * binpac.git * bro-aux.git * broccoli-d.e.f * broccoli.git * broccoli-python.git * broctl-g.h.i * broctl.git * capstats.git * trace-summary.git * pysubnettree.git * bro-all-a.b.c (using Bro's version number). * All repos (except bro-scripts.git) Additionally a source package of user contributed policy scripts should be possible (this repository currently doesn't exist): * bro-scripts- * bro-scripts.git -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 4 11:38:07 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 04 Jan 2011 19:38:07 -0000 Subject: [Bro-Dev] #345: trace-summary topic/jsiwek/misc-fixes Message-ID: <045.5a3efa17208d50cccac12d33fd20d087@tracker.icir.org> #345: trace-summary topic/jsiwek/misc-fixes ---------------------------+------------------------ Reporter: jsiwek | Owner: Type: Merge Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: trace-summary | Version: git/master Keywords: | ---------------------------+------------------------ CHANGES: * Better error message if ipsumdump not installed * Also migrated from os.popen (deprecated since Python 2.6) to subprocess.Popen (available since Python 2.4). -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 4 12:35:57 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 04 Jan 2011 20:35:57 -0000 Subject: [Bro-Dev] #295: Create prebuilt binary packages In-Reply-To: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> References: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> Message-ID: <058.d9760cdec2c76df0ef48d68fab04c84c@tracker.icir.org> #295: Create prebuilt binary packages ----------------------+---------------------- Reporter: seth | Owner: jsiwek Type: Problem | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ----------------------+---------------------- Changes (by jsiwek): * owner: => jsiwek * status: new => assigned Comment: We previously decided on the bro-dev list that we should initially create: * RPMs that work on at least !RedHat and I would think that it's beneficial to provide both x86 and x86-64 support. * Mac !PackageMaker packages. Supporting Intel x86 and x86-64 can be done in a single package with universal binary format (excluding PowerPC). OS X 10.5 should be the minimum version. After those are finished, then we can work with others to tailor to specific distributions and maintain packages for the following formats: * DEB (possibly Justin Azoff) * RPM (no candidates yet) * FreeBSD ports (possibly Crag Leres of LBL) -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 4 12:38:42 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 04 Jan 2011 20:38:42 -0000 Subject: [Bro-Dev] #295: Create prebuilt binary packages In-Reply-To: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> References: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> Message-ID: <058.43b9e917b18a87d773d77511dd4580ac@tracker.icir.org> #295: Create prebuilt binary packages ----------------------+---------------------- Reporter: seth | Owner: jsiwek Type: Problem | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ----------------------+---------------------- Comment (by jsiwek): The binary packages we initially create/provide will follow the same structure as the source packages (see #344) -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 4 19:04:25 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 05 Jan 2011 03:04:25 -0000 Subject: [Bro-Dev] #345: trace-summary topic/jsiwek/misc-fixes In-Reply-To: <045.5a3efa17208d50cccac12d33fd20d087@tracker.icir.org> References: <045.5a3efa17208d50cccac12d33fd20d087@tracker.icir.org> Message-ID: <060.d3e71117e748423e97add88b0cde576e@tracker.icir.org> #345: trace-summary topic/jsiwek/misc-fixes ----------------------------+------------------------ Reporter: jsiwek | Owner: Type: Merge Request | Status: closed Priority: Normal | Milestone: Bro1.6 Component: trace-summary | Version: git/master Resolution: Merged | Keywords: ----------------------------+------------------------ Changes (by robin): * status: new => closed * resolution: => Merged -- Ticket URL: Bro Tracker Bro Issue Tracker From seth at icir.org Wed Jan 5 10:19:15 2011 From: seth at icir.org (Seth Hall) Date: Wed, 5 Jan 2011 13:19:15 -0500 Subject: [Bro-Dev] Script review: FTP Message-ID: <29A477E5-8825-42FF-8C2E-1088A223704F@icir.org> Welcome to the first script review period everyone! We are going to start with a single script/analyzer combination to get things started gently and we may just stick to this model because after discussing things a bit more we decided that we are going to skip these public comment periods for many Bro scripts that are less user visible and we'll just make changes to them. The FTP analyzer and ftp.bro script combination seems like a good place to start because it's mostly self contained and the feature requests shouldn't be quite as crazy and complex as for the HTTP analyzer and scripts. :) The ftp-ext.bro script that is still in my personal repository can be considered to be included in this review period too. https://github.com/sethhall/bro_scripts/blob/master/ftp-ext.bro Here we go.... FTP Analyzer and ftp.bro ==================== Related scripts: ftp-cmd-arg.bro http://tracker.icir.org/bro/browser/bro/policy/ftp-cmd-arg.bro ftp.bro http://tracker.icir.org/bro/browser/bro/policy/ftp.bro ftp-ext.bro https://github.com/sethhall/bro_scripts/blob/master/ftp-ext.bro Features: * Integrated with DPD for detecting FTP on any port. * Detects FTP sessions doing SITE exec (using FTP as a shell/terminal) * Detects file related commands using names defined by a regular expression (a file like this /.*sshd\.(tar|tgz).*/ transferred over FTP doesn't look good) * Detects excessively long filenames. * Single line activity logging (in ftp-ext.bro, but currently only logs RETR and STOR actions, this will be expanded) * Detects unexpected FTP data transmissions * Detects privileged ports used for FTP data * Detects Are there any others features that someone might find useful in their environment? The off-port protocol detection, "SITE exec" detection, and activity logging have all been really useful for me at various times, but (like always) I have a sense that someone out there has an idea that they'd like to see implemented that I've never even considered. The only example I can think of off the top of my head as a new feature I'd like to have is something to either positively or negatively alarm on regular expression defined ftp clients (the CLNT command which most clients seem to send). You could either specify FTP clients that are supposed to be used or not to be used connecting inbound or outbound. Actually, we will make sure to feed that into the software detection framework too. Any and all comments and thoughts are welcome. I will be summarizing this discussion somewhere for reference too. Thanks! .Seth -- Seth Hall International Computer Science Institute (Bro) because everyone has a network From bro at tracker.icir.org Wed Jan 5 14:05:07 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 05 Jan 2011 22:05:07 -0000 Subject: [Bro-Dev] #295: Create prebuilt binary packages In-Reply-To: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> References: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> Message-ID: <058.4c4a4e90378c179037b7b51f41450a17@tracker.icir.org> #295: Create prebuilt binary packages ----------------------+---------------------- Reporter: seth | Owner: jsiwek Type: Problem | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ----------------------+---------------------- Comment (by jsiwek): For the Mac package, a build w/ universal binaries containing both i386 and x86_64 is not currently possible because there is code that relies on preprocessor directives (e.g. SIZEOF_VOID_P) whose configuration is dependent on architecture. Meaning CMake wouldn't be able to make the universal binary in one-shot, we'd need to compile specifically for i386, then for x86_64 and combine them manually or with some other scripting. One easy answer is to make two Mac packages, one for i386 and one for x86_64, but since Apple has updated all product lines to 64-bit processors since ~ August 2007, I'm inclined to only make the x86_64 package (still targeting OS X 10.5 minimum). -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 5 14:25:09 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 05 Jan 2011 22:25:09 -0000 Subject: [Bro-Dev] #295: Create prebuilt binary packages In-Reply-To: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> References: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> Message-ID: <058.f95f2d641939f34ae57a475693d32220@tracker.icir.org> #295: Create prebuilt binary packages ----------------------+---------------------- Reporter: seth | Owner: jsiwek Type: Problem | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ----------------------+---------------------- Comment (by robin): > One easy answer is to make two Mac packages, one for i386 and one for > x86_64, but since Apple has updated all product lines to 64-bit processors > since ~ August 2007, I'm inclined to only make the x86_64 package (still > targeting OS X 10.5 minimum). Doesn't it take 10.6 to run 64-bit binaries? Or do I misrember that? If they run on 10.5, I'm fine with doing just one version; otherwise I'd prefer two packages. Robin -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 5 14:35:16 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 05 Jan 2011 22:35:16 -0000 Subject: [Bro-Dev] #295: Create prebuilt binary packages In-Reply-To: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> References: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> Message-ID: <058.009611688267c95f28f3f3aaac5905a3@tracker.icir.org> #295: Create prebuilt binary packages ----------------------+---------------------- Reporter: seth | Owner: jsiwek Type: Problem | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ----------------------+---------------------- Comment (by jsiwek): Replying to [comment:5 robin]: > Doesn't it take 10.6 to run 64-bit binaries? Or do I misrember that? > If they run on 10.5, I'm fine with doing just one version; otherwise > I'd prefer two packages. 10.6 introduced the ability run a 64-bit kernel, but running 64-bit processes was possible before that (provided you had 64-bit capable hardware). I have a 10.5 system still that I'll be using to make sure it works (a simple test was successful so far). -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 6 10:37:34 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 06 Jan 2011 18:37:34 -0000 Subject: [Bro-Dev] #344: Provide Source Packages via CMake/CPack In-Reply-To: <045.1859fda35d64b44f7d47cb8f7fd3d7f9@tracker.icir.org> References: <045.1859fda35d64b44f7d47cb8f7fd3d7f9@tracker.icir.org> Message-ID: <060.027c85d4ee229da41fa0862ff19c7f57@tracker.icir.org> #344: Provide Source Packages via CMake/CPack ---------------------+-------------------- Reporter: jsiwek | Owner: jsiwek Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ---------------------+-------------------- Comment (by robin): The script repo actually does exist now: http://git.icir.org/bro- scripts.git -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 6 11:00:42 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 06 Jan 2011 19:00:42 -0000 Subject: [Bro-Dev] #344: Provide Source Packages via CMake/CPack In-Reply-To: <045.1859fda35d64b44f7d47cb8f7fd3d7f9@tracker.icir.org> References: <045.1859fda35d64b44f7d47cb8f7fd3d7f9@tracker.icir.org> Message-ID: <060.ec38e0a109d697e01f11962d0364e34d@tracker.icir.org> #344: Provide Source Packages via CMake/CPack ---------------------+-------------------- Reporter: jsiwek | Owner: jsiwek Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ---------------------+-------------------- Comment (by jsiwek): > The script repo actually does exist now: http://git.icir.org/bro- scripts.git Thanks, I missed it... I don't need to incorporate the making of the bro-scripts tarball w/ CMake, right (seems like overkill)? Simply documenting how to make the tarball w/ a timestamp in the name I would think is sufficient. Are we decided on using the timestamp (as in `date "+%Y%m%d"`) for versioning? -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 6 11:10:22 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 06 Jan 2011 19:10:22 -0000 Subject: [Bro-Dev] #344: Provide Source Packages via CMake/CPack In-Reply-To: <045.1859fda35d64b44f7d47cb8f7fd3d7f9@tracker.icir.org> References: <045.1859fda35d64b44f7d47cb8f7fd3d7f9@tracker.icir.org> Message-ID: <060.ca9c431ced10713f4123a90d2879ac2d@tracker.icir.org> #344: Provide Source Packages via CMake/CPack ---------------------+-------------------- Reporter: jsiwek | Owner: jsiwek Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ---------------------+-------------------- Comment (by robin): On Thu, Jan 06, 2011 at 19:00 -0000, you wrote: > I don't need to incorporate the making of the bro-scripts tarball w/ > CMake, right (seems like overkill)? Simply documenting how to make the > tarball w/ a timestamp in the name I would think is sufficient. How about a simple Makefile that does the right thing on "make dist"? > Are we decided on using the timestamp (as in `date "+%Y%m%d"`) for > versioning? Yes, sounds fine. (For the record, the scripts tarball will likely be replaced eventually with somethign else anyway (that's the "CPAN-for-Bro" vision)) -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 6 14:31:36 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 06 Jan 2011 22:31:36 -0000 Subject: [Bro-Dev] #295: Create prebuilt binary packages In-Reply-To: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> References: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> Message-ID: <058.06d975f36c98ad9b55f432ffea1824b5@tracker.icir.org> #295: Create prebuilt binary packages ----------------------+---------------------- Reporter: seth | Owner: jsiwek Type: Problem | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ----------------------+---------------------- Comment (by jsiwek): In general, x86_64 binaries seem to run on 10.5, but when trying to run an x86_64 bro binary (compiled on the same 10.5.8 machine) I see a trace like: {{{ $ BROPATH=`source bro-path-dev` gdb ./src/bro ... (gdb) run Starting program: /Users/jsiwek/Projects/bro/bro/build/src/bro warning: posix_spawn failed, trying execvp, error: 86 Reading symbols for shared libraries ++++++++. done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff808ed209 0x00007fff843466bd in res_build_start () (gdb) where #0 0x00007fff843466bd in res_build_start () #1 0x00007fff84347483 in res_9_vinit () #2 0x00000001001ab215 in nb_dns_init (errstr=0x7fff5fbfea90 "###") at /Users/jsiwek/Projects/bro/bro/src/nb_dns.c:133 #3 0x0000000100092635 in DNS_Mgr::DNS_Mgr (this=0x100808200, arg_mode=DNS_DEFAULT) at /Users/jsiwek/Projects/bro/bro/src/DNS_Mgr.cc:350 #4 0x000000010006046b in main (argc=53, argv=0x7fff5fbff098) at /Users/jsiwek/Projects/bro/bro/src/main.cc:709 }}} An i386 bro binary works on 10.5. I'm thinking that something's wrong with the x86_64 libresolv.dylib on 10.5 -- googling around I see traces for a couple other 64-bit applications that crap out in the same spot in libresolv on OS X 10.5, but no answers/solutions. I don't have a strong urge to investigate further, so it may be that we have to make an i386 package for 10.5+ and an x86_64 package for 10.6+. We should probably consider this again at the time we're ready for a bro 1.6 release -- maybe we want to make it a habit to only make packages for OS versions currently supported by Apple, which may be 10.6 and 10.7 by the time we're ready. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 6 14:36:38 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 06 Jan 2011 22:36:38 -0000 Subject: [Bro-Dev] #295: Create prebuilt binary packages In-Reply-To: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> References: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> Message-ID: <058.5c1f71272e63b9004a6318d2563c5b11@tracker.icir.org> #295: Create prebuilt binary packages ----------------------+---------------------- Reporter: seth | Owner: jsiwek Type: Problem | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ----------------------+---------------------- Comment (by robin): > I don't have a strong urge to investigate further, so it may be that we > have to make an i386 package for 10.5+ and an x86_64 package for 10.6+. > > We should probably consider this again at the time we're ready for a bro > 1.6 release -- maybe we want to make it a habit to only make packages for > OS versions currently supported by Apple, which may be 10.6 and 10.7 by > the time we're ready. Both sound good, assuming that doing the extra i386 package for 10.5 is not significantly more work to set it up. If it is, we can even do just the 10.6; people can always compile themselves. -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 6 17:05:27 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 07 Jan 2011 01:05:27 -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.738bb11a0a3cb85dead1eb93a6d2a497@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): This still doesn't seem to working right, I now get these with devel on the testsutie: 1081882021.976706 error: '>' not found in argument to RCPT: TO: -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 6 17:07:52 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 07 Jan 2011 01:07:52 -0000 Subject: [Bro-Dev] #346: topic/robin/global-attr Message-ID: <044.88c585a8aac86616c08a16f732524101@tracker.icir.org> #346: topic/robin/global-attr ---------------------------+-------------------- Reporter: robin | Owner: Type: Merge Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | ---------------------------+-------------------- Removing "global_attrs" from parser, along with record attributes. This closes #11. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 6 19:20:37 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 07 Jan 2011 03:20:37 -0000 Subject: [Bro-Dev] #265: topic/robin/entropy - Entropy testing BiFs (was: Entropy testing BiFs) In-Reply-To: <043.8e334b34bdf23f9d7b102b8c4e3da6bd@tracker.icir.org> References: <043.8e334b34bdf23f9d7b102b8c4e3da6bd@tracker.icir.org> Message-ID: <058.95153d88e23fd3696dfde373a6179309@tracker.icir.org> #265: topic/robin/entropy - Entropy testing BiFs ----------------------------+-------------------- Reporter: seth | Owner: Type: Merge Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: ----------------------------+-------------------- Changes (by robin): * type: Patch => Merge Request -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 6 19:21:28 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 07 Jan 2011 03:21:28 -0000 Subject: [Bro-Dev] #346: topic/robin/global-attr - Removing "global_attrs" (was: topic/robin/global-attr) In-Reply-To: <044.88c585a8aac86616c08a16f732524101@tracker.icir.org> References: <044.88c585a8aac86616c08a16f732524101@tracker.icir.org> Message-ID: <059.863e683c02adeb1756eb6d9552239c78@tracker.icir.org> #346: topic/robin/global-attr - Removing "global_attrs" ----------------------------+-------------------- Reporter: robin | Owner: Type: Merge Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ----------------------------+-------------------- -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 7 09:49:21 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 07 Jan 2011 17:49:21 -0000 Subject: [Bro-Dev] #295: Create prebuilt binary packages In-Reply-To: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> References: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> Message-ID: <058.5cdc769dd8f61acdda3824a900ab4aa6@tracker.icir.org> #295: Create prebuilt binary packages ----------------------+---------------------- Reporter: seth | Owner: jsiwek Type: Problem | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ----------------------+---------------------- Comment (by jsiwek): I just submitted a bug report to Apple because I could reproduce it simply on 10.5.8 with: {{{ #include int main() { res_init(); return 0; } }}} Compiled like: {{{ gcc -arch x86_64 resolvtest.c -lresolv }}} We'll see if anything happens. -- Ticket URL: Bro Tracker Bro Issue Tracker From martin.arlitt at ucalgary.ca Fri Jan 7 11:01:21 2011 From: martin.arlitt at ucalgary.ca (Martin Arlitt) Date: Fri, 07 Jan 2011 12:01:21 -0700 Subject: [Bro-Dev] revised technical report Message-ID: <4D276301.40205@ucalgary.ca> hi I just wanted to inform you of a revision to the technical report that describes the integration of DataSeries into Apache and Bro. http://www.hpl.hp.com/techreports/2010/HPL-2010-164R1.html the main difference between this version and the initial one is the inclusion of analysis results from a file server connected via 1 GbE rather than 100 MbE. thanks Martin From jsiwek at ncsa.illinois.edu Mon Jan 10 11:53:54 2011 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Mon, 10 Jan 2011 13:53:54 -0600 (CST) Subject: [Bro-Dev] [Bro-Commits] [git/broctl] master: Changing some installation paths. (90ddc4d) In-Reply-To: <201101050446.p054k7kA021162@envoy.icir.org> Message-ID: <29966836.145.1294689230829.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Robin, > - The CMake install does no longer recreate some of the > top-level directories when they already exist. That makes it > possible to now symlink them somewhere else after the first > install. The new code probably isn't doing as you intended. The OPTIONAL flag seems unrelated to the existence of the destination directory, it's checking the existence of the named directory as a source directory (part of the build) and won't complain if it doesn't exist, but it also won't create the destination directory in that case, which is a problem. In other words, for a fresh install, the spool and logs directories don't get created for me. I would re-code it to script the creation of those directories at `make install` time, but I'm finding that CPack will only bundle things up into the binary package if they've been installed w/ the install() macro and that's not callable at `make install` time. So my idea is that I'll re-code for the general case to script the directory creation at `make install` time, but also add a configure option that a packager can set to explicitly use the install() macro instead. Are you able to give the platform and CMake version that produced the bad behavior of the installation of directories overwriting/recreating existing ones? I don't see the same problem (using the original code) on OS X 10.6 + CMake 2.8.3, so I'd like to document it. > diff --git a/CMakeLists.txt b/CMakeLists.txt > index 5056886..a098852 100644 > --- a/CMakeLists.txt > +++ b/CMakeLists.txt > @@ -184,14 +184,25 @@ else () > RENAME networks.cfg.example) > endif () > > -install(DIRECTORY DESTINATION spool) > -install(DIRECTORY DESTINATION spool/tmp) > -install(DIRECTORY DESTINATION logs) > - > -# The dynamic state will be updated on first `broctl install` > -file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/broctl.dat) > -install(FILES ${CMAKE_CURRENT_BINARY_DIR}/broctl.dat > - DESTINATION spool) > +if (NOT EXISTS ${PREFIX}/spool) > + install(DIRECTORY DESTINATION spool OPTIONAL) > +endif () > + > +if (NOT EXISTS ${PREFIX}/spool/policy) > + install(DIRECTORY DESTINATION spool/policy OPTIONAL) > +endif () > + > +if (NOT EXISTS ${PREFIX}/spool/tmp) > + install(DIRECTORY DESTINATION spool/tmp OPTIONAL) > +endif () > + > +if (NOT EXISTS ${PREFIX}/logs) > + install(DIRECTORY DESTINATION logs OPTIONAL) > +endif () From bro at tracker.icir.org Mon Jan 10 11:54:50 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 10 Jan 2011 19:54:50 -0000 Subject: [Bro-Dev] #328: Patch to add programmatic pattern construction at init time. In-Reply-To: <043.f9c865007fdbbe40274ceab20806264f@tracker.icir.org> References: <043.f9c865007fdbbe40274ceab20806264f@tracker.icir.org> Message-ID: <058.354eaffcc07b304087a81e39e96ab38d@tracker.icir.org> #328: Patch to add programmatic pattern construction at init time. ---------------------+---------------------- Reporter: seth | Owner: robin Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ---------------------+---------------------- Comment (by robin): Different idea: how about checking "bro_start_network_time", defined in Net.h, instead if the event name? If it's zero, we haven't see a packet yet, i.e., we should still be initializing. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Jan 10 12:05:45 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 10 Jan 2011 20:05:45 -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.885aff02ef8ebff14ec53b596a46a30c@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: ----------------------+---------------------- Comment (by robin): Seems this has been partially integrated. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Jan 10 12:10:58 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 10 Jan 2011 20:10:58 -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.9cdaa13a20379f334629e5e08f1907c6@tracker.icir.org> #64: DNS lookup routines may return either string or addr ----------------------+-------------------- Reporter: mej | Owner: robin Type: Problem | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.4 Resolution: Solved | Keywords: ----------------------+-------------------- Changes (by robin): * status: accepted => closed * resolution: => Solved Comment: Oops no, the patch has been correctly integrated already. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Jan 10 12:13:46 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 10 Jan 2011 20:13:46 -0000 Subject: [Bro-Dev] #328: Patch to add programmatic pattern construction at init time. In-Reply-To: <043.f9c865007fdbbe40274ceab20806264f@tracker.icir.org> References: <043.f9c865007fdbbe40274ceab20806264f@tracker.icir.org> Message-ID: <058.e93895ca50c8d0d0061a117268f9af16@tracker.icir.org> #328: Patch to add programmatic pattern construction at init time. ---------------------+---------------------- Reporter: seth | Owner: robin Type: Patch | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ---------------------+---------------------- Comment (by seth): > Different idea: how about checking "bro_start_network_time", defined in > Net.h, instead if the event name? Oh, I like that idea. It allows pattern construction in functions and possibly other handlers at init time. I'll make the change soon-ish. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Jan 10 12:15:38 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 10 Jan 2011 20:15:38 -0000 Subject: [Bro-Dev] #267: Patch to fix internal log_encryption_key handling In-Reply-To: <043.efcd269209695b49b3d8f0ada56409ce@tracker.icir.org> References: <043.efcd269209695b49b3d8f0ada56409ce@tracker.icir.org> Message-ID: <058.1930a18ad9de8db6b5861c9d7103c3b1@tracker.icir.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: ---------------------+-------------------- Comment (by robin): What was the problem here? The original way of accessing the variable should work. -- Ticket URL: Bro Tracker Bro Issue Tracker From robin at icir.org Mon Jan 10 12:34:54 2011 From: robin at icir.org (Robin Sommer) Date: Mon, 10 Jan 2011 12:34:54 -0800 Subject: [Bro-Dev] [Bro-Commits] [git/broctl] master: Changing some installation paths. (90ddc4d) In-Reply-To: <29966836.145.1294689230829.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <201101050446.p054k7kA021162@envoy.icir.org> <29966836.145.1294689230829.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20110110203454.GV35202@icir.org> On Mon, Jan 10, 2011 at 13:53 -0600, you wrote: > case, which is a problem. In other words, for a fresh install, the > spool and logs directories don't get created for me. Hmm, just tried it, and they do get created for me with current master. (Though I indeed might have misunderstood OPTIONS, from a quick try I don't see a difference without). So, not sure what's different over here. Here's what I need: I have a setup where I link spool and logs to somewhere else. I do that manually after the first "make install", and then need later "make installs" to not delete those links, but jsut follow them as necessary. I thought that the "NOT EXISTS" would do the trick? > Are you able to give the platform and CMake version that produced FreeBSD and cmake 2.8.2 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 Jan 10 13:57:04 2011 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Mon, 10 Jan 2011 15:57:04 -0600 (CST) Subject: [Bro-Dev] [Bro-Commits] [git/broctl] master: Changing some installation paths. (90ddc4d) In-Reply-To: <20110110203454.GV35202@icir.org> Message-ID: <4447343.187.1294696620811.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > > case, which is a problem. In other words, for a fresh install, the > > spool and logs directories don't get created for me. > > Hmm, just tried it, and they do get created for me with current > master. (Though I indeed might have misunderstood OPTIONS, from a > quick try I don't see a difference without). Yeah, after thinking about it again, the OPTIONAL flag shouldn't cause different behavior in the case of not supplying a src dir and probably actually doesn't (though, I think it still doesn't help accomplish what you need). I think I figured out what was actually happening to me... > So, not sure what's different over here. Here's what I need: I have > a setup where I link spool and logs to somewhere else. I do that > manually after the first "make install", and then need later "make > installs" to not delete those links, but jsut follow them as > necessary. I thought that the "NOT EXISTS" would do the trick? That check will happen at the configure time. So the problem I ran into was I had a previous installation at /usr/local/bro, then I did: ./configure cd build make # at this point I realize that I have an existing installation that I want to get rid of to test a clean install rm -rf /usr/local/bro make install So /usr/local/bro/spool/* and /usr/local/bro/logs didn't get created because they existed at configure time. > > Are you able to give the platform and CMake version that produced > > FreeBSD and cmake 2.8.2 So the question I have now is, does CMake code like the following: install(DIRECTORY DESTINATION spool) actually overwrite your symlinks on FreeBSD while doing `make install`? I don't see that happening on OS X 10.6 (w/ CMake 2.8.3) or Fedora 14 (w/ CMake 2.8.2). From robin at icir.org Mon Jan 10 14:10:48 2011 From: robin at icir.org (Robin Sommer) Date: Mon, 10 Jan 2011 14:10:48 -0800 Subject: [Bro-Dev] [Bro-Commits] [git/broctl] master: Changing some installation paths. (90ddc4d) In-Reply-To: <4447343.187.1294696620811.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <20110110203454.GV35202@icir.org> <4447343.187.1294696620811.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20110110221048.GA79625@icir.org> On Mon, Jan 10, 2011 at 15:57 -0600, you wrote: > So the question I have now is, does CMake code like the following: > > install(DIRECTORY DESTINATION spool) > > actually overwrite your symlinks on FreeBSD while doing `make install`? Well, that's funny because now that I'm trying this, it doesn't overwrite the links. However, I'm pretty sure it did it when I was using that earlier ... Let me try a bit more, if everything works fine, I'll revert the change. 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 Tue Jan 11 07:18:38 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 11 Jan 2011 15:18:38 -0000 Subject: [Bro-Dev] #347: Problem with df helper script Message-ID: <043.4fa077db3c407c8aec1acb0385cc972d@tracker.icir.org> #347: Problem with df helper script ------------------------+------------------------ Reporter: seth | Owner: robin Type: Problem | Status: new Priority: High | Milestone: Component: BroControl | Version: git/master Keywords: | ------------------------+------------------------ This is related to ticket #251. The problem is seen in that ticket but is not found as the correct problem. On some machines, the file system device will be too long and df will wrap the line which messes up the df helper... {{{ [root at local bro]# df -h /bro Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup00-LogVol00 212G 8.0G 193G 4% / }}} The fix seems to be to add the -P flag to the df command in the df helper script. I just don't know if that's going to cause compatibility problems with different 'df's. It seems to work on MacOS X and GNU df. {{{ [root at local bro]# df -Ph /bro Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup00-LogVol00 212G 8.0G 193G 4% / }}} I think we should try and get this fix in before we do the final 1.5 release because many boxes can't run the broctl cron command fully due to this bug. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 11 09:14:22 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 11 Jan 2011 17:14:22 -0000 Subject: [Bro-Dev] #347: Problem with df helper script In-Reply-To: <043.4fa077db3c407c8aec1acb0385cc972d@tracker.icir.org> References: <043.4fa077db3c407c8aec1acb0385cc972d@tracker.icir.org> Message-ID: <058.bba8d2e2908853f2f7bd71744c3fec66@tracker.icir.org> #347: Problem with df helper script -------------------------+------------------------ Reporter: seth | Owner: robin Type: Problem | Status: new Priority: High | Milestone: Component: BroControl | Version: git/master Resolution: | Keywords: -------------------------+------------------------ Comment (by robin): On Tue, Jan 11, 2011 at 15:18 -0000, you wrote: > The fix seems to be to add the -P flag to the df command in the df helper > script. I just don't know if that's going to cause compatibility problems > with different 'df's. It seems to work on MacOS X and GNU df. The FreeBSD man page says: {{{ -P Use POSIX compliant output of 512-byte blocks rather than the default. Note that this overrides the BLOCKSIZE specification from the environment. }}} That sounds like there need to be more changes to the script to deal with that (and it's unclear I guess whether -P also prevents wrappin on FreeBSD?). I'd be fine still including this into 1.5.2 but we need a version of the script that works on Linux, FreeBSD, and OSX, if necessary with treating them separately as in "top". -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 11 10:25:31 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 11 Jan 2011 18:25:31 -0000 Subject: [Bro-Dev] #347: Problem with df helper script In-Reply-To: <043.4fa077db3c407c8aec1acb0385cc972d@tracker.icir.org> References: <043.4fa077db3c407c8aec1acb0385cc972d@tracker.icir.org> Message-ID: <058.f4d7f72fcb7da904f97173e3d5853d0a@tracker.icir.org> #347: Problem with df helper script -------------------------+------------------------ Reporter: seth | Owner: robin Type: Problem | Status: new Priority: High | Milestone: Component: BroControl | Version: git/master Resolution: | Keywords: -------------------------+------------------------ Comment (by seth): > -P Use POSIX compliant output of 512-byte blocks rather than > the default. Note that this overrides the BLOCKSIZE > specification from the environment. "df -kP" does POSIX output with 1k blocks on FreeBSD, Linux, and Mac OS X. I just tested it. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 12 09:29:33 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 12 Jan 2011 17:29:33 -0000 Subject: [Bro-Dev] #348: Reassembler integer overflow issues. Data not delivered after 2GB Message-ID: <045.50782a98afd446d5533512f10b0a2995@tracker.icir.org> #348: Reassembler integer overflow issues. Data not delivered after 2GB ----------------------+------------------------ Reporter: gregor | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Keywords: inttypes | ----------------------+------------------------ {{{ #!rst The TCP Reassembler does not deliver any data to analyzers after the first 2GB due to signed integer overflow (Actually it will deliver again between 4--6GB, etc.) This happens silently, i.e., without content_gap events or Undelivered calls. This report superseded #315, #137 The TCP Reassembler (and Reassem) base class use ``int`` to keep track of sequence numbers and ``seq_delta`` to check for differences. If a connection exceeds 2GB, the relative sequence numbers (int) used by the Reassembler become negative. While many parts of the Reassembler still work (because seq_delta still reports the correct difference) some parts do not. In particular ``seq_to_skip`` is broken (and fails silently). There might well be other parts of the Reassembler that fail silently as well, that I haven't found yet. See Comments in TCP_Reassembler.cc for more details. The Reassembler should use int64. However this will require deep changes to the Reassembler and the TCP Analyzer and TCP_Endpoint classes (since we also store sequence numbers there). Also, the analyzer framework will need tweaks as well (e.g., Undelivered uses ``int`` for sequence numbers, also has to go to 64 bit) As a hotfix that seems to work I disabled the ``seq_to_skip`` features. It wasn't used by any analyzer or policy script (Note, that seq_to_skip is different from skip_deliveries). Hotfix is in topic/gregor/reassembler-hotfix }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 12 09:30:14 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 12 Jan 2011 17:30:14 -0000 Subject: [Bro-Dev] #317: Analyzer::Undelivered should use relative sequence numbers (and go to 64bit) In-Reply-To: <045.958e8ad1a89ce34c09add70439e6e92a@tracker.icir.org> References: <045.958e8ad1a89ce34c09add70439e6e92a@tracker.icir.org> Message-ID: <060.d4b8782f22b3097cc4df16aa4981534c@tracker.icir.org> #317: Analyzer::Undelivered should use relative sequence numbers (and go to 64bit) -----------------------+------------------------ Reporter: gregor | Owner: Type: Task | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: Rejected | Keywords: inttypes -----------------------+------------------------ Changes (by gregor): * status: new => closed * resolution: => Rejected Comment: This is a non-bug actually. Undelivered in fact uses relative sequence numbers. However, it should still use 64 bit sequence numbers. See #348 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 12 09:31:07 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 12 Jan 2011 17:31:07 -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.63133031b2a1832ab054574e61cdc913@tracker.icir.org> #315: TCP Reassemblier type inconsistency ------------------------+------------------------ Reporter: gregor | Owner: Type: Problem | Status: closed Priority: Low | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: Duplicate | Keywords: inttypes ------------------------+------------------------ Changes (by gregor): * status: new => closed * resolution: => Duplicate Comment: This is actually a larger issues. Detailed report in #348. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 12 09:32:41 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 12 Jan 2011 17:32:41 -0000 Subject: [Bro-Dev] #332: Portmap analyzer segfaults when parsing portmap dump replies In-Reply-To: <045.fc87d35e27cf53e26f8771e6f7836df6@tracker.icir.org> References: <045.fc87d35e27cf53e26f8771e6f7836df6@tracker.icir.org> Message-ID: <060.dd381984128a778779c568d3676fc673@tracker.icir.org> #332: Portmap analyzer segfaults when parsing portmap dump replies ---------------------+-------------------- Reporter: gregor | Owner: Type: Patch | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: Solved | Keywords: ---------------------+-------------------- Changes (by gregor): * status: new => closed * resolution: => Solved Comment: Applied to fastpath. -- Ticket URL: Bro Tracker Bro Issue Tracker From gregor at icir.org Wed Jan 12 10:17:02 2011 From: gregor at icir.org (Gregor Maier) Date: Wed, 12 Jan 2011 10:17:02 -0800 Subject: [Bro-Dev] Git merge and submodules Message-ID: <4D2DF01E.6030404@icir.org> Hi, I've got a curious problem here with git. I've merge one of my topic branches (topic/gregor/ressembler-hotfix) into another one (topic/gregor/rpc) using git merge --no-ff. This worked fine, but it also updated my submodules. When I do a git status right after the merge I get: # (use "git checkout -- ..." to discard changes in working directory) # # modified: aux/binpac (new commits) # modified: aux/bro-aux (new commits) # modified: aux/broccoli (new commits) # modified: aux/broctl (new commits) How I can I get rid of that. I don't really care for updating my submodules. The "git checkout -- aux/binpac", etc. didn't help. Can I do a merge without getting the submodules as well? Alternatively, I guess I can just accept the changes to the submodules. Can I just do a "git commit -a" ? On a different note. Just before the merge I pushed a bunch of commits that had accumulated to the server. Then I merged the other topic branch. However, git status still tells that I'm ahead by 7 commits? Why? I can see that I'm ahead by 1 commit, namely the merge commit.... # On branch topic/gregor/rpc # Your branch is ahead of 'origin/topic/gregor/rpc' by 7 commits. A git pull says "already up-to-date".... 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 Wed Jan 12 11:10:52 2011 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Wed, 12 Jan 2011 13:10:52 -0600 (CST) Subject: [Bro-Dev] Git merge and submodules In-Reply-To: <4D2DF01E.6030404@icir.org> Message-ID: <30829228.289.1294859450612.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > How I can I get rid of that. I don't really care for updating my > submodules. The "git checkout -- aux/binpac", etc. didn't help. If you just want to prevent it from showing something in `git status`, you can give it the --ignore-submodules options. There's also a global git config option you can add to your ~/.gitconfig, e.g.: [submodule "aux/binpac"] ignore = all You'd have to add a section for each submodule you want to ignore, though. > Can I do a merge without getting the submodules as well? Just to be sure we're understanding what happened, can you check if files were actually updated in the submodules? If my understanding is right, nothing actually was updated in the submodules. What has changed are your bro repository's submodule "pointers", which essentially track a specific version (commit) of a foreign repository so that you'd checkout that version when you explicitly do a `git submodule update`. If this is the case, I'd recommend just taking the "ignore" approach I described above. > Alternatively, I guess I can just accept the changes to the submodules. > Can I just do a "git commit -a" ? That's another option, but I don't think I like it because it pollutes the commit history with a bunch of "updating submodule" type commits and I think it might also lead to the repository maintainer having to reset submodules again upon merging your branch. > However, git status still tells that I'm ahead by 7 commits? > Why? I can see that I'm ahead by 1 commit, namely the merge commit.... Sorry, don't have any good idea about why that is. Maybe compare with a fresh clone of the repository. - Jon From gregor at icir.org Wed Jan 12 11:26:00 2011 From: gregor at icir.org (Gregor Maier) Date: Wed, 12 Jan 2011 11:26:00 -0800 Subject: [Bro-Dev] Git merge and submodules In-Reply-To: <30829228.289.1294859450612.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <30829228.289.1294859450612.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <7701B249-93B9-4763-842B-F56026821403@icir.org> it's indeed just the pointers that changed. I was hoping that I can just revert the pointers to their previous values ... cu gregor -- sent from iPhone - might be shorter as usual On Jan 12, 2011, at 11:10, Jonathan Siwek wrote: >> How I can I get rid of that. I don't really care for updating my >> submodules. The "git checkout -- aux/binpac", etc. didn't help. > > If you just want to prevent it from showing something in `git status`, you can give it the --ignore-submodules options. There's also a global git config option you can add to your ~/.gitconfig, e.g.: > > [submodule "aux/binpac"] > ignore = all > > You'd have to add a section for each submodule you want to ignore, though. > >> Can I do a merge without getting the submodules as well? > > Just to be sure we're understanding what happened, can you check if files were actually updated in the submodules? > > If my understanding is right, nothing actually was updated in the submodules. What has changed are your bro repository's submodule "pointers", which essentially track a specific version (commit) of a foreign repository so that you'd checkout that version when you explicitly do a `git submodule update`. > > If this is the case, I'd recommend just taking the "ignore" approach I described above. > >> Alternatively, I guess I can just accept the changes to the submodules. >> Can I just do a "git commit -a" ? > > That's another option, but I don't think I like it because it pollutes the commit history with a bunch of "updating submodule" type commits and I think it might also lead to the repository maintainer having to reset submodules again upon merging your branch. > >> However, git status still tells that I'm ahead by 7 commits? >> Why? I can see that I'm ahead by 1 commit, namely the merge commit.... > > Sorry, don't have any good idea about why that is. Maybe compare with a fresh clone of the repository. > > - Jon > From gregor at icir.org Wed Jan 12 15:45:41 2011 From: gregor at icir.org (Gregor Maier) Date: Wed, 12 Jan 2011 15:45:41 -0800 Subject: [Bro-Dev] Git merge and submodules In-Reply-To: <7701B249-93B9-4763-842B-F56026821403@icir.org> References: <30829228.289.1294859450612.JavaMail.jsiwek@tangent.ncsa.illinois.edu> <7701B249-93B9-4763-842B-F56026821403@icir.org> Message-ID: <4D2E3D25.4080704@icir.org> FYI "git submodule --recursive update" seems to have solved the problem. No idea what was going on there and where to wrong submodule info came from.... cu gregor On 1/12/11 11:26 , Gregor Maier wrote: > it's indeed just the pointers that changed. I was hoping that I can just revert the pointers to their previous values ... > > cu > gregor > -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From robin at icir.org Wed Jan 12 20:03:12 2011 From: robin at icir.org (Robin Sommer) Date: Wed, 12 Jan 2011 20:03:12 -0800 Subject: [Bro-Dev] [Bro-Commits] [git/bro] topic/gregor/rpc's head updated: Merge branch 'topic/gregor/reassmbler-hotfix' into topic/gregor/rpc (70b6891) In-Reply-To: <201101122345.p0CNjsrd011923@envoy.icir.org> References: <201101122345.p0CNjsrd011923@envoy.icir.org> Message-ID: <20110113040312.GJ19299@icir.org> On Wed, Jan 12, 2011 at 15:45 -0800, you wrote: > Branch 'topic/gregor/rpc' now includes: Jfyi, this is a new feature of our git-notify script: when a git head moves to now include commits that have already been reported with their diffs earlier, such a summary mail is generated. This is so that we see what's going on with a branch even if the change doesn't include new commits (e.g., fast-forwards). These notifications might still be a bit too noisy in the sense that they can report cases that aren't really that interesting. But let's see, I'm not quite sure yet what the exact definition of "interesting cases" is. Robin > 943b5ed Merge branch 'master' into topic/cmake-port > 51d561c Fix wrong variable names in bro-path-dev script > 3facb6a Merge remote branch 'origin/topic/cmake-port' > 0ebcf2d Setting executable bit for bro-dev-path.in. > d24f7a6 Update submodules > a5632af TCP Reassembler hotfix for conns > 2GB. > 70b6891 Merge branch 'topic/gregor/reassmbler-hotfix' into topic/gregor/rpc -- 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 Thu Jan 13 07:41:08 2011 From: gregor at icir.org (Gregor Maier) Date: Thu, 13 Jan 2011 07:41:08 -0800 Subject: [Bro-Dev] [Bro-Commits] [git/bro] topic/gregor/rpc's head updated: Merge branch 'topic/gregor/reassmbler-hotfix' into topic/gregor/rpc (70b6891) In-Reply-To: <20110113040312.GJ19299@icir.org> References: <201101122345.p0CNjsrd011923@envoy.icir.org> <20110113040312.GJ19299@icir.org> Message-ID: <4D2F1D14.2060605@icir.org> > Jfyi, this is a new feature of our git-notify script: when a git > head moves to now include commits that have already been reported > with their diffs earlier, such a summary mail is generated. This is > so that we see what's going on with a branch even if the change > doesn't include new commits (e.g., fast-forwards). cool feature. I think it's great to have. cu gregor -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From jsiwek at ncsa.illinois.edu Thu Jan 13 08:29:48 2011 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Thu, 13 Jan 2011 10:29:48 -0600 (CST) Subject: [Bro-Dev] Git merge and submodules In-Reply-To: <4D2E3D25.4080704@icir.org> Message-ID: <12561545.306.1294936184099.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > No idea what was going on there and where to wrong submodule info came from.... It's because the two branches that were merged had differing submodule "pointers" and when the merge occurs it just changes the pointers, not the actual content of your local repositories submodules, thus `git status` has to report a change in the submodules. > "git submodule --recursive update" seems to have solved the problem. Yeah, I haven't strained myself too hard thinking about this but I think maybe this is a good solution for anyone that encounters this after doing branch merges because after the merge, submodule pointers should always be set to the most recent version between the two merging branches. i.e. it's not possible that the `git submodule update` actually checked out an older version of the submodules. On the other hand, for someone that's directly making changes to submodules, this would probably not be the command they want to run when they see similar things from `git status`. - Jon From robin at icir.org Thu Jan 13 08:49:19 2011 From: robin at icir.org (Robin Sommer) Date: Thu, 13 Jan 2011 08:49:19 -0800 Subject: [Bro-Dev] Git merge and submodules In-Reply-To: <12561545.306.1294936184099.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <4D2E3D25.4080704@icir.org> <12561545.306.1294936184099.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20110113164919.GC36781@icir.org> On Thu, Jan 13, 2011 at 10:29 -0600, you wrote: > Yeah, I haven't strained myself too hard thinking about this but I > think maybe this is a good solution for anyone that encounters this Gregor and I talked yesterday about adding a simple script like "fix-submodules" that would do whatever is necessary to get the submodules into the right state (which probably is just such a recursive update; but Gregor, didn't we have a second thing the script could do as well?). So, after a merge one would just run that and be good. Another script which I think would be useful is something like "update-submodules" that moves all submodules to their most recent version (e.g., if we're in master, checks out all the other master version and commits the update). Do you think these make sense? 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 Thu Jan 13 09:32:39 2011 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Thu, 13 Jan 2011 11:32:39 -0600 (CST) Subject: [Bro-Dev] Git merge and submodules In-Reply-To: <20110113164919.GC36781@icir.org> Message-ID: <23192682.338.1294939954241.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > Gregor and I talked yesterday about adding a simple script like > "fix-submodules" that would do whatever is necessary to get the > submodules into the right state (which probably is just such a > recursive update; but Gregor, didn't we have a second thing the > script could do as well?). So, after a merge one would just run that > and be good. Yeah, I think doing a recursive update of submodules is the right thing to do after merging with another branch. But the other case (which is probably less common) is that someone may be doing work on the submodule repositories. The submodule update command for them does the wrong thing. They need to either 1) Ignore submodule changes that `git status` (i.e. don't commit submodule pointers), either with a gitconfig option or just by cautiously not adding submodule changes to commits. 2) Go ahead w/ committing submodule pointer changes In either case, the repo maintainer will make sure every submodule points to the most recent master commit after a branch is merged. Do you have an opinion for which convention we should follow? Since the same thing happens in the end, maybe it's fine to just leave it to developer preference (as long as they try to avoid spamming the commit log with purely "update submodule" type commits if they choose #2). > Another script which I think would be useful is something like > "update-submodules" that moves all submodules to their most recent > version (e.g., if we're in master, checks out all the other master > version and commits the update). Sounds useful, but mostly for use by repo maintainers, right? But the name might be confusing because it actually doesn't involve the submodule update command. - Jon From gregor at icir.org Thu Jan 13 09:43:40 2011 From: gregor at icir.org (Gregor Maier) Date: Thu, 13 Jan 2011 09:43:40 -0800 Subject: [Bro-Dev] Git merge and submodules In-Reply-To: <23192682.338.1294939954241.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <23192682.338.1294939954241.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <4D2F39CC.5030808@icir.org> On 1/13/11 9:32 , Jonathan Siwek wrote: >> Gregor and I talked yesterday about adding a simple script like >> "fix-submodules" that would do whatever is necessary to get the >> submodules into the right state (which probably is just such a >> recursive update; but Gregor, didn't we have a second thing the >> script could do as well?). So, after a merge one would just run that >> and be good. > > Yeah, I think doing a recursive update of submodules is the right thing to do after merging with another branch. Exactly. I think that's the common case, that somebody just wants to work on bro itself and not be bothered with submodule changes. The idea was that such a script would make life easier for people new or not too familiar with git. > But the other case (which is probably less common) is that someone may be doing work on the submodule repositories. The submodule update command for them does the wrong thing. They need to either > [ACK] > > Since the same thing happens in the end, maybe it's fine to just leave it to developer preference (as long as they try to avoid spamming the commit log with purely "update submodule" type commits if they choose #2). ACK. I think that can be left up to the developer. >> Another script which I think would be useful is something like >> "update-submodules" that moves all submodules to their most recent >> [cut] > [cut] > But the name might be confusing because it actually doesn't involve the submodule update command. ACK. -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From gregor at icir.org Thu Jan 13 09:46:23 2011 From: gregor at icir.org (Gregor Maier) Date: Thu, 13 Jan 2011 09:46:23 -0800 Subject: [Bro-Dev] Git merge and submodules In-Reply-To: <20110113164919.GC36781@icir.org> References: <4D2E3D25.4080704@icir.org> <12561545.306.1294936184099.JavaMail.jsiwek@tangent.ncsa.illinois.edu> <20110113164919.GC36781@icir.org> Message-ID: <4D2F3A6F.8010902@icir.org> > [cut] but Gregor, didn't we have a second thing the > script could do as well?). git submodule init (maybe with --recursive, don't know whether it's needed) This command can be used if you cloned the repository and forgot the --recursive. (*) The submodule init will then clone the submodule repositories and check out the appropriate version. cu Gregor (*) This actually happened to me a couple of times. I clone the repository. Did my changes and when I tried to compile it complained that I didn't have binpac.... -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From robin at icir.org Thu Jan 13 09:49:35 2011 From: robin at icir.org (Robin Sommer) Date: Thu, 13 Jan 2011 09:49:35 -0800 Subject: [Bro-Dev] Git merge and submodules In-Reply-To: <23192682.338.1294939954241.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <20110113164919.GC36781@icir.org> <23192682.338.1294939954241.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20110113174935.GI36781@icir.org> > Since the same thing happens in the end, maybe it's fine to just leave it to developer preference (as long as they try to avoid spamming the commit log with purely "update submodule" type commits if they choose #2). Yeah, sounds right for now. If we had a reliable way to identify "update submodule" commits, the notifier script could suppress them on topic branches, but not sure how to recognize them. Otherwise, likewise ACK on the rest. > But the name might be confusing because it actually doesn't involve the submodule update command. Other suggestions? "move-submodules"? 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 Thu Jan 13 09:56:09 2011 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Thu, 13 Jan 2011 11:56:09 -0600 (CST) Subject: [Bro-Dev] Git merge and submodules In-Reply-To: <20110113174935.GI36781@icir.org> Message-ID: <32541861.340.1294941369125.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > Other suggestions? "move-submodules"? "remaster-submodules" ? From gregor at icir.org Thu Jan 13 13:54:13 2011 From: gregor at icir.org (Gregor Maier) Date: Thu, 13 Jan 2011 13:54:13 -0800 Subject: [Bro-Dev] Subversion (and CVS) style $Id$ keywords Message-ID: <4D2F7485.3070405@icir.org> Hi, I was just wondering whether we want to use something similar to the $Id$ keyword for git. If not, we should probably remove all the $Id$ lines in the code.... It's seems it's deliberately not supported in git. However, gitattributes(5) can be used to embed a "blobid" (which basically is the SHA-1 of the file's contents when it was committed). There's also a "filter" feature in gitattributes that could be used to hack something together, but it's probably a bad idea. Why is it not in git: http://thread.gmane.org/gmane.comp.version-control.git/44750 gitattributes: http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html cu gregor -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From jsiwek at ncsa.illinois.edu Thu Jan 13 14:21:55 2011 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Thu, 13 Jan 2011 16:21:55 -0600 (CST) Subject: [Bro-Dev] Subversion (and CVS) style $Id$ keywords In-Reply-To: <4D2F7485.3070405@icir.org> Message-ID: <6452407.370.1294957311750.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > However, gitattributes(5) can be used to embed a "blobid" (which basically is > the SHA-1 of the file's contents when it was committed). Is there an example where anyone would care to look at that? The git log seems like a better place to turn to. My opinion would be to ditch the keyword substitutions. - Jon From gregor at icir.org Thu Jan 13 14:39:41 2011 From: gregor at icir.org (Gregor Maier) Date: Thu, 13 Jan 2011 14:39:41 -0800 Subject: [Bro-Dev] Expire in policy scripts Message-ID: <4D2F7F2D.8040107@icir.org> Hi, I have a question regarding expire in policy scripts: If I use: global rpc_calls: table[conn_id] of table[count] of rpc_call_state &write_expire = rpc_timeout &expire_func=expire_rpc_call; will the expire timer be linked to the table that's indexed by conn_id or the table that's indexed by count? Can I specify the table that should have an expire timer? I want the timer linked to the table indexed by count. thanks, gregor -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From gregor at icir.org Thu Jan 13 14:50:44 2011 From: gregor at icir.org (Gregor Maier) Date: Thu, 13 Jan 2011 14:50:44 -0800 Subject: [Bro-Dev] Subversion (and CVS) style $Id$ keywords In-Reply-To: <6452407.370.1294957311750.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <6452407.370.1294957311750.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <4D2F81C4.7050504@icir.org> On 1/13/11 14:21 , Jonathan Siwek wrote: >> However, gitattributes(5) can be used to embed a "blobid" (which basically is >> the SHA-1 of the file's contents when it was committed). > > Is there an example where anyone would care to look at that? The git log seems like a better place to turn to. My opinion would be to ditch the keyword substitutions. ditching it works for me cu gregor -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From vern at icir.org Thu Jan 13 17:16:53 2011 From: vern at icir.org (Vern Paxson) Date: Thu, 13 Jan 2011 17:16:53 -0800 Subject: [Bro-Dev] Subversion (and CVS) style $Id$ keywords In-Reply-To: <4D2F7485.3070405@icir.org> (Thu, 13 Jan 2011 13:54:13 PST). Message-ID: <20110114011653.B22DB36A412@taffy.ICSI.Berkeley.EDU> > Why is it not in git: > http://thread.gmane.org/gmane.comp.version-control.git/44750 Um, that's a 50-100 message thread - care to summarize it for us? Vern From gregor at icir.org Thu Jan 13 17:51:13 2011 From: gregor at icir.org (Gregor Maier) Date: Thu, 13 Jan 2011 17:51:13 -0800 Subject: [Bro-Dev] Subversion (and CVS) style $Id$ keywords In-Reply-To: <20110114011653.B22DB36A412@taffy.ICSI.Berkeley.EDU> References: <20110114011653.B22DB36A412@taffy.ICSI.Berkeley.EDU> Message-ID: <4D2FAC11.5000308@icir.org> On 1/13/11 17:16 , Vern Paxson wrote: >> Why is it not in git: >> http://thread.gmane.org/gmane.comp.version-control.git/44750 > > Um, that's a 50-100 message thread - care to summarize it for us? I'll try (I've only skimmed over the thread) * Problematic with git's approach of addressing and tracking *content* (because the same file-content, identified by its SHA-1 can be present in many different commits. A commit points to a file's content, but given a file-content, there can be any number of commits associated with it) * It can break diffs (if the keyword line is part of the context and and the keywords are different (e.g., due to different branches)) * performance. Keyword expansion is expensive * Linus Torvalds hates them I seems that this mail covers most of the arguments (it's kinda longish) http://article.gmane.org/gmane.comp.version-control.git/44654, Another argument is, that if keywords are desired, they should be added when a file is exported from revision control (so that it's in the tarball) -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From robin at icir.org Thu Jan 13 21:49:17 2011 From: robin at icir.org (Robin Sommer) Date: Thu, 13 Jan 2011 21:49:17 -0800 Subject: [Bro-Dev] Expire in policy scripts In-Reply-To: <4D2F7F2D.8040107@icir.org> References: <4D2F7F2D.8040107@icir.org> Message-ID: <20110114054917.GE51781@icir.org> On Thu, Jan 13, 2011 at 14:39 -0800, you wrote: > global rpc_calls: table[conn_id] of table[count] of rpc_call_state > &write_expire = rpc_timeout &expire_func=expire_rpc_call; Iirc, it applies to the outer one. You can get the inner one by assigning the expire to a local and then inserting that into the outer table: local inner: table[count] of rpc_call_state &write_expire=rpc_timeout; rpc_call[cid] = inner; 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 Jan 14 13:57:14 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 14 Jan 2011 21:57:14 -0000 Subject: [Bro-Dev] #349: Overly long timestamp segfault in cf Message-ID: <043.937b10beaedb8bac75a3aa2d574a5123@tracker.icir.org> #349: Overly long timestamp segfault in cf ---------------------+-------------------- Reporter: seth | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: bro-aux | Version: Keywords: | ---------------------+-------------------- To reproduce: {{{ $ echo "115676919450185299598" | cf Segmentation fault }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 14 14:53:42 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 14 Jan 2011 22:53:42 -0000 Subject: [Bro-Dev] #349: Overly long timestamp segfault in cf In-Reply-To: <043.937b10beaedb8bac75a3aa2d574a5123@tracker.icir.org> References: <043.937b10beaedb8bac75a3aa2d574a5123@tracker.icir.org> Message-ID: <058.ea2412ce0b009e0e2f3672155125aea0@tracker.icir.org> #349: Overly long timestamp segfault in cf ----------------------+-------------------- Reporter: seth | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: bro-aux | Version: Resolution: | Keywords: ----------------------+-------------------- Comment (by aashish): I tried with the following and works alright: # echo "115676919450185299598232222222222222222" | cf Jan 18 19:14:07 # cf -v cf version 1.2.1 usage: cf [-f fmt] [-lpsu] [file ...] -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 14 21:03:58 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Sat, 15 Jan 2011 05:03:58 -0000 Subject: [Bro-Dev] #350: topic/jsiwek/packaging Message-ID: <045.9e4d7dc5383e7486f68e28aab57a0fef@tracker.icir.org> #350: topic/jsiwek/packaging ---------------------------+------------------------ Reporter: jsiwek | Owner: Type: Merge Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Keywords: | ---------------------------+------------------------ This topic exists across all the main bro repositories: bro, binpac, bro- aux, broccoli, broccoli-python, broctl, capstats, trace-summary, pysubnettree as well as bro-scripts (which currently isn't found in the bro tree by means of git submodule) and establishes a framework for source and binary packaging (via CPack). They can be considered for merging to master. Key CHANGES: * `make dist` is now available to be used with the top-level Makefile for creating source packages according to #344 * `make-rpm-packages` and `make-mac-packages` scripts can now generate binary packages according to #295 * Additional configure options to change packaging behavior * OS X builds will now prefer to link static libraries of optional dependencies that don't come with the vanilla operating system * Fix for OS X 10.5 compile error dealing with the llabs() function from stdlib * Installing as a different user than the one that configured/built now works (although, a harmless error message about not being able to write the install manifest may occur) -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Sat Jan 15 16:26:14 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Sun, 16 Jan 2011 00:26:14 -0000 Subject: [Bro-Dev] #350: topic/jsiwek/packaging In-Reply-To: <045.9e4d7dc5383e7486f68e28aab57a0fef@tracker.icir.org> References: <045.9e4d7dc5383e7486f68e28aab57a0fef@tracker.icir.org> Message-ID: <060.f5b370205cdbc76211d4b68292a51bd4@tracker.icir.org> #350: topic/jsiwek/packaging ----------------------------+------------------------ Reporter: jsiwek | Owner: Type: Merge Request | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: Merged | Keywords: ----------------------------+------------------------ Changes (by robin): * status: new => closed * resolution: => Merged -- Ticket URL: Bro Tracker Bro Issue Tracker From robin at icir.org Sat Jan 15 16:52:12 2011 From: robin at icir.org (Robin Sommer) Date: Sat, 15 Jan 2011 16:52:12 -0800 Subject: [Bro-Dev] Git merge and submodules In-Reply-To: <23192682.338.1294939954241.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <20110113164919.GC36781@icir.org> <23192682.338.1294939954241.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20110116005212.GA68520@icir.org> On Thu, Jan 13, 2011 at 11:32 -0600, you wrote: > Sounds useful, but mostly for use by repo maintainers, right? Right. I now have a script for that, will test a bit more before commiting it. 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 Tue Jan 18 08:50:45 2011 From: gregor at icir.org (Gregor Maier) Date: Tue, 18 Jan 2011 08:50:45 -0800 Subject: [Bro-Dev] Per connection byte and packet counting In-Reply-To: <4D0805D6.7030206@icir.org> References: <4D0805D6.7030206@icir.org> Message-ID: <4D35C4E5.3070907@icir.org> Hi, since there were no more comments. I'll wrap up these changes and make them ready for a merge. I will also make the connection history in the conn record an optional field, since this will save quite a bit of memory. cu Gregor On 12/14/10 16:03 , Gregor Maier wrote: > Hi, > > I've played around with packet and byte counting for connections some > more. I think I've got a pretty neat version: > > * Counting is done in a separate analyzer that can be added to the > initial analyzer tree based on a global boolean const. > > * Reporting is done via the endpoint records in the connection record ( > c$orig, c$resp). The endpoint records have to new &optional fields for > number of packets and number of bytes. > > * Updating the counters in the endpoint is done by: > + Removing UpdateEndpointVal() from TransportAnalyzer > + Adding a UpdateConnVal(conn_val) to Analyzer.cc. When a Conn object > needs to update the conn_val (e.g., to generate an event) it calls > the root analyzer's UpdateConnVal(). This call is then "forwarded" > to every analyzer in the tree. I.e., every analyzer could update the > conn_val, e.g., by adding additional, optional fields to the > connection record. > > In terms of speed and memory consumption this is surprisingly > lightweight. Runtime as reported by time, memory consumption from top. > I've only loaded conn and weird: > > * Baseline. Current git master: (3 runs) > 2m42s 900MB > 2m37s 900MB > 2m37s 900MB > > * My version, with counting disabled (i.e., counting analyzer not > instantiated, no the optional fields in endpoint are NULL): > 2m34s 898MB > 2m36s 898MB > 2m36s 898MB > It seems to be faster and using less memory(!). There is an > explanation why it needs slightly less memory: the git-master Conn.cc > had two RecordVal* for orig_endp, and resp_endp that were passed to > UpdateEndpointVal. Since I now only pass the conn_val to > UpdateConnVal, I don't need these pointers in Conn.cc anymore. > I've checked the testsuite it my version passes it. > > > * My version with counting enabled: > 2m40s 1000MB > 2m41s 1000MB > 2m41s 1000MB > 2m41s 1000MB > So: no speed penalty and about 100MB for the analyzer instance and > the additional fields in endpoint (these are responsible for most of > the memory. Vals are expensive memory-wise). > > * As an additional experiment, I made the history field in conn_val > &optional, so that it's only allocated, if record_state_history=T. > Results: > with counting: 2m39s 862MB > wihtout counting: 2m33s 962MB > So I think it might make sense to also integrate this change. > (Currently the history is always tracked and always part of the > connection record, but it is only logged in conn.log if > record_state_history=T). > > Finally, a longer trace with way more data and more policy scripts (conn > weird dpd http-request htt-reply dns): > master / baseline 88m38 2906MB > no counting 88m37 2907MB > with counting 87m47 2963MB > > > So, all in all I would say: we should go with this version, as this > seems to be the ideal solution: overhead when disabled, only memory > overhead when enabled (and this overhead is inevitable!). > > In addition, I would suggest to make c$history &optional and only > allocate and assign a Val* to it if record_state_history=T, since this > seems to safe quite a bit of memory! > > cu > Gregor -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From bro at tracker.icir.org Tue Jan 18 08:57:14 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 18 Jan 2011 16:57:14 -0000 Subject: [Bro-Dev] #351: Incorrect bounds checking with truncated TCP options Message-ID: <045.3765c34dcbc7131bcc86b357fe1364f6@tracker.icir.org> #351: Incorrect bounds checking with truncated TCP options ---------------------+------------------------ Reporter: gregor | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Keywords: | ---------------------+------------------------ {{{ #!rst (from an e-mail I sent a while ago) (setting milestone to 1.6. Can probably be pushed back) Hi, there is a potential problem in Bro when it receives a packet with truncated TCP options (i.e., the packet isn't long enough to accommodate all options). This can happen: a) in the ConnCompressor: it calls ParseTCPOptions without checking whether the packet is long enough to contain all options. ConnCompressor needs to parse the TCP options to know the window scaling factor. b) in TCP.cc, when caplen < len and len is long enough for the TCP options but caplen is not. ExtractTCPHeader() ensures that the len is long enough to contain the options and that caplen is long enough to contain a struct tcphdr (but doesn't check for options). Presumably this is done to enable parsing of header only traces that truncate options. Nevertheless, the TCP Analyzer correctly checks caplen before ParseTCPOptions(). But there are also situations when options are parsed without checking for caplen: * BuildSYNVal(), which is called on every SYN to get the window scaling options. * BuildOSVal(), which is only called when the OS_version_found event has a handler * TCP TraceRewriter (presumably we can ignore this, as we were going to remove it anyway) So, question is: what's the best way to tackle this? One option is to not parse packets that are truncated. But that's probably not a good idea wrt header traces. The other option is to check for the caplen whenever we parse options. That might be cumbersome as this information needs to be passed to many functions, e.g. in TCP_Analyzer: ProcessFlags -> ProcessSYN -> BuildSYNPacketVal. (In any case, truncated packets mean that we can't learn the window scaling....) }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From gregor at icir.org Tue Jan 18 08:58:49 2011 From: gregor at icir.org (Gregor Maier) Date: Tue, 18 Jan 2011 08:58:49 -0800 Subject: [Bro-Dev] Bro roadmap Message-ID: <4D35C6C9.1070209@icir.org> hi, I was wondering whether it makes sense to have a page on the new website indicating when we want to get Bro 1.6 and Bro 1.7 done and which features we plan to integrate in which version. (I'm often wondering whether I should set the milestone for tickets I file to 1.6 or 1.7) cu gregor -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From slagell at ncsa.illinois.edu Tue Jan 18 09:02:41 2011 From: slagell at ncsa.illinois.edu (Adam Slagell) Date: Tue, 18 Jan 2011 11:02:41 -0600 (CST) Subject: [Bro-Dev] Bro roadmap In-Reply-To: <4D35C6C9.1070209@icir.org> References: <4D35C6C9.1070209@icir.org> Message-ID: <7E47A35C-9655-4A07-A47B-6397E09FE6B9@ncsa.illinois.edu> I think this makes sense for "what" and not "when". Just specify target features and fixes not dates Sent from my mobile On Jan 18, 2011, at 10:59 AM, Gregor Maier wrote: > hi, > > I was wondering whether it makes sense to have a page on the new website > indicating when we want to get Bro 1.6 and Bro 1.7 done and which > features we plan to integrate in which version. (I'm often wondering > whether I should set the milestone for tickets I file to 1.6 or 1.7) > > cu > gregor > -- > Gregor Maier > > Int. Computer Science Institute (ICSI) > 1947 Center St., Ste. 600 > Berkeley, CA 94704, USA > http://www.icir.org/gregor/ > _______________________________________________ > bro-dev mailing list > bro-dev at bro-ids.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > From robin at icir.org Tue Jan 18 09:19:04 2011 From: robin at icir.org (Robin Sommer) Date: Tue, 18 Jan 2011 09:19:04 -0800 Subject: [Bro-Dev] Bro roadmap In-Reply-To: <4D35C6C9.1070209@icir.org> References: <4D35C6C9.1070209@icir.org> Message-ID: <20110118171904.GM77804@icir.org> On Tue, Jan 18, 2011 at 08:58 -0800, you wrote: > features we plan to integrate in which version. For the features, we had that but have now moved them to tracker milestones. > (I'm often wondering whether I should set the milestone for tickets > I file to 1.6 or 1.7) Generally speaking, 1.6 is clean up and bug fixing for the C++ part; restructuring of scripts and their output; new build and test infrastructure; and documentation (partially). If something clearly fits in there, set it to 1.6; otherwise leave the version open. I guess we could put something like that online as a guideline. 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 Tue Jan 18 09:47:45 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 18 Jan 2011 17:47:45 -0000 Subject: [Bro-Dev] #352: Make --enable-ipv6 default Message-ID: <044.12c39bf282859c1efd399c7a7103e7ce@tracker.icir.org> #352: Make --enable-ipv6 default --------------------+-------------------- Reporter: robin | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.7 Component: Bro | Version: Keywords: | --------------------+-------------------- We should remove the two different code path for v4 vs v6. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 18 11:08:43 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 18 Jan 2011 19:08:43 -0000 Subject: [Bro-Dev] #291: lookup_addr() only supports IPv4 addresses In-Reply-To: <044.ac2fb4cb11fcfbae75d1e9c96c3f1a02@tracker.icir.org> References: <044.ac2fb4cb11fcfbae75d1e9c96c3f1a02@tracker.icir.org> Message-ID: <059.e9009960240f5004009e7620e5132566@tracker.icir.org> #291: lookup_addr() only supports IPv4 addresses ----------------------+-------------------- Reporter: leres | Owner: Type: Problem | Status: seen Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.1 Resolution: | Keywords: ----------------------+-------------------- Changes (by robin): * milestone: Bro1.7 => Bro1.6 Comment: Seems we should at least put a work-around in place for that for now. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 18 11:51:27 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 18 Jan 2011 19:51:27 -0000 Subject: [Bro-Dev] #272: topic/seth/strings-without-checkstring - Use Bytes() and Len() instead of CheckString() in strings.bif (was: Patch to fix do_split function) In-Reply-To: <043.1e378c2cf2d2f272b054d3bd5b2f44d9@tracker.icir.org> References: <043.1e378c2cf2d2f272b054d3bd5b2f44d9@tracker.icir.org> Message-ID: <058.a8e2be0dde982e43346a628b3f9fc74c@tracker.icir.org> #272: topic/seth/strings-without-checkstring - Use Bytes() and Len() instead of CheckString() in strings.bif ----------------------------+---------------------- Reporter: seth | Owner: seth Type: Merge Request | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: ----------------------------+---------------------- Changes (by seth): * type: Patch => Merge Request Comment: Fixed. I'm renaming this ticket and changing it to a merge request. Here's a CHANGES message: {{{ - Reworked string BiFs to extract strings with a pointer and length instead of the previous method of working with the extracted string until a NULL is encountered. Result is that string BiFs now function reliably on strings containing NULL values. }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 18 14:46:37 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 18 Jan 2011 22:46:37 -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.374c8fe6fab96c5e682e6c3121225906@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 sprint ---------------------+----------------------------------- Changes (by robin): * keywords: ssl extensions => ssl extensions sprint Comment: Would be good to have a trace to reproduce this, but we may just want to apply the patch as-is for now. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 18 14:48:24 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 18 Jan 2011 22:48:24 -0000 Subject: [Bro-Dev] #234: RPM spec for BRO In-Reply-To: <060.c786c37f0467ab3a10e097503e3b7462@tracker.icir.org> References: <060.c786c37f0467ab3a10e097503e3b7462@tracker.icir.org> Message-ID: <075.1c1984c99585abee681f2c0c0f30941d@tracker.icir.org> #234: RPM spec for BRO ------------------------------------+---------------------- Reporter: brad.doctor@? | Owner: Type: Patch | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: Solved | Keywords: rpm spec ------------------------------------+---------------------- Changes (by robin): * status: seen => closed * resolution: => Solved Comment: Seems this is superseded by the new build infrastructure. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 18 14:51:15 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 18 Jan 2011 22:51:15 -0000 Subject: [Bro-Dev] #318: Use inttypes.h instead of home-made ifdefs In-Reply-To: <045.88735bcfdba109ea208b3a5820e31694@tracker.icir.org> References: <045.88735bcfdba109ea208b3a5820e31694@tracker.icir.org> Message-ID: <060.a5995460c7165fa13dc3b0e942774522@tracker.icir.org> #318: Use inttypes.h instead of home-made ifdefs ---------------------+------------------------ Reporter: gregor | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.7 Component: Bro | Version: git/master Resolution: | Keywords: inttypes ---------------------+------------------------ Changes (by robin): * milestone: Bro1.6 => Bro1.7 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 18 14:55:50 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 18 Jan 2011 22:55:50 -0000 Subject: [Bro-Dev] #342: Add payload to ICMP analyzer In-Reply-To: <043.9f47668a205ed0345f897209d20f2055@tracker.icir.org> References: <043.9f47668a205ed0345f897209d20f2055@tracker.icir.org> Message-ID: <058.ad3e062e27d18377a6993d2e8de10b89@tracker.icir.org> #342: Add payload to ICMP analyzer ---------------------+-------------------- Reporter: seth | Owner: Type: Patch | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: ---------------------+-------------------- Comment (by robin): There are some changes to the ICMP analyzer in the pipeline, let's postpone until there are in. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 18 15:00:05 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 18 Jan 2011 23:00:05 -0000 Subject: [Bro-Dev] #337: BroCtl's top has trouble with large values In-Reply-To: <044.194bdf0be7a34bfafe07f70c1ae7871f@tracker.icir.org> References: <044.194bdf0be7a34bfafe07f70c1ae7871f@tracker.icir.org> Message-ID: <059.b34b4576e1bf50db6868100c8d3908c7@tracker.icir.org> #337: BroCtl's top has trouble with large values -------------------------+------------------------ Reporter: robin | Owner: robin Type: Problem | Status: closed Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: git/master Resolution: Merged | Keywords: -------------------------+------------------------ Changes (by robin): * status: new => closed * resolution: => Merged -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 18 18:00:31 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 02:00:31 -0000 Subject: [Bro-Dev] #353: Restore and improve IDMEF support Message-ID: <043.68b445e31106dba307ec798618814419@tracker.icir.org> #353: Restore and improve IDMEF support --------------------+-------------------- Reporter: seth | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.7 Component: Bro | Version: Keywords: | --------------------+-------------------- It would help us to integrate with other tools. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 18 20:03:06 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 04:03:06 -0000 Subject: [Bro-Dev] #264: Experimental MPLS support. In-Reply-To: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org> References: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org> Message-ID: <059.c02f3a72afbb6da6e06af7abda686fb5@tracker.icir.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: sprint ---------------------+-------------------- Comment (by seth): Question for the sprint (after looking over this code a bit).... should it be possible to define mpls and vlan tags at the same time? The mpls branch doesn't support this currently. I think we should probably support this since it should be easy to do. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 18 20:46:15 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 04:46:15 -0000 Subject: [Bro-Dev] #267: Patch to fix internal log_encryption_key handling In-Reply-To: <043.efcd269209695b49b3d8f0ada56409ce@tracker.icir.org> References: <043.efcd269209695b49b3d8f0ada56409ce@tracker.icir.org> Message-ID: <058.401d6953e7ec90e06e14065d9fd66545@tracker.icir.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: sprint ---------------------+-------------------- Comment (by seth): Replying to [comment:2 robin]: > What was the problem here? The original way of accessing the variable should work. Not sure. It was giving me this error.. {{{ Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000030 0x00000001000958a9 in Val::AsString (this=0x0) at Val.h:241 241 CONST_ACCESSOR(TYPE_STRING, BroString*, string_val, AsString) (gdb) bt #0 0x00000001000958a9 in Val::AsString (this=0x0) at Val.h:241 #1 0x000000010012f5db in BroFile::SetAttrs (this=0x100bd02b0, arg_attrs=0x100bd0140) at /Users/seth/bro/bro.git/src/File.cc:503 #2 0x00000001001666fb in ID::UpdateValAttrs (this=0x100bcfb90) at /Users/seth/bro/bro.git/src/ID.cc:221 #3 0x0000000100235b2b in make_var (id=0x100bcfb90, t=0x100986060, c=INIT_FULL, init=0x100bcffd0, attr=0x100bd00d0, dt=VAR_REGULAR, do_init=1) at /Users/seth/bro/bro.git/src/Var.cc:172 #4 0x0000000100235eaf in add_global (id=0x100bcfb90, t=0x0, c=INIT_FULL, init=0x100bcffd0, attr=0x100bd00d0, dt=VAR_REGULAR) at /Users/seth/bro/bro.git/src/Var.cc:179 #5 0x000000010008331f in yyparse () at parse.y:800 #6 0x000000010009365a in main (argc=2, argv=0x7fff5fbfeee8) at /Users/seth/bro/bro.git/src/main.cc:741 (gdb) up #1 0x000000010012f5db in BroFile::SetAttrs (this=0x100bd02b0, arg_attrs=0x100bd0140) at /Users/seth/bro/bro.git/src/File.cc:503 503 InitEncrypt(log_encryption_key->AsString()->CheckString()); (gdb) down #0 0x00000001000958a9 in Val::AsString (this=0x0) at Val.h:241 241 CONST_ACCESSOR(TYPE_STRING, BroString*, string_val, AsString) (gdb) print this $1 = (const Val * const) 0x0 }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 07:11:00 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 15:11:00 -0000 Subject: [Bro-Dev] #328: topic/runtime-patterns - Enable pattern construction during init time (was: Patch to add programmatic pattern construction at init time.) In-Reply-To: <043.f9c865007fdbbe40274ceab20806264f@tracker.icir.org> References: <043.f9c865007fdbbe40274ceab20806264f@tracker.icir.org> Message-ID: <058.040aa5b63c1644e7a761015389f7e8a4@tracker.icir.org> #328: topic/runtime-patterns - Enable pattern construction during init time ----------------------------+---------------------- Reporter: seth | Owner: robin Type: Merge Request | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: sprint ----------------------------+---------------------- Changes (by seth): * type: Patch => Merge Request Comment: CHANGES message: {{{ Programmatic pattern construction at initialization time is now enabled with the BiFs string_to_pattern and merge_pattern. }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 07:38:44 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 15:38:44 -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.d2da8abfb18c534829576cc3f204b5f5@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: sprint -------------------------+---------------------- Comment (by seth): Topic branch at topic/bro_dns_fake_message. Output looks like this... {{{ $BRO_DNS_FAKE | enable faked DNS query responses () }}} The value BRO_DNS_FAKE is set to is placed in the parens at the end of the line. Thoughts on the approach are welcome. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 08:25:26 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 16:25:26 -0000 Subject: [Bro-Dev] #354: Allow analyser to process partial HTTP connections. Message-ID: <052.ab31f68f582bf8f7f004c3896a1c2d98@tracker.icir.org> #354: Allow analyser to process partial HTTP connections. ---------------------------+----------------------------- Reporter: sridhar.basam | Type: Feature Request Status: new | Priority: Normal Milestone: | Component: Bro Version: | Keywords: ---------------------------+----------------------------- By default the HTTP analyser doesn't process packets where bro did not see the initial handshake. I got a couple of 1 line patches from Vern to fix it. Can we roll this into a future release? Sridhar -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 08:30:00 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 16:30:00 -0000 Subject: [Bro-Dev] #354: Allow analyser to process partial HTTP connections. In-Reply-To: <052.ab31f68f582bf8f7f004c3896a1c2d98@tracker.icir.org> References: <052.ab31f68f582bf8f7f004c3896a1c2d98@tracker.icir.org> Message-ID: <067.382dcc1b607b62be7059a14a2fdc71ca@tracker.icir.org> #354: Allow analyser to process partial HTTP connections. ------------------------------+----------------- Reporter: sridhar.basam | Owner: Type: Feature Request | Status: new Priority: Normal | Milestone: Component: Bro | Version: Resolution: | Keywords: ------------------------------+----------------- Old description: > By default the HTTP analyser doesn't process packets where bro did not > see the initial handshake. I got a couple of 1 line patches from Vern to > fix it. Can we roll this into a future release? > > Sridhar New description: By default the HTTP analyser doesn't process packets where bro did not see the initial handshake. I got a couple of 1 line patches from Vern to fix it. Can we roll this into a future release? Sridhar -- Comment (by seth): This is a fairly large change in semantics for how Bro currently functions and I'm curious what your motivation for this change is. Can you give an example of the conditions where this is causing a problem for you? -- Ticket URL: Bro Tracker Bro Issue Tracker From sri at basam.org Wed Jan 19 08:40:44 2011 From: sri at basam.org (sridhar basam) Date: Wed, 19 Jan 2011 11:40:44 -0500 Subject: [Bro-Dev] #354: Allow analyser to process partial HTTP connections. In-Reply-To: <067.382dcc1b607b62be7059a14a2fdc71ca@tracker.icir.org> References: <052.ab31f68f582bf8f7f004c3896a1c2d98@tracker.icir.org> <067.382dcc1b607b62be7059a14a2fdc71ca@tracker.icir.org> Message-ID: On Wed, Jan 19, 2011 at 11:30 AM, Bro Tracker wrote: > #354: Allow analyser to process partial HTTP connections. > ------------------------------+----------------- > Reporter: sridhar.basam | Owner: > Type: Feature Request | Status: new > Priority: Normal | Milestone: > Component: Bro | Version: > Resolution: | Keywords: > ------------------------------+----------------- > > Old description: > > > By default the HTTP analyser doesn't process packets where bro did not > > see the initial handshake. I got a couple of 1 line patches from Vern to > > fix it. Can we roll this into a future release? > > > > Sridhar > > New description: > > By default the HTTP analyser doesn't process packets where bro did not see > the initial handshake. I got a couple of 1 line patches from Vern to fix > it. Can we roll this into a future release? > > Sridhar > > -- > > Comment (by seth): > > This is a fairly large change in semantics for how Bro currently functions > and I'm curious what your motivation for this change is. Can you give an > example of the conditions where this is causing a problem for you? > > -- > Ticket URL: > Bro Tracker > Bro Issue Tracker > I have applications which use a persistant HTTP connections to talk to upstream services. These connections live for a really long time, thousands/tens of thousands of requests on a single tcp connection. I use bro to analyse http request and replies for these applications. I need the ability to run the analyser for these partial connections in the pcap file. Sridhar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20110119/7fdaaffa/attachment.html From bro at tracker.icir.org Wed Jan 19 08:48:26 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 16:48:26 -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.b8d71d79faa54c25334eee0ac36bca84@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 sprint ---------------------+----------------------------------- Comment (by seth): There is branch named topic/seth/ssl-analyzer-work that has these changes along with more known ciphers and probably other changes I'm not remembering at the moment. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 09:04:36 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 17:04:36 -0000 Subject: [Bro-Dev] #354: Allow analyser to process partial HTTP connections. In-Reply-To: <052.ab31f68f582bf8f7f004c3896a1c2d98@tracker.icir.org> References: <052.ab31f68f582bf8f7f004c3896a1c2d98@tracker.icir.org> Message-ID: <067.562bb8d70691150efa66973758543f25@tracker.icir.org> #354: Allow analyser to process partial HTTP connections. ------------------------------+----------------- Reporter: sridhar.basam | Owner: Type: Feature Request | Status: new Priority: Normal | Milestone: Component: Bro | Version: Resolution: | Keywords: ------------------------------+----------------- Comment (by seth): From Sridhar: > I have applications which use a persistant HTTP connections to > talk to upstream services. These connections live for a really long > time, thousands/tens of thousands of requests on a single tcp > connection. I use bro to analyse http request and replies for these > applications. I need the ability to run the analyser for these > partial connections in the pcap file. Ah! I totally understand your frustration with this behavior then. We'll make sure and discuss this for the 1.6 release. It's definitely not going to make it into a 1.5.x release for the reasons that Robin mentioned previously. Thanks for following up. That's a great example for this ticket. .Seth -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 09:33:22 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 17:33:22 -0000 Subject: [Bro-Dev] #291: lookup_addr() only supports IPv4 addresses In-Reply-To: <044.ac2fb4cb11fcfbae75d1e9c96c3f1a02@tracker.icir.org> References: <044.ac2fb4cb11fcfbae75d1e9c96c3f1a02@tracker.icir.org> Message-ID: <059.8c3f907d4ee820410d75e68075d79d05@tracker.icir.org> #291: lookup_addr() only supports IPv4 addresses ----------------------+-------------------- Reporter: leres | Owner: Type: Problem | Status: seen Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.1 Resolution: | Keywords: sprint ----------------------+-------------------- Comment (by robin): I'm fixing this with a work-around for now that warns the user once, and doesn't return any results in the v6 case. Going to open a new ticket for the real fix. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 09:36:34 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 17:36:34 -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.b51e4a24ea88679be118575cde03b876@tracker.icir.org> #263: --enable-int64 breaks bropipe ------------------------------+----------------------- Reporter: ssakai@? | Owner: christian Type: defect | Status: assigned Priority: High | Milestone: Bro1.6 Component: Bro | Version: 1.5.1 Resolution: | Keywords: inttypes ------------------------------+----------------------- Changes (by seth): * priority: Low => High Comment: Just noticed that this is categorized as a low priority item. It's actually very high priority for 1.6. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 09:40:59 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 17:40:59 -0000 Subject: [Bro-Dev] #355: lookup_addr() only supports IPv4 addresses Message-ID: <044.0ce69ee37c5d63609723d72c28234976@tracker.icir.org> #355: lookup_addr() only supports IPv4 addresses ---------------------+-------------------- Reporter: robin | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.7 Component: Bro | Version: Keywords: ipv6 | ---------------------+-------------------- We fixed Bro crashing with a work-around in #291, but the problem remains and needs to be addressed when we cleanup IPv6 support. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 10:02:50 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 18:02:50 -0000 Subject: [Bro-Dev] #356: Unidirectional MPLS tags, VLAN tags, and raw ethernet Message-ID: <043.eb12a774d481e57eb2f1a8245cb9fdf8@tracker.icir.org> #356: Unidirectional MPLS tags, VLAN tags, and raw ethernet -------------------------------+------------------------ Reporter: seth | Owner: Type: Test Case Missing | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Keywords: | -------------------------------+------------------------ The tracefile attached to this ticket includes unidirectional MPLS tags, bidirectional VLAN tags, and raw ethernet encapsulated IP packets. Bro should be able to handle all of the packets in this tracefile without problems. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 11:15:36 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 19:15:36 -0000 Subject: [Bro-Dev] #291: fastpath: lookup_addr() only supports IPv4 addresses (was: lookup_addr() only supports IPv4 addresses) In-Reply-To: <044.ac2fb4cb11fcfbae75d1e9c96c3f1a02@tracker.icir.org> References: <044.ac2fb4cb11fcfbae75d1e9c96c3f1a02@tracker.icir.org> Message-ID: <059.8a662df899dd3efdb92a4d3dad4c8fc4@tracker.icir.org> #291: fastpath: lookup_addr() only supports IPv4 addresses ----------------------------+-------------------- Reporter: leres | Owner: Type: Merge Request | Status: seen Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.1 Resolution: | Keywords: sprint ----------------------------+-------------------- Changes (by robin): * type: Problem => Merge Request -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 11:22:51 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 19:22:51 -0000 Subject: [Bro-Dev] #357: Only log missing support for libgeoip a single time. Message-ID: <043.5e3eefc4db47729fe7e887317f7619e6@tracker.icir.org> #357: Only log missing support for libgeoip a single time. ---------------------+------------------------ Reporter: seth | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Keywords: sprint | ---------------------+------------------------ I've seen too many people with logs that are full of messages indicating no support for libgeoip. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 11:50:40 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 19:50:40 -0000 Subject: [Bro-Dev] #338: fastpath: Start time semantics in ConnCompressor when seeing multiple SYNs (was: Start time semantics in ConnCompressor when seeing multiple SYNs) In-Reply-To: <045.d47f21f1434fb366c8024e70fefc463d@tracker.icir.org> References: <045.d47f21f1434fb366c8024e70fefc463d@tracker.icir.org> Message-ID: <060.0814aa0b12eef7f34380e1b3affe372b@tracker.icir.org> #338: fastpath: Start time semantics in ConnCompressor when seeing multiple SYNs ----------------------------+-------------------- Reporter: gregor | Owner: Type: Merge Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: sprint ----------------------------+-------------------- Changes (by robin): * type: Problem => Merge Request -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 11:53:07 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 19:53:07 -0000 Subject: [Bro-Dev] #330: fastpath: Nit: portmapper.bro needs to load scan.bro (was: Nit: portmapper.bro needs to load scan.bro) In-Reply-To: <045.6906275de61b10a445ed6ef3638fd852@tracker.icir.org> References: <045.6906275de61b10a445ed6ef3638fd852@tracker.icir.org> Message-ID: <060.cea4de3c1b2697c40746a693b31fea0d@tracker.icir.org> #330: fastpath: Nit: portmapper.bro needs to load scan.bro ----------------------------+------------------------ Reporter: gregor | Owner: Type: Merge Request | Status: new Priority: Low | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: | Keywords: sprint ----------------------------+------------------------ Changes (by robin): * type: Problem => Merge Request Comment: Just adding the load for now, seems the rest is an indepedent problem. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 12:25:23 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 20:25:23 -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.5ef7f94705640aa5076a680f05e0cb26@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: sprint -------------------------+-------------------- Comment (by robin): I simply removing this output in Bro. Nobody is getting any use out if it anyway. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 12:29:20 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 20:29:20 -0000 Subject: [Bro-Dev] #329: Optimizing detect-protocols.bro (was: Remove detect-protocols-http.bro from Broctl's default local.bro) In-Reply-To: <043.4171f047fca9bbca4e3e8c6e560433d7@tracker.icir.org> References: <043.4171f047fca9bbca4e3e8c6e560433d7@tracker.icir.org> Message-ID: <058.a77627b0df65551f31fb2c79de433ca0@tracker.icir.org> #329: Optimizing detect-protocols.bro ---------------------+-------------------- Reporter: seth | Owner: robin Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: sprint ---------------------+-------------------- Changes (by robin): * component: BroControl => Bro Comment: Giving the ticket a new title, and moving to Bro. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 12:40:43 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 20:40:43 -0000 Subject: [Bro-Dev] #222: Patch to fix scaling factor in prettyPrintVal In-Reply-To: <043.c05e54f6c2d35bb4b8dd9e710044ca89@tracker.icir.org> References: <043.c05e54f6c2d35bb4b8dd9e710044ca89@tracker.icir.org> Message-ID: <058.43d24377a0973ad24347b9a927964f2c@tracker.icir.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: sprint -------------------------+-------------------- -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 12:40:43 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 20:40:43 -0000 Subject: [Bro-Dev] #224: Patch to make cluster events redef-able In-Reply-To: <043.6a95a8887f1a2a867594821e13021bb6@tracker.icir.org> References: <043.6a95a8887f1a2a867594821e13021bb6@tracker.icir.org> Message-ID: <058.9e6508b9b24e3cc8211829a1562cb391@tracker.icir.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: sprint -------------------------+-------------------- -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 12:40:43 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 20:40:43 -0000 Subject: [Bro-Dev] #208: broctl netstats broken on cluster In-Reply-To: <045.45796dd3abfdc9eb556105893bafacf5@tracker.icir.org> References: <045.45796dd3abfdc9eb556105893bafacf5@tracker.icir.org> Message-ID: <060.416c56b00cc4f70a188fa043c82c2973@tracker.icir.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,sprint -------------------------+------------------------------------- -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 12:40:44 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 20:40:44 -0000 Subject: [Bro-Dev] #289: Crash in broctl due to missing lockfile. In-Reply-To: <043.917fec1d31d25ef8a59f31d1c7cfc5d2@tracker.icir.org> References: <043.917fec1d31d25ef8a59f31d1c7cfc5d2@tracker.icir.org> Message-ID: <058.b57432aa8c45467153893947103a582c@tracker.icir.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: sprint -------------------------+-------------------- -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 12:40:44 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 20:40:44 -0000 Subject: [Bro-Dev] #293: scripts/local-interfaces cannot find ifconfig In-Reply-To: <047.ac9986b0dbc785e69d293483a6ce99e7@tracker.icir.org> References: <047.ac9986b0dbc785e69d293483a6ce99e7@tracker.icir.org> Message-ID: <062.b86cc5a487db0ded04da745b59b189da@tracker.icir.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: sprint -------------------------+-------------------- -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 13:00:54 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 21:00:54 -0000 Subject: [Bro-Dev] #336: topic/seth/mpls -- Global config variable to disable packet filtering (i.e., accept all packets) (was: Global config variable to disable packet filtering (i.e., accept all packets)) In-Reply-To: <045.52e9f4c6d1c96231af2e6b5c4bcf4038@tracker.icir.org> References: <045.52e9f4c6d1c96231af2e6b5c4bcf4038@tracker.icir.org> Message-ID: <060.3bb4dfb499604277e2b3f6384a1e374f@tracker.icir.org> #336: topic/seth/mpls -- Global config variable to disable packet filtering (i.e., accept all packets) ----------------------------+-------------------- Reporter: gregor | Owner: Type: Merge Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: sprint ----------------------------+-------------------- Changes (by seth): * type: Feature Request => Merge Request Comment: Branch name for merging added to the summary. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 13:10:43 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 21:10:43 -0000 Subject: [Bro-Dev] #257: topic/bro_dns_fake_message - Commandline flag to enable BRO_FAKE_DNS (was: Commandline flag to enable BRO_FAKE_DNS) In-Reply-To: <049.463a3aa2505ed0b2731a01396c4cbef8@tracker.icir.org> References: <049.463a3aa2505ed0b2731a01396c4cbef8@tracker.icir.org> Message-ID: <064.71a7467f0e19a20b4993792b55e64fa2@tracker.icir.org> #257: topic/bro_dns_fake_message - Commandline flag to enable BRO_FAKE_DNS ----------------------------+---------------------- Reporter: brosenberg | Owner: vern Type: Merge Request | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: sprint ----------------------------+---------------------- Changes (by seth): * type: Patch => Merge Request Comment: Changing this ticket to a merge request. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 13:13:51 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 21:13:51 -0000 Subject: [Bro-Dev] #264: topic/seth/mpls - Experimental MPLS support. (was: Experimental MPLS support.) In-Reply-To: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org> References: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org> Message-ID: <059.c90897e1e99951487fa9ac274dcc2296@tracker.icir.org> #264: topic/seth/mpls - Experimental MPLS support. ---------------------+-------------------- Reporter: robin | Owner: Type: Patch | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.1 Resolution: | Keywords: sprint ---------------------+-------------------- Comment (by seth): This code seems ready to merge but really be checked over for sanity since it rewrites part of the core packet extraction method. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 13:15:05 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 21:15:05 -0000 Subject: [Bro-Dev] #358: topic/jsiwek/macports-fink-fix Message-ID: <045.83037a0d6db75e6aea7cab74c9ad64cb@tracker.icir.org> #358: topic/jsiwek/macports-fink-fix ---------------------------+------------------------ Reporter: jsiwek | Owner: Type: Merge Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Keywords: | ---------------------------+------------------------ This branch exists on all Bro submodules (recursively). It changes the behavior of how dependencies are found when building on Macs. The default !MacPorts (/opt/local) and Fink (/sw) are now searched ahead of standard locations (/usr). For users of !MacPorts and Fink this should result in consistently pulling in the same dependencies at configure time as well as build time. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 13:15:38 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 21:15:38 -0000 Subject: [Bro-Dev] #336: topic/seth/mpls -- Global config variable to disable packet filtering (i.e., accept all packets) In-Reply-To: <045.52e9f4c6d1c96231af2e6b5c4bcf4038@tracker.icir.org> References: <045.52e9f4c6d1c96231af2e6b5c4bcf4038@tracker.icir.org> Message-ID: <060.ffeb8bd77a025d9af3b5d3ea474c187a@tracker.icir.org> #336: topic/seth/mpls -- Global config variable to disable packet filtering (i.e., accept all packets) ----------------------------+-------------------- Reporter: gregor | Owner: Type: Merge Request | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: Solved | Keywords: sprint ----------------------------+-------------------- Changes (by seth): * status: new => closed * resolution: => Solved Comment: I'm going to close this ticket since I implemented the feature in the MPLS branch, ticket #264. -- Ticket URL: Bro Tracker Bro Issue Tracker From jmellander at lbl.gov Wed Jan 19 13:17:56 2011 From: jmellander at lbl.gov (Jim Mellander) Date: Wed, 19 Jan 2011 13:17:56 -0800 Subject: [Bro-Dev] Running Linux non-SUID on Linux Message-ID: Hi gang: I've been helping someone install Bro on Linux, and we don't want to go the SUID route, and thought that by using setcap to set cap_net_raw on the binary, it would work, but Bro startup copies the binary to a temp directory, which loses all privileges - here's the communication from the user: One piece that I'm running into issues with though is the cap-net-raw stuff and how broctl starts up. The error I get when attempting to start is ==== stderr.log /usr/local/bro/spool/tmp/bro: problem with interface eth4 -pcap_open_live: socket: Operation not permitted If I setcap cap_net_raw+ei /usr/local/bro/spool/tmp/bro, it appears to set things up properly, but they don't stick. In looking deeper, the start process in broctl purges that spool/tmp directory then copies the executable back into that space. The result is that the setcap is gone. Has this been addressed somewhere, or do I go digging deeper? ==================================================================== One thing I thought of was to write a custom SUID root program whose only function is to set the capabilities on the binary in the temp directory (hard coded into the SUID program, for securities sake), and run it just after the copy..... Any ideas, suggestions? From jmellander at lbl.gov Wed Jan 19 14:14:03 2011 From: jmellander at lbl.gov (Jim Mellander) Date: Wed, 19 Jan 2011 14:14:03 -0800 Subject: [Bro-Dev] Running Bro nonSUID on Linux Message-ID: Hi gang: I've been helping someone install Bro on Linux, and we don't want to go the SUID route, and thought that by using setcap to set cap_net_raw on the binary, it would work, but Bro startup copies the binary to a temp directory, which loses all privileges - here's the communication from the user: One piece that I'm running into issues with though is the cap-net-raw stuff and how broctl starts up. The error I get when attempting to start is ==== stderr.log /usr/local/bro/spool/tmp/bro: problem with interface eth4 -pcap_open_live: socket: Operation not permitted If I setcap cap_net_raw+ei /usr/local/bro/spool/tmp/bro, it appears to set things up properly, but they don't stick. In looking deeper, the start process in broctl purges that spool/tmp directory then copies the executable back into that space. The result is that the setcap is gone. Has this been addressed somewhere, or do I go digging deeper? ==================================================================== One thing I thought of was to write a custom SUID root program whose only function is to set the capabilities on the binary in the temp directory (hard coded into the SUID program, for securities sake), and run it just after the copy..... Any ideas, suggestions? From jmellander at lbl.gov Wed Jan 19 14:31:12 2011 From: jmellander at lbl.gov (Jim Mellander) Date: Wed, 19 Jan 2011 14:31:12 -0800 Subject: [Bro-Dev] Running Bro non-SUID on Linux Message-ID: Hi gang: I've been helping someone install Bro on Linux, and we don't want to go the SUID route, and thought that by using setcap to set cap_net_raw on the binary, it would work, but Bro startup copies the binary to a temp directory, which loses all privileges - here's the communication from the user: One piece that I'm running into issues with though is the cap-net-raw stuff and how broctl starts up. The error I get when attempting to start is ==== stderr.log /usr/local/bro/spool/tmp/bro: problem with interface eth4 - pcap_open_live: socket: Operation not permitted If I setcap cap_net_raw+ei /usr/local/bro/spool/tmp/bro, it appears to set things up properly, but they don't stick. In looking deeper, the start process in broctl purges that spool/tmp directory then copies the executable back into that space. The result is that the setcap is gone. Has this been addressed somewhere, or do I go digging deeper? ==================================================================== One thing I thought of was to write a custom SUID root program whose only function is to set the capabilities on the binary in the temp directory (hard coded into the SUID program, for securities sake), and run it just after the copy..... Any ideas, suggestions? From bro at tracker.icir.org Wed Jan 19 15:08:03 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 19 Jan 2011 23:08:03 -0000 Subject: [Bro-Dev] #350: topic/jsiwek/packaging In-Reply-To: <045.9e4d7dc5383e7486f68e28aab57a0fef@tracker.icir.org> References: <045.9e4d7dc5383e7486f68e28aab57a0fef@tracker.icir.org> Message-ID: <060.98b4e652dc87ac5c3616288c95b897f5@tracker.icir.org> #350: topic/jsiwek/packaging ----------------------------+------------------------ Reporter: jsiwek | Owner: Type: Merge Request | Status: reopened Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: | Keywords: ----------------------------+------------------------ Changes (by jsiwek): * status: closed => reopened * resolution: Merged => Comment: Re-opened for another merge of this branch in bro, broctl, and broccoli repositories. Changed behavior of how binary packaging installs config files. The pre/post install scripts for RPMs should not perform any logic to backup config files, instead relying on the standard logic that RPMs normally do. For Mac packages, when an existing config file differs from the package's version, the previous version is always kept and an alert is displayed to the user explaining the situation. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 17:18:28 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 01:18:28 -0000 Subject: [Bro-Dev] #291: fastpath: lookup_addr() only supports IPv4 addresses In-Reply-To: <044.ac2fb4cb11fcfbae75d1e9c96c3f1a02@tracker.icir.org> References: <044.ac2fb4cb11fcfbae75d1e9c96c3f1a02@tracker.icir.org> Message-ID: <059.68291aa443bab468e8e451d75e319e2b@tracker.icir.org> #291: fastpath: lookup_addr() only supports IPv4 addresses -----------------------------+-------------------- Reporter: leres | Owner: Type: Merge Request | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.1 Resolution: Merged/Applied | Keywords: sprint -----------------------------+-------------------- Changes (by robin): * status: seen => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 17:18:28 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 01:18:28 -0000 Subject: [Bro-Dev] #330: fastpath: Nit: portmapper.bro needs to load scan.bro In-Reply-To: <045.6906275de61b10a445ed6ef3638fd852@tracker.icir.org> References: <045.6906275de61b10a445ed6ef3638fd852@tracker.icir.org> Message-ID: <060.1cd132b34c5f49d7e4c27f00f45226bc@tracker.icir.org> #330: fastpath: Nit: portmapper.bro needs to load scan.bro -----------------------------+------------------------ Reporter: gregor | Owner: Type: Merge Request | Status: closed Priority: Low | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: Merged/Applied | Keywords: sprint -----------------------------+------------------------ Changes (by robin): * status: new => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 17:18:28 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 01:18:28 -0000 Subject: [Bro-Dev] #338: fastpath: Start time semantics in ConnCompressor when seeing multiple SYNs In-Reply-To: <045.d47f21f1434fb366c8024e70fefc463d@tracker.icir.org> References: <045.d47f21f1434fb366c8024e70fefc463d@tracker.icir.org> Message-ID: <060.58eca02afcce700f31d55d82667a7348@tracker.icir.org> #338: fastpath: Start time semantics in ConnCompressor when seeing multiple SYNs -----------------------------+-------------------- Reporter: gregor | Owner: Type: Merge Request | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: Merged/Applied | Keywords: sprint -----------------------------+-------------------- Changes (by robin): * status: new => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 17:31:34 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 01:31:34 -0000 Subject: [Bro-Dev] #257: topic/bro_dns_fake_message - Commandline flag to enable BRO_FAKE_DNS In-Reply-To: <049.463a3aa2505ed0b2731a01396c4cbef8@tracker.icir.org> References: <049.463a3aa2505ed0b2731a01396c4cbef8@tracker.icir.org> Message-ID: <064.2f4b2ac61a635624d54521d704bac043@tracker.icir.org> #257: topic/bro_dns_fake_message - Commandline flag to enable BRO_FAKE_DNS -----------------------------+-------------------- Reporter: brosenberg | Owner: vern Type: Merge Request | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: Merged/Applied | Keywords: sprint -----------------------------+-------------------- Changes (by robin): * status: assigned => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 17:38:52 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 01:38:52 -0000 Subject: [Bro-Dev] #265: topic/robin/entropy - Entropy testing BiFs In-Reply-To: <043.8e334b34bdf23f9d7b102b8c4e3da6bd@tracker.icir.org> References: <043.8e334b34bdf23f9d7b102b8c4e3da6bd@tracker.icir.org> Message-ID: <058.5823e6cfa0c9e188d9b2eb3b4a579420@tracker.icir.org> #265: topic/robin/entropy - Entropy testing BiFs -----------------------------+-------------------- Reporter: seth | Owner: Type: Merge Request | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: Merged/Applied | Keywords: sprint -----------------------------+-------------------- Changes (by robin): * status: new => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 17:53:05 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 01:53:05 -0000 Subject: [Bro-Dev] #328: topic/runtime-patterns - Enable pattern construction during init time In-Reply-To: <043.f9c865007fdbbe40274ceab20806264f@tracker.icir.org> References: <043.f9c865007fdbbe40274ceab20806264f@tracker.icir.org> Message-ID: <058.db03409c996965e5bb8bf3147babe38f@tracker.icir.org> #328: topic/runtime-patterns - Enable pattern construction during init time -----------------------------+-------------------- Reporter: seth | Owner: robin Type: Merge Request | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: Merged/Applied | Keywords: sprint -----------------------------+-------------------- Changes (by robin): * status: assigned => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 18:00:42 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 02:00:42 -0000 Subject: [Bro-Dev] #346: topic/robin/global-attr - Removing "global_attrs" In-Reply-To: <044.88c585a8aac86616c08a16f732524101@tracker.icir.org> References: <044.88c585a8aac86616c08a16f732524101@tracker.icir.org> Message-ID: <059.7dba9d76692b84d35b074f8e7c61925b@tracker.icir.org> #346: topic/robin/global-attr - Removing "global_attrs" -----------------------------+-------------------- Reporter: robin | Owner: Type: Merge Request | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: Merged/Applied | Keywords: sprint -----------------------------+-------------------- Changes (by robin): * status: new => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 18:13:34 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 02:13:34 -0000 Subject: [Bro-Dev] #358: topic/jsiwek/macports-fink-fix In-Reply-To: <045.83037a0d6db75e6aea7cab74c9ad64cb@tracker.icir.org> References: <045.83037a0d6db75e6aea7cab74c9ad64cb@tracker.icir.org> Message-ID: <060.55a9f4f81a1c8b1827005a084dd51a81@tracker.icir.org> #358: topic/jsiwek/macports-fink-fix -----------------------------+------------------------ Reporter: jsiwek | Owner: Type: Merge Request | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: Merged/Applied | Keywords: -----------------------------+------------------------ Changes (by robin): * status: new => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 18:13:48 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 02:13:48 -0000 Subject: [Bro-Dev] #350: topic/jsiwek/packaging In-Reply-To: <045.9e4d7dc5383e7486f68e28aab57a0fef@tracker.icir.org> References: <045.9e4d7dc5383e7486f68e28aab57a0fef@tracker.icir.org> Message-ID: <060.d9c1802759e49633e1de5fb500c6c20c@tracker.icir.org> #350: topic/jsiwek/packaging -----------------------------+------------------------ Reporter: jsiwek | Owner: Type: Merge Request | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: Merged/Applied | Keywords: -----------------------------+------------------------ Changes (by robin): * status: reopened => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 18:15:09 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 02:15:09 -0000 Subject: [Bro-Dev] #208: broctl netstats broken on cluster In-Reply-To: <045.45796dd3abfdc9eb556105893bafacf5@tracker.icir.org> References: <045.45796dd3abfdc9eb556105893bafacf5@tracker.icir.org> Message-ID: <060.6022d6780a8b9ff620db26da83ecd57c@tracker.icir.org> #208: broctl netstats broken on cluster -----------------------------+------------------------------------- Reporter: justin | Owner: robin Type: Patch | Status: closed Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: 1.5.2 Resolution: Merged/Applied | Keywords: netstats,cluster,sprint -----------------------------+------------------------------------- Changes (by robin): * status: assigned => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 18:15:09 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 02:15:09 -0000 Subject: [Bro-Dev] #222: Patch to fix scaling factor in prettyPrintVal In-Reply-To: <043.c05e54f6c2d35bb4b8dd9e710044ca89@tracker.icir.org> References: <043.c05e54f6c2d35bb4b8dd9e710044ca89@tracker.icir.org> Message-ID: <058.7c74b313ddaf3aaa95bfffa06da13cd2@tracker.icir.org> #222: Patch to fix scaling factor in prettyPrintVal -----------------------------+-------------------- Reporter: seth | Owner: robin Type: Patch | Status: closed Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: 1.5.2 Resolution: Merged/Applied | Keywords: sprint -----------------------------+-------------------- Changes (by robin): * status: new => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 18:15:09 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 02:15:09 -0000 Subject: [Bro-Dev] #224: Patch to make cluster events redef-able In-Reply-To: <043.6a95a8887f1a2a867594821e13021bb6@tracker.icir.org> References: <043.6a95a8887f1a2a867594821e13021bb6@tracker.icir.org> Message-ID: <058.ab09b3daee20041d24d348cf3de21253@tracker.icir.org> #224: Patch to make cluster events redef-able -----------------------------+-------------------- Reporter: seth | Owner: robin Type: Patch | Status: closed Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: 1.5.2 Resolution: Merged/Applied | Keywords: sprint -----------------------------+-------------------- Changes (by robin): * status: new => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 18:15:09 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 02:15:09 -0000 Subject: [Bro-Dev] #289: Crash in broctl due to missing lockfile. In-Reply-To: <043.917fec1d31d25ef8a59f31d1c7cfc5d2@tracker.icir.org> References: <043.917fec1d31d25ef8a59f31d1c7cfc5d2@tracker.icir.org> Message-ID: <058.ebaff918810d8fd375aef888fff84171@tracker.icir.org> #289: Crash in broctl due to missing lockfile. -----------------------------+-------------------- Reporter: seth | Owner: robin Type: Patch | Status: closed Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: 1.5.2 Resolution: Merged/Applied | Keywords: sprint -----------------------------+-------------------- Changes (by robin): * status: new => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 18:15:10 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 02:15:10 -0000 Subject: [Bro-Dev] #293: scripts/local-interfaces cannot find ifconfig In-Reply-To: <047.ac9986b0dbc785e69d293483a6ce99e7@tracker.icir.org> References: <047.ac9986b0dbc785e69d293483a6ce99e7@tracker.icir.org> Message-ID: <062.3bbe058c9f3338e2a61b62a8949160f8@tracker.icir.org> #293: scripts/local-interfaces cannot find ifconfig -----------------------------+-------------------- Reporter: vallenti | Owner: robin Type: Problem | Status: closed Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: 1.5.1 Resolution: Merged/Applied | Keywords: sprint -----------------------------+-------------------- Changes (by robin): * status: new => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 19 18:15:09 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 02:15:09 -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.e04f4e23716054cacd6d917aba72fbec@tracker.icir.org> #292: Cluttering of alarm.log with serialization messages -----------------------------+-------------------- Reporter: vallenti | Owner: robin Type: Problem | Status: closed Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: 1.5.1 Resolution: Merged/Applied | Keywords: sprint -----------------------------+-------------------- Changes (by robin): * status: new => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From robin at icir.org Wed Jan 19 18:21:02 2011 From: robin at icir.org (Robin Sommer) Date: Wed, 19 Jan 2011 18:21:02 -0800 Subject: [Bro-Dev] Git notifications for master Message-ID: <20110120022102.GT50421@icir.org> I'm just realizing that the logic the git-notifications script uses for deciding when to send a diff, will often not produce one for changes to master. That's because with a merge, the commit has already been seen before and thus the assumption is that the diff has already been mailed out. I will change the script to always mail out diffs for everything going into master, even if we have already seen it before. 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 Jan 19 21:09:29 2011 From: robin at icir.org (Robin Sommer) Date: Wed, 19 Jan 2011 21:09:29 -0800 Subject: [Bro-Dev] config.status Message-ID: <20110120050929.GU50421@icir.org> Jon, I have another feature request regarding the CMake setup. With autotools, one gets a config.status file that when run recreates a configuration including all the configure options. That's quite handy, and not for the least because one can easily check how exactly one ran configure last time (prefix, debug enabled, etc.) Can we add something like that to the CMake setup? I'm thinking all it needs to be is actually the exact configure call written into a file and made executable. However, ideally that would not end up in the build directory because they it won't survive a make distclean. 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 Jan 20 04:41:38 2011 From: seth at icir.org (Seth Hall) Date: Thu, 20 Jan 2011 07:41:38 -0500 Subject: [Bro-Dev] Running Bro non-SUID on Linux In-Reply-To: References: Message-ID: <43BE2010-E2EB-4FA3-B4C1-01713749C615@icir.org> On Jan 19, 2011, at 5:31 PM, Jim Mellander wrote: > I've been helping someone install Bro on Linux, and we don't want to > go the SUID route, and thought that by using setcap to set cap_net_raw > on the binary, it would work, but Bro startup copies the binary to a > temp directory, which loses all privileges - here's the communication > from the user: I think that Justin has a patch for Bro that drops privileges after starting up. It's possible that we could just integrate that patch since it was a very small change, only something around 5 lines if I remember correctly. The addition to BroControl should be really small and easy too. Justin, could you file a tracker ticket if you still have that patch floating around somewhere? .Seth -- Seth Hall International Computer Science Institute (Bro) because everyone has a network http://www.bro-ids.org/ From gregor at icir.org Thu Jan 20 08:12:50 2011 From: gregor at icir.org (Gregor Maier) Date: Thu, 20 Jan 2011 08:12:50 -0800 Subject: [Bro-Dev] config.status In-Reply-To: <20110120050929.GU50421@icir.org> References: <20110120050929.GU50421@icir.org> Message-ID: <4D385F02.8040206@icir.org> On 1/19/11 21:09 , Robin Sommer wrote: > I have another feature request regarding the CMake setup. With > autotools, one gets a config.status file that when run recreates a > configuration including all the configure options. That's quite > handy, and not for the least because one can easily check how > exactly one ran configure last time (prefix, debug enabled, etc.) > Can we add something like that to the CMake setup? I'm thinking all > it needs to be is actually the exact configure call written into a > file and made executable. However, ideally that would not end up in > the build directory because they it won't survive a make distclean. Why doesn't the CMakeCache.txt file work? If you run cmake again with an exisiting CMakeCache.txt it should do exactly that. Maybe we could add an option to the configure script to just re-run cmake without changing and settings? I don't really like to have anything created during build-time that's not in build. This would be the only file that lives outside of build. And AFAIK the config.status files get's deleted when you do a "make distclean". (As it should, since distclean should get you to a the point you had just after extracting the distribution tarball). just my 2ct Gregor -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From robin at icir.org Thu Jan 20 08:50:23 2011 From: robin at icir.org (Robin Sommer) Date: Thu, 20 Jan 2011 08:50:23 -0800 Subject: [Bro-Dev] Running Bro non-SUID on Linux In-Reply-To: References: <43BE2010-E2EB-4FA3-B4C1-01713749C615@icir.org> Message-ID: <20110120165023.GA28125@icir.org> A number of things here: On Wed, Jan 19, 2011 at 14:31 -0800, you wrote: > I've been helping someone install Bro on Linux, and we don't want to > go the SUID route, and thought that by using setcap to set cap_net_raw > on the binary, it would work, but Bro startup copies the binary to a > temp directory, which loses all privileges Yeah, this copying has bitten people in the past. The reason for that is NFS, where running the original binary may cause trouble. Still, we might want to get rid of this, or make it optional, or keep it just to the NFS mode. Independent of that, is there a way to copy an executable while keeping its capabilities? > One thing I thought of was to write a custom SUID root program whose > only function is to set the capabilities on the binary in the temp > directory (hard coded into the SUID program, for securities sake), and > run it just after the copy..... Would work I guess, though we don't have a hook in broctl right now to trigger that so need'd to hack the script. On Thu, Jan 20, 2011 at 07:41 -0500, you wrote: > I think that Justin has a patch for Bro that drops privileges after > starting up. Yeah, that has been on my list for a while, we should definitly integrate it. 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 Jan 20 08:54:16 2011 From: robin at icir.org (Robin Sommer) Date: Thu, 20 Jan 2011 08:54:16 -0800 Subject: [Bro-Dev] config.status In-Reply-To: <4D385F02.8040206@icir.org> References: <20110120050929.GU50421@icir.org> <4D385F02.8040206@icir.org> Message-ID: <20110120165416.GB28125@icir.org> On Thu, Jan 20, 2011 at 08:12 -0800, you wrote: > Why doesn't the CMakeCache.txt file work? Because it doesn't show me the original configure parameters (which is also very convienient for copy&paste, say over to a different machine rather than having to copy the cache, which may or may not work). > And AFAIK the config.status files get's deleted when you do a "make > distclean". Yeah, I know, and I should have written "rm -rf build" instead of "make distlean". But ok, I think I can live with having this file being generated inside the build directiory. 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 Thu Jan 20 09:07:09 2011 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Thu, 20 Jan 2011 11:07:09 -0600 (CST) Subject: [Bro-Dev] config.status In-Reply-To: <20110120165416.GB28125@icir.org> Message-ID: <23420857.4.1295543225468.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > > And AFAIK the config.status files get's deleted when you do a "make > > distclean". > > Yeah, I know, and I should have written "rm -rf build" instead of > "make distlean". But ok, I think I can live with having this file > being generated inside the build directiory. I was also going to agree with Gregor's rationale of not polluting the source tree. Plus if one wants to use a single source tree for multiple build trees, then you either have to overwrite the config.status or start disambiguating like config.status.${builddir}. But yeah, I should be able to get it to create config.status's in build dirs. - Jon From robin at icir.org Thu Jan 20 09:08:36 2011 From: robin at icir.org (Robin Sommer) Date: Thu, 20 Jan 2011 09:08:36 -0800 Subject: [Bro-Dev] config.status In-Reply-To: <23420857.4.1295543225468.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <20110120165416.GB28125@icir.org> <23420857.4.1295543225468.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20110120170836.GD28125@icir.org> On Thu, Jan 20, 2011 at 11:07 -0600, you wrote: > the source tree. Plus if one wants to use a single source tree for > multiple build trees, then you either have to overwrite the > config.status or start disambiguating like > config.status.${builddir}. Good point. > But yeah, I should be able to get it to create config.status's in build dirs. Deal. :) Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From jmellander at lbl.gov Thu Jan 20 09:15:39 2011 From: jmellander at lbl.gov (Jim Mellander) Date: Thu, 20 Jan 2011 09:15:39 -0800 Subject: [Bro-Dev] Running Bro non-SUID on Linux In-Reply-To: <20110120165023.GA28125@icir.org> References: <43BE2010-E2EB-4FA3-B4C1-01713749C615@icir.org> <20110120165023.GA28125@icir.org> Message-ID: On Thu, Jan 20, 2011 at 8:50 AM, Robin Sommer wrote: > A number of things here: > > On Wed, Jan 19, 2011 at 14:31 -0800, you wrote: > >> I've been helping someone install Bro on Linux, and we don't want to >> go the SUID route, and thought that by using setcap to set cap_net_raw >> on the binary, it would work, but Bro startup copies the binary to a >> temp directory, which loses all privileges > > Yeah, this copying has bitten people in the past. The reason for > that is NFS, where running the original binary may cause trouble. > Still, we might want to get rid of this, or make it optional, or > keep it just to the NFS mode. I think modifying the script to make the copy an optional feature would be reasonable. > > Independent of that, is there a way to copy an executable while > keeping its capabilities? > >> One thing I thought of was to write a custom SUID root program whose >> only function is to set the capabilities on the binary in the temp >> directory (hard coded into the SUID program, for securities sake), and >> run it just after the copy..... > > Would work I guess, though we don't have a hook in broctl right now > to trigger that so need'd to hack the script. > > On Thu, Jan 20, 2011 at 07:41 -0500, you wrote: > >> I think that Justin has a patch for Bro that drops privileges after >> starting up. > > Yeah, that has been on my list for a while, we should definitly > integrate it. > > Robin > Well, I believe that copying an SUID-root as non-root will cause SUID to be dropped, so the copy still is a limiting factor. Interested in seeing the drop privilege code too, tho' Thanks to all!!!! From bro at tracker.icir.org Thu Jan 20 10:43:56 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 18:43:56 -0000 Subject: [Bro-Dev] #359: topic/jsiwek/add-config-status Message-ID: <045.033a6a37fac82056e0cf3bbef39519ab@tracker.icir.org> #359: topic/jsiwek/add-config-status ---------------------------+------------------------ Reporter: jsiwek | Owner: Type: Merge Request | Status: new Priority: Low | Milestone: Bro1.6 Component: Bro | Version: git/master Keywords: | ---------------------------+------------------------ This branch exists across all Bro submodules (recursively) except for trace-summary. It changes the configure wrapper to create a config.status file in the build directory containing the exact command used to configure that build. -- Ticket URL: Bro Tracker Bro Issue Tracker From seth at icir.org Thu Jan 20 11:42:56 2011 From: seth at icir.org (Seth Hall) Date: Thu, 20 Jan 2011 14:42:56 -0500 Subject: [Bro-Dev] --with-binpac Message-ID: This doesn't seem to work on the configure script. I have a separate binpac that I want use and it still builds and runs the one in the tree. .Seth From seth at icir.org Thu Jan 20 11:52:37 2011 From: seth at icir.org (Seth Hall) Date: Thu, 20 Jan 2011 14:52:37 -0500 Subject: [Bro-Dev] ccache Message-ID: <92E8FA51-0B7E-45D0-8DD5-35ACF92CD639@icir.org> People doing development on Bro may want to look into installing ccache. I can do a build after "make clean" in 22 seconds on my laptop now. I don't know if there is any potential to cause strange problem with ccache or not, but for the day to day builds and rebuilds it has been really nice. So far everything seems to be ok though. It's in MacPorts too, just make sure you add /opt/local/libexec/ccache to the beginning of your PATH so that you're running it's gcc/g++ shims instead of the actual gcc and g++. .Seth From jsiwek at ncsa.illinois.edu Thu Jan 20 11:55:15 2011 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Thu, 20 Jan 2011 13:55:15 -0600 (CST) Subject: [Bro-Dev] --with-binpac In-Reply-To: Message-ID: <6070057.26.1295553310962.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > This doesn't seem to work on the configure script. I have a separate > binpac that I want use and it still builds and runs the one in the > tree. Try this patch (to bro): $ git diff diff --git a/CMakeLists.txt b/CMakeLists.txt index 005c5ae..e048305 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -77,7 +77,8 @@ FindRequiredPackage(PCAP) FindRequiredPackage(OpenSSL) FindRequiredPackage(BIND) -if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/aux/binpac/CMakeLists.txt) +if (NOT BinPAC_ROOT_DIR AND + EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/aux/binpac/CMakeLists.txt) add_subdirectory(aux/binpac) endif () FindRequiredPackage(BinPAC) From seth at icir.org Thu Jan 20 12:12:25 2011 From: seth at icir.org (Seth Hall) Date: Thu, 20 Jan 2011 15:12:25 -0500 Subject: [Bro-Dev] fixing compiler warnings Message-ID: <94468298-2B2E-457B-9F6E-77C0DE88E90C@icir.org> There are a couple of issues left that I'm not sure what to do with them.... [ 36%] Building CXX object src/CMakeFiles/bro.dir/main.cc.o /Users/seth/bro/bro.git/src/main.cc: In function ?int main(int, char**)?: /Users/seth/bro/bro.git/src/main.cc:415: warning: deprecated conversion from string constant to ?char*? [ 70%] Building CXX object src/CMakeFiles/bro.dir/Sessions.cc.o /Users/seth/bro/bro.git/src/Sessions.cc: In member function ?void NetSessions::Internal(const char*, const pcap_pkthdr*, const u_char*)?: /Users/seth/bro/bro.git/src/Sessions.cc:1357: warning: format not a string literal and no format arguments If anyone would like to offer suggestions, I'm listening. :) .Seth From seth at icir.org Thu Jan 20 12:29:08 2011 From: seth at icir.org (Seth Hall) Date: Thu, 20 Jan 2011 15:29:08 -0500 Subject: [Bro-Dev] --with-binpac In-Reply-To: <6070057.26.1295553310962.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <6070057.26.1295553310962.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: On Jan 20, 2011, at 2:55 PM, Jonathan Siwek wrote: >> This doesn't seem to work on the configure script. I have a separate >> binpac that I want use and it still builds and runs the one in the >> tree. > > Try this patch (to bro): That worked! Thanks. One weird side effect is that if I do "make clean", and reconfigure without --with-binpac it still uses my separate out-of-tree binpac. I don't know if that matters or not, but it seems a little weird. .Seth From jsiwek at ncsa.illinois.edu Thu Jan 20 13:04:57 2011 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Thu, 20 Jan 2011 15:04:57 -0600 (CST) Subject: [Bro-Dev] --with-binpac In-Reply-To: Message-ID: <33494908.50.1295557495738.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > One weird side effect is that if I do "make clean", and reconfigure > without --with-binpac it still uses my separate out-of-tree binpac. I > don't know if that matters or not, but it seems a little weird. --with-binpac will set BinPAC_ROOT_DIR in the CMakeCache.txt and "make clean" doesn't get rid of it. At the moment I'm not sure if this behavior is going to be easily changed because it's actually a lot more pervasive than just --with-binpac. I think this occurs at least with the way most dependency libraries/headers will be found as well as some of the configure checks. It's probably also partly a downside to using a configure wrapper; I think using one of the standard cmake front-ends would allow you to directly set/unset any variable. You could also directly edit the cache, if you want. I thought I remember from my experiences with Autotools-based software, that it's usually recommended to do a distclean if you're going to be reconfiguring w/ significantly different choices? So translating that to CMake, I'd recommend starting from a new build directory (not necessarily deleting the original one; see the --builddir option). Is that cool w/ everyone? - Jon From bro at tracker.icir.org Thu Jan 20 13:14:24 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 21:14:24 -0000 Subject: [Bro-Dev] #349: Overly long timestamp segfault in cf In-Reply-To: <043.937b10beaedb8bac75a3aa2d574a5123@tracker.icir.org> References: <043.937b10beaedb8bac75a3aa2d574a5123@tracker.icir.org> Message-ID: <058.6648eabe49212d8396d75dcdf0f0cadc@tracker.icir.org> #349: Overly long timestamp segfault in cf ----------------------+-------------------- Reporter: seth | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: bro-aux | Version: Resolution: | Keywords: ----------------------+-------------------- Comment (by seth): Where did you get a version of cf that is version 1.2.1? -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 20 13:26:09 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 21:26:09 -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.a81474ee6bc0bf0aa10806c4e1feaa01@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 -------------------------+--------------------------- Comment (by seth): Robin and I discussed this a while ago and I think the general consensus was to remove the &redef attribute. It's sort of redundant with the export section now and we can just be sure to rewrite all of the scripts to put their redef-ables in the export section. &redef can also be applied to globals which doesn't exactly make sense and actually causes problems as this ticket demonstrates. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 20 13:31:30 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 21:31:30 -0000 Subject: [Bro-Dev] #86: topic/small_remote_connection_fix - Bro-Bro event communication tricky to test (was: Bro-Bro event communication tricky to test) In-Reply-To: <047.506ab4129936e190cc70d752016f502b@tracker.icir.org> References: <047.506ab4129936e190cc70d752016f502b@tracker.icir.org> Message-ID: <062.fd3c9394282e418466e79cce340d10e0@tracker.icir.org> #86: topic/small_remote_connection_fix - Bro-Bro event communication tricky to test -------------------------+------------------------------------------------- Reporter: kreibich | Owner: robin Type: Merge | Status: assigned Request | Milestone: Bro1.6 Priority: Low | Version: 1.5.2 Component: Bro | Keywords: Resolution: | communication,bro,schedule,event,sprint -------------------------+------------------------------------------------- Changes (by seth): * type: Problem => Merge Request Comment: Added the branch name to the summary and changed to a merge request. -- Ticket URL: Bro Tracker Bro Issue Tracker From seth at icir.org Thu Jan 20 13:50:47 2011 From: seth at icir.org (Seth Hall) Date: Thu, 20 Jan 2011 16:50:47 -0500 Subject: [Bro-Dev] enums in modules Message-ID: How would I refer to an enum type as type for an argument in a BiF or function? I have an enum named Logging::ID, and I want it to be the first argument in this BiF... function logging_log%(id: Logging::ID, rec: any%): bool That obviously doesn't parse though, are there any workarounds? .Seth From bro at tracker.icir.org Thu Jan 20 14:35:46 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 20 Jan 2011 22:35:46 -0000 Subject: [Bro-Dev] #272: topic/seth/strings-without-checkstring - Use Bytes() and Len() instead of CheckString() in strings.bif In-Reply-To: <043.1e378c2cf2d2f272b054d3bd5b2f44d9@tracker.icir.org> References: <043.1e378c2cf2d2f272b054d3bd5b2f44d9@tracker.icir.org> Message-ID: <058.b6f1474c525b6e00960ab7ebe1d98c13@tracker.icir.org> #272: topic/seth/strings-without-checkstring - Use Bytes() and Len() instead of CheckString() in strings.bif ----------------------------+---------------------- Reporter: seth | Owner: seth Type: Merge Request | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: sprint ----------------------------+---------------------- Comment (by robin): I've added a few smaller tweaks to the branch but I have trouble following do_split() (well, that's true for the original version as well). One question: In the inner loop with MatchPrefix(), n is decreased, but it's never reset later. Is that right? (offset is reset to zero at the beginning of the outer loop.). Also, I've added a check to strip(), please check. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 20 16:31:23 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 21 Jan 2011 00:31:23 -0000 Subject: [Bro-Dev] #86: topic/small_remote_connection_fix - Bro-Bro event communication tricky to test In-Reply-To: <047.506ab4129936e190cc70d752016f502b@tracker.icir.org> References: <047.506ab4129936e190cc70d752016f502b@tracker.icir.org> Message-ID: <062.0c8988d5609a6da4e76451c9f0c6d751@tracker.icir.org> #86: topic/small_remote_connection_fix - Bro-Bro event communication tricky to test -------------------------+------------------------------------------------- Reporter: kreibich | Owner: robin Type: Merge | Status: closed Request | Milestone: Bro1.6 Priority: Low | Version: 1.5.2 Component: Bro | Keywords: Resolution: | communication,bro,schedule,event,sprint Merged/Applied | -------------------------+------------------------------------------------- Changes (by robin): * status: assigned => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 20 16:34:15 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 21 Jan 2011 00:34:15 -0000 Subject: [Bro-Dev] #359: topic/jsiwek/add-config-status In-Reply-To: <045.033a6a37fac82056e0cf3bbef39519ab@tracker.icir.org> References: <045.033a6a37fac82056e0cf3bbef39519ab@tracker.icir.org> Message-ID: <060.b9f6db16bb6289c5df2376acd559f6cf@tracker.icir.org> #359: topic/jsiwek/add-config-status -----------------------------+------------------------ Reporter: jsiwek | Owner: Type: Merge Request | Status: closed Priority: Low | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: Merged/Applied | Keywords: -----------------------------+------------------------ Changes (by robin): * status: new => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From gregor at icir.org Thu Jan 20 17:33:52 2011 From: gregor at icir.org (Gregor Maier) Date: Thu, 20 Jan 2011 17:33:52 -0800 Subject: [Bro-Dev] fixing compiler warnings In-Reply-To: <94468298-2B2E-457B-9F6E-77C0DE88E90C@icir.org> References: <94468298-2B2E-457B-9F6E-77C0DE88E90C@icir.org> Message-ID: <4D38E280.2090406@icir.org> On 1/20/11 12:12 , Seth Hall wrote: > There are a couple of issues left that I'm not sure what to do with them.... > > [ 36%] Building CXX object src/CMakeFiles/bro.dir/main.cc.o > /Users/seth/bro/bro.git/src/main.cc: In function ?int main(int, char**)?: > /Users/seth/bro/bro.git/src/main.cc:415: warning: deprecated conversion from string constant to ?char*? int main(int argc, char *argv[]) might to the trick.... > [ 70%] Building CXX object src/CMakeFiles/bro.dir/Sessions.cc.o > /Users/seth/bro/bro.git/src/Sessions.cc: In member function ?void NetSessions::Internal(const char*, const pcap_pkthdr*, const u_char*)?: > /Users/seth/bro/bro.git/src/Sessions.cc:1357: warning: format not a string literal and no format arguments -internal_error(msg); +internal_error("%s", msg); On a different note wrt to integer format string warnings: These warnings tend to creep back in whenever you compile on a different platform that has different integers widths. AFAIK the only way to get really rid of them for good is to use the macros from inttypes.h But that's already flagged for the integer types cleanup in ticket #319 cu Gregor -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From gregor at icir.org Thu Jan 20 17:36:37 2011 From: gregor at icir.org (Gregor Maier) Date: Thu, 20 Jan 2011 17:36:37 -0800 Subject: [Bro-Dev] --with-binpac In-Reply-To: <33494908.50.1295557495738.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <33494908.50.1295557495738.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <4D38E325.2010103@icir.org> > I thought I remember from my experiences with Autotools-based software, that it's usually recommended to do a distclean if you're going to be reconfiguring w/ significantly different choices? So translating that to CMake, I'd recommend starting from a new build directory (not necessarily deleting the original one; see the --builddir option). Is that cool w/ everyone? The configure wrapper could maybe issue a warning if it is run as a reconfigure (i.e., if it's run and builddir already exists....) cu gregor -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From robin at icir.org Thu Jan 20 17:40:03 2011 From: robin at icir.org (Robin Sommer) Date: Thu, 20 Jan 2011 17:40:03 -0800 Subject: [Bro-Dev] fixing compiler warnings In-Reply-To: <4D38E280.2090406@icir.org> References: <94468298-2B2E-457B-9F6E-77C0DE88E90C@icir.org> <4D38E280.2090406@icir.org> Message-ID: <20110121014003.GC42874@icir.org> On Thu, Jan 20, 2011 at 17:33 -0800, you wrote: > platform that has different integers widths. AFAIK the only way to get > really rid of them for good is to use the macros from inttypes.h > But that's already flagged for the integer types cleanup in ticket #319 Haven't looked at Seth's changes yet, but this is indeed the best way to go about them. 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 Jan 20 18:30:13 2011 From: seth at icir.org (Seth Hall) Date: Thu, 20 Jan 2011 21:30:13 -0500 Subject: [Bro-Dev] --with-binpac In-Reply-To: <4D38E325.2010103@icir.org> References: <33494908.50.1295557495738.JavaMail.jsiwek@tangent.ncsa.illinois.edu> <4D38E325.2010103@icir.org> Message-ID: <23A24216-63ED-4F5A-9193-E77CE4F8A464@icir.org> On Jan 20, 2011, at 8:36 PM, Gregor Maier wrote: > The configure wrapper could maybe issue a warning if it is run as a > reconfigure (i.e., if it's run and builddir already exists....) That might be nice. It would at least be a good reminder when I (inevitably) do this in the future. .Seth From robin at icir.org Thu Jan 20 20:54:24 2011 From: robin at icir.org (Robin Sommer) Date: Thu, 20 Jan 2011 20:54:24 -0800 Subject: [Bro-Dev] Git notifications for master In-Reply-To: <20110120022102.GT50421@icir.org> References: <20110120022102.GT50421@icir.org> Message-ID: <20110121045424.GA83418@icir.org> On Wed, Jan 19, 2011 at 18:21 -0800, I wrote: > I will change the script to always mail out diffs for everything > going into master, even if we have already seen it before. ... and once I have done that, I'll also send retrospective diffs for the recent master changes for reference. 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 Fri Jan 21 08:31:09 2011 From: robin at icir.org (Robin Sommer) Date: Fri, 21 Jan 2011 08:31:09 -0800 Subject: [Bro-Dev] --with-binpac In-Reply-To: <23A24216-63ED-4F5A-9193-E77CE4F8A464@icir.org> References: <33494908.50.1295557495738.JavaMail.jsiwek@tangent.ncsa.illinois.edu> <4D38E325.2010103@icir.org> <23A24216-63ED-4F5A-9193-E77CE4F8A464@icir.org> Message-ID: <20110121163109.GE83418@icir.org> On Thu, Jan 20, 2011 at 21:30 -0500, you wrote: > That might be nice. It would at least be a good reminder when I (inevitably) do this in the future. Could the configure wrapper just decline to configure with a different set of options than last time (plus some advice on how to solve the problem)? Now that we have config.status, we already remember what was used before. 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 Jan 21 08:35:17 2011 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Fri, 21 Jan 2011 10:35:17 -0600 (CST) Subject: [Bro-Dev] --with-binpac In-Reply-To: <20110121163109.GE83418@icir.org> Message-ID: <32724506.93.1295627713360.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > Could the configure wrapper just decline to configure with a > different set of options than last time (plus some advice on how to > solve the problem)? Now that we have config.status, we already > remember what was used before. I was also thinking this approach would be good. I'll wait to see if there's more comments, though. - Jon From seth at icir.org Fri Jan 21 13:44:39 2011 From: seth at icir.org (Seth Hall) Date: Fri, 21 Jan 2011 16:44:39 -0500 Subject: [Bro-Dev] fixing compiler warnings In-Reply-To: <4D38E280.2090406@icir.org> References: <94468298-2B2E-457B-9F6E-77C0DE88E90C@icir.org> <4D38E280.2090406@icir.org> Message-ID: <544A4996-3EB6-4650-ACDB-BE9141F67616@icir.org> On Jan 20, 2011, at 8:33 PM, Gregor Maier wrote: > On 1/20/11 12:12 , Seth Hall wrote: >> >> [ 36%] Building CXX object src/CMakeFiles/bro.dir/main.cc.o >> /Users/seth/bro/bro.git/src/main.cc: In function ?int main(int, char**)?: >> /Users/seth/bro/bro.git/src/main.cc:415: warning: deprecated conversion from string constant to ?char*? > > int main(int argc, char *argv[]) > might to the trick.... That was my first inclination too, but the error isn't on that line. :) > -internal_error(msg); > +internal_error("%s", msg); Oh! Of course. > On a different note wrt to integer format string warnings: These > warnings tend to creep back in whenever you compile on a different > platform that has different integers widths. AFAIK the only way to get > really rid of them for good is to use the macros from inttypes.h > But that's already flagged for the integer types cleanup in ticket #319 I'm pretty clueless about the course of action that needs to happen for ticket #319. Could you give some guidance? Maybe I could go ahead and do it sometime if I knew what needs done. .Seth From bro at tracker.icir.org Fri Jan 21 13:49:59 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 21 Jan 2011 21:49:59 -0000 Subject: [Bro-Dev] #360: topic/quiet - Add a quiet option to binpac Message-ID: <043.7bf34fedd16e3e556928ffd69c7f1917@tracker.icir.org> #360: topic/quiet - Add a quiet option to binpac ---------------------------+-------------------- Reporter: seth | Owner: Type: Merge Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: BinPAC | Version: Keywords: | ---------------------------+-------------------- This branch adds a '-q' option to binpac to quiet it's normal status output. The plan is to use that to further quiet the output while building Bro so that all messages are from cmake during the build. The default retains the existing output and functionality. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 21 13:59:11 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 21 Jan 2011 21:59:11 -0000 Subject: [Bro-Dev] #272: topic/seth/strings-without-checkstring - Use Bytes() and Len() instead of CheckString() in strings.bif In-Reply-To: <043.1e378c2cf2d2f272b054d3bd5b2f44d9@tracker.icir.org> References: <043.1e378c2cf2d2f272b054d3bd5b2f44d9@tracker.icir.org> Message-ID: <058.baf2de0074a9f79fea15c07aa2e2d16e@tracker.icir.org> #272: topic/seth/strings-without-checkstring - Use Bytes() and Len() instead of CheckString() in strings.bif ----------------------------+---------------------- Reporter: seth | Owner: seth Type: Merge Request | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: sprint ----------------------------+---------------------- Comment (by seth): In do_split, n is initialized to the length of the string and is used to count how many characters are left in the string. Not sure why I did it that way, it's definitely a little confusing. For the change to strip, it looks like the if at the end isn't needed. The string length given to BroString comes out to zero if you have a string containing only spaces which seems to work fine. Here is the status of the variables just before getting to the "if ( sp > e )" statement: {{{ 604 in strings.bif (gdb) print e $2 = (const u_char *) 0x100c89b70 " " (gdb) print sp $3 = (const u_char *) 0x100c89b71 " " (gdb) print (e-sp+1) $4 = 0 (gdb) }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From robin at icir.org Fri Jan 21 14:00:06 2011 From: robin at icir.org (Robin Sommer) Date: Fri, 21 Jan 2011 14:00:06 -0800 Subject: [Bro-Dev] fixing compiler warnings In-Reply-To: <544A4996-3EB6-4650-ACDB-BE9141F67616@icir.org> References: <94468298-2B2E-457B-9F6E-77C0DE88E90C@icir.org> <4D38E280.2090406@icir.org> <544A4996-3EB6-4650-ACDB-BE9141F67616@icir.org> Message-ID: <20110121220006.GA13972@icir.org> On Fri, Jan 21, 2011 at 16:44 -0500, you wrote: > for ticket #319. Could you give some guidance? Take a look at the libhilti code, "grep PRI binpacpp/hilti/libhilti/*.c" will show some examples of using these macros. 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 Fri Jan 21 14:33:03 2011 From: gregor at icir.org (Gregor Maier) Date: Fri, 21 Jan 2011 14:33:03 -0800 Subject: [Bro-Dev] fixing compiler warnings In-Reply-To: <20110121220006.GA13972@icir.org> References: <94468298-2B2E-457B-9F6E-77C0DE88E90C@icir.org> <4D38E280.2090406@icir.org> <544A4996-3EB6-4650-ACDB-BE9141F67616@icir.org> <20110121220006.GA13972@icir.org> Message-ID: <4D3A099F.8010007@icir.org> On 1/21/11 14:00 , Robin Sommer wrote: > > On Fri, Jan 21, 2011 at 16:44 -0500, you wrote: > >> for ticket #319. Could you give some guidance? > > Take a look at the libhilti code, "grep PRI > binpacpp/hilti/libhilti/*.c" will show some examples of using these > macros. Basically the problem is that the uintXX_t and intXX_t types have to be printed differently on different platforms (e.g., int64_t could be a %d or %ld or %lld"). Using the macros gives you a portable way to specify the format specifier. So, you have to search the code for all instances were a fixed width integer is printed (or formated) and change the format specifier to use one of the macros. However, I'm not sure whether it makes sense to do this before we check whether we need to use 64 bit integers in some places. Since these changes might require another set of updating format specifiers. hth gregor -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From gregor at icir.org Fri Jan 21 15:04:12 2011 From: gregor at icir.org (Gregor Maier) Date: Fri, 21 Jan 2011 15:04:12 -0800 Subject: [Bro-Dev] fixing compiler warnings In-Reply-To: <544A4996-3EB6-4650-ACDB-BE9141F67616@icir.org> References: <94468298-2B2E-457B-9F6E-77C0DE88E90C@icir.org> <4D38E280.2090406@icir.org> <544A4996-3EB6-4650-ACDB-BE9141F67616@icir.org> Message-ID: <4D3A10EC.9050008@icir.org> On 1/21/11 13:44 , Seth Hall wrote: > > On Jan 20, 2011, at 8:33 PM, Gregor Maier wrote: > >> On 1/20/11 12:12 , Seth Hall wrote: >>> >>> [ 36%] Building CXX object src/CMakeFiles/bro.dir/main.cc.o >>> /Users/seth/bro/bro.git/src/main.cc: In function ?int main(int, char**)?: >>> /Users/seth/bro/bro.git/src/main.cc:415: warning: deprecated conversion from string constant to ?char*? >> >> int main(int argc, char *argv[]) >> might to the trick.... > That was my first inclination too, but the error isn't on that line. :) Hmm. The error looks to be in this line: prefixes.append(""); // "" = "no prefix" where prefixes is of type "name_list", which is defined in List.h as PList(char). Thus the append's prototype is "char *". But it seems converting a string literal to a "char *" now results in this warning (the prototype would have to be a "const char*")...... I think the quickest hotfix would be prefixes.append(strdup("")); (and add an #include ) cu gregor -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From robin at icir.org Sat Jan 22 14:18:54 2011 From: robin at icir.org (Robin Sommer) Date: Sat, 22 Jan 2011 14:18:54 -0800 Subject: [Bro-Dev] enums in modules In-Reply-To: References: Message-ID: <20110122221854.GD65883@icir.org> On Thu, Jan 20, 2011 at 16:50 -0500, you wrote: > function logging_log%(id: Logging::ID, rec: any%): bool Would be nice if that worked. Seems like something we should fix eventually. I'm actually not quite sure to which degree enums are supported by bifcl right now. Two things you could try: (1) do they work if they don't have namespace?; and (2) does it work to say just ":enum" (probably not). The alternative would be to use "any" and check for the type's correctness dynamically inside the function body until we have fixed this. (The other work-around is using strings, as I think you said you are alrady doing now) . 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 Sat Jan 22 14:20:49 2011 From: robin at icir.org (Robin Sommer) Date: Sat, 22 Jan 2011 14:20:49 -0800 Subject: [Bro-Dev] fixing compiler warnings In-Reply-To: <4D3A099F.8010007@icir.org> References: <94468298-2B2E-457B-9F6E-77C0DE88E90C@icir.org> <4D38E280.2090406@icir.org> <544A4996-3EB6-4650-ACDB-BE9141F67616@icir.org> <20110121220006.GA13972@icir.org> <4D3A099F.8010007@icir.org> Message-ID: <20110122222049.GE65883@icir.org> On Fri, Jan 21, 2011 at 14:33 -0800, you wrote: > However, I'm not sure whether it makes sense to do this before we check > whether we need to use 64 bit integers in some places. I think it does. I would like to get rid of all compiler warnings now, even if these will require more tweaking 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 at tracker.icir.org Sat Jan 22 14:27:21 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Sat, 22 Jan 2011 22:27:21 -0000 Subject: [Bro-Dev] #361: Copy Bro binary only when in NFS mode Message-ID: <044.468176c485675ae94b1733335d79df5c@tracker.icir.org> #361: Copy Bro binary only when in NFS mode ------------------------+------------------------ Reporter: robin | Owner: robin Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: git/master ------------------------+------------------------ Currently, BroControl copies the bro binary to all clients' spool directory, and then runs it from there. While that avoids problems when the Bro installation is on NFS, it can cause trouble in other contexts (like capabilities set for the binary to be lost; and I think we had more in the past I don't recall right now). So, the solution seems to be to avoid the copy unless in NFS mode. We could also revisit whether we want to keep supporting runnign from NFS at all, but generall I'd like to do so. -- Ticket URL: Bro Tracker Bro Issue Tracker From robin at icir.org Sat Jan 22 14:27:43 2011 From: robin at icir.org (Robin Sommer) Date: Sat, 22 Jan 2011 14:27:43 -0800 Subject: [Bro-Dev] Running Bro non-SUID on Linux In-Reply-To: References: <43BE2010-E2EB-4FA3-B4C1-01713749C615@icir.org> <20110120165023.GA28125@icir.org> Message-ID: <20110122222743.GG65883@icir.org> On Thu, Jan 20, 2011 at 09:15 -0800, you wrote: > I think modifying the script to make the copy an optional feature > would be reasonable. I've opened a ticket for this. 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 Sat Jan 22 22:21:51 2011 From: seth at icir.org (Seth Hall) Date: Sun, 23 Jan 2011 01:21:51 -0500 Subject: [Bro-Dev] enums in modules In-Reply-To: <20110122221854.GD65883@icir.org> References: <20110122221854.GD65883@icir.org> Message-ID: <83CFDCA8-F81A-449D-A7CD-F1B5299EEBC6@icir.org> On Jan 22, 2011, at 5:18 PM, Robin Sommer wrote: > I'm actually not quite sure to which degree enums are supported by > bifcl right now. Two things you could try: (1) do they work if they > don't have namespace?; I think that does work, it's the namespacing that messes things up because the Bro and C syntaxes don't mesh. Maybe bifcl could munge namespaces from Logging::ID to _Logging__ID or something to provide the transition? > and (2) does it work to say just ":enum" > (probably not). I can't imagine that it would work. I'll give it a try though. > The alternative would be to use "any" and check for the type's > correctness dynamically inside the function body until we have fixed > this. Good point, I may go that way once I have the other kinks worked out. Thanks, .Seth -- Seth Hall International Computer Science Institute (Bro) because everyone has a network http://www.bro-ids.org/ From bro at tracker.icir.org Mon Jan 24 01:01:22 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 24 Jan 2011 09:01:22 -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.1b8dcf65d12e56965c87f140289f07cb@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 -------------------------+--------------------------- Comment (by vern): Well I'm not sure if we're at a stage yet where you + Robin = "general consensus" :-), but I agree this probably makes sense. It will take some thought regarding backward compatibility, however. -- Ticket URL: Bro Tracker Bro Issue Tracker From robin at icir.org Mon Jan 24 08:31:33 2011 From: robin at icir.org (Robin Sommer) Date: Mon, 24 Jan 2011 08:31:33 -0800 Subject: [Bro-Dev] enums in modules In-Reply-To: <83CFDCA8-F81A-449D-A7CD-F1B5299EEBC6@icir.org> References: <20110122221854.GD65883@icir.org> <83CFDCA8-F81A-449D-A7CD-F1B5299EEBC6@icir.org> Message-ID: <20110124163133.GB49577@icir.org> On Sun, Jan 23, 2011 at 01:21 -0500, you wrote: > I think that does work, it's the namespacing that messes things up > because the Bro and C syntaxes don't mesh. Maybe bifcl could munge > namespaces from Logging::ID to _Logging__ID or something to provide > the transition? I'd need to look closer at bifcl. Can you file a ticket with a small example demonstrating the problem? 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 Mon Jan 24 08:57:20 2011 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Mon, 24 Jan 2011 10:57:20 -0600 (CST) Subject: [Bro-Dev] --with-binpac In-Reply-To: <32724506.93.1295627713360.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <23764233.150.1295888237160.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > > Could the configure wrapper just decline to configure with a > > different set of options than last time (plus some advice on how to > > solve the problem)? Now that we have config.status, we already > > remember what was used before. > > I was also thinking this approach would be good. I'll wait to see if > there's more comments, though. Thought of solution that I think is best: on each invocation, the configure wrapper can just delete an existing CMakeCache.txt before calling cmake (no need for displaying warnings to user about anything). This makes each ./configure independent from previous ones. - Jon From robin at icir.org Mon Jan 24 09:27:34 2011 From: robin at icir.org (Robin Sommer) Date: Mon, 24 Jan 2011 09:27:34 -0800 Subject: [Bro-Dev] --with-binpac In-Reply-To: <23764233.150.1295888237160.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <32724506.93.1295627713360.JavaMail.jsiwek@tangent.ncsa.illinois.edu> <23764233.150.1295888237160.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20110124172734.GC49577@icir.org> On Mon, Jan 24, 2011 at 10:57 -0600, you wrote: > Thought of solution that I think is best: on each invocation, the > configure wrapper can just delete an existing CMakeCache.txt before Makes sense. 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 Jan 24 09:35:15 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 24 Jan 2011 17:35:15 -0000 Subject: [Bro-Dev] #362: topic/jsiwek/reconfigure Message-ID: <045.c9977298577da447e1f528ef43bef23a@tracker.icir.org> #362: topic/jsiwek/reconfigure ---------------------------+------------------------ Reporter: jsiwek | Owner: Type: Merge Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Keywords: | ---------------------------+------------------------ This branch exists in the Bro repository and all submodules (recursively, except for trace-summary), and fixes two things: * The --with-binpac configure option is no longer overridden by the "compile binpac from source" logic when those sources exist. * The configure wrapper now deletes CMakeCache.txt if it exists to prevent previous configurations from tainting the current one. -- Ticket URL: Bro Tracker Bro Issue Tracker From seth at icir.org Mon Jan 24 10:32:01 2011 From: seth at icir.org (Seth Hall) Date: Mon, 24 Jan 2011 13:32:01 -0500 Subject: [Bro-Dev] --with-binpac In-Reply-To: <23764233.150.1295888237160.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <23764233.150.1295888237160.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: On Jan 24, 2011, at 11:57 AM, Jonathan Siwek wrote: > This makes each ./configure independent from previous ones. Sounds good to me. .Seth From gregor at icir.org Mon Jan 24 11:46:12 2011 From: gregor at icir.org (Gregor Maier) Date: Mon, 24 Jan 2011 11:46:12 -0800 Subject: [Bro-Dev] enums in modules In-Reply-To: <20110124163133.GB49577@icir.org> References: <20110122221854.GD65883@icir.org> <83CFDCA8-F81A-449D-A7CD-F1B5299EEBC6@icir.org> <20110124163133.GB49577@icir.org> Message-ID: <4D3DD704.5000006@icir.org> On 1/24/11 8:31 , Robin Sommer wrote: > > On Sun, Jan 23, 2011 at 01:21 -0500, you wrote: > >> I think that does work, it's the namespacing that messes things up >> because the Bro and C syntaxes don't mesh. Maybe bifcl could munge >> namespaces from Logging::ID to _Logging__ID or something to provide >> the transition? > > I'd need to look closer at bifcl. Can you file a ticket with a small > example demonstrating the problem? Thanks, bifcl supports enums (it just casts them as a "neutral" Val*, same as for record types). So it would just be a matter of telling bifcl to accept the Namespace::Type name syntax. That should be it. The C part doesn't really care about the type. It's all a "netural" Val*. The type is only used for the policy file and type checking. EnumType and EnumVal should make accessing the enum's value relatively easy. I'm using that in my re-working of the NFS analyzer. Let me know if you want details. cu Gregor -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From seth at icir.org Mon Jan 24 11:50:07 2011 From: seth at icir.org (Seth Hall) Date: Mon, 24 Jan 2011 14:50:07 -0500 Subject: [Bro-Dev] enums in modules In-Reply-To: <20110124163133.GB49577@icir.org> References: <20110122221854.GD65883@icir.org> <83CFDCA8-F81A-449D-A7CD-F1B5299EEBC6@icir.org> <20110124163133.GB49577@icir.org> Message-ID: <4EB6C517-486A-414D-8DDB-601B22EAD38D@icir.org> On Jan 24, 2011, at 11:31 AM, Robin Sommer wrote: > > On Sun, Jan 23, 2011 at 01:21 -0500, you wrote: > >> I think that does work, it's the namespacing that messes things up >> because the Bro and C syntaxes don't mesh. Maybe bifcl could munge >> namespaces from Logging::ID to _Logging__ID or something to provide >> the transition? > > I'd need to look closer at bifcl. Can you file a ticket with a small > example demonstrating the problem? Thanks, After taking a deeper look into this, I realized that I may be misunderstanding how enums are supposed to be used. Does it make sense that you'd provide an enum name as a type to get static type checking? Like this... type TEST_ENUM: enum { test_one, test_two, test_three }; function blah(b: TEST_ENUM) { print "did it work?"; } event bro_init() { local a = test_two; print blah(a); } I get this error from that code.. [seth at Blake build (master)]$ ./src/bro test.bro ./test.bro, line 11 (print blah(a)): error, value of type void illegal Before I send my example for namespaced enums, I think I need to get more of the base usage of enums clarified. Are there any examples that you know of where enums are used as parameter values like this? .Seth -- Seth Hall International Computer Science Institute (Bro) because everyone has a network http://www.bro-ids.org/ From gregor at icir.org Mon Jan 24 11:56:12 2011 From: gregor at icir.org (Gregor Maier) Date: Mon, 24 Jan 2011 11:56:12 -0800 Subject: [Bro-Dev] enums in modules In-Reply-To: <4EB6C517-486A-414D-8DDB-601B22EAD38D@icir.org> References: <20110122221854.GD65883@icir.org> <83CFDCA8-F81A-449D-A7CD-F1B5299EEBC6@icir.org> <20110124163133.GB49577@icir.org> <4EB6C517-486A-414D-8DDB-601B22EAD38D@icir.org> Message-ID: <4D3DD95C.6020400@icir.org> On 1/24/11 11:50 , Seth Hall wrote: > > On Jan 24, 2011, at 11:31 AM, Robin Sommer wrote: > >> >> On Sun, Jan 23, 2011 at 01:21 -0500, you wrote: >> >>> I think that does work, it's the namespacing that messes things up >>> because the Bro and C syntaxes don't mesh. Maybe bifcl could munge >>> namespaces from Logging::ID to _Logging__ID or something to provide >>> the transition? >> >> I'd need to look closer at bifcl. Can you file a ticket with a small >> example demonstrating the problem? Thanks, > > > After taking a deeper look into this, I realized that I may be misunderstanding how enums are supposed to be used. Does it make sense that you'd provide an enum name as a type to get static type checking? Like this... > > > type TEST_ENUM: enum { test_one, test_two, test_three }; > > function blah(b: TEST_ENUM) > { > print "did it work?"; > } > > event bro_init() > { > local a = test_two; > print blah(a); > } > > > I get this error from that code.. > > [seth at Blake build (master)]$ ./src/bro test.bro > ./test.bro, line 11 (print blah(a)): error, value of type void illegal blah() doesn't return anything, so you can't print it.... cu Gregor -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From seth at icir.org Mon Jan 24 12:01:02 2011 From: seth at icir.org (Seth Hall) Date: Mon, 24 Jan 2011 15:01:02 -0500 Subject: [Bro-Dev] enums in modules In-Reply-To: <4D3DD95C.6020400@icir.org> References: <20110122221854.GD65883@icir.org> <83CFDCA8-F81A-449D-A7CD-F1B5299EEBC6@icir.org> <20110124163133.GB49577@icir.org> <4EB6C517-486A-414D-8DDB-601B22EAD38D@icir.org> <4D3DD95C.6020400@icir.org> Message-ID: <0EE1E7E8-FB35-4EAD-B406-2A77B6136BB4@icir.org> On Jan 24, 2011, at 2:56 PM, Gregor Maier wrote: > blah() doesn't return anything, so you can't print it.... Haha, whoops. Ok, that throws my whole thought out the window. Thanks for your comments, I'll look at things a bit more. .Seth From robin at icir.org Mon Jan 24 12:32:25 2011 From: robin at icir.org (Robin Sommer) Date: Mon, 24 Jan 2011 12:32:25 -0800 Subject: [Bro-Dev] Enable DPD per default in 1.6? Message-ID: <20110124203225.GB74546@icir.org> I'm wondering whether we should turn on DPD by default in 1.6. Doing so would involve two things: (1) Loading the DPD signatures (i.e., dpd.bro) (2) Setting the packet filter to include all packets. The former shouldn't be a problem, but the latter would be a major change. We'd still keep the current build-your-filter-dynamically scheme, but it would have to be enabled explicity (say, with an option in pcap.bro). There's a further advantage to doing (2): it would eliminate one of the most common mistakes: not realizing that Bro's filter doesn't include what one wants to analyze. With a default-all filter, Bro does what one would intuitively expect, and changing the filter to be more restrictive could be filed under "performance tuning". Thoughts? 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 Mon Jan 24 12:36:39 2011 From: gregor at icir.org (Gregor Maier) Date: Mon, 24 Jan 2011 12:36:39 -0800 Subject: [Bro-Dev] enums in modules In-Reply-To: <0EE1E7E8-FB35-4EAD-B406-2A77B6136BB4@icir.org> References: <20110122221854.GD65883@icir.org> <83CFDCA8-F81A-449D-A7CD-F1B5299EEBC6@icir.org> <20110124163133.GB49577@icir.org> <4EB6C517-486A-414D-8DDB-601B22EAD38D@icir.org> <4D3DD95C.6020400@icir.org> <0EE1E7E8-FB35-4EAD-B406-2A77B6136BB4@icir.org> Message-ID: <4D3DE2D7.20706@icir.org> On 1/24/11 12:01 , Seth Hall wrote: > > On Jan 24, 2011, at 2:56 PM, Gregor Maier wrote: > >> blah() doesn't return anything, so you can't print it.... > > > Haha, whoops. Ok, that throws my whole thought out the window. Thanks for your comments, I'll look at things a bit more. I don't think that enums are used extensively between C and policy scripts. AFAIK, my NFS analyzer is one of the first that passes enums as event arguments. cu gregor -- Gregor Maier Int. Computer Science Institute (ICSI) 1947 Center St., Ste. 600 Berkeley, CA 94704, USA http://www.icir.org/gregor/ From seth at icir.org Mon Jan 24 12:50:42 2011 From: seth at icir.org (Seth Hall) Date: Mon, 24 Jan 2011 15:50:42 -0500 Subject: [Bro-Dev] Enable DPD per default in 1.6? In-Reply-To: <20110124203225.GB74546@icir.org> References: <20110124203225.GB74546@icir.org> Message-ID: <6C4E8AB2-BB81-4056-B392-BC67F98851AB@icir.org> On Jan 24, 2011, at 3:32 PM, Robin Sommer wrote: > There's a further advantage to doing (2): it would eliminate one of > the most common mistakes: not realizing that Bro's filter doesn't > include what one wants to analyze. With a default-all filter, Bro > does what one would intuitively expect, and changing the filter to > be more restrictive could be filed under "performance tuning". > > Thoughts? I like the idea. The common case seems to have become running with DPD enabled anyway. It would be one less thing for most people to have to configure as soon as they do the install. All as long as the filtering system gets some documentation. :) .Seth -- Seth Hall International Computer Science Institute (Bro) because everyone has a network http://www.bro-ids.org/ From slagell at ncsa.illinois.edu Mon Jan 24 12:53:58 2011 From: slagell at ncsa.illinois.edu (Adam J. Slagell) Date: Mon, 24 Jan 2011 14:53:58 -0600 Subject: [Bro-Dev] Enable DPD per default in 1.6? In-Reply-To: <6C4E8AB2-BB81-4056-B392-BC67F98851AB@icir.org> References: <20110124203225.GB74546@icir.org> <6C4E8AB2-BB81-4056-B392-BC67F98851AB@icir.org> Message-ID: On Jan 24, 2011, at 2:50 PM, Seth Hall wrote: > > On Jan 24, 2011, at 3:32 PM, Robin Sommer wrote: > >> There's a further advantage to doing (2): it would eliminate one of >> the most common mistakes: not realizing that Bro's filter doesn't >> include what one wants to analyze. With a default-all filter, Bro >> does what one would intuitively expect, and changing the filter to >> be more restrictive could be filed under "performance tuning". >> >> Thoughts? > > I like the idea. The common case seems to have become running with DPD enabled anyway. It would be one less thing for most people to have to configure as soon as they do the install. All as long as the filtering system gets some documentation. :) > > .Seth Definitely a change to highlight in the INSTALL file and the FAQ page on the web. I imagine some people will be wondering why it slowed down for them on a 1.6 update because of that change. If this change isn't very clear, then they could just give up on 1.6. From bro at tracker.icir.org Mon Jan 24 13:43:23 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 24 Jan 2011 21:43:23 -0000 Subject: [Bro-Dev] #363: Sets of records with optional values is broken Message-ID: <043.ac0562b4c61c89e48c3efe1b91abe100@tracker.icir.org> #363: Sets of records with optional values is broken ---------------------+------------------------ Reporter: seth | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Keywords: | ---------------------+------------------------ If you have a record with optional value(s) and the optional value(s) aren't assigned to, adding an instance of that record type to a set (or probably using it as an index of any kind) fails. Example code: {{{ type FOO: record { a: count; b: count; c: count &optional; }; global foobar: set[FOO] = set(); event bro_init() { local bar : FOO = [$a=1, $b=2]; add foobar[bar]; } }}} Gives this error: {{{ 1295905258.355592 and ./test.bro, line 7 ([a=1, b=2, c=] and list of record { a:count; b:count; c:count; }): error, index type doesn't match table }}} It seems that the type checking being done by the list code doesn't account for the &optional attribute. -- Ticket URL: Bro Tracker Bro Issue Tracker From Tyler.Schoenke at colorado.edu Mon Jan 24 13:59:52 2011 From: Tyler.Schoenke at colorado.edu (Tyler T. Schoenke) Date: Mon, 24 Jan 2011 14:59:52 -0700 Subject: [Bro-Dev] Enable DPD per default in 1.6? In-Reply-To: References: <20110124203225.GB74546@icir.org> <6C4E8AB2-BB81-4056-B392-BC67F98851AB@icir.org> Message-ID: <4D3DF658.3010603@colorado.edu> I agree with the change. My performance issues seemed to be related to how many alerts were firing. Once I turned off many of the alerts, the cluster was more stable. I played with turning the dpd.bro off, and didn't notice much performance improvement. I also didn't notice much of a performance change when the packet filter was set to the default set or all packets. I think most people will have performance issues with the volume of traffic they are processing. I was estimating 32 cores would be needed to handle 1 Gbps comfortably. Our 8 cores are dropping typically around 5-20% of the traffic, while processing 580 Mbps. Using Click! was critical to getting the cluster processing at a decent rate. Turning off some of the less-needed alerts might help offset enabling DPD. Tyler -- Tyler Schoenke Network Security Analyst IT Security Office University of Colorado - Boulder On 1/24/11 1:53 PM, Adam J. Slagell wrote: > > On Jan 24, 2011, at 2:50 PM, Seth Hall wrote: > >> >> On Jan 24, 2011, at 3:32 PM, Robin Sommer wrote: >> >>> There's a further advantage to doing (2): it would eliminate one of >>> the most common mistakes: not realizing that Bro's filter doesn't >>> include what one wants to analyze. With a default-all filter, Bro >>> does what one would intuitively expect, and changing the filter to >>> be more restrictive could be filed under "performance tuning". >>> >>> Thoughts? >> >> I like the idea. The common case seems to have become running with DPD enabled anyway. It would be one less thing for most people to have to configure as soon as they do the install. All as long as the filtering system gets some documentation. :) >> >> .Seth > > Definitely a change to highlight in the INSTALL file and the FAQ page on the web. I imagine some people will be wondering why it slowed down for them on a 1.6 update because of that change. If this change isn't very clear, then they could just give up on 1.6. > _______________________________________________ > 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 Mon Jan 24 15:24:31 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 24 Jan 2011 23:24:31 -0000 Subject: [Bro-Dev] #362: topic/jsiwek/reconfigure In-Reply-To: <045.c9977298577da447e1f528ef43bef23a@tracker.icir.org> References: <045.c9977298577da447e1f528ef43bef23a@tracker.icir.org> Message-ID: <060.facfd438755a3d9e607fd1ce43ce13cb@tracker.icir.org> #362: topic/jsiwek/reconfigure -----------------------------+------------------------ Reporter: jsiwek | Owner: Type: Merge Request | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: Merged/Applied | Keywords: -----------------------------+------------------------ Changes (by robin): * status: new => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Jan 24 18:09:06 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 25 Jan 2011 02:09:06 -0000 Subject: [Bro-Dev] #272: topic/seth/strings-without-checkstring - Use Bytes() and Len() instead of CheckString() in strings.bif In-Reply-To: <043.1e378c2cf2d2f272b054d3bd5b2f44d9@tracker.icir.org> References: <043.1e378c2cf2d2f272b054d3bd5b2f44d9@tracker.icir.org> Message-ID: <058.434c783e75148dc26a93047e413ff5f4@tracker.icir.org> #272: topic/seth/strings-without-checkstring - Use Bytes() and Len() instead of CheckString() in strings.bif ----------------------------+---------------------- Reporter: seth | Owner: robin Type: Merge Request | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: sprint ----------------------------+---------------------- Changes (by seth): * owner: seth => robin -- Ticket URL: Bro Tracker Bro Issue Tracker From seth at icir.org Mon Jan 24 18:21:43 2011 From: seth at icir.org (Seth Hall) Date: Mon, 24 Jan 2011 21:21:43 -0500 Subject: [Bro-Dev] Enable DPD per default in 1.6? In-Reply-To: <4D3DF658.3010603@colorado.edu> References: <20110124203225.GB74546@icir.org> <6C4E8AB2-BB81-4056-B392-BC67F98851AB@icir.org> <4D3DF658.3010603@colorado.edu> Message-ID: <1C50C239-83F9-4BE2-9BC7-290852435D5D@icir.org> On Jan 24, 2011, at 4:59 PM, Tyler T. Schoenke wrote: > I think most people will have performance issues with the volume of > traffic they are processing. I was estimating 32 cores would be needed > to handle 1 Gbps comfortably. Our 8 cores are dropping typically around > 5-20% of the traffic, while processing 580 Mbps. Hm, that doesn't mesh with my experience. I would expect 8 cores to be able to deal with 580 Mbps pretty comfortably. I'll follow up with you offlist. .Seth -- Seth Hall International Computer Science Institute (Bro) because everyone has a network http://www.bro-ids.org/ From bro at tracker.icir.org Tue Jan 25 10:39:11 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 25 Jan 2011 18:39:11 -0000 Subject: [Bro-Dev] #255: internal error: NB-DNS error in DNS_Mgr::Process (recvfrom(): Connection refused) In-Reply-To: <053.579a3a1961b5438528c584f5820dae14@tracker.icir.org> References: <053.579a3a1961b5438528c584f5820dae14@tracker.icir.org> Message-ID: <068.38d2e9105d6ba98ecce73b2219adf058@tracker.icir.org> #255: internal error: NB-DNS error in DNS_Mgr::Process (recvfrom(): Connection refused) -----------------------------+-------------------- Reporter: Tyler.Schoenke | Owner: Type: Problem | 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 at tracker.icir.org Tue Jan 25 15:21:16 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 25 Jan 2011 23:21:16 -0000 Subject: [Bro-Dev] #364: login.bro should raise Notices when being confused Message-ID: <044.1b678a6ea7d79bc24ec52cce8754ad5d@tracker.icir.org> #364: login.bro should raise Notices when being confused ------------------------+--------------------- Reporter: robin | Type: Problem Status: new | Priority: Normal Milestone: Bro1.6 | Component: Bro Version: git/master | ------------------------+--------------------- When we cleanup login.bro, we should turn the weird's that are generated for being "confused" into notices, as they may reflect evasive behaviour. (Note that I'm already changing the script to not write into weird.log directly, but go throigh weird.bro. That should be in master soon.) -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 25 15:26:25 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 25 Jan 2011 23:26:25 -0000 Subject: [Bro-Dev] #360: topic/quiet - Add a quiet option to binpac In-Reply-To: <043.7bf34fedd16e3e556928ffd69c7f1917@tracker.icir.org> References: <043.7bf34fedd16e3e556928ffd69c7f1917@tracker.icir.org> Message-ID: <058.26eb9084661b86ff591003c38d428c5e@tracker.icir.org> #360: topic/quiet - Add a quiet option to binpac -----------------------------+-------------------- Reporter: seth | Owner: Type: Merge Request | Status: closed Priority: Normal | Milestone: Bro1.6 Component: BinPAC | Version: Resolution: Merged/Applied | Keywords: -----------------------------+-------------------- Changes (by robin): * status: new => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Tue Jan 25 15:42:30 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Tue, 25 Jan 2011 23:42:30 -0000 Subject: [Bro-Dev] #272: topic/seth/strings-without-checkstring - Use Bytes() and Len() instead of CheckString() in strings.bif In-Reply-To: <043.1e378c2cf2d2f272b054d3bd5b2f44d9@tracker.icir.org> References: <043.1e378c2cf2d2f272b054d3bd5b2f44d9@tracker.icir.org> Message-ID: <058.7ae6b83518f986e84adc149002f45bab@tracker.icir.org> #272: topic/seth/strings-without-checkstring - Use Bytes() and Len() instead of CheckString() in strings.bif ----------------------------+---------------------- Reporter: seth | Owner: seth Type: Merge Request | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: sprint ----------------------------+---------------------- Changes (by robin): * owner: robin => seth Comment: I'm still getting errors with the test-suite after merging, e.g, +1106565897.306747 error: '>' not found in argument to RCPT: TO: NOTIFY=FAILURE,DELAY Can you please double-check that they are really gone for you? -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 26 10:29:04 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 26 Jan 2011 18:29:04 -0000 Subject: [Bro-Dev] #365: Conn.log rollover time Message-ID: <043.a626e691ffb447bbf308f50fc2a6fb58@tracker.icir.org> #365: Conn.log rollover time ------------------------+-------------------- Reporter: seth | Owner: robin Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: Keywords: | ------------------------+-------------------- When using BroControl, if you change your log rollover interval with the log_rotate_interval variable, the conn.log will continue to roll over on a 24 hour interval and ignore the other setting. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 26 11:30:41 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 26 Jan 2011 19:30:41 -0000 Subject: [Bro-Dev] #365: Conn.log rollover time In-Reply-To: <043.a626e691ffb447bbf308f50fc2a6fb58@tracker.icir.org> References: <043.a626e691ffb447bbf308f50fc2a6fb58@tracker.icir.org> Message-ID: <058.2a7a9a9b5675cc97e766317f5dae4318@tracker.icir.org> #365: Conn.log rollover time -------------------------+-------------------- Reporter: seth | Owner: robin Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: Resolution: | Keywords: -------------------------+-------------------- Comment (by seth): I had that wrong actually. The conn.log rollover is 12 hours regardless of the log rollover you set. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 26 11:34:10 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 26 Jan 2011 19:34:10 -0000 Subject: [Bro-Dev] #365: Conn.log rollover time In-Reply-To: <043.a626e691ffb447bbf308f50fc2a6fb58@tracker.icir.org> References: <043.a626e691ffb447bbf308f50fc2a6fb58@tracker.icir.org> Message-ID: <058.171611e566cfb02efb304c04cfab11be@tracker.icir.org> #365: Conn.log rollover time -------------------------+-------------------- Reporter: seth | Owner: robin Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: Resolution: | Keywords: -------------------------+-------------------- Comment (by robin): On Wed, Jan 26, 2011 at 19:30 -0000, you wrote: > I had that wrong actually. The conn.log rollover is 12 hours regardless > of the log rollover you set. It used to be like that, but I thought conn.log is now also rotating at 24hrs. Is this with a current version (i.e., either master or 1.5.2)? -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 26 11:40:44 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 26 Jan 2011 19:40:44 -0000 Subject: [Bro-Dev] #365: Conn.log rollover time In-Reply-To: <043.a626e691ffb447bbf308f50fc2a6fb58@tracker.icir.org> References: <043.a626e691ffb447bbf308f50fc2a6fb58@tracker.icir.org> Message-ID: <058.d48ab2e4e73fbbe5e75d882ce4049481@tracker.icir.org> #365: Conn.log rollover time -------------------------+-------------------- Reporter: seth | Owner: robin Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: Resolution: | Keywords: -------------------------+-------------------- Comment (by seth): > It used to be like that, but I thought conn.log is now also rotating > at 24hrs. Is this with a current version (i.e., either master or > 1.5.2)? Oh, this is likely an older version. I forgot that had been modified. I'll verify and update the ticket. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 26 11:49:36 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 26 Jan 2011 19:49:36 -0000 Subject: [Bro-Dev] #366: Crash with optional table and record ctors Message-ID: <044.239d846a881e67ec1f52965a6200a7b6@tracker.icir.org> #366: Crash with optional table and record ctors -------------------+----------------------- Reporter: robin | Type: Problem Status: new | Priority: Normal Component: Bro | Version: git/master -------------------+----------------------- This crashes: type request: record { ... t: time; x: table[string] of string &optional &default="-"; ... } local req: request = [$t=network_time()]; # <-- here (gdb) print this Cannot access memory at address 0x0 #0 RecordVal::Assign (this=0x10125dcd0, field=6, new_val=0x0, op=OP_ASSIGN) at /Users/robin/bro/master/src/Val.cc:2850 #1 0x00000001000c6d5f in RecordCoerceExpr::Fold (this=0x10123e960, v=0x10125eab0) at /Users/robin/bro/master/src/Expr.cc:4052 #2 0x00000001000c9485 in UnaryExpr::Eval (this=0x10123e960, f=) at /Users/robin/bro/master/src/Expr.cc:509 #3 0x00000001000c3eea in AssignExpr::Eval (this=0x10123e830, f=0x101254110) at /Users/robin/bro/master/src/Expr.cc:2609 warning: .o file "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Stmt.cc.o" more recent than executable timestamp in "/Users/robin/bin/bro" warning: Couldn't open object file '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Stmt.cc.o' #4 0x00000001001766a6 in ExprStmt::Exec () #5 0x0000000100172640 in StmtList::Exec () #6 0x0000000100172640 in StmtList::Exec () warning: .o file "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Func.cc.o" more recent than executable timestamp in "/Users/robin/bin/bro" warning: Couldn't open object file '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Func.cc.o' #7 0x00000001000e037d in BroFunc::Call () warning: .o file "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/EventHandler.cc.o" more recent than executable timestamp in "/Users/robin/bin/bro" warning: Couldn't open object file '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/EventHandler.cc.o' #8 0x000000010009f154 in EventHandler::Call () warning: .o file "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Event.cc.o" more recent than executable timestamp in "/Users/robin/bin/bro" warning: Couldn't open object file '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Event.cc.o' #9 0x000000010009eb1d in EventMgr::Dispatch () #10 0x000000010009ec48 in EventMgr::Drain () warning: .o file "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Net.cc.o" more recent than executable timestamp in "/Users/robin/bin/bro" warning: Couldn't open object file '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Net.cc.o' #11 0x00000001001297b5 in net_packet_dispatch () warning: .o file "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/PktSrc.cc.o" more recent than executable timestamp in "/Users/robin/bin/bro" warning: Couldn't open object file '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/PktSrc.cc.o' #12 0x0000000100136cf7 in PktSrc::Process () #13 0x0000000100129a50 in net_run () warning: .o file "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/main.cc.o" more recent than executable timestamp in "/Users/robin/bin/bro" warning: Couldn't open object file '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/main.cc.o' #14 0x00000001000600b3 in main () -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 26 13:21:44 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 26 Jan 2011 21:21:44 -0000 Subject: [Bro-Dev] #366: Crash with optional table and record ctors In-Reply-To: <044.239d846a881e67ec1f52965a6200a7b6@tracker.icir.org> References: <044.239d846a881e67ec1f52965a6200a7b6@tracker.icir.org> Message-ID: <059.d9d112e871c87551a1912840c86ad68c@tracker.icir.org> #366: Crash with optional table and record ctors ----------------------+------------------------ Reporter: robin | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Component: Bro | Version: git/master Resolution: | Keywords: ----------------------+------------------------ Comment (by seth): > type request: record { > ... > t: time; > x: table[string] of string &optional &default="-"; > ... > } > > local req: request = [$t=network_time()]; # <-- here This is actually crashing because of the &default. If you remove the &optional attribute, it still crashes. What are you trying to set to "-"? It doesn't make much sense that you'd get back a table like this: {{{ [ ["-"] = nil ] }}} Of course Bro doesn't have a nil value anyway, but you get the idea. The use of the &default attribute on complex types in records has never been very well defined and I think this is one of the cases where things need handled differently. It occurs to me that I should be able to provide the default attribute something like this: {{{ x: table[string] of string &default = table(["-"] = ""); }}} I know that would cause some problems with execution time and is why table() and set() can't be used as default attributes yet, but it should definitely work. I think that has been one of my largest annoyances about the scripting language overall. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 26 13:44:41 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 26 Jan 2011 21:44:41 -0000 Subject: [Bro-Dev] #367: internal_error with &optional fields in records used as indexes Message-ID: <043.81b272eefc82d70a12d6ae939c639044@tracker.icir.org> #367: internal_error with &optional fields in records used as indexes ---------------------+------------------------ Reporter: seth | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Keywords: | ---------------------+------------------------ Trying to add records with optional fields to tables or sets as the index fails (doesn't crash though) if one of the optional fields does not have a value. This script will cause the error: {{{ type FOO: record { a: count; b: count &optional; }; event bro_init() { local set_of_foo: set[FOO] = set(); add set_of_foo[[$a=3]]; print set_of_foo; } }}} {{{ $ ./src/bro test-367.bro 1296078003.394335 and ./test-367.bro, line 11 ([a=3, b=] and list of record { a:count; b:count; }): error, index type doesn't match table { } }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Wed Jan 26 15:52:54 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Wed, 26 Jan 2011 23:52:54 -0000 Subject: [Bro-Dev] #366: Crash with optional table and record ctors In-Reply-To: <044.239d846a881e67ec1f52965a6200a7b6@tracker.icir.org> References: <044.239d846a881e67ec1f52965a6200a7b6@tracker.icir.org> Message-ID: <059.df7ee239a6a3f8b953a21afc0fc6aa14@tracker.icir.org> #366: Crash with optional table and record ctors ----------------------+------------------------ Reporter: robin | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Component: Bro | Version: git/master Resolution: | Keywords: ----------------------+------------------------ Comment (by vern): Seth, I think it's actually different. The semantics of {{{ x: table[string] of string &optional &default="-" }}} is that x is an optional field, and it's type is {{{table[string] of string}}}. In addition, if you look up a string in that table and the value isn't present, then what's returned is the string {{{"-"}}}. I.e., {{{&default}}} associates with the value of missing table elements, not with the value of the entire record field missing (which IIRC isn't controllable). At least, I'm pretty sure I have that right ... -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 27 05:10:41 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 27 Jan 2011 13:10:41 -0000 Subject: [Bro-Dev] #368: Patch for Reverse DNS Lookups and DNS TTL support Message-ID: <051.d0f4965bdff7b3c1b00d8279da7dd66d@tracker.icir.org> #368: Patch for Reverse DNS Lookups and DNS TTL support --------------------------+----------------------------- Reporter: thomas.other | Type: Patch Status: new | Priority: Normal Milestone: | Component: Bro Version: 1.5.2 | Keywords: DNS TTL Resolve --------------------------+----------------------------- In large networks with short DHCP lease times it may be advantageous to log DNS hostnames additionally to the IP of a given host. While support for forward DNS lookups is already built into the print statement in the scripting language, and the DNS manager already offers support for both types of queries, a new explicit resolve expression completes the set of DNS functions in bro. In order to obtain the most recent DNS zone record for a given host, instead of a previously received and locally cached value, the DNS manager must pay respect to the TTL value associated with a DNS zone record. The currently used resolver API (bind) offers support for TTL retrieval, therefore this value shall be passed on to the DNS manager where it is used to decide whether a new resolve request should be issued if the currently cached record has become stale. Two patches address these issues (based on SVN r7165): * resolve.patch: * enables the use of the resolve() expression in bro scripts * e.g. resolve("www.microsoft.com") or resolve(65.55.21.250) * dnsttls.patch: * enables DNS to requery records that are older than the records TTL * is controlled through configure flag --enable-dns- ttl, if omitted behavior is as if the patch wasn't applied Both patches have been thoroughly tested in productive environments. The implementation of the resolve expression declares several methods where a reproduction of the intended funtionality couldn't be verified a 100%. If a more experienced bro developer could have a look at following methods and provide a quick feedback it would be greatly appreciated: {{{ - Expr.cc: ResolveExpr::Simplify - Expr.cc: ResolveExpr::Traverse - Expr.cc: ResolveExpr::ExprDescribe - Expr.cc: ResolveExpr::DoSerialize - Expr.cc: ResolveExpr::DoUnserialize }}} Many thanks! Thomas -- Ticket URL: Bro Tracker Bro Issue Tracker From robin at icir.org Thu Jan 27 09:45:52 2011 From: robin at icir.org (Robin Sommer) Date: Thu, 27 Jan 2011 09:45:52 -0800 Subject: [Bro-Dev] cmake/install question Message-ID: <20110127174552.GI57524@icir.org> Hi Jon, another question about the cmake install: when I change one of the broctl Python scripts, the change doesn't seem to get copied over into the build directory (and therefore then also not installed on "make install"): > dir aux/broctl/BroControl/options.py -rw-r--r-- 1 robin robin 12940 Jan 25 15:14 aux/broctl/BroControl/options.py > dir ./build/aux/broctl/BroControl/options.py -rw-r--r-- 1 robin robin 12842 Jan 10 16:01 ./build/aux/broctl/BroControl/options.py > make ( cd build && make ) [ 1%] Built target binpac_lib [ 14%] Built target binpac [ 16%] Built target bifcl [ 81%] Built target bro [ 82%] Built target _SubnetTree [ 82%] Built target capstats [ 83%] Built target adtrace [ 83%] Built target bdcat [ 84%] Built target cf [ 86%] Built target hf [ 87%] Built target nf [ 88%] Built target pf [ 88%] Built target ftwire2bro [ 88%] Built target nfcollector [ 89%] Built target rst [ 98%] Built target broccoli [ 98%] Built target broconftest [ 98%] Built target broconn [ 99%] Built target broenum [ 99%] Built target brohose [ 99%] Built target broping [100%] Built target brotable [100%] Built target _broccoli_intern > dir ./build/aux/broctl/BroControl/options.py -rw-r--r-- 1 robin robin 12842 Jan 10 16:01 ./build/aux/broctl/BroControl/options.py Any idea? 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 Thu Jan 27 10:13:33 2011 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Thu, 27 Jan 2011 12:13:33 -0600 (CST) Subject: [Bro-Dev] cmake/install question In-Reply-To: <20110127174552.GI57524@icir.org> Message-ID: <2966906.506.1296152013257.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > when I change one of the broctl Python scripts, the change doesn't seem to get copied over into the build directory Hmm. I thought I remember streamlining it so that the BroControl scripts don't get copied into the build directory anymore, they're installed straight from the source dir. I think what you're seeing in the build dir is just leftovers from before this change happened and it's just a red herring. > (and therefore then also not installed on "make install"): I don't see the same behavior with a fresh clone. After `make install`: $ ls -l ./build/aux/broctl/BroControl/ ls: ./build/aux/broctl/BroControl/: No such file or directory $ tail -n2 /usr/local/bro/lib/broctl/BroControl/options.py printOptions(Option.AUTOMATIC) $ echo "# some modification" >> aux/broctl/BroControl/options.py $ make install ... $ tail -n2 /usr/local/bro/lib/broctl/BroControl/options.py printOptions(Option.AUTOMATIC) # some modification Maybe you weren't looking in the right install prefix for the change? I don't think it's possible for it to accidentally be picking up those old files in build directory, but you might try deleting them to see if that changes the behavior. - Jon From robin at icir.org Thu Jan 27 10:31:02 2011 From: robin at icir.org (Robin Sommer) Date: Thu, 27 Jan 2011 10:31:02 -0800 Subject: [Bro-Dev] cmake/install question In-Reply-To: <2966906.506.1296152013257.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <20110127174552.GI57524@icir.org> <2966906.506.1296152013257.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20110127183102.GK57524@icir.org> On Thu, Jan 27, 2011 at 12:13 -0600, you wrote: > I think what you're seeing in the build dir is just leftovers from > before this change happened and it's just a red herring. That may be, I didn't clean up after pulling in the recent changes. However, now that I did, I'm running into different problems with my multi-user setup: Compiling as user robin: [in ~robin/bro/master/] > rm -rf build > ./configure --prefix=/home/bro/ --enable-cluster > (cd build && make -j 8) Installing as user bro: [in ~bro/] > ( cd ~robin/bro/master && make install ) ( cd build && make install ) CMake Error: Could not open file for write in copy operation /home/robin/bro/master/build/cmake_uninstall.cmake.tmp CMake Error: : System Error: Permission denied CMake Error at CMakeLists.txt:18 (configure_file): configure_file Problem configuring file CMake Error: Could not open file for write in copy operation /home/robin/bro/master/build/bro-path-dev.tmp CMake Error: : System Error: Permission denied CMake Error at CMakeLists.txt:39 (configure_file): configure_file Problem configuring file [...] That looks like it's now trying again to write into the build directory on "make install"? This is cmake 2.8.2 if that matters. > Maybe you weren't looking in the right install prefix for the change? I had tried deleting the installed version of the file, and it got reinstalled but with the old version, that's why though it must have been coming out of the build directory. 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 Thu Jan 27 11:03:04 2011 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Thu, 27 Jan 2011 13:03:04 -0600 (CST) Subject: [Bro-Dev] cmake/install question In-Reply-To: <20110127183102.GK57524@icir.org> Message-ID: <27841800.520.1296154980913.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > I'm running into different problems with my multi-user setup: > > Compiling as user robin: > > [in ~robin/bro/master/] > > rm -rf build > > ./configure --prefix=/home/bro/ --enable-cluster > > (cd build && make -j 8) > > Installing as user bro: > > [in ~bro/] > > ( cd ~robin/bro/master && make install ) > ( cd build && make install ) > CMake Error: Could not open file for write in copy operation > /home/robin/bro/master/build/cmake_uninstall.cmake.tmp > CMake Error: : System Error: Permission denied > CMake Error at CMakeLists.txt:18 (configure_file): > configure_file Problem configuring file > > > CMake Error: Could not open file for write in copy operation > /home/robin/bro/master/build/bro-path-dev.tmp > CMake Error: : System Error: Permission denied > CMake Error at CMakeLists.txt:39 (configure_file): > configure_file Problem configuring file > > [...] > > That looks like it's now trying again to write into the build > directory on "make install"? Yeah, but AFAIK the stuff it's trying to write doesn't normally happen on every `make install`, it only happens when part of the CMake framework changes and it determines that it has to "reconfigure" and produce a new cache. You should be able to look further down in the output that got clipped out of your last email and see the "build summary" outputs? That should be a signal that this is what's occurring. Did something happen between the `make` as user robin and the `make install` as user bro? I can make the same thing happen if I just stick a `touch CMakeLists.txt` in between those two steps. > This is cmake 2.8.2 if that matters. I was able to produce the same behavior w/ 2.8.3 as explained above. From robin at icir.org Thu Jan 27 11:46:41 2011 From: robin at icir.org (Robin Sommer) Date: Thu, 27 Jan 2011 11:46:41 -0800 Subject: [Bro-Dev] cmake/install question In-Reply-To: <27841800.520.1296154980913.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <20110127183102.GK57524@icir.org> <27841800.520.1296154980913.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20110127194641.GM57524@icir.org> On Thu, Jan 27, 2011 at 13:03 -0600, you wrote: > Did something happen between the `make` as user robin and the `make install` as user bro? No, nothing, but I've figured it out: NFS was involved, the build was on a different machine than the install. Guess I just need to remember to not do that. Now doing all on the same machine. But, sorry!, it still doesn't work. I reverted to a clean master, did a rebuild as robin, and an install as user bro. That worked. But then I applied my original modifiction to options.py, did another "make" as user robin in the top-level bro directory (which went clean and didn't shown anything done); and then did the "make install" again as user bro: Error copying directory from "/home/robin/bro/master/aux/broctl/BroControl" to "/home/robin/bro/master/build/aux/broctl/BroControl". Listing BroControl ... Can't list BroControl -- Installing: /home/bro/bin/broctl CMake Error at aux/broctl/cmake_install.cmake:47 (FILE): file INSTALL cannot find "/home/robin/bro/master/build/aux/broctl/BroControl". Call Stack (most recent call first): cmake_install.cmake:48 (INCLUDE) 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 Thu Jan 27 12:04:47 2011 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Thu, 27 Jan 2011 14:04:47 -0600 (CST) Subject: [Bro-Dev] cmake/install question In-Reply-To: <20110127194641.GM57524@icir.org> Message-ID: <24600188.556.1296158686071.JavaMail.jsiwek@tangent.ncsa.illinois.edu> > I reverted to a clean master When you're inside the aux/broctl directory, what does `git show-ref master` tell you? > Error copying directory from > "/home/robin/bro/master/aux/broctl/BroControl" to > "/home/robin/bro/master/build/aux/broctl/BroControl". I really don't think that copy should be happening anymore. You might just send me your current version of aux/broctl/CMakeLists.txt and I can see if it's old. From robin at icir.org Thu Jan 27 12:17:01 2011 From: robin at icir.org (Robin Sommer) Date: Thu, 27 Jan 2011 12:17:01 -0800 Subject: [Bro-Dev] cmake/install question In-Reply-To: <24600188.556.1296158686071.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <20110127194641.GM57524@icir.org> <24600188.556.1296158686071.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20110127201701.GN57524@icir.org> On Thu, Jan 27, 2011 at 14:04 -0600, you wrote: > When you're inside the aux/broctl directory, what does `git show-ref master` tell you? Argh, it was indeed *still* not up to date. Works now, 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 Jan 27 12:59:48 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 27 Jan 2011 20:59:48 -0000 Subject: [Bro-Dev] #344: Provide Source Packages via CMake/CPack In-Reply-To: <045.1859fda35d64b44f7d47cb8f7fd3d7f9@tracker.icir.org> References: <045.1859fda35d64b44f7d47cb8f7fd3d7f9@tracker.icir.org> Message-ID: <060.63d0571bb22cbe9a5d79dfabbaa3a85a@tracker.icir.org> #344: Provide Source Packages via CMake/CPack ---------------------+-------------------- Reporter: jsiwek | Owner: jsiwek Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ---------------------+-------------------- Comment (by jsiwek): Status update: All the desired source packages should be generated with: {{{ git clone --recursive git://git.icir.org/bro cd bro make dist }}} and {{{ git clone git://git.icir.org/bro-scripts cd bro-scripts make dist }}} -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 27 13:20:20 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 27 Jan 2011 21:20:20 -0000 Subject: [Bro-Dev] #295: Create prebuilt binary packages In-Reply-To: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> References: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> Message-ID: <058.15910ba1f7d8145f5ef2c0f5e4d5198e@tracker.icir.org> #295: Create prebuilt binary packages ----------------------+---------------------- Reporter: seth | Owner: jsiwek Type: Problem | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ----------------------+---------------------- Comment (by jsiwek): Status update: There was a confirmed problem with the x86_64 libresolv on OS X 10.5. The following will produce all the i386 packages when run on 10.5, and x86_64 packages when run on 10.6: {{{ git clone --recursive git://git.icir.org/bro cd bro ./make-mac-packages }}} The `make-mac-packages` script will need some modifications to produce 10.6 compatible packages if run on 10.7 (when it's out). The following will produce RPMs compatible with the architecture of the machine building it: {{{ git clone --recursive git://git.icir.org/bro cd bro ./make-rpm-packages }}} Justin Azoff and Craig Leres were contacted about deb packages and FreeBSD ports. The only thing left to do in this ticket would be create packages for Bro 1.6 when it's ready, but it would be great if the NMI testbed is testing package creation for some time before that. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 27 14:53:56 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Thu, 27 Jan 2011 22:53:56 -0000 Subject: [Bro-Dev] #295: Create prebuilt binary packages In-Reply-To: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> References: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> Message-ID: <058.dd182e0c6f20129df2d804dd6d018a7b@tracker.icir.org> #295: Create prebuilt binary packages ----------------------+---------------------- Reporter: seth | Owner: jsiwek Type: Problem | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ----------------------+---------------------- Comment (by robin): > The only thing left to do in this ticket would be create packages for Bro > 1.6 when it's ready, but it would be great if the NMI testbed is testing > package creation for some time before that. Sounds like we can close this ticket then, and open a new one for testing on the NMI testbed? Robin -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Thu Jan 27 17:43:39 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 01:43:39 -0000 Subject: [Bro-Dev] #295: Create prebuilt binary packages In-Reply-To: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> References: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> Message-ID: <058.41cb29e7dc57e27e8f993053463df562@tracker.icir.org> #295: Create prebuilt binary packages ----------------------+---------------------- Reporter: seth | Owner: jsiwek Type: Problem | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ----------------------+---------------------- Comment (by jsiwek): > Sounds like we can close this ticket then, and open a new one for > testing on the NMI testbed? I agree that a new ticket for NMI testing might make sense to help track the things we need to be testing, but I was thinking that this one wouldn't close until the actual creation of packages for 1.6 is complete. It's probably hard to forget to do that, though, so I don't mind if you want to close it (I guess same goes for #344) -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 08:05:51 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 16:05:51 -0000 Subject: [Bro-Dev] #369: Expand and document local-*.bro scripts Message-ID: <043.56e896c79399af1a721c8d10c21b4018@tracker.icir.org> #369: Expand and document local-*.bro scripts ------------------------+-------------------- Reporter: seth | Owner: seth Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: Keywords: | ------------------------+-------------------- It would be very helpful to new users to have lots of inline documentation and external documentation for what to put into the various local-manager, local-workers, and local.bro scripts. Having examples of common practices in those files commented out would be very helpful too. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 08:32:11 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 16:32:11 -0000 Subject: [Bro-Dev] #295: Create prebuilt binary packages In-Reply-To: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> References: <043.5bb3b42886a93b64dbf0cb7215a12581@tracker.icir.org> Message-ID: <058.72a639df2769b3a947d47d53466c10f0@tracker.icir.org> #295: Create prebuilt binary packages -----------------------------+-------------------- Reporter: seth | Owner: jsiwek Type: Problem | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: Merged/Applied | Keywords: -----------------------------+-------------------- Changes (by robin): * status: assigned => closed * resolution: => Merged/Applied Comment: I'm closing it. Making packages will be part of the standard release process now, so not really something that needs a ticket. Instead, we'll need to do a todo-for-release howto at some point, but that's too early right now I guess. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 08:32:32 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 16:32:32 -0000 Subject: [Bro-Dev] #344: Provide Source Packages via CMake/CPack In-Reply-To: <045.1859fda35d64b44f7d47cb8f7fd3d7f9@tracker.icir.org> References: <045.1859fda35d64b44f7d47cb8f7fd3d7f9@tracker.icir.org> Message-ID: <060.0faf376c4bb31826af7540c8f82e7e91@tracker.icir.org> #344: Provide Source Packages via CMake/CPack -----------------------------+-------------------- Reporter: jsiwek | Owner: jsiwek Type: Task | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: Merged/Applied | Keywords: -----------------------------+-------------------- Changes (by robin): * status: new => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 09:02:06 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 17:02:06 -0000 Subject: [Bro-Dev] #370: Plugin interface for BroControl Message-ID: <043.95b2acb07df54963a84b633b546fafcb@tracker.icir.org> #370: Plugin interface for BroControl -----------------------------+-------------------- Reporter: seth | Owner: robin Type: Feature Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: BroControl | Version: Keywords: | -----------------------------+-------------------- Features that a first version of the plugin interface should have... * Hooks to execute external scripts before and after start, stop, and install. * Mechanism for plugin scripts to provide feedback to BroControl. Maybe just succeed or fail+message would be enough? * Setting options for plugins in broctl.cfg. Maybe set ENV vars when running scripts? Currently, I'm thinking that using a naming convention for files in /share/broctl/plugins would work for installing plugins. Names like this: post-install-plugin1 or pre-start-plugin2. That would provide BroControl enough information to know which configuration options to set in the environment when executing those scripts and when they are supposed to be executed. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 09:16:00 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 17:16:00 -0000 Subject: [Bro-Dev] #298: Automatic build tests on NMI testbed. In-Reply-To: <043.117bc47cd43283656aadb96286c21804@tracker.icir.org> References: <043.117bc47cd43283656aadb96286c21804@tracker.icir.org> Message-ID: <058.a8c8841f0eccd2f6a90be0f96e1078b9@tracker.icir.org> #298: Automatic build tests on NMI testbed. ---------------------+-------------------- Reporter: seth | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ---------------------+-------------------- Comment (by jsiwek): Just starting the list of things that should fall under this task: * builds from git repositories (release, master, devel branches) * source package creation (check that they do not differ from what gets checked out from git) * binary package creation * binary package installation (check that they install the same stuff as `make install`) -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 09:20:11 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 17:20:11 -0000 Subject: [Bro-Dev] #298: Automatic build tests on NMI testbed. In-Reply-To: <043.117bc47cd43283656aadb96286c21804@tracker.icir.org> References: <043.117bc47cd43283656aadb96286c21804@tracker.icir.org> Message-ID: <058.ff7731bf15b861de524f022b98210575@tracker.icir.org> #298: Automatic build tests on NMI testbed. ---------------------+-------------------- Reporter: seth | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ---------------------+-------------------- Comment (by robin): In fact, we should probably generally create the final release packages on NMI. That makes sure that (1) we're testing what we're releasing; and (2) results will be the same no matter who's doing the release (i.e., specifics will not slightly differ just because of the maintainer working on a different machine than last time). -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 10:09:52 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 18:09:52 -0000 Subject: [Bro-Dev] #366: Crash with optional table and record ctors In-Reply-To: <044.239d846a881e67ec1f52965a6200a7b6@tracker.icir.org> References: <044.239d846a881e67ec1f52965a6200a7b6@tracker.icir.org> Message-ID: <059.705de0371fd943857a0d8458586d26df@tracker.icir.org> #366: Crash with optional table and record ctors ----------------------+------------------------ Reporter: robin | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Component: Bro | Version: git/master Resolution: | Keywords: ----------------------+------------------------ Old description: > This crashes: > > type request: record { > ... > t: time; > x: table[string] of string &optional &default="-"; > ... > } > > local req: request = [$t=network_time()]; # <-- here > > (gdb) print this > Cannot access memory at address 0x0 > #0 RecordVal::Assign (this=0x10125dcd0, field=6, new_val=0x0, > op=OP_ASSIGN) at /Users/robin/bro/master/src/Val.cc:2850 > #1 0x00000001000c6d5f in RecordCoerceExpr::Fold (this=0x10123e960, > v=0x10125eab0) at /Users/robin/bro/master/src/Expr.cc:4052 > #2 0x00000001000c9485 in UnaryExpr::Eval (this=0x10123e960, f= temporarily unavailable, due to optimizations>) at > /Users/robin/bro/master/src/Expr.cc:509 > #3 0x00000001000c3eea in AssignExpr::Eval (this=0x10123e830, > f=0x101254110) at /Users/robin/bro/master/src/Expr.cc:2609 > warning: .o file > "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Stmt.cc.o" > more recent than executable timestamp in "/Users/robin/bin/bro" > warning: Couldn't open object file > '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Stmt.cc.o' > #4 0x00000001001766a6 in ExprStmt::Exec () > #5 0x0000000100172640 in StmtList::Exec () > #6 0x0000000100172640 in StmtList::Exec () > warning: .o file > "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Func.cc.o" > more recent than executable timestamp in "/Users/robin/bin/bro" > warning: Couldn't open object file > '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Func.cc.o' > #7 0x00000001000e037d in BroFunc::Call () > warning: .o file > "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/EventHandler.cc.o" > more recent than executable timestamp in "/Users/robin/bin/bro" > warning: Couldn't open object file > '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/EventHandler.cc.o' > #8 0x000000010009f154 in EventHandler::Call () > warning: .o file > "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Event.cc.o" > more recent than executable timestamp in "/Users/robin/bin/bro" > warning: Couldn't open object file > '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Event.cc.o' > #9 0x000000010009eb1d in EventMgr::Dispatch () > #10 0x000000010009ec48 in EventMgr::Drain () > warning: .o file > "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Net.cc.o" > more recent than executable timestamp in "/Users/robin/bin/bro" > warning: Couldn't open object file > '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Net.cc.o' > #11 0x00000001001297b5 in net_packet_dispatch () > warning: .o file > "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/PktSrc.cc.o" > more recent than executable timestamp in "/Users/robin/bin/bro" > warning: Couldn't open object file > '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/PktSrc.cc.o' > #12 0x0000000100136cf7 in PktSrc::Process () > #13 0x0000000100129a50 in net_run () > warning: .o file > "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/main.cc.o" > more recent than executable timestamp in "/Users/robin/bin/bro" > warning: Couldn't open object file > '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/main.cc.o' > #14 0x00000001000600b3 in main () New description: This crashes: {{{ type request: record { ... t: time; x: table[string] of string &optional &default="-"; ... } local req: request = [$t=network_time()]; # <-- here (gdb) print this Cannot access memory at address 0x0 #0 RecordVal::Assign (this=0x10125dcd0, field=6, new_val=0x0, op=OP_ASSIGN) at /Users/robin/bro/master/src/Val.cc:2850 #1 0x00000001000c6d5f in RecordCoerceExpr::Fold (this=0x10123e960, v=0x10125eab0) at /Users/robin/bro/master/src/Expr.cc:4052 #2 0x00000001000c9485 in UnaryExpr::Eval (this=0x10123e960, f=) at /Users/robin/bro/master/src/Expr.cc:509 #3 0x00000001000c3eea in AssignExpr::Eval (this=0x10123e830, f=0x101254110) at /Users/robin/bro/master/src/Expr.cc:2609 warning: .o file "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Stmt.cc.o" more recent than executable timestamp in "/Users/robin/bin/bro" warning: Couldn't open object file '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Stmt.cc.o' #4 0x00000001001766a6 in ExprStmt::Exec () #5 0x0000000100172640 in StmtList::Exec () #6 0x0000000100172640 in StmtList::Exec () warning: .o file "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Func.cc.o" more recent than executable timestamp in "/Users/robin/bin/bro" warning: Couldn't open object file '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Func.cc.o' #7 0x00000001000e037d in BroFunc::Call () warning: .o file "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/EventHandler.cc.o" more recent than executable timestamp in "/Users/robin/bin/bro" warning: Couldn't open object file '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/EventHandler.cc.o' #8 0x000000010009f154 in EventHandler::Call () warning: .o file "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Event.cc.o" more recent than executable timestamp in "/Users/robin/bin/bro" warning: Couldn't open object file '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Event.cc.o' #9 0x000000010009eb1d in EventMgr::Dispatch () #10 0x000000010009ec48 in EventMgr::Drain () warning: .o file "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Net.cc.o" more recent than executable timestamp in "/Users/robin/bin/bro" warning: Couldn't open object file '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/Net.cc.o' #11 0x00000001001297b5 in net_packet_dispatch () warning: .o file "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/PktSrc.cc.o" more recent than executable timestamp in "/Users/robin/bin/bro" warning: Couldn't open object file '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/PktSrc.cc.o' #12 0x0000000100136cf7 in PktSrc::Process () #13 0x0000000100129a50 in net_run () warning: .o file "/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/main.cc.o" more recent than executable timestamp in "/Users/robin/bin/bro" warning: Couldn't open object file '/Users/robin/Dropbox/Home/bro/master/build/src/CMakeFiles/bro.dir/main.cc.o' #14 0x00000001000600b3 in main () }}} -- Comment (by robin): Vern, yes that was the intent. However, I'm not sure it actually works here as I intended: as the value is optional, the table instance is created later, and I'm guessing not transfering the &default over. Seth, so this is not exactly the same problem you were running into for the logging framework, is it? -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 10:14:14 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 18:14:14 -0000 Subject: [Bro-Dev] #371: New column-based logging interface. Message-ID: <044.6ec0868897a17557cdbad939647d20a3@tracker.icir.org> #371: New column-based logging interface. --------------------+----------------------- Reporter: robin | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/topic Keywords: | --------------------+----------------------- See http://bro.icir.org/devel/projects/logging-api.html for more information. Implementation proceeds in branch `topic/logging-framework`. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 10:14:52 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 18:14:52 -0000 Subject: [Bro-Dev] #301: Switch to binary logging In-Reply-To: <043.495d3fa38ccf5577a30cf4b0e6f565a0@tracker.icir.org> References: <043.495d3fa38ccf5577a30cf4b0e6f565a0@tracker.icir.org> Message-ID: <058.08be61829cf9fad4b880988da878a453@tracker.icir.org> #301: Switch to binary logging ------------------------------+-------------------- Reporter: seth | Owner: Type: Feature Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ------------------------------+-------------------- Comment (by robin): Requires implementation of #371 first. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 10:20:54 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 18:20:54 -0000 Subject: [Bro-Dev] #372: bifcl cannot pass specific enum types Message-ID: <044.b8c2079313fca2a6187512304835f0f1@tracker.icir.org> #372: bifcl cannot pass specific enum types ---------------------+-------------------- Reporter: robin | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | ---------------------+-------------------- From Seth: > I have an enum named Logging::ID, and I want it to be the first argument in this BiF? > {{{function logging_log%(id: Logging::ID, rec: any%): bool}}} From Gregor: > bifcl supports enums (it just casts them as a "neutral" Val*, same as > for record types). So it would just be a matter of telling bifcl to > accept the Namespace::Type name syntax. That should be it. > > The C part doesn't really care about the type. It's all a "netural" > Val*. The type is only used for the policy file and type checking. > > EnumType and EnumVal should make accessing the enum's value relatively > easy. I'm using that in my re-working of the NFS analyzer. Let me know > if you want details. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 10:22:53 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 18:22:53 -0000 Subject: [Bro-Dev] #366: Crash with optional table and record ctors In-Reply-To: <044.239d846a881e67ec1f52965a6200a7b6@tracker.icir.org> References: <044.239d846a881e67ec1f52965a6200a7b6@tracker.icir.org> Message-ID: <059.8729dc8ac5957b54e985d2323cde0c8d@tracker.icir.org> #366: Crash with optional table and record ctors ----------------------+------------------------ Reporter: robin | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Component: Bro | Version: git/master Resolution: | Keywords: ----------------------+------------------------ Comment (by seth): Replying to [comment:2 robin]: > Seth, so this is not exactly the same problem you were running into for the logging framework, is it? Nope, totally different problem actually. That's why I went ahead and created #367 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 10:27:49 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 18:27:49 -0000 Subject: [Bro-Dev] #371: New column-based logging interface. In-Reply-To: <044.6ec0868897a17557cdbad939647d20a3@tracker.icir.org> References: <044.6ec0868897a17557cdbad939647d20a3@tracker.icir.org> Message-ID: <059.585dfd7951c76388142789e1ac3af38a@tracker.icir.org> #371: New column-based logging interface. ---------------------+----------------------- Reporter: robin | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/topic Resolution: | Keywords: ---------------------+----------------------- Comment (by robin): Seth, nice work with the initial code! So how do we proceed? Seems there are a number of things blocking some of the stuff: * #363 * #372 What else? -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 10:29:12 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 18:29:12 -0000 Subject: [Bro-Dev] #366: Crash with optional table and record ctors In-Reply-To: <044.239d846a881e67ec1f52965a6200a7b6@tracker.icir.org> References: <044.239d846a881e67ec1f52965a6200a7b6@tracker.icir.org> Message-ID: <059.a2d2116ace6d59bbc7727c06e889ea95@tracker.icir.org> #366: Crash with optional table and record ctors ----------------------+------------------------ Reporter: robin | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Component: Bro | Version: git/master Resolution: | Keywords: ----------------------+------------------------ Comment (by robin): On Fri, Jan 28, 2011 at 18:22 -0000, you wrote: > Nope, totally different problem actually. That's why I went ahead and > created #367 Ah, missed that! Robin -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 10:51:27 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 18:51:27 -0000 Subject: [Bro-Dev] #373: topic/jsiwek/missing-config-options Message-ID: <045.4b6ea97fc726f96dd1227e1c5188e29d@tracker.icir.org> #373: topic/jsiwek/missing-config-options ---------------------------+------------------------ Reporter: jsiwek | Owner: Type: Merge Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Keywords: | ---------------------------+------------------------ This topic branch exists in the bro repository and all submodules recursively (except the trace-summary and capstats repos contain no new commits). It adds options to each configure wrapper script to assist users that need to find dependencies in non-standard locations. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 11:04:17 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 19:04:17 -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.0afe049d136ca2318454e440aeb2d22b@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 sprint ---------------------+----------------------------------- Comment (by robin): So is this ready for merging? -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 11:08:36 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 19:08:36 -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.9e050b07ebe47af93bfe544ac45b14ed@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 sprint ---------------------+----------------------------------- Comment (by seth): Nope, that's actually what I've been working on today. There were several other bugs I'm fixing in that analyzer right now. Almost done. -- Ticket URL: Bro Tracker Bro Issue Tracker From seth at icir.org Fri Jan 28 11:13:52 2011 From: seth at icir.org (Seth Hall) Date: Fri, 28 Jan 2011 14:13:52 -0500 Subject: [Bro-Dev] all changes in branch? Message-ID: <4F1DD470-D42A-4733-B875-1C034CB54908@icir.org> How would I go about seeing all of the changes that have happened in a branch since the branch was created? .Seth From bro at tracker.icir.org Fri Jan 28 11:14:57 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 19:14:57 -0000 Subject: [Bro-Dev] #374: Add type testing operator Message-ID: <043.8b359cb3ae787df001044e74fe896074@tracker.icir.org> #374: Add type testing operator -----------------------------+-------------------- Reporter: seth | Owner: Type: Feature Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | -----------------------------+-------------------- This is needed for generic filtering of log records in the logging framework. Initial discussions have used a syntax like this: {{{ function generic_outbound(rec: any) { rec$?cid ... }}} That syntax would check that the record type instance 'rec' has a field named 'cid' with the type 'conn_id'. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 11:20:01 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 19:20:01 -0000 Subject: [Bro-Dev] #375: Extending record type fields Message-ID: <043.8edae7eaa6a3609d14220f5e1643d239@tracker.icir.org> #375: Extending record type fields -----------------------------+-------------------- Reporter: seth | Owner: Type: Feature Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: logging | -----------------------------+-------------------- One proposal for giving users the ability to add their own fields to the record type used for logging to a particular stream in the new logging framework involves redef-ing the record type to add new fields. Example syntax: {{{ module SSH; type Log = record { client: string; server: string; } redef type SSH::Log += { id: conn_id &optional; }; }}} I'm even thinking that fields added in redefs could even be mandatory or implicitly &optional to avoid causing errors with shipped scripts. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 11:20:13 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 19:20:13 -0000 Subject: [Bro-Dev] #374: Add type testing operator In-Reply-To: <043.8b359cb3ae787df001044e74fe896074@tracker.icir.org> References: <043.8b359cb3ae787df001044e74fe896074@tracker.icir.org> Message-ID: <058.1a72f90da6d11eff8678cdcf48689041@tracker.icir.org> #374: Add type testing operator ------------------------------+--------------------- Reporter: seth | Owner: Type: Feature Request | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: logging ------------------------------+--------------------- Changes (by seth): * keywords: => logging -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 11:20:50 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 19:20:50 -0000 Subject: [Bro-Dev] #371: New column-based logging interface. In-Reply-To: <044.6ec0868897a17557cdbad939647d20a3@tracker.icir.org> References: <044.6ec0868897a17557cdbad939647d20a3@tracker.icir.org> Message-ID: <059.490479104e0d343f0d26a95c9cd4513e@tracker.icir.org> #371: New column-based logging interface. ---------------------+----------------------- Reporter: robin | Owner: Type: Task | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/topic Resolution: | Keywords: ---------------------+----------------------- Comment (by seth): These tickets too for a full implementation. * #374 * #375 -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 11:21:08 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 19:21:08 -0000 Subject: [Bro-Dev] #367: internal_error with &optional fields in records used as indexes In-Reply-To: <043.81b272eefc82d70a12d6ae939c639044@tracker.icir.org> References: <043.81b272eefc82d70a12d6ae939c639044@tracker.icir.org> Message-ID: <058.160bce08151577f47487976b3864f072@tracker.icir.org> #367: internal_error with &optional fields in records used as indexes ----------------------+------------------------ Reporter: seth | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: | Keywords: logging ----------------------+------------------------ Changes (by seth): * keywords: => logging -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 11:21:51 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 19:21:51 -0000 Subject: [Bro-Dev] #376: Parse git commits to change ticket status Message-ID: <044.94d2de55f3d5e894caa22879955b5dc2@tracker.icir.org> #376: Parse git commits to change ticket status -----------------------------+------------------ Reporter: robin | Owner: seth Type: Feature Request | Status: new Priority: Normal | Milestone: Component: TicketTracker | Version: Keywords: | -----------------------------+------------------ With Subversion, we could write something like "closes #23" into a commit message, and the ticket would automatically be closed. Would be nice to have with git too. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 11:22:01 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 19:22:01 -0000 Subject: [Bro-Dev] #372: bifcl cannot pass specific enum types In-Reply-To: <044.b8c2079313fca2a6187512304835f0f1@tracker.icir.org> References: <044.b8c2079313fca2a6187512304835f0f1@tracker.icir.org> Message-ID: <059.837adda88ebb4b226487acbb33471142@tracker.icir.org> #372: bifcl cannot pass specific enum types ----------------------+--------------------- Reporter: robin | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: logging ----------------------+--------------------- Changes (by seth): * keywords: => logging -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 11:27:37 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 19:27:37 -0000 Subject: [Bro-Dev] #213: Portability fixes for broctl on OpenBSD In-Reply-To: <054.60e6a9a9cc06771e42a1c013d763acee@tracker.icir.org> References: <054.60e6a9a9cc06771e42a1c013d763acee@tracker.icir.org> Message-ID: <069.413ccb9e9138118edd3591934aaffa13@tracker.icir.org> #213: Portability fixes for broctl on OpenBSD ------------------------------+-------------------- Reporter: kevlo@? | Owner: robin Type: Patch | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: Merged/Applied | Keywords: sprint ------------------------------+-------------------- Changes (by robin): * status: assigned => closed * resolution: => Merged/Applied Comment: Applied, finally. Thanks! -- Ticket URL: Bro Tracker Bro Issue Tracker From robin at icir.org Fri Jan 28 12:53:36 2011 From: robin at icir.org (Robin Sommer) Date: Fri, 28 Jan 2011 12:53:36 -0800 Subject: [Bro-Dev] all changes in branch? In-Reply-To: <4F1DD470-D42A-4733-B875-1C034CB54908@icir.org> References: <4F1DD470-D42A-4733-B875-1C034CB54908@icir.org> Message-ID: <20110128205336.GA59197@icir.org> On Fri, Jan 28, 2011 at 14:13 -0500, you wrote: > How would I go about seeing all of the changes that have happened in a > branch since the branch was created? If you really want *all* changes, I think you need the revision r of the branch point and can then do "git log r..HEAD". If you want everything on the branch, but not on, say, master: "git log HEAD ^master" (which I think is actually the same as "git log master..HEAD", but more intuitive). You might want to throw in a "--no-merges" 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 bro at tracker.icir.org Fri Jan 28 13:34:14 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 21:34:14 -0000 Subject: [Bro-Dev] #209: topic/seth/ssl-analyzer-work - small patch SSLv3 for detect Extensions Length in bro v1.5.1 (was: 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.e8be60a665f3224f563a705053077ff7@tracker.icir.org> #209: topic/seth/ssl-analyzer-work - small patch SSLv3 for detect Extensions Length in bro v1.5.1 ----------------------------+----------------------------------- Reporter: rmkml | Owner: Type: Merge Request | Status: seen Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: ssl extensions sprint ----------------------------+----------------------------------- Changes (by seth): * type: Patch => Merge Request Comment: This should be ready for merging now. I've run it on some traces I have and the results look better than they did before. Nothing relating to SSL was affected in the test suite (not that I know if there is anything testing SSL in the test suite). -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Fri Jan 28 13:41:27 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Fri, 28 Jan 2011 21:41:27 -0000 Subject: [Bro-Dev] #209: topic/seth/ssl-analyzer-work - 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.e8d4d36d5a906d76d51c14c96cdc0214@tracker.icir.org> #209: topic/seth/ssl-analyzer-work - small patch SSLv3 for detect Extensions Length in bro v1.5.1 ----------------------------+----------------------------------- Reporter: rmkml | Owner: Type: Merge Request | Status: seen Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: ssl extensions sprint ----------------------------+----------------------------------- Comment (by seth): One more thing in case anyone feels like looking into it is that the "SSLProxy: Excessive small TCP Segment!" weird is still being thrown in cases that I don't think it should be. It could be worth looking into. It may have something to do with this (backward compatibility with SSL2.0 servers): http://tools.ietf.org/html/rfc5246#appendix-E.2 -- Ticket URL: Bro Tracker Bro Issue Tracker From jsiwek at ncsa.illinois.edu Fri Jan 28 14:18:28 2011 From: jsiwek at ncsa.illinois.edu (Jonathan Siwek) Date: Fri, 28 Jan 2011 16:18:28 -0600 (CST) Subject: [Bro-Dev] git-notifier error In-Reply-To: <21573599.614.1296252766415.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <6624706.618.1296253108226.JavaMail.jsiwek@tangent.ncsa.illinois.edu> For the capstats repository, I just merged master into fastpath, made a commit, then got the following when pushing: jsiwek at tangent:capstats (fastpath) $ git push origin HEAD Counting objects: 8, done. Delta compression using up to 4 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 617 bytes, done. Total 4 (delta 2), reused 0 (delta 0) remote: Traceback (most recent call last): remote: File "/db/bro/git-notifier/git-notifier", line 447, in remote: cache.readFrom(CacheFile) remote: File "/db/bro/git-notifier/git-notifier", line 50, in readFrom remote: (type, key, val) = (m[0], m[1], m[2]) remote: IndexError: list index out of range To ssh://bro at git.icir.org/capstats 3f47337..31dc5b0 HEAD -> fastpath So it looks like an email wasn't sent to bro-commits, but the repository has been updated. - Jon From robin at icir.org Fri Jan 28 15:55:41 2011 From: robin at icir.org (Robin Sommer) Date: Fri, 28 Jan 2011 15:55:41 -0800 Subject: [Bro-Dev] git-notifier error In-Reply-To: <6624706.618.1296253108226.JavaMail.jsiwek@tangent.ncsa.illinois.edu> References: <21573599.614.1296252766415.JavaMail.jsiwek@tangent.ncsa.illinois.edu> <6624706.618.1296253108226.JavaMail.jsiwek@tangent.ncsa.illinois.edu> Message-ID: <20110128235541.GB59197@icir.org> On Fri, Jan 28, 2011 at 16:18 -0600, you wrote: > I just merged master into fastpath, made a commit, then got the following when pushing: Interesting, there's a commit in there which isn't reachable from any head ... My script didn't like that, but should be fixed now. 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 Jan 31 09:20:24 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 31 Jan 2011 17:20:24 -0000 Subject: [Bro-Dev] #272: topic/seth/strings-without-checkstring - Use Bytes() and Len() instead of CheckString() in strings.bif In-Reply-To: <043.1e378c2cf2d2f272b054d3bd5b2f44d9@tracker.icir.org> References: <043.1e378c2cf2d2f272b054d3bd5b2f44d9@tracker.icir.org> Message-ID: <058.7229df6518099755331108213445d294@tracker.icir.org> #272: topic/seth/strings-without-checkstring - Use Bytes() and Len() instead of CheckString() in strings.bif ----------------------------+---------------------- Reporter: seth | Owner: seth Type: Merge Request | Status: assigned Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: 1.5.2 Resolution: | Keywords: sprint ----------------------------+---------------------- Comment (by seth): I don't know why I didn't see the error in the test suite last time. The problem is fixed now. Sorry about the other false starts. :) I commented on what was going wrong in the commit. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Jan 31 12:33:33 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 31 Jan 2011 20:33:33 -0000 Subject: [Bro-Dev] #373: topic/jsiwek/missing-config-options In-Reply-To: <045.4b6ea97fc726f96dd1227e1c5188e29d@tracker.icir.org> References: <045.4b6ea97fc726f96dd1227e1c5188e29d@tracker.icir.org> Message-ID: <060.e0f87b13ddac91c976a63f44e90caab1@tracker.icir.org> #373: topic/jsiwek/missing-config-options -----------------------------+------------------------ Reporter: jsiwek | Owner: Type: Merge Request | Status: closed Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: git/master Resolution: Merged/Applied | Keywords: -----------------------------+------------------------ Changes (by robin): * status: new => closed * resolution: => Merged/Applied -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Jan 31 13:14:48 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 31 Jan 2011 21:14:48 -0000 Subject: [Bro-Dev] #377: software.bro is non-functional Message-ID: <044.f0f943ece4e3b985eb7ba0625378fe3d@tracker.icir.org> #377: software.bro is non-functional ---------------------+-------------------- Reporter: robin | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Keywords: | ---------------------+-------------------- The only analzyer that currently generates the neccessary events is HTTP, and that one has actually an `#ifdef 0 / #endif` around the relevant code. So, probably something to remove, as it may be superseded by new functionality in the future anyway. -- Ticket URL: Bro Tracker Bro Issue Tracker From bro at tracker.icir.org Mon Jan 31 13:20:46 2011 From: bro at tracker.icir.org (Bro Tracker) Date: Mon, 31 Jan 2011 21:20:46 -0000 Subject: [Bro-Dev] #377: software.bro is non-functional In-Reply-To: <044.f0f943ece4e3b985eb7ba0625378fe3d@tracker.icir.org> References: <044.f0f943ece4e3b985eb7ba0625378fe3d@tracker.icir.org> Message-ID: <059.5f9f650d5575ea38fbf4c0eeb2eb2737@tracker.icir.org> #377: software.bro is non-functional ----------------------+-------------------- Reporter: robin | Owner: Type: Problem | Status: new Priority: Normal | Milestone: Bro1.6 Component: Bro | Version: Resolution: | Keywords: ----------------------+-------------------- Comment (by seth): I was planning on replacing it with my software-ext script. It's basically the same script, but with some features cleaned up and integrated into other scripts. -- Ticket URL: Bro Tracker Bro Issue Tracker