<div>Its based of Suse on a powerpc architecture.</div>
<div> </div>
<div>The stalls only seemed to happen when there are filtered packets. If I had redefined my capture_filters to accept all traffic the stalls do not happen. </div>
<div> </div>
<div>// Joel <br><br></div>
<div class="gmail_quote">On Wed, Apr 2, 2008 at 1:43 PM, Robin Sommer <<a href="mailto:robin@icir.org">robin@icir.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d"><br>On Wed, Apr 02, 2008 at 13:20 -0600, Joel Ebrahimi wrote:<br><br>> I have been working on Bro on both an Intell and Bivio platform. On the<br>> Bivio system there is some strange occurence where if I my capture_filters<br>
> are excluding traffic it will cause the application to periodically stall<br>> and completley destroy performance.<br><br></div>What OS is the Bivio platform running? We've recently been seeing<br>stalls with FreeBSD 7 which sound pretty similar to what you<br>
describe. My guess is that the FB7 problems are related to<br>non-blocking pcap as well because Bro seems to be the only<br>application which triggers them.<br>
<div class="Ih2E3d"><br>> This build will not to communicate with other nodes so this sounds like a<br>> perfect solution.<br><br></div>(There's actually a bit more functionality which in principle could<br>stall, such as async DNS lookups (not a problem) or the new NetFlow<br>
analyzer (which isn't in trunk yet)). But in any case, as long as<br>you have a steady stream of packets on the wire, pcap will always<br>have something to pass back to Bro and thus not block anyway.)<br>
<div>
<div></div>
<div class="Wj3C7c"><br>Robin<br><br>--<br>Robin Sommer * Phone +1 (510) 666-2886 * <a href="mailto:robin@icir.org">robin@icir.org</a><br>ICSI/LBNL * Fax +1 (510) 666-2956 * <a href="http://www.icir.org/" target="_blank">www.icir.org</a><br>
</div></div></blockquote></div><br>