From bro at tracker.icir.org  Fri Apr  1 08:59:03 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 01 Apr 2011 15:59:03 -0000
Subject: [Bro-Dev] #430: Build error in LogMgr.cc
In-Reply-To: <047.b7495de40c3e3ce4a9d440149e22b540@tracker.icir.org>
References: <047.b7495de40c3e3ce4a9d440149e22b540@tracker.icir.org>
Message-ID: <062.2712b8f34d15e300a7674e26c09016ac@tracker.icir.org>

#430: Build error in LogMgr.cc
-----------------------+-----------------------
  Reporter:  appleman  |      Owner:  robin
      Type:  Problem   |     Status:  assigned
  Priority:  Normal    |  Milestone:
 Component:  Bro       |    Version:  git/topic
Resolution:            |   Keywords:
-----------------------+-----------------------
Changes (by jsiwek):

 * owner:   => robin
 * status:  new => assigned


Comment:

 That seems like the right thing to do.  Not including `<algorithm>` when
 the source code depends on `std::transform` is probably a coding error
 regardless of whether it results in a build error on different platforms
 -- i.e. it might succeed by chance if header inter-dependencies happen to
 include `<algorithm>`.

 So are you just waiting for Robin to make a change to his `topic/robin
 /logging-internals` since that's an upstream source of `topic/policy-
 scripts-new` ?  I'll assign this to him, but maybe he'll say it's cool for
 you to just go ahead and do that.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/430#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr  1 09:10:48 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 01 Apr 2011 16:10:48 -0000
Subject: [Bro-Dev] #430: Build error in LogMgr.cc
In-Reply-To: <047.b7495de40c3e3ce4a9d440149e22b540@tracker.icir.org>
References: <047.b7495de40c3e3ce4a9d440149e22b540@tracker.icir.org>
Message-ID: <062.9ddaa72e6d96458cab3eeaf85833aedf@tracker.icir.org>

#430: Build error in LogMgr.cc
-----------------------+-----------------------
  Reporter:  appleman  |      Owner:  robin
      Type:  Problem   |     Status:  assigned
  Priority:  Normal    |  Milestone:
 Component:  Bro       |    Version:  git/topic
Resolution:            |   Keywords:
-----------------------+-----------------------

Comment (by robin):

 On Fri, Apr 01, 2011 at 15:59 -0000, you wrote:

 >  So are you just waiting for Robin to make a change to his `topic/robin
 >  /logging-internals` since that's an upstream source of `topic/policy-
 >  scripts-new` ?  I'll assign this to him, but maybe he'll say it's cool
 for
 >  you to just go ahead and do that.

 Yes, that's totally fine.

 Robin

 --
 Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org
 ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/430#comment:3>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr  1 09:58:10 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 01 Apr 2011 16:58:10 -0000
Subject: [Bro-Dev] #431: Tracker glitch
Message-ID: <043.289f106ef6e101dcd05d8bb8c3785c91@tracker.icir.org>

#431: Tracker glitch
---------------------+-----------------
 Reporter:  vern     |      Owner:
     Type:  Problem  |     Status:  new
 Priority:  Normal   |  Milestone:
Component:  Bro      |    Version:
 Keywords:           |
---------------------+-----------------
 When accessing the tracker, I'm getting the message:

 ''Warning: Error with navigation contributor "BrowserModule"''

 (that's a literal Browser Module [with no space between the words], which
 as I type it as a single word above is being turned into a Wiki link)

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/431>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr  1 10:00:01 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 01 Apr 2011 17:00:01 -0000
Subject: [Bro-Dev] #432: exporting names from icmp.bro
Message-ID: <043.462dd26178957a450c3018f70ad24db7@tracker.icir.org>

#432: exporting names from icmp.bro
-----------------------------+-----------------
 Reporter:  vern             |      Owner:
     Type:  Feature Request  |     Status:  new
 Priority:  Normal           |  Milestone:
Component:  Bro              |    Version:
 Keywords:                   |
-----------------------------+-----------------
 It's useful to have external access to ICMP::names (and probably also
 ICMP::IP_proto_name) so that additional ICMP event handlers can determine
 what type of ICMP they've been passed by inspecting the associated name,
 rather than the raw number.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/432>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr  1 11:09:50 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 01 Apr 2011 18:09:50 -0000
Subject: [Bro-Dev] #431: Tracker glitch
In-Reply-To: <043.289f106ef6e101dcd05d8bb8c3785c91@tracker.icir.org>
References: <043.289f106ef6e101dcd05d8bb8c3785c91@tracker.icir.org>
Message-ID: <058.bb6a74b292ba23301deab15f4d5d7582@tracker.icir.org>

#431: Tracker glitch
------------------------+--------------------
  Reporter:  vern       |      Owner:
      Type:  Problem    |     Status:  closed
  Priority:  Normal     |  Milestone:
 Component:  Bro        |    Version:
Resolution:  Duplicate  |   Keywords:
------------------------+--------------------
Changes (by seth):

 * status:  new => closed
 * resolution:   => Duplicate


Comment:

 I'll be fixing that as soon as I can.  Looks like probably not until next
 week at this point though.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/431#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr  1 14:36:54 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 01 Apr 2011 21:36:54 -0000
Subject: [Bro-Dev] #72: Use 64Bit integers in Bro by default
In-Reply-To: <045.e3497c69dfe36a4cddde29c01881d602@tracker.icir.org>
References: <045.e3497c69dfe36a4cddde29c01881d602@tracker.icir.org>
Message-ID: <060.ea4871ab41fb9f7190c00082ae0c32fa@tracker.icir.org>

#72: Use 64Bit integers in Bro by default
-----------------------------+--------------------------------------------
  Reporter:  gregor          |      Owner:  robin
      Type:  Task            |     Status:  closed
  Priority:  Normal          |  Milestone:  Bro1.6
 Component:  Bro             |    Version:  1.5.2
Resolution:  Merged/Applied  |   Keywords:  integer size, 64 bit, inttypes
-----------------------------+--------------------------------------------
Changes (by robin):

 * status:  testing => closed
 * resolution:   => Merged/Applied


Comment:

 Closing because it has been applied already. The Broccoli ticket is still
 open though.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/72#comment:13>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr  1 15:28:52 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 01 Apr 2011 22:28:52 -0000
Subject: [Bro-Dev] #381: Switch to DPD by default
In-Reply-To: <044.78d90be2e52022fca356dc69969e0acc@tracker.icir.org>
References: <044.78d90be2e52022fca356dc69969e0acc@tracker.icir.org>
Message-ID: <059.4ede6ed89226fa07de6a1b8113224718@tracker.icir.org>

#381: Switch to DPD by default
---------------------+--------------------
  Reporter:  robin   |      Owner:  robin
      Type:  Task    |     Status:  closed
  Priority:  Normal  |  Milestone:  Bro1.6
 Component:  Bro     |    Version:
Resolution:  Solved  |   Keywords:
---------------------+--------------------
Changes (by robin):

 * status:  accepted => closed
 * resolution:   => Solved


Comment:

 Closing, this is part of Seth's script work already.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/381#comment:4>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr  1 15:59:42 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 01 Apr 2011 22:59:42 -0000
Subject: [Bro-Dev] #412: Port the istate tests to btes
In-Reply-To: <044.325f74c6d09693a51bde1e009db18a42@tracker.icir.org>
References: <044.325f74c6d09693a51bde1e009db18a42@tracker.icir.org>
Message-ID: <059.e44c2eaaf2cecab465ca01629356e8f2@tracker.icir.org>

#412: Port the istate tests to btes
---------------------+--------------------
  Reporter:  robin   |      Owner:  robin
      Type:  Task    |     Status:  new
  Priority:  Normal  |  Milestone:  Bro1.6
 Component:  Bro     |    Version:
Resolution:          |   Keywords:
---------------------+--------------------

Comment (by robin):

 This is done "in theory". However, the tests don't pass yet because of (1)
 the 64-bit Broccoli problem, and (2) the lack of the hash seed environment
 variable.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/412#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr  1 16:00:25 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 01 Apr 2011 23:00:25 -0000
Subject: [Bro-Dev] #297: Remove trace rewriter
In-Reply-To: <043.f4e0eb0a9924070cf852ace700beb6bf@tracker.icir.org>
References: <043.f4e0eb0a9924070cf852ace700beb6bf@tracker.icir.org>
Message-ID: <058.9e8cea3ab3a48515ef832edd69699790@tracker.icir.org>

#297: Remove trace rewriter
-----------------------------+---------------------
  Reporter:  seth            |      Owner:  robin
      Type:  Task            |     Status:  closed
  Priority:  Normal          |  Milestone:  Bro1.6
 Component:  Bro             |    Version:
Resolution:  Merged/Applied  |   Keywords:  cleanup
-----------------------------+---------------------
Changes (by robin):

 * status:  testing => closed
 * resolution:   => Merged/Applied


-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/297#comment:14>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr  1 16:00:25 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 01 Apr 2011 23:00:25 -0000
Subject: [Bro-Dev] #324: Remove EXPIRE_DFA_STATES code
In-Reply-To: <044.1d76ad3b3cc62054fae99370dccd0543@tracker.icir.org>
References: <044.1d76ad3b3cc62054fae99370dccd0543@tracker.icir.org>
Message-ID: <059.3d831239076b54b8a3f0c96246bb6429@tracker.icir.org>

#324: Remove EXPIRE_DFA_STATES code
-----------------------------+------------------------
  Reporter:  robin           |      Owner:  robin
      Type:  Task            |     Status:  closed
  Priority:  Normal          |  Milestone:  Bro1.6
 Component:  Bro             |    Version:  git/master
Resolution:  Merged/Applied  |   Keywords:  cleanup
-----------------------------+------------------------
Changes (by robin):

 * status:  testing => closed
 * resolution:   => Merged/Applied


-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/324#comment:7>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr  1 16:00:25 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 01 Apr 2011 23:00:25 -0000
Subject: [Bro-Dev] #325: Remove ACTIVE_MAPPING code
In-Reply-To: <044.35fa7a347d936d84e134297408ded21b@tracker.icir.org>
References: <044.35fa7a347d936d84e134297408ded21b@tracker.icir.org>
Message-ID: <059.09f3eda77eb011124073f080c0fdc758@tracker.icir.org>

#325: Remove ACTIVE_MAPPING code
-----------------------------+------------------------
  Reporter:  robin           |      Owner:  robin
      Type:  Task            |     Status:  closed
  Priority:  Normal          |  Milestone:  Bro1.6
 Component:  Bro             |    Version:  git/master
Resolution:  Merged/Applied  |   Keywords:  cleanup
-----------------------------+------------------------
Changes (by robin):

 * status:  testing => closed
 * resolution:   => Merged/Applied


-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/325#comment:6>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr  1 16:00:25 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 01 Apr 2011 23:00:25 -0000
Subject: [Bro-Dev] #384: Nearly any broccoli/ssl error causes bro to
	crash
In-Reply-To: <044.a28f494a460ad398fbc33365da861083@tracker.icir.org>
References: <044.a28f494a460ad398fbc33365da861083@tracker.icir.org>
Message-ID: <059.e3f51e2e8e6be19594e23ad95530f7ac@tracker.icir.org>

#384: Nearly any broccoli/ssl error causes bro to crash
-----------------------------+--------------------
  Reporter:  leres           |      Owner:  robin
      Type:  Problem         |     Status:  closed
  Priority:  Normal          |  Milestone:  Bro1.6
 Component:  Bro             |    Version:  1.5.1
Resolution:  Merged/Applied  |   Keywords:
-----------------------------+--------------------
Changes (by robin):

 * status:  testing => closed
 * resolution:   => Merged/Applied


-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/384#comment:4>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr  1 16:06:12 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 01 Apr 2011 23:06:12 -0000
Subject: [Bro-Dev] #421: Initialize set/table field in records.
In-Reply-To: <044.43058f6fba84734b712b1fcb46d48a68@tracker.icir.org>
References: <044.43058f6fba84734b712b1fcb46d48a68@tracker.icir.org>
Message-ID: <059.7ffcf60f7e9077f03801d1b89eec20f3@tracker.icir.org>

#421: Initialize set/table field in records.
---------------------+--------------------
  Reporter:  robin   |      Owner:  robin
      Type:  Task    |     Status:  new
  Priority:  Normal  |  Milestone:  Bro1.6
 Component:  Bro     |    Version:
Resolution:          |   Keywords:
---------------------+--------------------

Comment (by robin):

 Turns out that is already the case except for vectors.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/421#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr  1 16:36:38 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 01 Apr 2011 23:36:38 -0000
Subject: [Bro-Dev] #428: Cleanup aux
In-Reply-To: <044.a14838bdcd19a5e2ec52599102884d78@tracker.icir.org>
References: <044.a14838bdcd19a5e2ec52599102884d78@tracker.icir.org>
Message-ID: <059.70e614f9a6b93a4758d50dd74acc12ab@tracker.icir.org>

#428: Cleanup aux
-----------------------------+--------------------
  Reporter:  robin           |      Owner:  robin
      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: <http://tracker.icir.org/bro/ticket/428#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr  5 08:53:48 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 05 Apr 2011 15:53:48 -0000
Subject: [Bro-Dev] #433: run-time error: unserialized unknown global name
Message-ID: <045.a83f7bb8ab302100cf022197caba98f7@tracker.icir.org>

#433: run-time error: unserialized unknown global name
---------------------+------------------------
 Reporter:  jsiwek   |      Owner:
     Type:  Problem  |     Status:  new
 Priority:  Normal   |  Milestone:
Component:  Bro      |    Version:  git/master
 Keywords:           |
---------------------+------------------------
 I keep running into this message:

 {{{
 line 1: run-time error: unserialized unknown global name
 }}}

 as I'm working on my `doc-framework` branch, but found it also occurs in
 `master`.  Here's an example sequence of commands to reproduce it (may
 occur with other combinations of scripts):

 {{{
 $ ./src/bro ../policy/http-reply.bro
 $ ./src/bro ../policy/ssl-ciphers.bro
 line 1: run-time error: unserialized unknown global name
 $ echo $?
 0
 $ ./src/bro ../policy/ssl-ciphers.bro
 }}}

 The message doesn't occur after the second load, the exit status is 0, and
 it seems like parsing successfully completes even when the message is
 given.  So I don't think this is blocking my work in the `doc-framework`
 branch, but I have no idea if it's a bug that could cause problems in
 other operation or even what those problems would be.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/433>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr  5 09:05:43 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 05 Apr 2011 16:05:43 -0000
Subject: [Bro-Dev] #433: run-time error: unserialized unknown global name
In-Reply-To: <045.a83f7bb8ab302100cf022197caba98f7@tracker.icir.org>
References: <045.a83f7bb8ab302100cf022197caba98f7@tracker.icir.org>
Message-ID: <060.36488f658a314bb6a39dc52e26aa7d60@tracker.icir.org>

#433: run-time error: unserialized unknown global name
----------------------+------------------------
  Reporter:  jsiwek   |      Owner:
      Type:  Problem  |     Status:  new
  Priority:  Normal   |  Milestone:
 Component:  Bro      |    Version:  git/master
Resolution:           |   Keywords:
----------------------+------------------------

Comment (by robin):

 On Tue, Apr 05, 2011 at 15:53 -0000, you wrote:

 > #433: run-time error: unserialized unknown global name

 This happens when there is a .state directory from a previous run that
 was using a different Bro configuration. Bro stores its persistent
 state in that directory. If a global is recorded thehere which in the
 later run doesn't exist in the configuration (say, because you're now
 not loading the corresponding script anymore), you'll get the error.

 It's safe to just delete the .state directory if you don't need the
 persistent state.

 I've been wondering for a while whether we should just get rid of this
 message? It's mainly informational.

 Robin

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/433#comment:0>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr  5 10:37:27 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 05 Apr 2011 17:37:27 -0000
Subject: [Bro-Dev] #433: run-time error: unserialized unknown global name
In-Reply-To: <045.a83f7bb8ab302100cf022197caba98f7@tracker.icir.org>
References: <045.a83f7bb8ab302100cf022197caba98f7@tracker.icir.org>
Message-ID: <060.955ef90920cf83bc885bd5649614da2e@tracker.icir.org>

#433: run-time error: unserialized unknown global name
----------------------+------------------------
  Reporter:  jsiwek   |      Owner:
      Type:  Problem  |     Status:  new
  Priority:  Normal   |  Milestone:
 Component:  Bro      |    Version:  git/master
Resolution:           |   Keywords:
----------------------+------------------------

Comment (by jsiwek):

 > I've been wondering for a while whether we should just get rid of this
 > message? It's mainly informational.

 If it's kept, seems like there's room to improve the message.  For one,
 changing "error" to "warning" might help.

 > This happens when there is a .state directory from a previous run that
 > was using a different Bro configuration. Bro stores its persistent
 > state in that directory.

 This might warrant another ticket, but does it make sense to store that
 state data in a well-defined directory like `$prefix/var/lib` (or whatever
 the Filesystem Hierarchy Standard says is the place for state data) ?

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/433#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr  5 10:48:17 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 05 Apr 2011 17:48:17 -0000
Subject: [Bro-Dev] #433: run-time error: unserialized unknown global name
In-Reply-To: <045.a83f7bb8ab302100cf022197caba98f7@tracker.icir.org>
References: <045.a83f7bb8ab302100cf022197caba98f7@tracker.icir.org>
Message-ID: <060.79054c04d565ecb67bbd525eeba4f95f@tracker.icir.org>

#433: run-time error: unserialized unknown global name
----------------------+------------------------
  Reporter:  jsiwek   |      Owner:
      Type:  Problem  |     Status:  new
  Priority:  Normal   |  Milestone:
 Component:  Bro      |    Version:  git/master
Resolution:           |   Keywords:
----------------------+------------------------

Comment (by jsiwek):

 > This might warrant another ticket, but does it make sense to store that
 state data in a well-defined directory like `$prefix/var/lib` (or whatever
 the Filesystem Hierarchy Standard says is the place for state data) ?

 Or I guess a dot directory in the `$HOME` of the user that's running bro
 might be more appropriate.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/433#comment:2>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr  5 21:35:43 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Wed, 06 Apr 2011 04:35:43 -0000
Subject: [Bro-Dev] #433: run-time error: unserialized unknown global name
In-Reply-To: <045.a83f7bb8ab302100cf022197caba98f7@tracker.icir.org>
References: <045.a83f7bb8ab302100cf022197caba98f7@tracker.icir.org>
Message-ID: <060.a7b56ce3e7aa9a97a3e9f3e28849dd92@tracker.icir.org>

#433: run-time error: unserialized unknown global name
----------------------+------------------------
  Reporter:  jsiwek   |      Owner:
      Type:  Problem  |     Status:  new
  Priority:  Normal   |  Milestone:
 Component:  Bro      |    Version:  git/master
Resolution:           |   Keywords:
----------------------+------------------------

Comment (by robin):

 On Tue, Apr 05, 2011 at 17:48 -0000, you wrote:

 >  Or I guess a dot directory in the `$HOME` of the user that's running
 bro
 >  might be more appropriate.

 Not sure. It's using the current directory because that's where all
 the other logs are written into as well. I would find putting the
 state somewhere else confusing. However, note that when using broctl,
 the cwd is in spool/*, so logs and state are recorded there.

 Robin

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/433#comment:3>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Wed Apr  6 08:58:42 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Wed, 06 Apr 2011 15:58:42 -0000
Subject: [Bro-Dev] #433: run-time error: unserialized unknown global name
In-Reply-To: <045.a83f7bb8ab302100cf022197caba98f7@tracker.icir.org>
References: <045.a83f7bb8ab302100cf022197caba98f7@tracker.icir.org>
Message-ID: <060.d96d5c1098267cae5b94a3c2a021410a@tracker.icir.org>

#433: run-time error: unserialized unknown global name
----------------------+------------------------
  Reporter:  jsiwek   |      Owner:
      Type:  Problem  |     Status:  new
  Priority:  Low      |  Milestone:
 Component:  Bro      |    Version:  git/master
Resolution:           |   Keywords:
----------------------+------------------------
Changes (by jsiwek):

 * priority:  Normal => Low


Comment:

 > Not sure. It's using the current directory because that's where all
 > the other logs are written into as well. I would find putting the
 > state somewhere else confusing.

 I think I see what you mean... by having logs and state output to the cwd,
 it makes it easy to resume a previous bro run by just starting it up in
 the same working dir as before, right?

 Putting state somewhere else would require some extra mechanisms to
 separate state per bro instance and an explicit way for a user to say
 which state they want to resume.  If that sounds right, I don't think I
 have a good argument to change where state is stored at the moment.

 But another small gripe is that some might consider the fact that it's a
 dot directory created in the cwd "rude" if users are less aware they
 could be creating that all over their filesystem when running bro
 standalone on trace files or something.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/433#comment:4>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Wed Apr  6 17:34:16 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Thu, 07 Apr 2011 00:34:16 -0000
Subject: [Bro-Dev] #434: Fix secondary path
Message-ID: <044.85e21964b392c98245087f961a298869@tracker.icir.org>

#434: Fix secondary path
--------------------+--------------------
 Reporter:  robin   |      Owner:
     Type:  Task    |     Status:  new
 Priority:  Normal  |  Milestone:  Bro1.7
Component:  Bro     |    Version:
 Keywords:          |
--------------------+--------------------
 We decided that want to keep the secondary path, but it seems there are
 some pieces whereit is  not well integrated with the rest. Non-standard
 packet sources is one area (like the Endace support); there may be more.
 See its paper for more information on the secondary path.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/434>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Mon Apr 11 10:24:42 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Mon, 11 Apr 2011 17:24:42 -0000
Subject: [Bro-Dev] #435: topic/jsiwek/doc-framework
Message-ID: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>

#435: topic/jsiwek/doc-framework
---------------------------+------------------------
 Reporter:  jsiwek         |      Owner:
     Type:  Merge Request  |     Status:  new
 Priority:  Low            |  Milestone:  Bro1.6
Component:  Bro            |    Version:  git/master
 Keywords:                 |
---------------------------+------------------------
 * Changes to Bro's scanner/parser to facilitate automatic generation of
 Bro policy script documentation (reStructuredText format)
 * Adds command line flags `-Z` and `--doc-scripts` to bro to toggle this
 new doc generation mode
 * Changes to bifcl to pass comments starting with "##" through into the
 generated .bro script
 * Adds a `make doc` build target to generate reStructuredText for a
 defined set of Bro policy scripts and then run that through Sphinx to
 create HTML documentation

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/435>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Mon Apr 11 12:36:18 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Mon, 11 Apr 2011 19:36:18 -0000
Subject: [Bro-Dev] #402: [PATCH] -fPIC is needed for FreeBSD/amd64
In-Reply-To: <044.b362feee6fb80f2733ffbc095b60d620@tracker.icir.org>
References: <044.b362feee6fb80f2733ffbc095b60d620@tracker.icir.org>
Message-ID: <059.ba0368290b321854bdef6a06c80b09a9@tracker.icir.org>

#402: [PATCH] -fPIC is needed for FreeBSD/amd64
-----------------------+-----------------------
  Reporter:  leres     |      Owner:  jsiwek
      Type:  Problem   |     Status:  assigned
  Priority:  Normal    |  Milestone:
 Component:  Broccoli  |    Version:  git/devel
Resolution:            |   Keywords:
-----------------------+-----------------------

Comment (by jsiwek):

 I'm not that keen on adding a default compile flag for this -- mostly
 because there's differences between `-fPIC` and `-fpic` on different
 platforms and I don't want to try to make an assumption on what the user
 wants.  One easy/flexible way to resolve the error (trying to link shared
 broccoli bindings library against static broccoli library on x86_64) is:

 {{{
 CFLAGS=-fPIC ./configure --enable-static
 }}}

 Needing to link the broccoli bindings against a static broccoli library
 should not be a common situation that users will find themselves in.

 To wrap this up, I'll make some clarity changes to `./configure -help` and
 add an option to disable broccoli bindings as another workaround to this
 for users that just don't care about the bindings.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/402#comment:5>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Mon Apr 11 13:00:33 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Mon, 11 Apr 2011 20:00:33 -0000
Subject: [Bro-Dev] #413: Headers not added to CMake-generated Xcode
	project
In-Reply-To: <045.54fd1755a615e8fc1a684c9c99a794ab@tracker.icir.org>
References: <045.54fd1755a615e8fc1a684c9c99a794ab@tracker.icir.org>
Message-ID: <060.8a0e86c93d905240d4aeb491c7cdca78@tracker.icir.org>

#413: Headers not added to CMake-generated Xcode project
---------------------+------------------------
  Reporter:  jsiwek  |      Owner:  jsiwek
      Type:  Task    |     Status:  new
  Priority:  Low     |  Milestone:  Bro1.6
 Component:  Bro     |    Version:  git/master
Resolution:          |   Keywords:
---------------------+------------------------

Comment (by jsiwek):

 CMake's own documentation recommends against using globbing to collect
 lists of source files, so I'll take that advice and stick to supplying
 explicit file lists to build targets when fixing this issue.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/413#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Mon Apr 11 14:50:12 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Mon, 11 Apr 2011 21:50:12 -0000
Subject: [Bro-Dev] #273: "read" command in broctl
In-Reply-To: <043.056559d2c20015e30c45a37dfa040284@tracker.icir.org>
References: <043.056559d2c20015e30c45a37dfa040284@tracker.icir.org>
Message-ID: <058.66da7be9a4a57589237e81cf7dfc933d@tracker.icir.org>

#273: "read" command in broctl
------------------------------+-------------------
  Reporter:  seth             |      Owner:
      Type:  Feature Request  |     Status:  seen
  Priority:  Normal           |  Milestone:
 Component:  BroControl       |    Version:  1.5.1
Resolution:                   |   Keywords:
------------------------------+-------------------

Comment (by will):

 Expounding upon what is already here, I would suggest the following
 functionality be added to Broctl.

 {{{
 usage: broctl [options] [file ...]
 <file>                            |policy file, or stdin
 -r|read |--readfile <readfile>    |reads from given tcpdump file
 -t|trace|--tracefile <tracefile>  |activate execution tracing
 -d|debug|--debug-policy           |activate policy file debugging

 [BroControl] > -t execfile -r /data/badness.pcap local.policy.bro

 }}}

 The above would create log file for anything called by the
 local.policy.bro script. The execfile would contain executed tracing of
 the entire process used by broctl to include the use of broctl scripts.

 {{{
 cat execfile |less
 0.000000 /usr/local/bro/share/bro/bro.init:303  function called:
 open_log_file(tag = 'alarm')
 0.000000 /usr/local/bro/share/bro/bro.init:298          function called:
 log_file_name(tag = 'alarm')
 0.000000 /usr/local/bro/share/bro/bro.init:297                  Builtin
 Function called: getenv(var = 'BRO_LOG_SUFFIX')
 0.000000 /usr/local/bro/share/bro/bro.init:297                  Function
 return:
 0.000000 /usr/local/bro/share/bro/bro.init:298                  Builtin
 Function called: fmt(va_args = '%s.%s', vararg0 = 'alarm', vararg1 =
 'log')
 0.000000 /usr/local/bro/share/bro/bro.init:298                  Function
 return: alarm.log
 0.000000 /usr/local/bro/share/bro/bro.init:298          Function return:
 alarm.log
 0.000000 /usr/local/bro/share/bro/bro.init:303          Builtin Function
 called: open(f = 'alarm.log')
 0.000000 /usr/local/bro/share/bro/bro.init:303          Function return:
 file "alarm.log" of string
 [...truncated]
 }}}

 Example of logs files created (this would obviously depend completely upon
 configuration of local.policy.bro)

 {{{
 drwx------  3 root  wheel      512 Apr 11 17:35 .state
 -rw-r--r--  1 root  wheel      222 Apr 11 17:35 alarm.log
 -rw-r--r--  1 root  wheel  5476223 Apr 11 17:35 badness
 -rw-r--r--  1 root  wheel   390608 Apr 11 15:54 badness.pcap
 -rw-r--r--  1 root  wheel     1118 Apr 11 17:35 conn.log
 -rw-r--r--  1 root  wheel       92 Apr 11 17:35 ftp-ext.log
 -rw-r--r--  1 root  wheel        0 Apr 11 17:35 ftp.log
 -rw-r--r--  1 root  wheel       92 Apr 11 17:35 http-client-body.log
 -rw-r--r--  1 root  wheel      344 Apr 11 17:35 http-ext-identified-
 files.log
 -rw-r--r--  1 root  wheel     1595 Apr 11 17:35 http-ext.log
 -rw-r--r--  1 root  wheel       16 Apr 11 17:35 http-user-agents.log
 -rw-r--r--  1 root  wheel    33593 Apr 11 17:35 http.log
 -rw-r--r--  1 root  wheel        0 Apr 11 17:35 known-hosts.log
 -rw-r--r--  1 root  wheel        0 Apr 11 17:35 known-services.log
 -rw-r--r--  1 root  wheel      472 Apr 11 17:35 notice.log
 -rw-r--r--  1 root  wheel        0 Apr 11 17:35 null.log
 -rw-r--r--  1 root  wheel    10025 Apr 11 17:35 prof.log
 -rw-r--r--  1 root  wheel        0 Apr 11 17:35 signatures.log
 -rw-r--r--  1 root  wheel      225 Apr 11 17:35 weird.log
 }}}

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/273#comment:3>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Mon Apr 11 16:07:17 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Mon, 11 Apr 2011 23:07:17 -0000
Subject: [Bro-Dev] #402: [PATCH] -fPIC is needed for FreeBSD/amd64
In-Reply-To: <044.b362feee6fb80f2733ffbc095b60d620@tracker.icir.org>
References: <044.b362feee6fb80f2733ffbc095b60d620@tracker.icir.org>
Message-ID: <059.cd2b06bc97f6067c2716d820130dde1b@tracker.icir.org>

#402: [PATCH] -fPIC is needed for FreeBSD/amd64
-----------------------+-----------------------
  Reporter:  leres     |      Owner:  jsiwek
      Type:  Problem   |     Status:  assigned
  Priority:  Normal    |  Milestone:
 Component:  Broccoli  |    Version:  git/devel
Resolution:            |   Keywords:
-----------------------+-----------------------

Comment (by leres):

 Since the 1.5.3 version of Broccoli builds both shared and static
 libraries by default on FreeBSD amd64 without issue I think it's
 ridiculous that the new cmake version can't.

 That said, I just tried grabbing a fresh copy of git://git.bro-
 ids.org/broccoli and building with --enable-static and --enable-shared
 (7.2-RELEASE and 8.2-RELEASE, both amd64) and although there doesn't
 appear to be a way to build both static and shared libraries at the same
 time (why not??), I no longer see any errors from either build. So
 something has changed since in the way broccoli is being built between now
 and when I filed this ticket.

 {{{
 Needing to link the broccoli bindings against a static broccoli library
 should not
 be a common situation that users will find themselves in.
 }}}

 I think there's a big difference between that and disallowing the user to
 build both.

 BTW, is there magic to coerce cmake into to showing the actual gcc lines?
 "Building C object" is nice when things work but it isn't so helpful when
 things don't.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/402#comment:6>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 12 10:53:31 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 12 Apr 2011 17:53:31 -0000
Subject: [Bro-Dev] #413: Headers not added to CMake-generated Xcode
	project
In-Reply-To: <045.54fd1755a615e8fc1a684c9c99a794ab@tracker.icir.org>
References: <045.54fd1755a615e8fc1a684c9c99a794ab@tracker.icir.org>
Message-ID: <060.9854d55a617d0028010656e507cfb071@tracker.icir.org>

#413: Headers not added to CMake-generated Xcode project
----------------------------+------------------------
  Reporter:  jsiwek         |      Owner:  jsiwek
      Type:  Merge Request  |     Status:  new
  Priority:  Low            |  Milestone:  Bro1.6
 Component:  Bro            |    Version:  git/master
Resolution:                 |   Keywords:
----------------------------+------------------------
Changes (by jsiwek):

 * type:  Task => Merge Request


Comment:

 Fixes for this are now in the `topic/jsiwek/CMake-IDE-tweaks` branch of
 the `bro`, `broccoli`, and `binpac` repositories.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/413#comment:2>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 12 11:41:33 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 12 Apr 2011 18:41:33 -0000
Subject: [Bro-Dev] #402: [PATCH] -fPIC is needed for FreeBSD/amd64
In-Reply-To: <044.b362feee6fb80f2733ffbc095b60d620@tracker.icir.org>
References: <044.b362feee6fb80f2733ffbc095b60d620@tracker.icir.org>
Message-ID: <059.8b435b350c4c89cebae891bcc2633465@tracker.icir.org>

#402: [PATCH] -fPIC is needed for FreeBSD/amd64
-----------------------+-----------------------
  Reporter:  leres     |      Owner:  jsiwek
      Type:  Problem   |     Status:  assigned
  Priority:  Normal    |  Milestone:
 Component:  Broccoli  |    Version:  git/devel
Resolution:            |   Keywords:
-----------------------+-----------------------

Comment (by jsiwek):

 >  I just tried grabbing a fresh copy of git://git.bro-ids.org/broccoli
 and building with --enable-static and --enable-shared (7.2-RELEASE and
 8.2-RELEASE, both amd64) and [cut] I no longer see any errors from either
 build. So something has changed since in the way broccoli is being built
 between now and when I filed this ticket.

 I think you are probably not building the python bindings now, but were
 not before.  If you clone the broccoli repository recursively, the python
 bindings code is present and automatically built by default. If you clone
 non-recursively, then the binding's source code doesn't exist and it just
 skips building them with a warning.  The error in this ticket specifically
 happens when linking the bindings module on x86_64 to a static broccoli
 library, so you won't see the error if you're just building the main
 broccoli library.

 I was able to reproduce the error yesterday, so I still want to do
 something to address it.

 > Since the 1.5.3 version of Broccoli builds both shared and static
 libraries by default on FreeBSD amd64 without issue I think it's
 ridiculous that the new cmake version can't.

 Again, I think the confusion is whether the broccoli python bindings are
 being built or not (In 1.5.3, I think the behavior is to only build them
 when installing broctl, linking them against the shared libbroccoli)

 > there doesn't appear to be a way to build both static and shared
 libraries at the same time (why not??)

 There is a CMake limitation that a given build target can't be both STATIC
 and SHARED during the same configuration/build.  See:

 http://www.cmake.org/pipermail/cmake/2005-August/007030.html
 http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_library

 However, I think what I want to try is specifying two distinct build
 targets, one each for STATIC and SHARED.  Then they can both be built by
 default and I'll prefer to link the broccoli python bindings against the
 SHARED version, for which this error will never occur.

 >
 > {{{
 > Needing to link the broccoli bindings against a static broccoli library
 should not
 > be a common situation that users will find themselves in.
 > }}}
 >
 > I think there's a big difference between that and disallowing the user
 to build both.

 I think there's a difference between "disallowing" and "not working by
 default" :)

 If I do the "two build targets" approach, all the common configurations
 should work by default with no user action necessary.  The one that will
 not work by default on x86_64 is:

 {{{
 # when configuring broccoli with bindings present
 ./configure --disable-shared
 }}}

 but the user can add the right `-fPIC` option to get it to work (if
 they're really sure that linking broccoli statically into the bindings is
 what they want to do).

 > BTW, is there magic to coerce cmake into to showing the actual gcc
 lines?  "Building C object" is nice when things work but it isn't so
 helpful when things don't.

 `make VERBOSE=1`

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/402#comment:7>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 12 13:37:00 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 12 Apr 2011 20:37:00 -0000
Subject: [Bro-Dev] #402: [PATCH] -fPIC is needed for FreeBSD/amd64
In-Reply-To: <044.b362feee6fb80f2733ffbc095b60d620@tracker.icir.org>
References: <044.b362feee6fb80f2733ffbc095b60d620@tracker.icir.org>
Message-ID: <059.7cdeaf9df2fc4dcd297c8df1cba651e8@tracker.icir.org>

#402: [PATCH] -fPIC is needed for FreeBSD/amd64
-----------------------+-----------------------
  Reporter:  leres     |      Owner:  jsiwek
      Type:  Problem   |     Status:  assigned
  Priority:  Normal    |  Milestone:
 Component:  Broccoli  |    Version:  git/devel
Resolution:            |   Keywords:
-----------------------+-----------------------

Comment (by jsiwek):

 I think I have a better solution ready for testing now (on an x86_64
 system):

 {{{
 # get the broccoli repository with python bindings
 git clone --recursive git://git.bro-ids.org/broccoli

 # this currently fails (in master branch)
 ./configure --enable-static && make

 # switch to branch w/ better solution
 git checkout topic/jsiwek/shared-static-defaults

 # this should now succeed and build both static and shared libbroccoli
 ./configure && make

 # this is now the case that does not automatically work
 ./configure --disable-shared && make
 # but after one gives it thought, decides they actually want this,
 # and finds the appropriate -fpic versus -fPIC option:
 CFLAGS=-fPIC ./configure --disable-shared && make
 }}}

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/402#comment:8>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Wed Apr 13 15:45:30 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Wed, 13 Apr 2011 22:45:30 -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.8e42fbb227935122b5812ece0584727c@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
-----------------------+-----------------------

Comment (by jsiwek):

 I was curious so I took a stab at this.  What I have in my `topic/jsiwek
 /64bit-val-fix` branch seems to at least fix the test case as presented in
 this ticket (count values), but it could use more testing/review (I'm not
 confident that I didn't overlook a whole bunch of stuff).

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/263#comment:4>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Wed Apr 13 15:52:58 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Wed, 13 Apr 2011 22:52:58 -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.62b2857293fafc09b09aacddb3c3467a@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
-----------------------+-----------------------

Comment (by robin):

 Cool, thanks!  I'll leave the review to Christian but I've already
 started to convert the old communication regression tests to btest.
 They include Broccoli tests. I'll finish them up and see if they pass
 now (they are in testing/btest/istate).

 Robin

 --
 Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org
 ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/263#comment:9>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From ksteph at cs.berkeley.edu  Thu Apr 14 20:57:51 2011
From: ksteph at cs.berkeley.edu (Kristin Stephens)
Date: Thu, 14 Apr 2011 20:57:51 -0700
Subject: [Bro-Dev] Help creating new analyzer
Message-ID: <BANLkTin53AT1Yp2t6xX6_R6g+0DPaGVZRQ@mail.gmail.com>

Hi Everyone,

I'm create a new analyzer for Bro and am currently just trying to create a
skeleton that does nothing, but compiles. I'm currently stuck at a compile
error that I don't really know the meaning of "cannot handle incremental
input"

I basically copied another analyzer and stripped out everything but the
basics. The only reference I could find to incremental input on the wiki was
using flowunit versus datagram in the *-analyzer.pac file. But I am using
flowunit there.

Any help would be much appreciated,
Kristin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20110414/5d8addbf/attachment.html 

From seth at icir.org  Fri Apr 15 05:31:12 2011
From: seth at icir.org (Seth Hall)
Date: Fri, 15 Apr 2011 08:31:12 -0400
Subject: [Bro-Dev] Help creating new analyzer
In-Reply-To: <BANLkTin53AT1Yp2t6xX6_R6g+0DPaGVZRQ@mail.gmail.com>
References: <BANLkTin53AT1Yp2t6xX6_R6g+0DPaGVZRQ@mail.gmail.com>
Message-ID: <ABD13B55-31D7-498F-906B-F37D6264E134@icir.org>


On Apr 14, 2011, at 11:57 PM, Kristin Stephens wrote:

> I'm create a new analyzer for Bro and am currently just trying to create a skeleton that does nothing, but compiles. I'm currently stuck at a compile error that I don't really know the meaning of "cannot handle incremental input"

Could you send along your .pac files?  It usually has to do with a unit where you are trying to have a bytestring parsed until &endofdata, but the unit or the parent unit doesn't have a &length applied (I think).

  .Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/



From ksteph at cs.berkeley.edu  Fri Apr 15 11:37:32 2011
From: ksteph at cs.berkeley.edu (Kristin Stephens)
Date: Fri, 15 Apr 2011 11:37:32 -0700
Subject: [Bro-Dev] Help creating new analyzer
In-Reply-To: <ABD13B55-31D7-498F-906B-F37D6264E134@icir.org>
References: <BANLkTin53AT1Yp2t6xX6_R6g+0DPaGVZRQ@mail.gmail.com>
	<ABD13B55-31D7-498F-906B-F37D6264E134@icir.org>
Message-ID: <BANLkTimSBSaZA+QGyvizf4=1=-mgzv3JpA@mail.gmail.com>

Attached are my .pac files. There's close to nothing in them though. I don't
use &endofdata anywhere.

Kristin

On Fri, Apr 15, 2011 at 5:31 AM, Seth Hall <seth at icir.org> wrote:

>
> On Apr 14, 2011, at 11:57 PM, Kristin Stephens wrote:
>
> > I'm create a new analyzer for Bro and am currently just trying to create
> a skeleton that does nothing, but compiles. I'm currently stuck at a compile
> error that I don't really know the meaning of "cannot handle incremental
> input"
>
> Could you send along your .pac files?  It usually has to do with a unit
> where you are trying to have a bytestring parsed until &endofdata, but the
> unit or the parent unit doesn't have a &length applied (I think).
>
>  .Seth
>
> --
> Seth Hall
> International Computer Science Institute
> (Bro) because everyone has a network
> http://www.bro-ids.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20110415/31132384/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bgp.pac
Type: application/octet-stream
Size: 215 bytes
Desc: not available
Url : http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20110415/31132384/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bgp-analyzer.pac
Type: application/octet-stream
Size: 254 bytes
Desc: not available
Url : http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20110415/31132384/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bgp-protocol.pac
Type: application/octet-stream
Size: 214 bytes
Desc: not available
Url : http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20110415/31132384/attachment-0002.obj 

From seth at icir.org  Fri Apr 15 11:56:22 2011
From: seth at icir.org (Seth Hall)
Date: Fri, 15 Apr 2011 14:56:22 -0400
Subject: [Bro-Dev] Help creating new analyzer
In-Reply-To: <BANLkTimSBSaZA+QGyvizf4=1=-mgzv3JpA@mail.gmail.com>
References: <BANLkTin53AT1Yp2t6xX6_R6g+0DPaGVZRQ@mail.gmail.com>
	<ABD13B55-31D7-498F-906B-F37D6264E134@icir.org>
	<BANLkTimSBSaZA+QGyvizf4=1=-mgzv3JpA@mail.gmail.com>
Message-ID: <FB1B78D2-42B1-44CD-A4FD-178E0046CC14@icir.org>


On Apr 15, 2011, at 2:37 PM, Kristin Stephens wrote:

> Attached are my .pac files. There's close to nothing in them though. I don't use &endofdata anywhere.

You are naming a field "length" in bgp-protocol.pac.  That token name is used for the unit length so you are essentially saying that your entire BGP_Message unit is the size of that &length field.

Just change the name. :)

  .Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/



From seth at icir.org  Fri Apr 15 11:57:52 2011
From: seth at icir.org (Seth Hall)
Date: Fri, 15 Apr 2011 14:57:52 -0400
Subject: [Bro-Dev] Help creating new analyzer
In-Reply-To: <BANLkTimSBSaZA+QGyvizf4=1=-mgzv3JpA@mail.gmail.com>
References: <BANLkTin53AT1Yp2t6xX6_R6g+0DPaGVZRQ@mail.gmail.com>
	<ABD13B55-31D7-498F-906B-F37D6264E134@icir.org>
	<BANLkTimSBSaZA+QGyvizf4=1=-mgzv3JpA@mail.gmail.com>
Message-ID: <F05322FB-B145-468A-8533-06555E2C1FE5@icir.org>


On Apr 15, 2011, at 2:37 PM, Kristin Stephens wrote:

> Attached are my .pac files. There's close to nothing in them though. I don't use &endofdata anywhere.

Oops, nevermind.  My answer just a second ago is wrong.  I'll look around a bit more.

  .Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/



From seth at icir.org  Fri Apr 15 12:18:18 2011
From: seth at icir.org (Seth Hall)
Date: Fri, 15 Apr 2011 15:18:18 -0400
Subject: [Bro-Dev] Help creating new analyzer
In-Reply-To: <BANLkTimSBSaZA+QGyvizf4=1=-mgzv3JpA@mail.gmail.com>
References: <BANLkTin53AT1Yp2t6xX6_R6g+0DPaGVZRQ@mail.gmail.com>
	<ABD13B55-31D7-498F-906B-F37D6264E134@icir.org>
	<BANLkTimSBSaZA+QGyvizf4=1=-mgzv3JpA@mail.gmail.com>
Message-ID: <D524C915-56DE-4763-99F3-90EF8A92AC7B@icir.org>


On Apr 15, 2011, at 2:37 PM, Kristin Stephens wrote:

> Attached are my .pac files. There's close to nothing in them though. I don't use &endofdata anywhere.

I think you found a bug in binpac.  I've noticed that bytestrings aren't handled correctly everywhere as you would expect if they have a static length (as it seems to be happening here).

In bgp-protocol.bro, if you change...

        marker: bytestring &length=16;
to 
        marker: uint8[16];

that will fix a piece of the problem, but you also need to define the total length of your outer containing unit (BGP_Message).  The following code will do it.

type BGP_Message = record {
        marker: uint8[16];
        length: uint16;
        type: uint8;
        msg: bytestring &restofdata;
} &byteorder = bigendian &length=length;

With that change to the BGP_Message, it compiles fine for me.  Looking forward to a BGP analyzer! :)

  .Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/



From ksteph at cs.berkeley.edu  Fri Apr 15 15:18:53 2011
From: ksteph at cs.berkeley.edu (Kristin Stephens)
Date: Fri, 15 Apr 2011 15:18:53 -0700
Subject: [Bro-Dev] Help creating new analyzer
In-Reply-To: <D524C915-56DE-4763-99F3-90EF8A92AC7B@icir.org>
References: <BANLkTin53AT1Yp2t6xX6_R6g+0DPaGVZRQ@mail.gmail.com>
	<ABD13B55-31D7-498F-906B-F37D6264E134@icir.org>
	<BANLkTimSBSaZA+QGyvizf4=1=-mgzv3JpA@mail.gmail.com>
	<D524C915-56DE-4763-99F3-90EF8A92AC7B@icir.org>
Message-ID: <BANLkTikOBuXBFhEbm=DHwK5tpyqgNPwFCQ@mail.gmail.com>

On Fri, Apr 15, 2011 at 12:18 PM, Seth Hall <seth at icir.org> wrote:
>
> On Apr 15, 2011, at 2:37 PM, Kristin Stephens wrote:
>
> > Attached are my .pac files. There's close to nothing in them though. I don't use &endofdata anywhere.
>
> I think you found a bug in binpac. ?I've noticed that bytestrings aren't handled correctly everywhere as you would expect if they have a static length (as it seems to be happening here).
>
> In bgp-protocol.bro, if you change...
>
> ? ? ? ?marker: bytestring &length=16;
> to
> ? ? ? ?marker: uint8[16];
>
> that will fix a piece of the problem, but you also need to define the total length of your outer containing unit (BGP_Message). ?The following code will do it.
>
> type BGP_Message = record {
> ? ? ? ?marker: uint8[16];
> ? ? ? ?length: uint16;
> ? ? ? ?type: uint8;
> ? ? ? ?msg: bytestring &restofdata;
> } &byteorder = bigendian &length=length;
>
> With that change to the BGP_Message, it compiles fine for me. ?Looking forward to a BGP analyzer! :)
>

Just for the sake of my own understanding. The changes you made above
say the exact same thing I had originally except they don't use the
&length attribute. And normally it would work except there is a bug
with bytestring and setting its &length property?

Kristin


From seth at icir.org  Fri Apr 15 16:57:19 2011
From: seth at icir.org (Seth Hall)
Date: Fri, 15 Apr 2011 19:57:19 -0400
Subject: [Bro-Dev] Help creating new analyzer
In-Reply-To: <BANLkTikOBuXBFhEbm=DHwK5tpyqgNPwFCQ@mail.gmail.com>
References: <BANLkTin53AT1Yp2t6xX6_R6g+0DPaGVZRQ@mail.gmail.com>
	<ABD13B55-31D7-498F-906B-F37D6264E134@icir.org>
	<BANLkTimSBSaZA+QGyvizf4=1=-mgzv3JpA@mail.gmail.com>
	<D524C915-56DE-4763-99F3-90EF8A92AC7B@icir.org>
	<BANLkTikOBuXBFhEbm=DHwK5tpyqgNPwFCQ@mail.gmail.com>
Message-ID: <E96E6EAD-6C2A-4346-9F95-017BFCBAD2EC@icir.org>


On Apr 15, 2011, at 6:18 PM, Kristin Stephens wrote:

> Just for the sake of my own understanding. The changes you made above
> say the exact same thing I had originally except they don't use the
> &length attribute.

Sort of.  When you go to use the marker value you will be receiving an array of 8bit ints instead of a bytestring value, but you can just write you code around that (assuming you are even using the marker value).  The main thing is that I set a length on the whole record.

> And normally it would work except there is a bug
> with bytestring and setting its &length property?


The bug is only prevalent in certain cases because binpac has to know the full size of the unit before it hits a dynamically sized field (if I understand it correctly) but for some reason even if you set a static size for a bytestring it thinks that's a dynamically sized field still which is why I changed it to a 16-long uint8 array.

  Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/



From bro at tracker.icir.org  Sun Apr 17 20:33:47 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Mon, 18 Apr 2011 03:33:47 -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.1f1a908b0df28df0ceeabe566a57668c@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
-----------------------+-----------------------

Comment (by robin):

 With the fixes, the ping test now works fine  (after adapting the protocol
 version in Broccoli). However, the pybroccoli test (which also tests more
 data types) segfaults on me, not sure why. There might be 64-bit issues in
 the python bindings as well.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/263#comment:10>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From robin at icir.org  Sun Apr 17 20:37:27 2011
From: robin at icir.org (Robin Sommer)
Date: Sun, 17 Apr 2011 20:37:27 -0700
Subject: [Bro-Dev] [Fwd] Re:  #263: --enable-int64 breaks bropipe
Message-ID: <20110418033727.GA84554@icir.org>

Christian,

can you take a look at Jon's changes to see what you think?

You can see the diff here:

    http://git.bro-ids.org/broccoli.git/commitdiff/refs/heads/topic/jsiwek/64bit-val-fix

Thanks,

Robin

----- Forwarded message from Bro Tracker <bro at tracker.icir.org> -----

Date: Mon, 18 Apr 2011 03:33:47 -0000
From: Bro Tracker <bro at tracker.icir.org>
Subject: Re: [Bro-Dev] #263: --enable-int64 breaks bropipe
Message-ID: <069.1f1a908b0df28df0ceeabe566a57668c at tracker.icir.org>
Reply-To: bro at 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
-----------------------+-----------------------

----- End forwarded message -----

-- 
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 Apr 18 12:51:45 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Mon, 18 Apr 2011 19:51:45 -0000
Subject: [Bro-Dev] #413: Headers not added to CMake-generated Xcode
	project
In-Reply-To: <045.54fd1755a615e8fc1a684c9c99a794ab@tracker.icir.org>
References: <045.54fd1755a615e8fc1a684c9c99a794ab@tracker.icir.org>
Message-ID: <060.f3dd4fff7dd2badabe2808f47effeb5d@tracker.icir.org>

#413: Headers not added to CMake-generated Xcode project
-----------------------------+------------------------
  Reporter:  jsiwek          |      Owner:  jsiwek
      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: <http://tracker.icir.org/bro/ticket/413#comment:3>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Mon Apr 18 14:10:33 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Mon, 18 Apr 2011 21:10:33 -0000
Subject: [Bro-Dev] #402: [PATCH] -fPIC is needed for FreeBSD/amd64
In-Reply-To: <044.b362feee6fb80f2733ffbc095b60d620@tracker.icir.org>
References: <044.b362feee6fb80f2733ffbc095b60d620@tracker.icir.org>
Message-ID: <059.5c92d0b5225a110a49c49559986f8e63@tracker.icir.org>

#402: [PATCH] -fPIC is needed for FreeBSD/amd64
----------------------------+------------------------
  Reporter:  leres          |      Owner:  jsiwek
      Type:  Merge Request  |     Status:  assigned
  Priority:  Normal         |  Milestone:
 Component:  Broccoli       |    Version:  git/master
Resolution:                 |   Keywords:
----------------------------+------------------------
Changes (by jsiwek):

 * version:  git/devel => git/master
 * type:  Problem => Merge Request


Comment:

 The changes in `topic/jsiwek/shared-static-defaults` now obviate the need
 for any extra flags in order to have static broccoli libs built (and it
 works on x86_64 platforms).  Please merge it to `master`.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/402#comment:9>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Mon Apr 18 14:57:57 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Mon, 18 Apr 2011 21:57:57 -0000
Subject: [Bro-Dev] #435: topic/jsiwek/doc-framework
In-Reply-To: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
References: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
Message-ID: <060.d5d89523e7fa262c9780445e60a22251@tracker.icir.org>

#435: topic/jsiwek/doc-framework
---------------------+------------------------
  Reporter:  jsiwek  |      Owner:  jsiwek
      Type:  Task    |     Status:  assigned
  Priority:  Low     |  Milestone:  Bro1.6
 Component:  Bro     |    Version:  git/master
Resolution:          |   Keywords:
---------------------+------------------------
Changes (by robin):

 * owner:   => jsiwek
 * status:  new => assigned
 * type:  Merge Request => Task


Comment:

 Very cool, I've merged this in.

 I have one more request though: can we move ``doc/`` into a subdirectory
 ``doc/scripts/``? We will have more documentation later. I would have just
 done it, but I'm not sure what the right CMake magic is to put into the
 intermediary directory.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/435#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Mon Apr 18 15:59:46 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Mon, 18 Apr 2011 22:59:46 -0000
Subject: [Bro-Dev] #435: topic/jsiwek/doc-framework
In-Reply-To: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
References: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
Message-ID: <060.640e8890db6412469ff2eaee58baca65@tracker.icir.org>

#435: topic/jsiwek/doc-framework
---------------------+------------------------
  Reporter:  jsiwek  |      Owner:  jsiwek
      Type:  Task    |     Status:  assigned
  Priority:  Low     |  Milestone:  Bro1.6
 Component:  Bro     |    Version:  git/master
Resolution:          |   Keywords:
---------------------+------------------------

Comment (by robin):

 Two more things:

       - I'm getting a number of `line 1: run-time error: unserialized
 unknown global name` messages when generating the individual reST
 documents. Sounds like  `.state` directory should removed before each run?

      - During Sphinx' indexing, I'm getting a number of `WARNING: unknown
 document: policy/hot`, `WARNING: unknown document: policy/port-name`, etc.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/435#comment:2>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Mon Apr 18 17:03:58 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 19 Apr 2011 00:03:58 -0000
Subject: [Bro-Dev] #435: topic/jsiwek/doc-framework
In-Reply-To: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
References: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
Message-ID: <060.ac136f50a9c38796d26993c823a8323d@tracker.icir.org>

#435: topic/jsiwek/doc-framework
---------------------+------------------------
  Reporter:  jsiwek  |      Owner:  jsiwek
      Type:  Task    |     Status:  assigned
  Priority:  Low     |  Milestone:  Bro1.6
 Component:  Bro     |    Version:  git/master
Resolution:          |   Keywords:
---------------------+------------------------

Comment (by robin):

 And one more: Sphinx says:

    `loading pickled environment... not yet created`

 I get that everytime I run, not only the first. Shouldn't it have the
 pickled data after the first execution to then run faster the next time?

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/435#comment:3>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Mon Apr 18 18:04:35 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 19 Apr 2011 01:04:35 -0000
Subject: [Bro-Dev] #435: topic/jsiwek/doc-framework
In-Reply-To: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
References: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
Message-ID: <060.0ca7a7f0287c0b3765b7c68adbe6f211@tracker.icir.org>

#435: topic/jsiwek/doc-framework
---------------------+------------------------
  Reporter:  jsiwek  |      Owner:  jsiwek
      Type:  Task    |     Status:  assigned
  Priority:  Low     |  Milestone:  Bro1.6
 Component:  Bro     |    Version:  git/master
Resolution:          |   Keywords:
---------------------+------------------------

Comment (by jsiwek):

 > I have one more request though: can we move ``doc/`` into a subdirectory
 ``doc/scripts/``?

 Yeah, I can do that.

 >  I'm getting a number of `line 1: run-time error: unserialized unknown
 global name` messages when generating the individual reST documents.
 Sounds like  `.state` directory should removed before each run?

 Yeah, I should probably do that.

 >      - During Sphinx' indexing, I'm getting a number of `WARNING:
 unknown document: policy/hot`, `WARNING: unknown document: policy/port-
 name`, etc.

 This is because some policy script loads `hot.bro` and `port-name.bro` and
 the generated reST doc contains the necessary cross-references, but we
 haven't said that we want to include the generated reST docs for `hot.bro`
 or `port-name.bro` in the collection that we use as input for Sphinx, so
 Sphinx just won't render the cross-reference as a hyperlink (you'll still
 get the right text, though).

 The master list of input sources is defined in `generate_reST_docs.py.in`.

 I was struggling somewhat to come up with a good way to organize this
 process, so let me know if you had some other ideas on how/if I can
 improve it.

 > Shouldn't it have the pickled data after the first execution to then run
 faster the next time?

 I made it do a clean before each run because Sphinx was always adding new
 files in the `_downloads` output dir regardless of whether the policy
 script actually changes.  So I was ending up with `alarm.bro`,
 `alarm2.bro`, `alarm3.bro`...

 I'll take a quick look to see if maybe there's some other way I can trick
 it to not do that.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/435#comment:4>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Mon Apr 18 20:06:17 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 19 Apr 2011 03:06:17 -0000
Subject: [Bro-Dev] #435: topic/jsiwek/doc-framework
In-Reply-To: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
References: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
Message-ID: <060.af1a892ed508ef0d11ddcb78ce17ff73@tracker.icir.org>

#435: topic/jsiwek/doc-framework
---------------------+------------------------
  Reporter:  jsiwek  |      Owner:  jsiwek
      Type:  Task    |     Status:  assigned
  Priority:  Low     |  Milestone:  Bro1.6
 Component:  Bro     |    Version:  git/master
Resolution:          |   Keywords:
---------------------+------------------------

Comment (by robin):

 On Tue, Apr 19, 2011 at 01:04 -0000, you wrote:

 >  The master list of input sources is defined in
 `generate_reST_docs.py.in`.

 So, once we list everything there, these messages will go away? Then
 nevermind.

 >  I was struggling somewhat to come up with a good way to organize this
 >  process, so let me know if you had some other ideas on how/if I can
 >  improve it.

 Can't think of much else. Let's organize the scripts once the new ones
 for 1.6 are in place.

 >  I made it do a clean before each run because Sphinx was always adding
 new
 >  files in the `_downloads` output dir regardless of whether the policy
 >  script actually changes.  So I was ending up with `alarm.bro`,
 >  `alarm2.bro`, `alarm3.bro`...

 Could we delete just the _downloads directory but keep the state?

 Robin

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/435#comment:7>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Mon Apr 18 20:33:23 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 19 Apr 2011 03:33:23 -0000
Subject: [Bro-Dev] #435: topic/jsiwek/doc-framework
In-Reply-To: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
References: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
Message-ID: <060.6d28f6c0ff7879a493d9950b64767ffa@tracker.icir.org>

#435: topic/jsiwek/doc-framework
---------------------+------------------------
  Reporter:  jsiwek  |      Owner:  jsiwek
      Type:  Task    |     Status:  assigned
  Priority:  Low     |  Milestone:  Bro1.6
 Component:  Bro     |    Version:  git/master
Resolution:          |   Keywords:
---------------------+------------------------

Comment (by robin):

 A question: can the doc framework deal with scripts in subdirectories? The
 new scripts now do some `@load foo/bar`.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/435#comment:8>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Mon Apr 18 21:33:52 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 19 Apr 2011 04:33:52 -0000
Subject: [Bro-Dev] #436: topic/seth/count_to_addr - BiF for turning a count
 into a v4 IP address
Message-ID: <043.90bdf588c71998e942e58d21b1ae3a08@tracker.icir.org>

#436: topic/seth/count_to_addr - BiF for turning a count into a v4 IP address
---------------------------+------------------------
 Reporter:  seth           |      Owner:  robin
     Type:  Merge Request  |     Status:  new
 Priority:  Normal         |  Milestone:  Bro1.6
Component:  Bro            |    Version:  git/master
 Keywords:                 |
---------------------------+------------------------
 The branch includes tests for the new count_to_v4_addr function.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/436>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Mon Apr 18 21:35:05 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 19 Apr 2011 04:35:05 -0000
Subject: [Bro-Dev] #436: topic/seth/count_to_addr - BiF for turning a
 count into a v4 IP address
In-Reply-To: <043.90bdf588c71998e942e58d21b1ae3a08@tracker.icir.org>
References: <043.90bdf588c71998e942e58d21b1ae3a08@tracker.icir.org>
Message-ID: <058.b4a920bb8e99a15a6ae0beb02467be61@tracker.icir.org>

#436: topic/seth/count_to_addr - BiF for turning a count into a v4 IP address
----------------------------+------------------------
  Reporter:  seth           |      Owner:  robin
      Type:  Merge Request  |     Status:  new
  Priority:  Normal         |  Milestone:  Bro1.6
 Component:  Bro            |    Version:  git/master
Resolution:                 |   Keywords:
----------------------------+------------------------
Description changed by seth:

Old description:

> The branch includes tests for the new count_to_v4_addr function.

New description:

 The branch includes a new function named count_to_v4_addr which will
 convert from a count to a v4 IP address.

 Tests are included as well.

--

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/436#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 19 10:51:25 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 19 Apr 2011 17:51:25 -0000
Subject: [Bro-Dev] #435: topic/jsiwek/doc-framework
In-Reply-To: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
References: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
Message-ID: <060.6bd9a91ff09595e48e484c4ec7438b96@tracker.icir.org>

#435: topic/jsiwek/doc-framework
---------------------+------------------------
  Reporter:  jsiwek  |      Owner:  jsiwek
      Type:  Task    |     Status:  assigned
  Priority:  Low     |  Milestone:  Bro1.6
 Component:  Bro     |    Version:  git/master
Resolution:          |   Keywords:
---------------------+------------------------

Comment (by jsiwek):

 > So, once we list everything there, these messages will go away? Then
 nevermind.

 Yes.

 > Could we delete just the _downloads directory but keep the state?

 That would only have the effect of cleaning out _downloads of unused
 files, but the latest one will still have a number suffix, e.g. you'd have
 an `alarm103.bro` after the 104th run of `make doc`.

 But I also realized that's not the only thing holding back the ability to
 do incremental builds.  In order to get that it to work, I kind of have to
 throw away the current version of `make doc` and organize more of it it
 inside CMake scripting so I can to teach it how to only generate new reST
 when the associated .bro or the `bro` binary itself changes.

 I think there's also some extra work to get it to automatically remove
 generated reST docs for bro policy scripts that we've removed (either
 don't want docs for or just got rid of entirely) -- something that's
 easier to do if we just always start clean like it currently does.

 > A question: can the doc framework deal with scripts in subdirectories?
 The new scripts now do some `@load foo/bar`.

 It doesn't -- the cross-referencing link in the docs for the script that
 does `@load foo/bar` doesn't point to the right place.

 Currently I'm dumping all the generated reST docs into a single flat
 directory for Sphinx to process.  So a couple options are

 1) Just change the link to point to the basename (bar) so that the link is
 fixed (the link text still says "foo/bar")
 2) Create directory trees for the Sphinx input sources that mimic how the
 scripts are `@load`ed.

 (1) should be easy, (2) seems more involved.  (1) seems ok if we don't
 expect to ever have multiple "bar" scripts that reside in different
 directories (seems like it would get real confusing if that becomes
 standard practice...).

 What do you think?

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/435#comment:9>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From seth at icir.org  Tue Apr 19 13:02:17 2011
From: seth at icir.org (Seth Hall)
Date: Tue, 19 Apr 2011 16:02:17 -0400
Subject: [Bro-Dev] "delete" for record field proposal
Message-ID: <DC2555CD-2999-49D0-A788-6541C3E02BF7@icir.org>

I wanted to propose an additional use for an existing syntax.  It would be helpful to be able to delete the value from record fields using the "delete" keyword.  Here's an example:

type Whatever: record {
	field1:   string &optional;
};

local foobar: Whatever;
print foobar;
  ===> [$field1 = <undefined>]

foobar$field1 = "test";
print foobar;
  ===> [$field1 = "test"]

delete foobar$field1;
print foobar;
  ===> [$field1 = <undefined>]

Thoughts?  Does reusing that existing keyword in this situation make sense?

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  Tue Apr 19 13:11:03 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 19 Apr 2011 20:11:03 -0000
Subject: [Bro-Dev] #435: topic/jsiwek/doc-framework
In-Reply-To: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
References: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
Message-ID: <060.d093951d2d92b6376160ab0882185edf@tracker.icir.org>

#435: topic/jsiwek/doc-framework
---------------------+------------------------
  Reporter:  jsiwek  |      Owner:  jsiwek
      Type:  Task    |     Status:  assigned
  Priority:  Low     |  Milestone:  Bro1.6
 Component:  Bro     |    Version:  git/master
Resolution:          |   Keywords:
---------------------+------------------------

Comment (by seth):

 > (1) should be easy, (2) seems more involved.  (1) seems ok if we don't
 > expect to ever have multiple "bar" scripts that reside in different
 > directories (seems like it would get real confusing if that becomes
 > standard practice...).

 I actually just started doing that recently (multiple "bar" scripts in
 different directories) because it helps to organize functionality across
 several scripts instead of creating huge core scripts that perform many
 different functions.

 How hard do you think it would be to support that?

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/435#comment:10>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From robin at icir.org  Tue Apr 19 13:41:41 2011
From: robin at icir.org (Robin Sommer)
Date: Tue, 19 Apr 2011 13:41:41 -0700
Subject: [Bro-Dev] "delete" for record field proposal
In-Reply-To: <DC2555CD-2999-49D0-A788-6541C3E02BF7@icir.org>
References: <DC2555CD-2999-49D0-A788-6541C3E02BF7@icir.org>
Message-ID: <20110419204141.GM84639@icir.org>


On Tue, Apr 19, 2011 at 16:02 -0400, you wrote:

> delete foobar$field1;

I like it. (Seth and I had talked about it earlier today already)

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 Apr 19 13:48:26 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 19 Apr 2011 20:48:26 -0000
Subject: [Bro-Dev] #435: topic/jsiwek/doc-framework
In-Reply-To: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
References: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
Message-ID: <060.1629ee911cac55af4b972308ecc341c0@tracker.icir.org>

#435: topic/jsiwek/doc-framework
---------------------+------------------------
  Reporter:  jsiwek  |      Owner:  jsiwek
      Type:  Task    |     Status:  assigned
  Priority:  Low     |  Milestone:  Bro1.6
 Component:  Bro     |    Version:  git/master
Resolution:          |   Keywords:
---------------------+------------------------

Comment (by jsiwek):

 > I actually just started doing that recently (multiple "bar" scripts in
 different directories) because it helps to organize functionality across
 several scripts instead of creating huge core scripts that perform many
 different functions.
 >
 > How hard do you think it would be to support that?

 It's hard enough that I'll need some time to think about how hard it will
 be... I don't really have a strong argument for why it shouldn't/can't
 support it, so just keep doing what you're doing; I'll try to figure
 something out.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/435#comment:11>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 19 13:51:40 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 19 Apr 2011 20:51:40 -0000
Subject: [Bro-Dev] #435: topic/jsiwek/doc-framework
In-Reply-To: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
References: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
Message-ID: <060.88455c41a11da7728a1f52d39f5284a0@tracker.icir.org>

#435: topic/jsiwek/doc-framework
---------------------+------------------------
  Reporter:  jsiwek  |      Owner:  jsiwek
      Type:  Task    |     Status:  assigned
  Priority:  Low     |  Milestone:  Bro1.6
 Component:  Bro     |    Version:  git/master
Resolution:          |   Keywords:
---------------------+------------------------

Comment (by robin):

 >  But I also realized that's not the only thing holding back the ability
 to
 >  do incremental builds.

 Got it. Ok, no big deal, let's leave it as it is.

 >  1) Just change the link to point to the basename (bar) so that the link
 is
 >  fixed (the link text still says "foo/bar")
 >  2) Create directory trees for the Sphinx input sources that mimic how
 the
 >  scripts are `@load`ed.

 >  (1) should be easy, (2) seems more involved.  (1) seems ok if we don't
 >  expect to ever have multiple "bar" scripts that reside in different
 >  directories

 Per Seth's reply, would be good to support this. Is there a middle way
 of keeping the flat structure and just naming the files in some unique
 fashion (e.g., foo/bar -> foo_bar)? Don't know whether that makes
 sense.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/435#comment:12>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 19 14:01:52 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 19 Apr 2011 21:01:52 -0000
Subject: [Bro-Dev] #435: topic/jsiwek/doc-framework
In-Reply-To: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
References: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
Message-ID: <060.ebe3c3d10bdac62d1452668cb662334d@tracker.icir.org>

#435: topic/jsiwek/doc-framework
---------------------+------------------------
  Reporter:  jsiwek  |      Owner:  jsiwek
      Type:  Task    |     Status:  assigned
  Priority:  Low     |  Milestone:  Bro1.6
 Component:  Bro     |    Version:  git/master
Resolution:          |   Keywords:
---------------------+------------------------

Comment (by jsiwek):

 Here's a question for you Seth:  with the way you're re-writing the policy
 scripts, are the dependencies going to be such that a given script can be
 loaded by itself as an argument to bro?

 i.e. I'm currently doing something like this over a defined list of
 scripts:

 {{{
 ./src/bro --doc-script ../policy/foo.bro
 }}}

 Then I only take the generated `foo.rst` as the input to Sphinx.  If we
 wanted to doc the scripts that were `@load`ed by `foo.bro`, those have to
 be run through bro individually.  I was doing it that way because
 otherwise `redef` interactions between scripts would possibly corrupt the
 documentation that's generated.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/435#comment:13>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 19 14:04:27 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 19 Apr 2011 21:04:27 -0000
Subject: [Bro-Dev] #435: topic/jsiwek/doc-framework
In-Reply-To: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
References: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
Message-ID: <060.45aeef407d5bc7e2a6418fa129a40886@tracker.icir.org>

#435: topic/jsiwek/doc-framework
---------------------+------------------------
  Reporter:  jsiwek  |      Owner:  jsiwek
      Type:  Task    |     Status:  assigned
  Priority:  Low     |  Milestone:  Bro1.6
 Component:  Bro     |    Version:  git/master
Resolution:          |   Keywords:
---------------------+------------------------

Comment (by jsiwek):

 > Is there a middle way of keeping the flat structure and just naming the
 files in some unique
 > fashion (e.g., foo/bar -> foo_bar)? Don't know whether that makes sense.

 That might be a good idea... I'll see if it can work in a way that's not
 too hacky.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/435#comment:14>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 19 15:57:04 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 19 Apr 2011 22:57:04 -0000
Subject: [Bro-Dev] #436: topic/seth/count_to_addr - BiF for turning a
 count into a v4 IP address
In-Reply-To: <043.90bdf588c71998e942e58d21b1ae3a08@tracker.icir.org>
References: <043.90bdf588c71998e942e58d21b1ae3a08@tracker.icir.org>
Message-ID: <058.7dfc395aef9bea57b6fe49a35e34b92f@tracker.icir.org>

#436: topic/seth/count_to_addr - BiF for turning a count into a v4 IP address
-----------------------------+------------------------
  Reporter:  seth            |      Owner:  robin
      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: <http://tracker.icir.org/bro/ticket/436#comment:2>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 19 15:57:03 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 19 Apr 2011 22:57:03 -0000
Subject: [Bro-Dev] #402: [PATCH] -fPIC is needed for FreeBSD/amd64
In-Reply-To: <044.b362feee6fb80f2733ffbc095b60d620@tracker.icir.org>
References: <044.b362feee6fb80f2733ffbc095b60d620@tracker.icir.org>
Message-ID: <059.4546b99a50de5f6aa8b10821c9558fc9@tracker.icir.org>

#402: [PATCH] -fPIC is needed for FreeBSD/amd64
-----------------------------+------------------------
  Reporter:  leres           |      Owner:  jsiwek
      Type:  Merge Request   |     Status:  closed
  Priority:  Normal          |  Milestone:
 Component:  Broccoli        |    Version:  git/master
Resolution:  Merged/Applied  |   Keywords:
-----------------------------+------------------------
Changes (by robin):

 * status:  assigned => closed
 * resolution:   => Merged/Applied


-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/402#comment:10>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 19 16:46:20 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 19 Apr 2011 23:46:20 -0000
Subject: [Bro-Dev] #435: topic/jsiwek/doc-framework
In-Reply-To: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
References: <045.b65563eef355461ecf3f82141e9643dd@tracker.icir.org>
Message-ID: <060.b064daad9ea34fe82d6495781e193d0b@tracker.icir.org>

#435: topic/jsiwek/doc-framework
---------------------+------------------------
  Reporter:  jsiwek  |      Owner:  jsiwek
      Type:  Task    |     Status:  assigned
  Priority:  Low     |  Milestone:  Bro1.6
 Component:  Bro     |    Version:  git/master
Resolution:          |   Keywords:
---------------------+------------------------

Comment (by seth):

 > Here's a question for you Seth:  with the way you're re-writing the
 policy
 > scripts, are the dependencies going to be such that a given script can
 be
 > loaded by itself as an argument to bro?

 Yes, that's what I'm aiming for.  I need to write something for btest
 eventually that will automatically test running Bro with each script
 individually to make sure that each script always loads all of it's
 dependencies.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/435#comment:15>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 19 17:05:44 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Wed, 20 Apr 2011 00:05:44 -0000
Subject: [Bro-Dev] #437: Unify tables/set/vectors
Message-ID: <044.58c2bcffb52551783a97903ea6580481@tracker.icir.org>

#437: Unify tables/set/vectors
----------------------+--------------------
 Reporter:  robin     |      Owner:
     Type:  Task      |     Status:  new
 Priority:  Normal    |  Milestone:  Bro1.7
Component:  Bro       |    Version:
 Keywords:  language  |
----------------------+--------------------
 Internally, tables/sets/vectors/records are all handled separately at many
 locations inside the interpreter (tables and sets sometimes are handled
 together, and sometimes aren't). I believe we should be able to unify much
 of that code in some form, like by moving more into a parent class
 `CompositeType`.

 I'd like to see most of these `if ( is-it-type-A ) ? if ( is-it-type-B )
 ?` go away.

 That would also make it much easier to implement a real list type.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/437>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 19 17:05:57 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Wed, 20 Apr 2011 00:05:57 -0000
Subject: [Bro-Dev] #437: Unify tables/set/vectors/records (was: Unify
 tables/set/vectors)
In-Reply-To: <044.58c2bcffb52551783a97903ea6580481@tracker.icir.org>
References: <044.58c2bcffb52551783a97903ea6580481@tracker.icir.org>
Message-ID: <059.f769467df21c45d347ebc765f344bac5@tracker.icir.org>

#437: Unify tables/set/vectors/records
---------------------+----------------------
  Reporter:  robin   |      Owner:
      Type:  Task    |     Status:  new
  Priority:  Normal  |  Milestone:  Bro1.7
 Component:  Bro     |    Version:
Resolution:          |   Keywords:  language
---------------------+----------------------

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/437#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 19 19:29:49 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Wed, 20 Apr 2011 02:29:49 -0000
Subject: [Bro-Dev] #438: topic/seth/fix-do_split - Fix and test for a
	do_split bug.
Message-ID: <043.72cddbbb547b6ff7bc886661390cb164@tracker.icir.org>

#438: topic/seth/fix-do_split - Fix and test for a do_split bug.
---------------------------+------------------------
 Reporter:  seth           |      Owner:  robin
     Type:  Merge Request  |     Status:  new
 Priority:  Normal         |  Milestone:  Bro1.6
Component:  Bro            |    Version:  git/master
 Keywords:                 |
---------------------------+------------------------
 * do_split was having a problem if there was another match
      after the end of the number of separators.  It would only
      return the match up to the point of the next match instead
      of the rest of the string.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/438>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From vern at icir.org  Tue Apr 19 23:15:25 2011
From: vern at icir.org (Vern Paxson)
Date: Tue, 19 Apr 2011 23:15:25 -0700
Subject: [Bro-Dev] "delete" for record field proposal
In-Reply-To: <DC2555CD-2999-49D0-A788-6541C3E02BF7@icir.org> (Tue,
	19 Apr 2011 16:02:17 EDT).
Message-ID: <20110420061525.8ED2636A037@taffy.ICSI.Berkeley.EDU>

> delete foobar$field1;
> print foobar;
>   ===> [$field1 = <undefined>]

Sounds good to me too.

		Vern

From bro at tracker.icir.org  Wed Apr 20 13:00:42 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Wed, 20 Apr 2011 20:00:42 -0000
Subject: [Bro-Dev] #439: topic/seth/decode-nbns-names - Updates to netbios
 name decoding function
Message-ID: <043.78815fb0c88dd4d7e2891f6837d32a85@tracker.icir.org>

#439: topic/seth/decode-nbns-names - Updates to netbios name decoding function
---------------------------+------------------------
 Reporter:  seth           |      Owner:
     Type:  Merge Request  |     Status:  new
 Priority:  Normal         |  Milestone:  Bro1.6
Component:  Bro            |    Version:  git/master
 Keywords:                 |
---------------------------+------------------------
 * New BiF named: decode_netbios_name_type
    * \x01 and \x02 are now decoded because I saw those
      bytes being actively used in names.
   * Tests and baseline for functions.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/439>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Wed Apr 20 13:12:01 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Wed, 20 Apr 2011 20:12:01 -0000
Subject: [Bro-Dev] #414: Xcode gives warnings about preprocessor
	redefinitions
In-Reply-To: <045.54694f79c4c975422186a462eb5ed664@tracker.icir.org>
References: <045.54694f79c4c975422186a462eb5ed664@tracker.icir.org>
Message-ID: <060.baf906091b6adea229fc9448f32b6995@tracker.icir.org>

#414: Xcode gives warnings about preprocessor redefinitions
---------------------+------------------------
  Reporter:  jsiwek  |      Owner:  jsiwek
      Type:  Task    |     Status:  closed
  Priority:  Low     |  Milestone:  Bro1.6
 Component:  Bro     |    Version:  git/master
Resolution:  Solved  |   Keywords:
---------------------+------------------------
Changes (by jsiwek):

 * status:  new => closed
 * resolution:   => Solved


Comment:

 This was originally addressed in bro fastpath with commit
 bdb1826ebadb62c1b9aa7ae0b3b60ef3af439fab, but later I discovered a problem
 with that solution resulting in another commit,
 9b7c8b9f98bf3693b375d2316847bffefba73125

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/414#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From robin at icir.org  Wed Apr 20 16:46:35 2011
From: robin at icir.org (Robin Sommer)
Date: Wed, 20 Apr 2011 16:46:35 -0700
Subject: [Bro-Dev] whitespace convention (tab vs. space)
In-Reply-To: <20110318154033.GG6542@icir.org>
References: <16987863.101.1300375835255.JavaMail.jsiwek@tangent.ncsa.illinois.edu>
	<29856286.113.1300376994341.JavaMail.jsiwek@tangent.ncsa.illinois.edu>
	<20110317161637.GE82025@icir.org> <4D824099.3060404@ee.lbl.gov>
	<20110317171733.GB86111@icir.org> <4D828A55.7080305@icir.org>
	<20110318154033.GG6542@icir.org>
Message-ID: <20110420234635.GA48863@icir.org>

A while ago, I wrote:

On Fri, Mar 18, 2011 at 08:40 -0700, I wrote:

> > <TAB><TAB> this_is_a_function (it, has, very_very_very_many,
> > <TAB><TAB><SP><SP>...<SP> arguments, more_args, foo, bar);
> 
> Just for the record, Bro code is not using this: it uses TABs
> exclusively also for the second line.

That's actually not true, upon closer inspection I find this more
often than I thought.

Vern, what *is* actually the prefered way for indenting such
continuations?

Robin

--
Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org

From vern at icir.org  Wed Apr 20 18:28:20 2011
From: vern at icir.org (Vern Paxson)
Date: Wed, 20 Apr 2011 18:28:20 -0700
Subject: [Bro-Dev] whitespace convention (tab vs. space)
In-Reply-To: <20110420234635.GA48863@icir.org> (Wed, 20 Apr 2011 16:46:35 PDT).
Message-ID: <20110421012820.CB0EC36A037@taffy.ICSI.Berkeley.EDU>

> Vern, what *is* actually the prefered way for indenting such
> continuations?

The style has been to align the argument of the second line with
those of the first, so like this:

int myClass::Method(int foo, char* bar,
<tab><tab>    int another_argument)

where if you expand those tabs, you'll find that the "int" for
"another_argument" is right below the "int" for "foo".

However, I believe we already have deviations from this.

		Vern

From jsiwek at ncsa.illinois.edu  Wed Apr 20 19:06:50 2011
From: jsiwek at ncsa.illinois.edu (Jonathan Siwek)
Date: Wed, 20 Apr 2011 21:06:50 -0500 (CDT)
Subject: [Bro-Dev] whitespace convention (tab vs. space)
In-Reply-To: <20110421012820.CB0EC36A037@taffy.ICSI.Berkeley.EDU>
Message-ID: <1821254847.5481.1303351610406.JavaMail.root@zimbra-1.ncsa.uiuc.edu>

> int myClass::Method(int foo, char* bar,
> <tab><tab> int another_argument)
> 
> where if you expand those tabs, you'll find that the "int" for
> "another_argument" is right below the "int" for "foo".

But then the alignment depends on tab width, right?  If we're going to use that style, we should all agree on what that width is.

Another way to do it is having the continuation line(s) contain a number of tabs equal to the level of indentation plus however many spaces are necessary to get the right alignment.  Then everyone would write code that aligns the same regardless of what tab width they're using.  So in the example Vern gave, there wouldn't be any tabs, just spaces because the indentation level of that code is 0.

- Jon

From vern at icir.org  Wed Apr 20 19:15:04 2011
From: vern at icir.org (Vern Paxson)
Date: Wed, 20 Apr 2011 19:15:04 -0700
Subject: [Bro-Dev] whitespace convention (tab vs. space)
In-Reply-To: <1821254847.5481.1303351610406.JavaMail.root@zimbra-1.ncsa.uiuc.edu>
	(Wed, 20 Apr 2011 21:06:50 CDT).
Message-ID: <20110421021504.857DF36A361@taffy.ICSI.Berkeley.EDU>

> But then the alignment depends on tab width, right?

Yep.  And for the Bro sources, that has always been 8 columns.

> Another way to do it is having the continuation line(s) contain a number
> of tabs equal to the level of indentation plus however many spaces are
> necessary to get the right alignment.

That's okay with me in principle.  But it's pretty fundamental that we
need a pretty printer that enforces stuff like this.  The current style
is the way it is in part due to how vi treats auto-indentation.

		Vern

From robin at icir.org  Wed Apr 20 19:37:17 2011
From: robin at icir.org (Robin Sommer)
Date: Wed, 20 Apr 2011 19:37:17 -0700
Subject: [Bro-Dev] whitespace convention (tab vs. space)
In-Reply-To: <20110421021504.857DF36A361@taffy.ICSI.Berkeley.EDU>
References: <1821254847.5481.1303351610406.JavaMail.root@zimbra-1.ncsa.uiuc.edu>
	<20110421021504.857DF36A361@taffy.ICSI.Berkeley.EDU>
Message-ID: <20110421023717.GA49846@icir.org>


On Wed, Apr 20, 2011 at 19:15 -0700, you wrote:

> need a pretty printer that enforces stuff like this.

Yeah, we really need that. It's indeed already a mix of different
styles.

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 Apr 21 07:13:36 2011
From: robin at icir.org (Robin Sommer)
Date: Thu, 21 Apr 2011 07:13:36 -0700
Subject: [Bro-Dev] Doc generation tests fail
Message-ID: <20110421141336.GA75458@icir.org>

Jon,

after merging in the logging code yesterday, the doc tests now fail,
and I'm not quite sure why. Here's the output:

    > bro --doc-scripts ../testing/btest/doc/autogen-reST-enums.bro
    [...]
    Documenting source: /home/robin/bro/master/policy/logging.bro
    Created reST document: logging.rst
    /home/robin/bro/master/policy/logging.bro, line 88: error: syntax error, at or near "}"

The interesting thing is that running without --doc-scripts doesn't
report any error:

    > bro  ../testing/btest/doc/autogen-reST-enums.bro
    [no output] 

Is there markup that can't be parsed?

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 Apr 21 07:42:08 2011
From: robin at icir.org (Robin Sommer)
Date: Thu, 21 Apr 2011 07:42:08 -0700
Subject: [Bro-Dev] [Bro-Commits] [git/bro] topic/policy-scripts-new:
	Extract	packet data for the dpd.log (7c168e0)
In-Reply-To: <201104210500.p3L50UIH005118@bro-ids.icir.org>
References: <201104210500.p3L50UIH005118@bro-ids.icir.org>
Message-ID: <20110421144208.GC75458@icir.org>


On Wed, Apr 20, 2011 at 22:00 -0700, you wrote:

> +	local packet_segment = sub_bytes(get_current_packet()$data, 0, packet_segment_size);

This is a nice idea but get_current_packet() has some fuzzy semantics:
the current packet is not necessarily the one triggering the event. It
probably works often, but not always, and I'm wondering if when it
doesn't, it could be very confusing to show the data here?

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 Apr 21 08:02:54 2011
From: jsiwek at ncsa.illinois.edu (Jonathan Siwek)
Date: Thu, 21 Apr 2011 10:02:54 -0500 (CDT)
Subject: [Bro-Dev] Doc generation tests fail
In-Reply-To: <20110421141336.GA75458@icir.org>
Message-ID: <356186256.1272.1303398174838.JavaMail.root@zimbra-1.ncsa.uiuc.edu>

> /home/robin/bro/master/policy/logging.bro, line 88: error: syntax
> error, at or near "}"
> ... 
> Is there markup that can't be parsed?

Here's what it's choking on:

    ## Information passed into rotation callback functions.
    type RotationInfo: record {
        writer: Writer; ##> Writer.
        path: string;   ##> Original path value.
        open: time; ##> Time when opened.
        close: time;    ##> Time when closed.
    };

That comment markup is using the wrong angle bracket.  Replace "##>" with "##<" and it should work.  The reason why the current markup results in a syntax error is because the parser will interpret that last "##>" comment as a "##" token, which is something that has to precede a record field declaration, and there are no more of those in that record.

Side note:  the "doc.autogen-reST-example" might still fail because (1) there's a missing period in one place in the baseline (2) the ordering of set/table values seems to be able to change between runs.  I fixed those last night in my topic/jsiwek/doc-framework branch.  I'm not sure if you want to try cherry-picking that commit or if you just want to wait until merging that branch again.

Also, these logging tests are failing for me:

logging.remote-types ... failed
logging.remote ... failed
logging.rotate-custom ... failed
logging.rotate ... failed
logging.types ... failed

I put relevant `btest -D` output here:
http://www.ncsa.illinois.edu/~jsiwek/tmp/bro_logging_test_failures

- Jon

From robin at icir.org  Thu Apr 21 09:11:24 2011
From: robin at icir.org (Robin Sommer)
Date: Thu, 21 Apr 2011 09:11:24 -0700
Subject: [Bro-Dev] Doc generation tests fail
In-Reply-To: <356186256.1272.1303398174838.JavaMail.root@zimbra-1.ncsa.uiuc.edu>
References: <20110421141336.GA75458@icir.org>
	<356186256.1272.1303398174838.JavaMail.root@zimbra-1.ncsa.uiuc.edu>
Message-ID: <20110421161124.GF75458@icir.org>


On Thu, Apr 21, 2011 at 10:02 -0500, you wrote:

> That comment markup is using the wrong angle bracket.  Replace "##>"
> with "##<" and it should work.

Ah. :-)

>   The reason why the current markup results in a syntax error is
>   because the parser will interpret that last "##>" comment as a "##"

Ok, two thoughts:

    - is there a way to produce an error messages that makes clear
    it's a problem with the doc markup? Otherwise this can be quite
    confusing as one would normally just ignore comments when looking
    for errors the parser is reporting.

    - I'm wondering whether Bro should report this also when not
    running in doc mode. Otherwise, such things are hard to catch.

    On the other hand, I'm not sure I want to enforce rules on
    comments for cases where the doc generation isn't used.

    Perhaps a middle ground: should we have a test that ensures that
    all scripts we ship do correctly parse in doc mode? The existing
    tests reported logging.bro but only because it's a central one.
    Ones that are less used will be harder to find (and will in
    particular mess up the auto-generated pages on the web server)

> Side note: the "doc.autogen-reST-example" might still fail because (1)
> there's a missing period in one place in the baseline (2) the ordering
> of set/table values seems to be able to change between runs.

In theory, that shouldn't be the case as long as the RNG's seed is
set, which btest.cfg does. (But see below for practice).

>  I'm not sure if you want to try cherry-picking that commit or if you
>  just want to wait until merging that branch again.

Fine waiting. 

> http://www.ncsa.illinois.edu/~jsiwek/tmp/bro_logging_test_failures

Funny, some of that looks like a timezone difference! :)

And the tables do actually come out in a different order here as well.
I'm wondering whether seeding the RNG isn't sufficient. It has been in
the past afairc, but I guess same order isn't guarnateed *across*
systems but only within a single system. But then we have a problem
here ...

I saw you added a canonifier script for (2) above, but I'm guessing
that works only in this specific case? (Haven't looked closer at it). 

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 Apr 21 09:13:02 2011
From: seth at icir.org (Seth Hall)
Date: Thu, 21 Apr 2011 12:13:02 -0400
Subject: [Bro-Dev] [Bro-Commits] [git/bro] topic/policy-scripts-new:
	Extract packet data for the dpd.log (7c168e0)
In-Reply-To: <20110421144208.GC75458@icir.org>
References: <201104210500.p3L50UIH005118@bro-ids.icir.org>
	<20110421144208.GC75458@icir.org>
Message-ID: <CB1CE87B-E5BA-4A83-BD38-16BB462A5A1E@icir.org>


On Apr 21, 2011, at 10:42 AM, Robin Sommer wrote:

> This is a nice idea but get_current_packet() has some fuzzy semantics:
> the current packet is not necessarily the one triggering the event. It
> probably works often, but not always, and I'm wondering if when it
> doesn't, it could be very confusing to show the data here?


The fairly limited testing I did last night was giving me the correct data.  What would you think if I just leave that field disabled by default?  We could implement that field in a separate script and put a big disclaimer in the script that about how it could give incorrect packet data.  Assuming that people are reading the docs we should be safe.

  .Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/



From slagell at ncsa.illinois.edu  Thu Apr 21 09:13:36 2011
From: slagell at ncsa.illinois.edu (Adam J. Slagell)
Date: Thu, 21 Apr 2011 11:13:36 -0500
Subject: [Bro-Dev] Doc generation tests fail
In-Reply-To: <20110421161124.GF75458@icir.org>
References: <20110421141336.GA75458@icir.org>
	<356186256.1272.1303398174838.JavaMail.root@zimbra-1.ncsa.uiuc.edu>
	<20110421161124.GF75458@icir.org>
Message-ID: <B0BB200A-3A6C-4ACA-91B0-78E68682B274@ncsa.illinois.edu>

Maybe we should just have it run in doc mode on one of the NMI platforms to go through Jon's tests daily.

On Apr 21, 2011, at 11:11 AM, Robin Sommer wrote:

>    - I'm wondering whether Bro should report this also when not
>    running in doc mode. Otherwise, such things are hard to catch.

------
Adam J. Slagell, CISSP
Sr. Security Engineer
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
www.slagell.info
217.244.8965








From robin at icir.org  Thu Apr 21 09:20:57 2011
From: robin at icir.org (Robin Sommer)
Date: Thu, 21 Apr 2011 09:20:57 -0700
Subject: [Bro-Dev] [Bro-Commits] [git/bro] topic/policy-scripts-new:
	Extract	packet data for the dpd.log (7c168e0)
In-Reply-To: <CB1CE87B-E5BA-4A83-BD38-16BB462A5A1E@icir.org>
References: <201104210500.p3L50UIH005118@bro-ids.icir.org>
	<20110421144208.GC75458@icir.org>
	<CB1CE87B-E5BA-4A83-BD38-16BB462A5A1E@icir.org>
Message-ID: <20110421162057.GH75458@icir.org>


On Thu, Apr 21, 2011 at 12:13 -0400, you wrote:

>   We could implement that field in a separate script and put a big
>   disclaimer in the script that about how it could give incorrect
>   packet data.

Yes, I like that. 

>  Assuming that people are reading the docs we should be safe.

We are going from one extreme to the other: from having no docs at all
to making them mandatory to read. :-)

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 Apr 21 09:24:15 2011
From: robin at icir.org (Robin Sommer)
Date: Thu, 21 Apr 2011 09:24:15 -0700
Subject: [Bro-Dev] [Bro-Commits] [git/bro]
	topic/policy-scripts-new:	Extract packet data for the dpd.log
	(7c168e0)
In-Reply-To: <20110421162057.GH75458@icir.org>
References: <201104210500.p3L50UIH005118@bro-ids.icir.org>
	<20110421144208.GC75458@icir.org>
	<CB1CE87B-E5BA-4A83-BD38-16BB462A5A1E@icir.org>
	<20110421162057.GH75458@icir.org>
Message-ID: <20110421162415.GA80148@icir.org>


On Thu, Apr 21, 2011 at 09:20 -0700, I wrote:

> Yes, I like that. 

I replied a bit too fast: an option inside the same script should
already do it; off by default and with a suitable comment. I think we
shouldn't add too many tiny scripts that do things that a boolean
option can achieve just as well. In other words: @load shouldn't
replace redef. :-)

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 Apr 21 09:34:21 2011
From: seth at icir.org (Seth Hall)
Date: Thu, 21 Apr 2011 12:34:21 -0400
Subject: [Bro-Dev] [Bro-Commits] [git/bro] topic/policy-scripts-new:
	Extract packet data for the dpd.log (7c168e0)
In-Reply-To: <20110421162415.GA80148@icir.org>
References: <201104210500.p3L50UIH005118@bro-ids.icir.org>
	<20110421144208.GC75458@icir.org>
	<CB1CE87B-E5BA-4A83-BD38-16BB462A5A1E@icir.org>
	<20110421162057.GH75458@icir.org> <20110421162415.GA80148@icir.org>
Message-ID: <42B59C2E-6841-4932-B320-96746E6F7712@icir.org>


On Apr 21, 2011, at 12:24 PM, Robin Sommer wrote:

>  I think we
> shouldn't add too many tiny scripts that do things that a boolean
> option can achieve just as well. In other words: @load shouldn't
> replace redef. :-)


Haha.  Telling me not to replace redef with @load as soon as we have it available as a viable option! :P

I initially thought of an option, but then decided it might be better as a separate script since the field would still be included if I left it as an option and I didn't want the field to show up at all.  What do you think?  I suppose it doesn't matter if the field shows up and is empty all of the time.

  .Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/



From jsiwek at ncsa.illinois.edu  Thu Apr 21 10:12:45 2011
From: jsiwek at ncsa.illinois.edu (Jonathan Siwek)
Date: Thu, 21 Apr 2011 12:12:45 -0500 (CDT)
Subject: [Bro-Dev] Doc generation tests fail
In-Reply-To: <20110421161124.GF75458@icir.org>
Message-ID: <30338234.277.1303405961940.JavaMail.jsiwek@tangent.ncsa.illinois.edu>

> - is there a way to produce an error messages that makes clear
> it's a problem with the doc markup? Otherwise this can be quite
> confusing as one would normally just ignore comments when looking
> for errors the parser is reporting.

Not sure how I can get it to be 100% sure a given parse error is because of doc markup, but I can easily add a hint to the message when in doc mode to remember to check ## style comments for syntax errors.

> - I'm wondering whether Bro should report this also when not
> running in doc mode. Otherwise, such things are hard to catch.

Right now it's using flex start conditions to only send doc-related tokens to the parser in certain places (enum/record bodies).  If instead I always send tokens, then this type of error could be reported when not running in doc mode.  But that would also probably mean that we can't re-use the "##" syntax in enum/record bodies -- we'd need yet another style.

> Perhaps a middle ground: should we have a test that ensures that
> all scripts we ship do correctly parse in doc mode? The existing
> tests reported logging.bro but only because it's a central one.
> Ones that are less used will be harder to find (and will in
> particular mess up the auto-generated pages on the web server)

I think maybe this can be covered by a build test on NMI that checks `make doc` doesn't have any error.
 
> > the ordering of set/table values seems to be able to change between runs.
> 
> In theory, that shouldn't be the case as long as the RNG's seed is
> set, which btest.cfg does. (But see below for practice).
>
> And the tables do actually come out in a different order here as well.
> I'm wondering whether seeding the RNG isn't sufficient. It has been in
> the past afairc, but I guess same order isn't guarnateed *across*
> systems but only within a single system. But then we have a problem
> here ...
>
> I saw you added a canonifier script for (2) above, but I'm guessing
> that works only in this specific case? (Haven't looked closer at it).

Yeah, it's really crappy; not generalizable.  I think we need something better (but I'm not sure where to start looking to fix the general problem).

- Jon

From slagell at ncsa.illinois.edu  Thu Apr 21 10:14:37 2011
From: slagell at ncsa.illinois.edu (Adam J. Slagell)
Date: Thu, 21 Apr 2011 12:14:37 -0500
Subject: [Bro-Dev] Doc generation tests fail
In-Reply-To: <30338234.277.1303405961940.JavaMail.jsiwek@tangent.ncsa.illinois.edu>
References: <30338234.277.1303405961940.JavaMail.jsiwek@tangent.ncsa.illinois.edu>
Message-ID: <09576ED7-A3E1-4BE5-B510-3E5059A8812A@ncsa.illinois.edu>


On Apr 21, 2011, at 12:12 PM, Jonathan Siwek wrote:

>> Perhaps a middle ground: should we have a test that ensures that
>> all scripts we ship do correctly parse in doc mode? The existing
>> tests reported logging.bro but only because it's a central one.
>> Ones that are less used will be harder to find (and will in
>> particular mess up the auto-generated pages on the web server)
> 
> I think maybe this can be covered by a build test on NMI that checks `make doc` doesn't have any error.

Yes. BTW, are we testing this Don?

------
Adam J. Slagell, CISSP
Sr. Security Engineer
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
www.slagell.info
217.244.8965








From robin at icir.org  Thu Apr 21 10:29:48 2011
From: robin at icir.org (Robin Sommer)
Date: Thu, 21 Apr 2011 10:29:48 -0700
Subject: [Bro-Dev] [Bro-Commits] [git/bro]
	topic/policy-scripts-new:	Extract packet data for the dpd.log
	(7c168e0)
In-Reply-To: <42B59C2E-6841-4932-B320-96746E6F7712@icir.org>
References: <201104210500.p3L50UIH005118@bro-ids.icir.org>
	<20110421144208.GC75458@icir.org>
	<CB1CE87B-E5BA-4A83-BD38-16BB462A5A1E@icir.org>
	<20110421162057.GH75458@icir.org> <20110421162415.GA80148@icir.org>
	<42B59C2E-6841-4932-B320-96746E6F7712@icir.org>
Message-ID: <20110421172948.GF80148@icir.org>


On Thu, Apr 21, 2011 at 12:34 -0400, you wrote:

> I initially thought of an option, but then decided it might be better
> as a separate script since the field would still be included if I left
> it as an option and I didn't want the field to show up at all.

Ok, I see that argument. That may actually also be a good rule of
thumb for @load vs redef-an-option: if not setting the option would
still be visible to the user in some non-pleasant form, a script may
indeed be the better way (you may have such rules in your head already
anyway; but I'm still learning them in the new model :-). 

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 Apr 21 10:39:03 2011
From: robin at icir.org (Robin Sommer)
Date: Thu, 21 Apr 2011 10:39:03 -0700
Subject: [Bro-Dev] Doc generation tests fail
In-Reply-To: <30338234.277.1303405961940.JavaMail.jsiwek@tangent.ncsa.illinois.edu>
References: <20110421161124.GF75458@icir.org>
	<30338234.277.1303405961940.JavaMail.jsiwek@tangent.ncsa.illinois.edu>
Message-ID: <20110421173903.GH80148@icir.org>


On Thu, Apr 21, 2011 at 12:12 -0500, you wrote:

> Not sure how I can get it to be 100% sure a given parse error is
> because of doc markup, but I can easily add a hint to the message when
> in doc mode to remember to check ## style comments for syntax errors.

That sounds good enough.

> I think maybe this can be covered by a build test on NMI that checks
> `make doc` doesn't have any error.

Ack, except that I'd also like to see that when running tests locally
already. Can we write a btest that does just the relevant subpart of
"make doc"? (e.g., doesn't need Sphinx). 

> something better (but I'm not sure where to start looking to fix the
> general problem).

Would it make sense to provide our own fully predictable (and simple)
RNG implementation (stolen from somewhere) that kicks in only when a
seed is explicitly set?

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 Apr 21 10:41:44 2011
From: seth at icir.org (Seth Hall)
Date: Thu, 21 Apr 2011 13:41:44 -0400
Subject: [Bro-Dev] [Bro-Commits] [git/bro] topic/policy-scripts-new:
	Extract packet data for the dpd.log (7c168e0)
In-Reply-To: <20110421172948.GF80148@icir.org>
References: <201104210500.p3L50UIH005118@bro-ids.icir.org>
	<20110421144208.GC75458@icir.org>
	<CB1CE87B-E5BA-4A83-BD38-16BB462A5A1E@icir.org>
	<20110421162057.GH75458@icir.org> <20110421162415.GA80148@icir.org>
	<42B59C2E-6841-4932-B320-96746E6F7712@icir.org>
	<20110421172948.GF80148@icir.org>
Message-ID: <D94DCAD2-7171-43E6-9E95-CF825AA9D836@icir.org>


On Apr 21, 2011, at 1:29 PM, Robin Sommer wrote:

> (you may have such rules in your head already
> anyway; but I'm still learning them in the new model :-). 

I'm going to start documenting all of these rules I have in my head soon. :P

  .Seth

From jsiwek at ncsa.illinois.edu  Thu Apr 21 11:00:01 2011
From: jsiwek at ncsa.illinois.edu (Jonathan Siwek)
Date: Thu, 21 Apr 2011 13:00:01 -0500 (CDT)
Subject: [Bro-Dev] Doc generation tests fail
In-Reply-To: <20110421173903.GH80148@icir.org>
Message-ID: <19507047.287.1303408800293.JavaMail.jsiwek@tangent.ncsa.illinois.edu>

> Ack, except that I'd also like to see that when running tests locally
> already. Can we write a btest that does just the relevant subpart of
> "make doc"? (e.g., doesn't need Sphinx).

Seems reasonable.  I'll work on that.

FYI, I'm thinking about rewriting how `make doc` does things almost entirely.  The scripts I did before don't seem like they're robust enough to deal with some of these new requirements we're working out.
 
> Would it make sense to provide our own fully predictable (and simple)
> RNG implementation (stolen from somewhere) that kicks in only when a
> seed is explicitly set?

Probably worth looking at.

- Jon

From appleman at ncsa.illinois.edu  Thu Apr 21 11:09:47 2011
From: appleman at ncsa.illinois.edu (Don Appleman)
Date: Thu, 21 Apr 2011 13:09:47 -0500 (CDT)
Subject: [Bro-Dev] Doc generation tests fail
In-Reply-To: <09576ED7-A3E1-4BE5-B510-3E5059A8812A@ncsa.illinois.edu>
Message-ID: <1490569784.2680.1303409387376.JavaMail.root@zimbra-1.ncsa.uiuc.edu>

We're not testing this yet. I added a note to my task list to run "make doc" at NMI. If we develop a BTest that validates docs, then this becomes moot.

Don


----- Original Message -----
From: "Adam J. Slagell" <slagell at ncsa.illinois.edu>
To: "Jonathan Siwek" <jsiwek at ncsa.illinois.edu>
Cc: bro-dev at bro-ids.org
Sent: Thursday, April 21, 2011 12:14:37 PM
Subject: Re: [Bro-Dev] Doc generation tests fail


On Apr 21, 2011, at 12:12 PM, Jonathan Siwek wrote:

>> Perhaps a middle ground: should we have a test that ensures that
>> all scripts we ship do correctly parse in doc mode? The existing
>> tests reported logging.bro but only because it's a central one.
>> Ones that are less used will be harder to find (and will in
>> particular mess up the auto-generated pages on the web server)
> 
> I think maybe this can be covered by a build test on NMI that checks `make doc` doesn't have any error.

Yes. BTW, are we testing this Don?

------
Adam J. Slagell, CISSP
Sr. Security Engineer
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
www.slagell.info
217.244.8965







_______________________________________________
bro-dev mailing list
bro-dev at bro-ids.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev


-- 
Don Appleman
National Center for Supercomputing Applications
2006B NCSA, 1205 W. Clark St.                            
Urbana, IL  61801
217/333-6340
appleman at ncsa.illinois.edu

From slagell at ncsa.illinois.edu  Thu Apr 21 11:11:54 2011
From: slagell at ncsa.illinois.edu (Adam J. Slagell)
Date: Thu, 21 Apr 2011 13:11:54 -0500
Subject: [Bro-Dev] Doc generation tests fail
In-Reply-To: <1490569784.2680.1303409387376.JavaMail.root@zimbra-1.ncsa.uiuc.edu>
References: <1490569784.2680.1303409387376.JavaMail.root@zimbra-1.ncsa.uiuc.edu>
Message-ID: <5BB5FDEE-BD94-4F1F-B16A-D45084D84FEB@ncsa.illinois.edu>


On Apr 21, 2011, at 1:09 PM, Don Appleman wrote:

> We're not testing this yet. I added a note to my task list to run "make doc" at NMI. If we develop a BTest that validates docs, then this becomes moot.

Which it looks like we are now.

------
Adam J. Slagell, CISSP
Sr. Security Engineer
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
www.slagell.info
217.244.8965








From appleman at ncsa.illinois.edu  Thu Apr 21 11:14:21 2011
From: appleman at ncsa.illinois.edu (Don Appleman)
Date: Thu, 21 Apr 2011 13:14:21 -0500 (CDT)
Subject: [Bro-Dev] Doc generation tests fail
In-Reply-To: <5BB5FDEE-BD94-4F1F-B16A-D45084D84FEB@ncsa.illinois.edu>
Message-ID: <1795561776.2736.1303409661807.JavaMail.root@zimbra-1.ncsa.uiuc.edu>

Yes, but I'll go ahead and test "make doc". I can remove it once we have a BTest for it (not sure when that will happen), and even if I don't, it's a harmless redundancy to test both ways.

Don


----- Original Message -----
From: "Adam J. Slagell" <slagell at ncsa.illinois.edu>
To: "Don Appleman" <appleman at ncsa.illinois.edu>
Cc: bro-dev at bro-ids.org, "Jonathan Siwek" <jsiwek at ncsa.illinois.edu>
Sent: Thursday, April 21, 2011 1:11:54 PM
Subject: Re: [Bro-Dev] Doc generation tests fail


On Apr 21, 2011, at 1:09 PM, Don Appleman wrote:

> We're not testing this yet. I added a note to my task list to run "make doc" at NMI. If we develop a BTest that validates docs, then this becomes moot.

Which it looks like we are now.

------
Adam J. Slagell, CISSP
Sr. Security Engineer
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
www.slagell.info
217.244.8965







-- 
Don Appleman
National Center for Supercomputing Applications
2006B NCSA, 1205 W. Clark St.                            
Urbana, IL  61801
217/333-6340
appleman at ncsa.illinois.edu

From robin at icir.org  Thu Apr 21 11:34:16 2011
From: robin at icir.org (Robin Sommer)
Date: Thu, 21 Apr 2011 11:34:16 -0700
Subject: [Bro-Dev] Doc generation tests fail
In-Reply-To: <1795561776.2736.1303409661807.JavaMail.root@zimbra-1.ncsa.uiuc.edu>
References: <5BB5FDEE-BD94-4F1F-B16A-D45084D84FEB@ncsa.illinois.edu>
	<1795561776.2736.1303409661807.JavaMail.root@zimbra-1.ncsa.uiuc.edu>
Message-ID: <20110421183416.GB83305@icir.org>


On Thu, Apr 21, 2011 at 13:14 -0500, you wrote:

> Yes, but I'll go ahead and test "make doc". I can remove it once we
> have a BTest for it (not sure when that will happen), and even if I
> don't, it's a harmless redundancy to test both ways.

And it's testing more, like the Sphinx setup, so that's still helpful.

Robin

-- 
Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org

From slagell at ncsa.illinois.edu  Thu Apr 21 11:47:27 2011
From: slagell at ncsa.illinois.edu (Adam J. Slagell)
Date: Thu, 21 Apr 2011 13:47:27 -0500
Subject: [Bro-Dev] Doc generation tests fail
In-Reply-To: <20110421183416.GB83305@icir.org>
References: <5BB5FDEE-BD94-4F1F-B16A-D45084D84FEB@ncsa.illinois.edu>
	<1795561776.2736.1303409661807.JavaMail.root@zimbra-1.ncsa.uiuc.edu>
	<20110421183416.GB83305@icir.org>
Message-ID: <FFA29A24-0839-4799-91CB-C97FA924FE1F@ncsa.illinois.edu>


On Apr 21, 2011, at 1:34 PM, Robin Sommer wrote:

>> 
>> Yes, but I'll go ahead and test "make doc". I can remove it once we
>> have a BTest for it (not sure when that will happen), and even if I
>> don't, it's a harmless redundancy to test both ways.
> 
> And it's testing more, like the Sphinx setup, so that's still helpful.

Do we want to test Sphinx setup on NMI B&T? That adds a bunch more dependencies on all of these targets?

------
Adam J. Slagell, CISSP
Sr. Security Engineer
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
www.slagell.info
217.244.8965








From jsiwek at ncsa.illinois.edu  Thu Apr 21 12:01:06 2011
From: jsiwek at ncsa.illinois.edu (Jonathan Siwek)
Date: Thu, 21 Apr 2011 14:01:06 -0500 (CDT)
Subject: [Bro-Dev] Doc generation tests fail
In-Reply-To: <FFA29A24-0839-4799-91CB-C97FA924FE1F@ncsa.illinois.edu>
Message-ID: <23518641.305.1303412465360.JavaMail.jsiwek@tangent.ncsa.illinois.edu>

> Do we want to test Sphinx setup on NMI B&T? That adds a bunch more dependencies on all of these targets?

It should just be adding 1 dependency on Sphinx to the relevant target (currently `make doc`, but that will probably be subdivided into smaller targets per earlier discussion).  And it should be possible to just use easy_install to install Sphinx into the home directory.  Doesn't seem like a huge hassle to do it on NMI.

- Jon

From slagell at ncsa.illinois.edu  Thu Apr 21 12:15:56 2011
From: slagell at ncsa.illinois.edu (Adam J. Slagell)
Date: Thu, 21 Apr 2011 14:15:56 -0500
Subject: [Bro-Dev] Doc generation tests fail
In-Reply-To: <23518641.305.1303412465360.JavaMail.jsiwek@tangent.ncsa.illinois.edu>
References: <23518641.305.1303412465360.JavaMail.jsiwek@tangent.ncsa.illinois.edu>
Message-ID: <1741E153-DF5B-4789-84FA-9323A09EFB22@ncsa.illinois.edu>


On Apr 21, 2011, at 2:01 PM, Jonathan Siwek wrote:

>> Do we want to test Sphinx setup on NMI B&T? That adds a bunch more dependencies on all of these targets?
> 
> It should just be adding 1 dependency on Sphinx to the relevant target (currently `make doc`, but that will probably be subdivided into smaller targets per earlier discussion).  And it should be possible to just use easy_install to install Sphinx into the home directory.  Doesn't seem like a huge hassle to do it on NMI.

Sounds good. Then I suggest we go forward with that.



From jsiwek at ncsa.illinois.edu  Thu Apr 21 14:49:16 2011
From: jsiwek at ncsa.illinois.edu (Jonathan Siwek)
Date: Thu, 21 Apr 2011 16:49:16 -0500 (CDT)
Subject: [Bro-Dev] @load convention for BIFs
In-Reply-To: <2199935.327.1303421801279.JavaMail.jsiwek@tangent.ncsa.illinois.edu>
Message-ID: <13069517.339.1303422551676.JavaMail.jsiwek@tangent.ncsa.illinois.edu>

Robin,

Here's how bro.init `@load`s the bro scripts generated from BIFs:

@load const.bif.bro
@load types.bif.bro
@load strings.bif.bro
@load bro.bif.bro
@load event.bif.bro

But logging.bro does it like this:

@load logging.bif

Can I add a ".bro" to that as a consistency nitpick?

(Currently it also triggers a warning when bro's in doc mode because it was expecting the former convention, but I may try to make it more robust as I'm going to need to revisit that piece of code anyway).

- Jon

From robin at icir.org  Thu Apr 21 17:48:41 2011
From: robin at icir.org (Robin Sommer)
Date: Thu, 21 Apr 2011 17:48:41 -0700
Subject: [Bro-Dev] @load convention for BIFs
In-Reply-To: <13069517.339.1303422551676.JavaMail.jsiwek@tangent.ncsa.illinois.edu>
References: <2199935.327.1303421801279.JavaMail.jsiwek@tangent.ncsa.illinois.edu>
	<13069517.339.1303422551676.JavaMail.jsiwek@tangent.ncsa.illinois.edu>
Message-ID: <20110422004841.GA96003@icir.org>


On Thu, Apr 21, 2011 at 16:49 -0500, you wrote:

> Can I add a ".bro" to that as a consistency nitpick?

Yes, that's fine.

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 Apr 21 19:06:17 2011
From: robin at icir.org (Robin Sommer)
Date: Thu, 21 Apr 2011 19:06:17 -0700
Subject: [Bro-Dev] Doc generation tests fail
In-Reply-To: <19507047.287.1303408800293.JavaMail.jsiwek@tangent.ncsa.illinois.edu>
References: <20110421173903.GH80148@icir.org>
	<19507047.287.1303408800293.JavaMail.jsiwek@tangent.ncsa.illinois.edu>
Message-ID: <20110422020617.GA851@icir.org>


On Thu, Apr 21, 2011 at 13:00 -0500, you wrote:

> Probably worth looking at.

Ok, I'll look into that. It's the only solution I can come up with.

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 Apr 21 19:35:02 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 22 Apr 2011 02:35:02 -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.5c25284c0b4c8a17f178e946b7c82b06@tracker.icir.org>

#374: Add type testing operator
------------------------------+---------------------
  Reporter:  seth             |      Owner:  robin
      Type:  Feature Request  |     Status:  closed
  Priority:  Normal           |  Milestone:  Bro1.6
 Component:  Bro              |    Version:
Resolution:  Merged/Applied   |   Keywords:  logging
------------------------------+---------------------
Changes (by robin):

 * status:  testing => closed
 * resolution:   => Merged/Applied


Comment:

 Merged into master.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/374#comment:9>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Thu Apr 21 19:35:22 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 22 Apr 2011 02:35:22 -0000
Subject: [Bro-Dev] #375: Extending record type fields
In-Reply-To: <043.8edae7eaa6a3609d14220f5e1643d239@tracker.icir.org>
References: <043.8edae7eaa6a3609d14220f5e1643d239@tracker.icir.org>
Message-ID: <058.0c770387dbb8564503ebfcb49a7978d1@tracker.icir.org>

#375: Extending record type fields
------------------------------+---------------------
  Reporter:  seth             |      Owner:  robin
      Type:  Feature Request  |     Status:  closed
  Priority:  Normal           |  Milestone:  Bro1.6
 Component:  Bro              |    Version:
Resolution:  Merged/Applied   |   Keywords:  logging
------------------------------+---------------------
Changes (by robin):

 * status:  testing => closed
 * resolution:   => Merged/Applied


-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/375#comment:8>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Thu Apr 21 19:35:38 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 22 Apr 2011 02:35:38 -0000
Subject: [Bro-Dev] #382: Design an internal API for logging backends
In-Reply-To: <044.1bec2fcec10edc2608651458c92f895a@tracker.icir.org>
References: <044.1bec2fcec10edc2608651458c92f895a@tracker.icir.org>
Message-ID: <059.ca5cd42241289983158dff3cb6e3dca1@tracker.icir.org>

#382: Design an internal API for logging backends
-----------------------------+---------------------
  Reporter:  robin           |      Owner:  robin
      Type:  Problem         |     Status:  closed
  Priority:  Normal          |  Milestone:  Bro1.6
 Component:  Bro             |    Version:
Resolution:  Merged/Applied  |   Keywords:  logging
-----------------------------+---------------------
Changes (by robin):

 * status:  testing => closed
 * resolution:   => Merged/Applied


-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/382#comment:5>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From robin at icir.org  Thu Apr 21 19:38:01 2011
From: robin at icir.org (Robin Sommer)
Date: Thu, 21 Apr 2011 19:38:01 -0700
Subject: [Bro-Dev] [Fwd] Re:  #263: --enable-int64 breaks bropipe
In-Reply-To: <20110418033727.GA84554@icir.org>
References: <20110418033727.GA84554@icir.org>
Message-ID: <20110422023801.GA1746@icir.org>

Christian,

any opinion? Shall I just merge it in?

Robin

On Sun, Apr 17, 2011 at 20:37 -0700, I wrote:

> Christian,
> 
> can you take a look at Jon's changes to see what you think?
> 
> You can see the diff here:
> 
>     http://git.bro-ids.org/broccoli.git/commitdiff/refs/heads/topic/jsiwek/64bit-val-fix

--
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 Apr 21 19:39:36 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 22 Apr 2011 02:39:36 -0000
Subject: [Bro-Dev] #420: Always associate &default with record fields
In-Reply-To: <044.fd88dd449ce707c62224c042cbd0b906@tracker.icir.org>
References: <044.fd88dd449ce707c62224c042cbd0b906@tracker.icir.org>
Message-ID: <059.ac9d4dc17535b04b5d5df323adca6bca@tracker.icir.org>

#420: Always associate &default with record fields
-----------------------------+--------------------
  Reporter:  robin           |      Owner:  robin
      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


Comment:

 Done

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/420#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Thu Apr 21 19:55:17 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 22 Apr 2011 02:55:17 -0000
Subject: [Bro-Dev] #439: topic/seth/decode-nbns-names - Updates to
 netbios name decoding function
In-Reply-To: <043.78815fb0c88dd4d7e2891f6837d32a85@tracker.icir.org>
References: <043.78815fb0c88dd4d7e2891f6837d32a85@tracker.icir.org>
Message-ID: <058.71714d571a4f5a6bb6569635005a0db1@tracker.icir.org>

#439: topic/seth/decode-nbns-names - Updates to netbios name decoding function
-----------------------------+------------------------
  Reporter:  seth            |      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: <http://tracker.icir.org/bro/ticket/439#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Thu Apr 21 19:55:31 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 22 Apr 2011 02:55:31 -0000
Subject: [Bro-Dev] #438: topic/seth/fix-do_split - Fix and test for a
	do_split bug.
In-Reply-To: <043.72cddbbb547b6ff7bc886661390cb164@tracker.icir.org>
References: <043.72cddbbb547b6ff7bc886661390cb164@tracker.icir.org>
Message-ID: <058.5e62a55c53ed6896ccaa3eeeac677d80@tracker.icir.org>

#438: topic/seth/fix-do_split - Fix and test for a do_split bug.
-----------------------------+------------------------
  Reporter:  seth            |      Owner:  robin
      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: <http://tracker.icir.org/bro/ticket/438#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From seth at icir.org  Fri Apr 22 07:39:31 2011
From: seth at icir.org (Seth Hall)
Date: Fri, 22 Apr 2011 10:39:31 -0400
Subject: [Bro-Dev] failing?
Message-ID: <4E3972A2-6D2D-4359-A804-42C928298804@icir.org>

Does it make sense that this code is failing?

=====START=====
type Bundle: table[string] of string;

const foobar: table[count] of Bundle = {} &redef;

redef foobar += {
        [1] = { ["A"] = "B" },
};
=====END=====

I'm getting this error:
./test2.bro, line 6: error: syntax error, at or near "{"

I'm seeing this on a branch, but I just merged in master so it should be happening on master too.

  .Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/



From vern at icir.org  Fri Apr 22 08:09:30 2011
From: vern at icir.org (Vern Paxson)
Date: Fri, 22 Apr 2011 08:09:30 -0700
Subject: [Bro-Dev] failing?
In-Reply-To: <4E3972A2-6D2D-4359-A804-42C928298804@icir.org> (Fri,
	22 Apr 2011 10:39:31 EDT).
Message-ID: <20110422150930.99889369FC9@taffy.ICSI.Berkeley.EDU>

> Does it make sense that this code is failing?

Well, define "sense" :-).  Yes, it makes sense to me, because I  could
easily see Bro's inference of types in initializations getting in the way
with what you've provided.  It has trouble with nested definitions.  Probably
the right way to fix this is to add support for constructors.

Can you get it to work using table()?  For example, the following

	print table([3] = table(["foo"] = "bar"));

does indeed work.

		Vern

From bro at tracker.icir.org  Fri Apr 22 09:43:13 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 22 Apr 2011 16:43:13 -0000
Subject: [Bro-Dev] #440: Add MD5 summing to existing file analyzer
Message-ID: <043.caa0e62418a169fbcf778f83e42edf94@tracker.icir.org>

#440: Add MD5 summing to existing file analyzer
-----------------------------+------------------------
 Reporter:  seth             |      Owner:
     Type:  Feature Request  |     Status:  new
 Priority:  Normal           |  Milestone:  Bro1.6
Component:  Bro              |    Version:  git/master
 Keywords:                   |
-----------------------------+------------------------
 It should be pretty straight forward, but there is a question about
 how/when to enable the checksumming because we don't want it to always be
 enabled.  It would be most helpful if we were able to get an initial chunk
 of data (for mime typing) prior to enabling the checksumming.

 I would *like* this to happen for 1.6, but if we don't come up with a good
 way to do it it doesn't matter too much since this feature will also be
 deprecated by the file analysis revisions that I proposed so if there
 isn't an obvious way to do it, let's skip it.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/440>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr 22 12:10:22 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 22 Apr 2011 19:10:22 -0000
Subject: [Bro-Dev] #440: Add MD5 summing to existing file analyzer
In-Reply-To: <043.caa0e62418a169fbcf778f83e42edf94@tracker.icir.org>
References: <043.caa0e62418a169fbcf778f83e42edf94@tracker.icir.org>
Message-ID: <058.91c5f3ae49f91744ea2889a4303fafae@tracker.icir.org>

#440: Add MD5 summing to existing file analyzer
------------------------------+------------------------
  Reporter:  seth             |      Owner:
      Type:  Feature Request  |     Status:  new
  Priority:  Normal           |  Milestone:  Bro1.6
 Component:  Bro              |    Version:  git/master
Resolution:                   |   Keywords:
------------------------------+------------------------

Comment (by aashish):

 None
 Filename None could not be saved, problem: (13, 'Permission denied')\May
 be I am stating the obvious:

 I'd say enable checksumming for 'WatchedMIME_Types'.

 Also, it would be useful, at policy level, to have alert trigged if
 there is a checksum match (md5) to a known list of bad md5 hashes.

 Aashish


 On Fri, Apr 22, 2011 at 04:43:13PM -0000, Bro Tracker wrote:
 > #440: Add MD5 summing to existing file analyzer
 > -----------------------------+------------------------
 >  Reporter:  seth             |      Owner:
 >      Type:  Feature Request  |     Status:  new
 >  Priority:  Normal           |  Milestone:  Bro1.6
 > Component:  Bro              |    Version:  git/master
 >  Keywords:                   |
 > -----------------------------+------------------------
 >  It should be pretty straight forward, but there is a question about
 >  how/when to enable the checksumming because we don't want it to always
 be
 >  enabled.  It would be most helpful if we were able to get an initial
 chunk
 >  of data (for mime typing) prior to enabling the checksumming.
 >
 >  I would *like* this to happen for 1.6, but if we don't come up with a
 good
 >  way to do it it doesn't matter too much since this feature will also be
 >  deprecated by the file analysis revisions that I proposed so if there
 >  isn't an obvious way to do it, let's skip it.
 >
 > --
 > Ticket URL: <http://tracker.icir.org/bro/ticket/440>
 > Bro Tracker <http://tracker.icir.org/bro>
 > Bro Issue Tracker
 >
 > _______________________________________________
 > bro-dev mailing list
 > bro-dev at bro-ids.org
 > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

 [attachment:"None"]

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/440#comment:0>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr 22 22:14:37 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Sat, 23 Apr 2011 05:14:37 -0000
Subject: [Bro-Dev] #408: Unique connection ID for bro
In-Reply-To: <045.d1dcc001adbef43f9bd34f06ae252340@tracker.icir.org>
References: <045.d1dcc001adbef43f9bd34f06ae252340@tracker.icir.org>
Message-ID: <060.115d34bf2856c05d322fed6e69f91e76@tracker.icir.org>

#408: Unique connection ID for bro
------------------------------+------------------------
  Reporter:  gregor           |      Owner:  robin
      Type:  Feature Request  |     Status:  closed
  Priority:  Normal           |  Milestone:  Bro1.6
 Component:  Bro              |    Version:  git/master
Resolution:  Merged/Applied   |   Keywords:
------------------------------+------------------------
Changes (by robin):

 * status:  accepted => closed
 * resolution:   => Merged/Applied


Comment:

 Done.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/408#comment:2>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 26 08:09:54 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 26 Apr 2011 15:09:54 -0000
Subject: [Bro-Dev] #264: topic/seth/mpls - Experimental MPLS support.
In-Reply-To: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org>
References: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org>
Message-ID: <059.78195807353dfb79ed272929941f838c@tracker.icir.org>

#264: topic/seth/mpls - Experimental MPLS support.
----------------------------+--------------------
  Reporter:  robin          |      Owner:
      Type:  Merge Request  |     Status:  new
  Priority:  Normal         |  Milestone:  Bro1.6
 Component:  Bro            |    Version:  1.5.1
Resolution:                 |   Keywords:  sprint
----------------------------+--------------------
Changes (by seth):

 * type:  Patch => Merge Request


-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/264#comment:8>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 26 08:11:11 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 26 Apr 2011 15:11:11 -0000
Subject: [Bro-Dev] #264: topic/seth/mpls - Experimental MPLS support.
In-Reply-To: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org>
References: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org>
Message-ID: <059.7e7f548ac05512ae0ed0dd913d2a98f5@tracker.icir.org>

#264: topic/seth/mpls - Experimental MPLS support.
----------------------------+--------------------
  Reporter:  robin          |      Owner:
      Type:  Merge Request  |     Status:  new
  Priority:  Normal         |  Milestone:  Bro1.6
 Component:  Bro            |    Version:  1.5.1
Resolution:                 |   Keywords:  sprint
----------------------------+--------------------

Comment (by seth):

 To answer my question from above, I *think* that the default filter to Bro
 will change to "ip or not ip" which will enable vlan and mpls packets
 being accepted by the BPF filter.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/264#comment:9>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 26 15:14:35 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Tue, 26 Apr 2011 22:14:35 -0000
Subject: [Bro-Dev] #441: MD5hash for mail attachments
Message-ID: <046.c4e0badeba3b6244824360cc26e86fc2@tracker.icir.org>

#441: MD5hash for mail attachments
---------------------+-----------------------------
 Reporter:  aashish  |       Type:  Feature Request
   Status:  new      |   Priority:  Normal
Milestone:  Bro1.6   |  Component:  Bro
  Version:           |   Keywords:
---------------------+-----------------------------
 It would be very useful to get md5hash calculated in logs for known mime-
 types which are delivered via HTTP or SMTP

 - log md5 hashes for all mail attachments
 - log md5 hashes for watched-mime-types for http traffic

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/441>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Tue Apr 26 17:21:21 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Wed, 27 Apr 2011 00:21:21 -0000
Subject: [Bro-Dev] #441: MD5hash for mail attachments
In-Reply-To: <046.c4e0badeba3b6244824360cc26e86fc2@tracker.icir.org>
References: <046.c4e0badeba3b6244824360cc26e86fc2@tracker.icir.org>
Message-ID: <061.de4b799986adcd33bdad8ebcecd489cf@tracker.icir.org>

#441: MD5hash for mail attachments
------------------------------+--------------------
  Reporter:  aashish          |      Owner:
      Type:  Feature Request  |     Status:  closed
  Priority:  Normal           |  Milestone:  Bro1.6
 Component:  Bro              |    Version:
Resolution:  Solved           |   Keywords:
------------------------------+--------------------
Changes (by seth):

 * status:  new => closed
 * resolution:   => Solved


Comment:

 This is the existing behavior in the scripts for the next release.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/441#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Wed Apr 27 09:32:21 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Wed, 27 Apr 2011 16:32:21 -0000
Subject: [Bro-Dev] #442: Hardcode Python path
Message-ID: <044.75c677aee0c63a0465103d3162763279@tracker.icir.org>

#442: Hardcode Python path
------------------------+--------------------
 Reporter:  robin       |      Owner:  jsiwek
     Type:  Problem     |     Status:  new
 Priority:  Normal      |  Milestone:  Bro1.6
Component:  BroControl  |    Version:
 Keywords:              |
------------------------+--------------------
 BroControl currently uses `#! /usr/bin/env` to find the Python binary at
 runtime. Craig suggested this instead:

 > I think the best way to go is to find python on the users path at the
 > time bro is built and use that full path in all python scripts (e.g. at
 > the point where the broctl.in template is transformed into broctl).

 Jon, is that something we can teach cmake to do?

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/442>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Wed Apr 27 16:07:15 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Wed, 27 Apr 2011 23:07:15 -0000
Subject: [Bro-Dev] #443: Print a message instead of a stack trace when
 debug.log can't be opened
Message-ID: <044.4e043473c81c6bae9f3157b943593659@tracker.icir.org>

#443: Print a message instead of a stack trace when debug.log can't be opened
-----------------------------+-------------------
 Reporter:  leres            |      Owner:  robin
     Type:  Feature Request  |     Status:  new
 Priority:  Low              |  Milestone:
Component:  BroControl       |    Version:  1.5.3
 Keywords:                   |
-----------------------------+-------------------
 If you start bro and neither the spool directory nor the current working
 directory are writable, you get a stack trace:

 {{{
 dig 16 # service bro start
 Traceback (most recent call last):
   File "/usr/local/bin/broctl", line 712, in <module>
     Config = config.Configuration("etc/broctl.cfg", BroBase, BroDist,
 Version, StandAlone)
   File "/usr/local/lib/broctl/BroControl/config.py", line 203, in __init__
     (success, output) = execute.captureCmd("uname")
   File "/usr/local/lib/broctl/BroControl/execute.py", line 200, in
 captureCmd
     util.debug(1, "%-10s %s" % ("[local]", cmdline))
   File "/usr/local/lib/broctl/BroControl/util.py", line 78, in debug
     DebugOut = open("debug.log", "a")
 IOError: [Errno 13] Permission denied: 'debug.log'
 }}}

 It would be a lot more helpful to print the paths; see attached patch to
 BroControl/util.py which results in:

 {{{
 dig 17 # service bro start
 warning: Can't open /usr/local/spool/debug.log: Permission denied
 error: Can't open /debug.log: Permission denied
 }}}

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/443>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Wed Apr 27 18:07:13 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Thu, 28 Apr 2011 01:07:13 -0000
Subject: [Bro-Dev] #264: topic/seth/mpls - Experimental MPLS support.
In-Reply-To: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org>
References: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org>
Message-ID: <059.43b089bb742ac633a3e3b8baacece82c@tracker.icir.org>

#264: topic/seth/mpls - Experimental MPLS support.
----------------------------+--------------------
  Reporter:  robin          |      Owner:
      Type:  Merge Request  |     Status:  new
  Priority:  Normal         |  Milestone:  Bro1.6
 Component:  Bro            |    Version:  1.5.1
Resolution:                 |   Keywords:  sprint
----------------------------+--------------------

Comment (by robin):

 I have a some questions. :)

 - not sure what the part is that you "*think*" will happen. Are you
 wondering whether "ip or not ip" will let vlan/mpls through? or whether we
 have indeed decided to make that the default filter? or whether the new
 filter code works at all?

 - seems the code no longer needs the `mpls_link` option, correct?

 - do we have small test trace with mixed MPLS/VLAN traffic?

 - one of the above questions doesn't seem answered: can there be VLAN over
 MPLS, and/or MPLS over VLAN? The code currently doesn't handle
 combinations.

 - to double-check my MPLS knowledge: is it right that with MPLS there's no
 way to find out whether the packets are actually of transport-layer type
 IP4/6?

 - the patch removes `vlan.bro` and some code in `pcap.bro` to handle that.
 Isn't the ``vlan`` keyword  still needed for BPF for doing more
 restrictive filters?

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/264#comment:10>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Wed Apr 27 19:25:35 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Thu, 28 Apr 2011 02:25:35 -0000
Subject: [Bro-Dev] #264: topic/seth/mpls - Experimental MPLS support.
In-Reply-To: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org>
References: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org>
Message-ID: <059.3989247aab1d474cfbf38f1b449772bc@tracker.icir.org>

#264: topic/seth/mpls - Experimental MPLS support.
----------------------------+----------------------
  Reporter:  robin          |      Owner:  seth
      Type:  Merge Request  |     Status:  assigned
  Priority:  Normal         |  Milestone:  Bro1.6
 Component:  Bro            |    Version:  1.5.1
Resolution:                 |   Keywords:  sprint
----------------------------+----------------------
Changes (by robin):

 * owner:   => seth
 * status:  new => assigned


-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/264#comment:11>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Wed Apr 27 21:38:13 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Thu, 28 Apr 2011 04:38:13 -0000
Subject: [Bro-Dev] #326: HTTP Analyzer overflow on content-lengths > 2GB
In-Reply-To: <045.82bf4b86731e1736daaef4caa8c63d05@tracker.icir.org>
References: <045.82bf4b86731e1736daaef4caa8c63d05@tracker.icir.org>
Message-ID: <060.a545d61347e3a3ae84fdb3362dbf61b0@tracker.icir.org>

#326: HTTP Analyzer overflow on content-lengths > 2GB
-----------------------------+-----------------------------
  Reporter:  gregor          |      Owner:  robin
      Type:  Patch           |     Status:  closed
  Priority:  Normal          |  Milestone:  Bro1.6
 Component:  Bro             |    Version:  git/master
Resolution:  Merged/Applied  |   Keywords:  inttypes,sprint
-----------------------------+-----------------------------
Changes (by robin):

 * status:  accepted => closed
 * resolution:   => Merged/Applied


-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/326#comment:12>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Thu Apr 28 06:31:03 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Thu, 28 Apr 2011 13:31:03 -0000
Subject: [Bro-Dev] #264: topic/seth/mpls - Experimental MPLS support.
In-Reply-To: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org>
References: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org>
Message-ID: <059.d5e8aa7853ff0c2cbae6ccd0723030ca@tracker.icir.org>

#264: topic/seth/mpls - Experimental MPLS support.
----------------------------+----------------------
  Reporter:  robin          |      Owner:  seth
      Type:  Merge Request  |     Status:  assigned
  Priority:  Normal         |  Milestone:  Bro1.6
 Component:  Bro            |    Version:  1.5.1
Resolution:                 |   Keywords:  sprint
----------------------------+----------------------

Comment (by seth):

 > - not sure what the part is that you "*think*" will happen. Are you
 > wondering whether "ip or not ip" will let vlan/mpls through? or whether
 we
 > have indeed decided to make that the default filter?

 It does pass through vlan&mpls and I've been thinking that's what we'd
 move to as the default filter.  I tried a lot of combinations and giving
 it an always true filter seems to be the only way to always pass through
 packets (like not having a filter at all).

 > - seems the code no longer needs the `mpls_link` option, correct?

 Correct, I think I removed that didn't I?

 > - do we have small test trace with mixed MPLS/VLAN traffic?

 I actually have one I grabbed from pcapr.net, I'll attach it to this
 ticket.

 > - one of the above questions doesn't seem answered: can there be VLAN
 over
 > MPLS, and/or MPLS over VLAN? The code currently doesn't handle
 > combinations.

 I have no clue.  I haven't heard of anyone encountering traffic like this
 and I haven't seen a trace showing it.

 > - to double-check my MPLS knowledge: is it right that with MPLS there's
 no
 > way to find out whether the packets are actually of transport-layer type
 > IP4/6?

 That's a good question, but I don't have a clue.

 > - the patch removes `vlan.bro` and some code in `pcap.bro` to handle
 that.
 > Isn't the ``vlan`` keyword  still needed for BPF for doing more
 > restrictive filters?

 Hm, yes.  I think we still need to figure out how we are going to handle
 choosing between the default "wide open" filter and accepting the filter
 set by the chosen scripts.  I removed vlan.bro because it won't normally
 be necessary with the open filter.  I'm of the opinion that people should
 just have to choose the correct filter for their traffic if they want to
 apply a filter since it's already like that with tcpdump (no filter you
 see vlan packets, but apply a filter without "vlan" you don't see them).

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/264#comment:19>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Thu Apr 28 09:35:19 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Thu, 28 Apr 2011 16:35:19 -0000
Subject: [Bro-Dev] #443: Print a message instead of a stack trace when
 debug.log can't be opened
In-Reply-To: <044.4e043473c81c6bae9f3157b943593659@tracker.icir.org>
References: <044.4e043473c81c6bae9f3157b943593659@tracker.icir.org>
Message-ID: <059.eb5f1ed8e212bce0e1885253bc58e94b@tracker.icir.org>

#443: Print a message instead of a stack trace when debug.log can't be opened
------------------------------+--------------------
  Reporter:  leres            |      Owner:  robin
      Type:  Feature Request  |     Status:  new
  Priority:  Low              |  Milestone:  Bro1.6
 Component:  BroControl       |    Version:  1.5.3
Resolution:                   |   Keywords:
------------------------------+--------------------
Changes (by robin):

 * milestone:   => Bro1.6


-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/443#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From christian at icir.org  Thu Apr 28 12:01:10 2011
From: christian at icir.org (Christian Kreibich)
Date: Thu, 28 Apr 2011 12:01:10 -0700
Subject: [Bro-Dev] [Fwd] Re:  #263: --enable-int64 breaks bropipe
In-Reply-To: <20110422023801.GA1746@icir.org>
References: <20110418033727.GA84554@icir.org> <20110422023801.GA1746@icir.org>
Message-ID: <4DB9B976.1010604@icir.org>

On 04/21/2011 07:38 PM, Robin Sommer wrote:
> Christian,
> 
> any opinion? Shall I just merge it in?

Sorry for the delay folks, I keep falling behind on this list. I've
looked through the patch and it looks good to me. Kudos, you actually
found some corners of the code that needed changing that I wouldn't have
thought of right away!

-- 
Cheers,
Christian

From bro at tracker.icir.org  Fri Apr 29 09:12:44 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 29 Apr 2011 16:12:44 -0000
Subject: [Bro-Dev] #264: topic/seth/mpls - Experimental MPLS support.
In-Reply-To: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org>
References: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org>
Message-ID: <059.fbb97ae2da97bb1b767788c8391d75ff@tracker.icir.org>

#264: topic/seth/mpls - Experimental MPLS support.
----------------------------+----------------------
  Reporter:  robin          |      Owner:  seth
      Type:  Merge Request  |     Status:  assigned
  Priority:  Normal         |  Milestone:  Bro1.6
 Component:  Bro            |    Version:  1.5.1
Resolution:                 |   Keywords:  sprint
----------------------------+----------------------

Comment (by robin):

 Merged now.

 For the record:

 - I have turned on `all_packets` by default, per the earlier discussion.

 - `mpls_link` was still in the code, removed.

 - I've extracted some packets out of the attached trace for a btest

 - the code currently does not handle vlan-over-mpls (or vice versa), seems
 ok until proven otherwise.

 - `vlan.bro` plus the corresponding code in `pcap.bro` is gon. Agree with
 Seth that with the new default we can leave it to users to set their
 filter correctly if they need to (there's also interaction between BPF's
 `vlan` and `mpls` keywords; it's just a mess).

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/264#comment:20>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr 29 13:58:08 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 29 Apr 2011 20:58:08 -0000
Subject: [Bro-Dev] #444: bug fix for POP3 analyzer
Message-ID: <043.07292c738bf0c10d763add2815eb974d@tracker.icir.org>

#444: bug fix for POP3 analyzer
---------------------+-----------------
 Reporter:  vern     |      Owner:
     Type:  Problem  |     Status:  new
 Priority:  Normal   |  Milestone:
Component:  Bro      |    Version:
 Keywords:           |
---------------------+-----------------
 The POP3 analyzer has a major bug, which is that it doesn't recognize '.'
 terminators in multi-line replies if the terminator is bare (no newline).
 This causes it to ignore the rest of the session that it's analyzing.

 Patch appended.  I even tested it!

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/444>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr 29 14:04:49 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 29 Apr 2011 21:04:49 -0000
Subject: [Bro-Dev] #444: bug fix for POP3 analyzer
In-Reply-To: <043.07292c738bf0c10d763add2815eb974d@tracker.icir.org>
References: <043.07292c738bf0c10d763add2815eb974d@tracker.icir.org>
Message-ID: <058.787402da17e741033b9b0c99bddafcbb@tracker.icir.org>

#444: bug fix for POP3 analyzer
---------------------+----------------------
  Reporter:  vern    |      Owner:  robin
      Type:  Patch   |     Status:  accepted
  Priority:  Normal  |  Milestone:  Bro1.6
 Component:  Bro     |    Version:
Resolution:          |   Keywords:
---------------------+----------------------
Changes (by robin):

 * owner:   => robin
 * status:  new => accepted
 * type:  Problem => Patch
 * milestone:   => Bro1.6


-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/444#comment:1>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Fri Apr 29 14:08:55 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Fri, 29 Apr 2011 21:08:55 -0000
Subject: [Bro-Dev] #445: Split up cron command
Message-ID: <044.981eef591b7c90a67b94edd89aad2930@tracker.icir.org>

#445: Split up cron command
------------------------+--------------------
 Reporter:  robin       |      Owner:  robin
     Type:  Task        |     Status:  new
 Priority:  Normal      |  Milestone:  Bro1.6
Component:  BroControl  |    Version:
 Keywords:              |
------------------------+--------------------
 Split the `cron` command into separate statistics and watch/restart
 commands.

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/445>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker


From bro at tracker.icir.org  Sat Apr 30 08:55:49 2011
From: bro at tracker.icir.org (Bro Tracker)
Date: Sat, 30 Apr 2011 15:55:49 -0000
Subject: [Bro-Dev] #264: topic/seth/mpls - Experimental MPLS support.
In-Reply-To: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org>
References: <044.b0b845d09cf6aeaf4acd749d0c4917c2@tracker.icir.org>
Message-ID: <059.7da1fd1425509ff09e2754310ee2b633@tracker.icir.org>

#264: topic/seth/mpls - Experimental MPLS support.
-----------------------------+--------------------
  Reporter:  robin           |      Owner:  seth
      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:  assigned => closed
 * resolution:   => Merged/Applied


-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/264#comment:21>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker