zeek-dev December 2013

zeek-dev@lists.zeek.org

90 discussions

[Bro-Dev] [JIRA] (BIT-1109) topic/dnthayer/doc-updates

by Daniel Thayer (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1109?page=com.atlassian.jira.p… ] Daniel Thayer updated BIT-1109: ------------------------------- Status: Merge Request (was: Open) > topic/dnthayer/doc-updates > -------------------------- > > Key: BIT-1109 > URL: https://bro-tracker.atlassian.net/browse/BIT-1109 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro, BroControl > Reporter: Daniel Thayer > Fix For: 2.3 > > > This branch (in bro and broctl repos) includes miscellaneous documentation > fixes. -- This message was sent by Atlassian JIRA (v6.2-OD-05-4#6207)

7 years, 7 months

[Bro-Dev] [JIRA] (BIT-1109) topic/dnthayer/doc-updates

by Daniel Thayer (JIRA)

Daniel Thayer created BIT-1109: ---------------------------------- Summary: topic/dnthayer/doc-updates Key: BIT-1109 URL: https://bro-tracker.atlassian.net/browse/BIT-1109 Project: Bro Issue Tracker Issue Type: Problem Components: Bro, BroControl Reporter: Daniel Thayer Fix For: 2.3 This branch (in bro and broctl repos) includes miscellaneous documentation fixes. -- This message was sent by Atlassian JIRA (v6.2-OD-05-4#6207)

7 years, 7 months

[Bro-Dev] [Auto] Merge Status

by Merge Tracker

Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------- ---------- ------------------------------------------------------- 8ea56ae [1] bro Jon Siwek 2013-12-12 Improve warnings emitted from raw/execute input reader. [1] 8ea56ae https://github.com/bro/bro/commit/8ea56ae567c3bd7c1d7f6349c0507ef6afef3d4d

7 years, 7 months

[Bro-Dev] [Auto] Merge Status

by Merge Tracker

7 years, 7 months

[Bro-Dev] [Auto] Merge Status

by Merge Tracker

7 years, 7 months

[Bro-Dev] [Auto] Merge Status

by Merge Tracker

7 years, 7 months

[Bro-Dev] [Auto] Merge Status

by Merge Tracker

Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------- ---------- ----------------------------------------------------------- 63c36d5 [1] bro Jon Siwek 2013-12-11 Another attempt to improve core.when-interpreter-exceptions [1] 63c36d5 https://github.com/bro/bro/commit/63c36d58f3c622238a84d0d32b854d33ed5ccc9b

7 years, 7 months

[Bro-Dev] [JIRA] (BIT-1108) Add broctl option to set PF_RING cluster type

by Seth Hall (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1108?page=com.atlassian.jira.p… ] Seth Hall commented on BIT-1108: -------------------------------- Let's change the default to 4-tuple. > Add broctl option to set PF_RING cluster type > --------------------------------------------- > > Key: BIT-1108 > URL: https://bro-tracker.atlassian.net/browse/BIT-1108 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > > Currently, when using PF_RING, broctl chooses the PF_RING > cluster type by setting the environment variable > PCAP_PF_RING_USE_CLUSTER_PER_FLOW. In order to use a > different cluster type, we would need to set a different > environment variable (the PF_RING-aware libpcap does not > look at the actual value of the environment variable, > just whether the variable is defined or not), but there is > no option in broctl to do this. > To address this issue, a new broctl option PFRINGClusterType > can be added, then a user could change the value of this > option to choose a different PF_RING cluster type (and the > broctl pf_ring plugin would set the appropriate env. variable). > The allowed values of this new broctl option would be: > "2-tuple", "4-tuple", "5-tuple", "tcp-5-tuple", "round-robin", > or "6-tuple" (this one corresponds to the current > cluster type used by broctl). By default, PFRINGClusterType > would be set to "6-tuple". -- This message was sent by Atlassian JIRA (v6.2-OD-03#6206)

7 years, 7 months

[Bro-Dev] [JIRA] (BIT-1108) Add broctl option to set PF_RING cluster type

by Daniel Thayer (JIRA)

[ https://bro-tracker.atlassian.net/browse/BIT-1108?page=com.atlassian.jira.p… ] Daniel Thayer commented on BIT-1108: ------------------------------------ Any opinions on whether we should keep the same default cluster type (6-tuple) as before, or change it to something else? > Add broctl option to set PF_RING cluster type > --------------------------------------------- > > Key: BIT-1108 > URL: https://bro-tracker.atlassian.net/browse/BIT-1108 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl > Reporter: Daniel Thayer > > Currently, when using PF_RING, broctl chooses the PF_RING > cluster type by setting the environment variable > PCAP_PF_RING_USE_CLUSTER_PER_FLOW. In order to use a > different cluster type, we would need to set a different > environment variable (the PF_RING-aware libpcap does not > look at the actual value of the environment variable, > just whether the variable is defined or not), but there is > no option in broctl to do this. > To address this issue, a new broctl option PFRINGClusterType > can be added, then a user could change the value of this > option to choose a different PF_RING cluster type (and the > broctl pf_ring plugin would set the appropriate env. variable). > The allowed values of this new broctl option would be: > "2-tuple", "4-tuple", "5-tuple", "tcp-5-tuple", "round-robin", > or "6-tuple" (this one corresponds to the current > cluster type used by broctl). By default, PFRINGClusterType > would be set to "6-tuple". -- This message was sent by Atlassian JIRA (v6.2-OD-03#6206)

7 years, 7 months

[Bro-Dev] Proposed IOSource reorg

by Robin Sommer

I'm thinking to move the IOSource infrastructure into its own subdirectory/namespace and turn the IOSourceRegistry into iosource::Manager in alignment with the layout we've started to move to with the logging/input/etc. I'd then move the classes derived from IOSource into corresponding subdirectories, like this: src/iosource/ src/iosource/Manager.{h,cc} src/iosource/IOSource.{h,cc} src/iosource/sources/pkt-src/PktSrc.{h,cc} src/iosource/sources/pkt-src/bpf/* src/iosource/sources/flow-src/* src/iosource/sources/dns-mgr/* src/iosource/sources/remote-serializer/* The sources would turn into plugin components. New types of packet sources (like netmap) would then go into iosource/pkt-src/foo/. Does that make sense? One piece where I'm unsure: would it be better to keep the remote serializer out if this and instead do a separate serializer/ hierarchy where all the current serialization/communication code goes? Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin(a)icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin

7 years, 7 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

zeek-dev December 2013