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)
[ 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)
[ 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)
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