> g++ -o bif_parse.o -c bif_parse.cc
> y.tab.c: In function `int yyparse()':
> y.tab.c:1705: syntax error before `goto'
y.tab.c is a generated file, so to diagnose it, please send a copy
of it, and/or lines 1700-1710 in order to localize the error.
Vern
> I just build and deployed bro-0.8a57 and the thing segfaults after about
> 5-100 minutes of running. I tried '-t file', but then it segfaults
> immediately.
>
> Platform is RedHat 9; default build of bro with ssl. Deployed on a fairly
> loaded 10MB/s link.
>
> Anybody else seeing this?
I don't run in that environment, but Robin does (or in something similar),
and I don't believe he's encountered any problems recently.
In general, when reporting a Bro crash, it helps a lot to show a traceback
(not -t output, which is generally much to voluminous to aid in debugging
crashes). Better (much) still is a tcpdump trace that reprodouces the
problem, if you're able to give me a copy of such.
Note, I recently ran across a problem running Bro's signature engine
against UDP or ICMP traffic. By default, each new UDP/ICMP flow sticks
around forever, so this rapidly consumes a huge amount of memory. You
can eliminate the problem via "@load reduce-memory".
Vern
> is Bro supported on NetBSD?
Not directly, since we don't have any NetBSD machines in house, but
it's certainly the intent that it runs under NetBSD (and in general
on systems with libpcap), if it's not too painful.
> If so, a recent thread on ethereal-dev
> discussed pcap_compile_nopcap() in that context and might be relevant
> for Bro. Have a look at
>
> http://www.ethereal.com/lists/ethereal-dev/200312/msg00401.html
Looks like some more autoconf'ing will be needed :-(. If someone cares
to contribute it, that would be great.
Vern
> For example, what if I run some proprietary service on port 80?
> Is is going to be service 'other' or service 'http'? What if
> I run telnetd on port 80?
Currently, this will be identified as "http".
Bro's TCP analyzers are being reworked so that in the future it will be
able to run alternate (or multiple) analyzers from that associated with
the well-known port. When that works, I think the above example would
have "telnet" as the service even though the responder port would be 80/tcp.
Vern
> > Good point. As implemented, it continues to be other-nnnnn, but I think
> > just plain "other" makes more sense, since we now can finally cleanly separate
> > the notion of service from the notion of port.
>
> It's cleaner, but is it really separated internally, or just in the logs?
The notion of "service" is "what is the actual service [application] running
on the connection". It initially arose from the utility of associating
"ftp-data" with connections that otherwise might not be identified as such,
since they didn't use well-known ports.
Bro is moving towards more fully decoupling the notion of what application
protocol to analyze vs. what application is usually associated with a given
well-known port, so I think the split of service in the connection logs
will be helpful in this regard.
> I confess (and probably reveal) my near total BRO ignorance, but isn't
> service just mapped from port number in some (many?) cases?
In most cases, yes, but not in all.
> Even if
> so, the separation is valuable and clearly necessary where not so,
> but I wonder if it wouldn't be useful to have some indication of those
> connections that BRO has determined the service of (via inspection)
> versus merely inferring the service from a port:name lookup table.
Hmmmm, perhaps this should be a new flag (to go along with 'L', and
the soon-to-depart 'U'), but I'm not sure it's worth it - do you have
an example in which this is particularly handy to have?
> PS. any consideration of making the log format a config spec:
>
> red_log_format: "%time %duration %service %oip %rip %bytes %rbytes ...."
>
> maybe little value... just a thought.
I think a better way to do this is to make it easy for the user to supply
their own connection log printer directly.
Vern
My apologies for dropping the ball on this thread :-(.
> - I am running this on a P3-600 MHz, 200 MB memory system. Is that too
> slow?
It crticially depends on your traffic volume. In my experience, a machine
like that should be able to monitor a network on the order of a hundred
machines with a 100 Mbps link; but that's somewhat a guess, as most of my
experience is with bigger/faster networks.
> - The size of the 'bro.core' file upon the seg-fault is of the order of 500
> MB.
> Isn't that weird?
This very likely indicates that Bro is crashing because you've reached
the process "datasize" limit. See what "limit datasize" reports.
> The response time of my system also increases drastically
That's because, given 200 MB of real memory, when Bro grows beyond that
towards 500 MB, you suffer a great deal of paging.
It appears very likely that you are encountering a memory leak.
Try (1) running the latest release (I just announced 0.8a58),
and, if the problem persists, turning on memory statistics, which
you can do by including "statistics.bro" as a policy script on the
command line or via @load.
Vern
Argh - the 0.8a57 release uses some new libpcap functionality
(pcap_compile_nocap(), and calling pcap_freecode() with a bpf_program*)
that isn't supported in older libpcap releases. If someone could please
contribute autoconf tweaks to deal with this incompatibility, I'd much
appreciate it.
Vern
> The changes notes above don't mention the <addl> field. Is that just
> an oversight in the notes,
Yes, just an oversight in the notes.
> Will <service> still contain port numbers? Or will "other-nnnnn" become
> simply "other"? (that would be my preference)
Good point. As implemented, it continues to be other-nnnnn, but I think
just plain "other" makes more sense, since we now can finally cleanly separate
the notion of service from the notion of port.
> Although I don't know what the "neighbor net" U flag even means, I wonder
> if this is the time to drop that, as the BRO manual says the whole notion
> is historical.
The notion of "neighbor" is still used a bit in the policy scripts
(in scan.bro, in particular - different rules apply to scan detection
for activity from neighbors than from others), but arguably this should
be structured in a different fashion (a general notion of networks that
are allowed to scan), and in fact this has bitten us operationally in
the past, when a infected neighbor scanned us.
Thanks for the suggestions!
Vern
