From rmkml at wanadoo.fr Sat Jan 8 06:48:38 2005 From: rmkml at wanadoo.fr (rmkml) Date: Sat, 8 Jan 2005 15:48:38 +0100 (CET) Subject: [bro] WeirdActivity truncated_NTP pb ? Message-ID: Hi, Happy New Year, I have this event : 1105106060.883849:WeirdActivity:NOTICE_ALARM_ALWAYS:::::::::::truncated_NTP x.x.x.x/32785 > 157.99.64.66/123: but ntp request is not trunc : $ tcpdump383 -vvnSlr bro_truncated_ntp.pcap 14:54:20.883849 IP (tos 0x0, ttl 63, id 42724, offset 0, flags [DF], length: 40) x.x.x.x.32785 > 157.99.64.66.123: [udp sum ok] [len=12]NTPv2 res1, strat 2, poll 0, prec 1 dist 0.000000, disp 0.000000 [|ntp] $ tcpdump372 -vvnSlr bro_truncated_ntp.pcap 14:54:20.883849 x.x.x.x.32785 > 157.99.64.66.123: [udp sum ok] [len=12] v2 res1 strat 2 poll 0 prec 1 dist 0.000000 disp 0.000000 ref 0.0.0.0 [|ntp] (DF) (ttl 63, id 42724, len 40) $ tethereal0101 -ta -nr bro_truncated_ntp.pcap 1 14:54:20.883849 x.x.x.x -> 157.99.64.66 NTP NTP control $ tethereal0101 -ta -Vnr bro_truncated_ntp.pcap ... Fragment offset: 0 Time to live: 63 Protocol: UDP (0x11) Header checksum: 0x5681 (correct) Source: x.x.x.x (x.x.x.x) Destination: 157.99.64.66 (157.99.64.66) User Datagram Protocol, Src Port: 32785 (32785), Dst Port: 123 (123) Source port: 32785 (32785) Destination port: 123 (123) Length: 20 Checksum: 0x2ad7 (correct) Network Time Protocol Flags: 0x16 00.. .... = Leap Indicator: no warning (0) ..01 0... = Version number: reserved (2) .... .110 = Mode: reserved for NTP control message (6) Flags 2: 0x02 0... .... = Response bit: Request (0) .0.. .... = Error bit: 0 ..0. .... = More bit: 0 ...0 0010 = Opcode: READVAR (2) false positive ? Im use bro09a7 on freebsd410 with "bro.init mt" Im use default rules/conf. Regards Rmkml at Wanadoo.fr From christian at whoop.org Sat Jan 8 11:38:12 2005 From: christian at whoop.org (Christian Kreibich) Date: Sat, 08 Jan 2005 20:38:12 +0100 Subject: [bro] WeirdActivity truncated_NTP pb ? In-Reply-To: References: Message-ID: <1105213093.3030.41.camel@localhost> On Sat, 2005-01-08 at 15:48 +0100, rmkml wrote: > Hi, > > Happy New Year, > > I have this event : > > 1105106060.883849:WeirdActivity:NOTICE_ALARM_ALWAYS:::::::::::truncated_NTP > x.x.x.x/32785 > 157.99.64.66/123: > > but ntp request is not trunc : > > $ tcpdump383 -vvnSlr bro_truncated_ntp.pcap > 14:54:20.883849 IP (tos 0x0, ttl 63, id 42724, offset 0, flags [DF], > length: 40) x.x.x.x.32785 > 157.99.64.66.123: [udp sum ok] > [len=12]NTPv2 res1, strat 2, poll 0, prec 1 dist 0.000000, disp 0.000000 > [|ntp] ^^^^^^ Yes it is ... your output indicates that your trace contains truncated NTP packets. Presumably you fed this trace to Bro... >From the tcpdump manpage: "Packets truncated because of a limited snapshot are indicated in the output with ``[|proto]'', where proto is the name of the protocol level at which the truncation has occurred." Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From herve.brelivet at enst-bretagne.fr Wed Jan 12 09:19:41 2005 From: herve.brelivet at enst-bretagne.fr (=?ISO-8859-1?Q?Herv=E9_Brelivet?=) Date: Wed, 12 Jan 2005 18:19:41 +0100 Subject: [Bro] URG Flag Message-ID: <41E55C2D.2010202@enst-bretagne.fr> Hello, I would like to know how I can retrieve urg flag in the tcp segment or count the number of tcp packets with a URG flag in a connection ? thanks From rpang at CS.Princeton.EDU Wed Jan 12 10:50:05 2005 From: rpang at CS.Princeton.EDU (Ruoming Pang) Date: Wed, 12 Jan 2005 13:50:05 -0500 Subject: [Bro] URG Flag In-Reply-To: <41E55C2D.2010202@enst-bretagne.fr> References: <41E55C2D.2010202@enst-bretagne.fr> Message-ID: One way is through event tcp_packet: event tcp_packet(c: connection, is_orig: bool, flags: string, seq: count, ack: count, len: count, payload: string) { if ( strstr(flags, "U") > 0 ) { ... } } But please note that it requires a per-TCP-packet event and thus only works for low volume traffic. Ruoming On Jan 12, 2005, at 12:19 PM, Herv? Brelivet wrote: > Hello, > > I would like to know how I can retrieve urg flag in the tcp segment or > count the number of tcp packets with a URG flag in a connection ? > > thanks > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From vern at icir.org Wed Jan 12 11:19:30 2005 From: vern at icir.org (Vern Paxson) Date: Wed, 12 Jan 2005 11:19:30 -0800 Subject: [Bro] URG Flag In-Reply-To: Your message of Wed, 12 Jan 2005 13:50:05 EST. Message-ID: <200501121919.j0CJJU7k080488@jaguar.icir.org> > One way is through event tcp_packet: > ... > But please note that it requires a per-TCP-packet event and thus only > works for low volume traffic. Yes. And, more generally, this sort of low-level analysis is not what Bro is designed for. If all you want to do is count URG packets, a simple tcpdump filter is much more efficient. Vern From yohann.thomas at rd.francetelecom.com Sun Jan 16 23:33:44 2005 From: yohann.thomas at rd.francetelecom.com (Yohann THOMAS) Date: Mon, 17 Jan 2005 08:33:44 +0100 Subject: [Bro] bad_tcp_checksum Message-ID: <41EB6A58.3070803@rd.francetelecom.com> Hi everybody, I've been using Bro on my computer on different purposes for a few months and till now, it always worked well ;-) Unfortunately, I'm experiencing a problem for a few days. In fact, when running Bro (with http.bro script) on some other computers, I have series of "bad_tcp_checksum" (with Linux) or "bad_ip_checksum" (with FreeBSD), and only a few packets seems to be read correctly. To sum up, here is the current situation : ->Bro still works on my computer (Linux Debian, Kernel 2.4.26 - Bro 0.8a87) ->I have "bad_tcp_checksum" or "bad_ip_checksum" in these (tested) cases (on 3 other computers) : 1.Bro 0.8a87, 0.8a88, 0.9a7 on Linux Debian Kernel 2.6.8 and 2.4.26, installed with the same mirrors (same versions of libpcap in particular) 2.Bro 0.8a37 (package) on FreeBSD 5.3 (Experiments were done on an operational network, but also directly between two computers with a crossover cable) If it can be of interest (I don't really know why, but...), my computer has an AMD PCnet32 ethernet controller. Bad checksums where obtained with Intel and Broadcom controllers. Hum... Any ideas are welcome... ;-) Thanks by advance, Yohann. From christian at whoop.org Mon Jan 17 08:15:59 2005 From: christian at whoop.org (Christian Kreibich) Date: Mon, 17 Jan 2005 16:15:59 +0000 Subject: [Bro] bad_tcp_checksum In-Reply-To: <41EB6A58.3070803@rd.francetelecom.com> References: <41EB6A58.3070803@rd.francetelecom.com> Message-ID: <1105978560.7595.215.camel@localhost> Hi Yohann, it looks like we should make sure it is actually a Bro problem first. When you run tcpdump on the link with -vvv and capturing entire packets, do you also see bad checksum warnings? Try to make sure the tcpdump is using the same libpcap as Bro before trying. Cheers, Christian. On Mon, 2005-01-17 at 08:33 +0100, Yohann THOMAS wrote: > Hi everybody, > > I've been using Bro on my computer on different purposes for a few > months and till now, it always worked well ;-) > Unfortunately, I'm experiencing a problem for a few days. > > In fact, when running Bro (with http.bro script) on some other > computers, I have series of "bad_tcp_checksum" (with Linux) or > "bad_ip_checksum" (with FreeBSD), and only a few packets seems to be > read correctly. > > To sum up, here is the current situation : > > ->Bro still works on my computer (Linux Debian, Kernel 2.4.26 - Bro 0.8a87) > > ->I have "bad_tcp_checksum" or "bad_ip_checksum" in these (tested) cases > (on 3 other computers) : > > 1.Bro 0.8a87, 0.8a88, 0.9a7 on Linux Debian Kernel 2.6.8 and 2.4.26, > installed with the same mirrors (same versions of libpcap in particular) > > 2.Bro 0.8a37 (package) on FreeBSD 5.3 > > (Experiments were done on an operational network, but also directly > between two computers with a crossover cable) > > If it can be of interest (I don't really know why, but...), my computer > has an > AMD PCnet32 ethernet controller. Bad checksums where obtained with Intel > and > Broadcom controllers. > > Hum... Any ideas are welcome... ;-) > > Thanks by advance, > > Yohann. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From yohann.thomas at rd.francetelecom.com Mon Jan 17 10:05:12 2005 From: yohann.thomas at rd.francetelecom.com (Yohann THOMAS) Date: Mon, 17 Jan 2005 19:05:12 +0100 Subject: [Bro] bad_tcp_checksum In-Reply-To: <1105978560.7595.215.camel@localhost> References: <41EB6A58.3070803@rd.francetelecom.com> <1105978560.7595.215.camel@localhost> Message-ID: <41EBFE58.20103@rd.francetelecom.com> Here are the last results of my investigation ;-) : -I confirm the bad tcp checksums when capturing with tcpdump, and I confirm that there is no bad tcp checksum with the computer on which Bro works correctly (using in both cases libpcap-0.8.3-5, which is the same as Bro), -Bro works offline for all the tested computers with a correct dump, -Considering It "could" be due to the ethernet controller (strange, but...), I tried another one. In fact, my old computer had a PCnet32, so I tried this one on the other computer. Result : it works !!! So, it first seems to confirm the problem isn't due to a conflict between software versions. Hum...In fact, I remember that I had Bro work very well with 3Com and Realtek chips, and also Intel e100... ...and suddenly, I come to the fact that the 2 computers on which I have bad tcp checksums have gigabit ethernet controllers... Note that one is really used in a gigabit network, but the other one is on a 100Mbps network, so it is automatically restricted at 100Mbps. So, my question is : Can the problem be due to the gigabit interfaces (even if one is used at a 100Mbps speed) ??? (Initialization problem ??? ...) Yohann. Christian Kreibich wrote: >Hi Yohann, > >it looks like we should make sure it is actually a Bro problem first. >When you run tcpdump on the link with -vvv and capturing entire packets, >do you also see bad checksum warnings? Try to make sure the tcpdump is >using the same libpcap as Bro before trying. > >Cheers, >Christian. > >On Mon, 2005-01-17 at 08:33 +0100, Yohann THOMAS wrote: > > >>Hi everybody, >> >>I've been using Bro on my computer on different purposes for a few >>months and till now, it always worked well ;-) >>Unfortunately, I'm experiencing a problem for a few days. >> >>In fact, when running Bro (with http.bro script) on some other >>computers, I have series of "bad_tcp_checksum" (with Linux) or >>"bad_ip_checksum" (with FreeBSD), and only a few packets seems to be >>read correctly. >> >>To sum up, here is the current situation : >> >>->Bro still works on my computer (Linux Debian, Kernel 2.4.26 - Bro 0.8a87) >> >>->I have "bad_tcp_checksum" or "bad_ip_checksum" in these (tested) cases >>(on 3 other computers) : >> >> 1.Bro 0.8a87, 0.8a88, 0.9a7 on Linux Debian Kernel 2.6.8 and 2.4.26, >> installed with the same mirrors (same versions of libpcap in particular) >> >> 2.Bro 0.8a37 (package) on FreeBSD 5.3 >> >>(Experiments were done on an operational network, but also directly >>between two computers with a crossover cable) >> >>If it can be of interest (I don't really know why, but...), my computer >>has an >>AMD PCnet32 ethernet controller. Bad checksums where obtained with Intel >>and >>Broadcom controllers. >> >>Hum... Any ideas are welcome... ;-) >> >>Thanks by advance, >> >>Yohann. >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20050117/2dcba508/attachment.html From kps at ucsb.edu Mon Jan 17 11:22:22 2005 From: kps at ucsb.edu (Kevin Schmidt) Date: Mon, 17 Jan 2005 11:22:22 -0800 Subject: [Bro] bad_tcp_checksum In-Reply-To: <41EBFE58.20103@rd.francetelecom.com> References: <41EB6A58.3070803@rd.francetelecom.com> <1105978560.7595.215.camel@localhost> <41EBFE58.20103@rd.francetelecom.com> Message-ID: <200501171122.23237.kps@ucsb.edu> On Monday 17 January 2005 10:05 am, you wrote: > -I confirm the bad tcp checksums when capturing with tcpdump ... > >> 2.Bro 0.8a37 (package) on FreeBSD 5.3 Just FWIW, I'm running a FreeBSD 5.3 GENERIC kernel on a Dell and have bad checksums with tcpdump using an nge interface. I don't have a solution (haven't really looked), but I thought I'd send a "me too" note to confirm you're not the only one who has seen this behavior. I'm not running bro on the 5.3 box so the checksum problem hasn't bothered me too much. The nge interface is gig-capable but runs at 100Mb as you describe. I've also noticed an apparent correlation between tcpdumps and panic reboots. Since it appears the problem exists across interface types (i.e. drivers), I wonder if it's a problem between libpcap and the drivers. -- Kevin Schmidt Campus Network Programmer Office of Information Technology University of California, Santa Barbara North Hall 2124 Santa Barbara, CA 93106-3201 805-893-7779 805-893-5051 FAX kps at ucsb.edu From goeldich at ee.ethz.ch Tue Jan 18 02:34:46 2005 From: goeldich at ee.ethz.ch (Christoph =?iso-8859-1?b?R/ZsZGk=?=) Date: Tue, 18 Jan 2005 10:34:46 +0000 Subject: [Bro] ltermcap Message-ID: <1106044486.41ece646d58e7@email.ee.ethz.ch> hi why does bro need the termcap library? i thougth that there isn't a console or something like that. greetz christoph From christian at whoop.org Tue Jan 18 03:39:42 2005 From: christian at whoop.org (Christian Kreibich) Date: Tue, 18 Jan 2005 11:39:42 +0000 Subject: [Bro] ltermcap In-Reply-To: <1106044486.41ece646d58e7@email.ee.ethz.ch> References: <1106044486.41ece646d58e7@email.ee.ethz.ch> Message-ID: <1106048382.7595.241.camel@localhost> Hi Christoph, On Tue, 2005-01-18 at 10:34 +0000, Christoph G?ldi wrote: > hi > > why does bro need the termcap library? > i thougth that there isn't a console or something like that. you can use it interactively as well: http://www.bro-ids.org/Bro-reference-manual/Using-Bro-interactively.html Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From goeldich at ee.ethz.ch Tue Jan 18 04:48:54 2005 From: goeldich at ee.ethz.ch (Christoph =?iso-8859-1?b?R/ZsZGk=?=) Date: Tue, 18 Jan 2005 12:48:54 +0000 Subject: [Bro] ltermcap In-Reply-To: <1106048382.7595.241.camel@localhost> References: <1106044486.41ece646d58e7@email.ee.ethz.ch> <1106048382.7595.241.camel@localhost> Message-ID: <1106052534.41ed05b62dd4a@email.ee.ethz.ch> yes, i know. but is this the reason why bro uses the termcap library? btw: the interactive mode doesn't work fine for me on linux... thanx anyway christoph Zitat von Christian Kreibich : > Hi Christoph, > > On Tue, 2005-01-18 at 10:34 +0000, Christoph G?ldi wrote: > > hi > > > > why does bro need the termcap library? > > i thougth that there isn't a console or something like that. > > you can use it interactively as well: > > http://www.bro-ids.org/Bro-reference-manual/Using-Bro-interactively.html > > Cheers, > Christian. > -- > ________________________________________________________________________ > http://www.cl.cam.ac.uk/~cpk25 > http://www.whoop.org > > > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > From vern at icir.org Tue Jan 18 07:58:26 2005 From: vern at icir.org (Vern Paxson) Date: Tue, 18 Jan 2005 07:58:26 -0800 Subject: [Bro] ltermcap In-Reply-To: Your message of Tue, 18 Jan 2005 10:34:46 GMT. Message-ID: <200501181558.j0IFwQ1u032562@jaguar.icir.org> > why does bro need the termcap library? > i thougth that there isn't a console or something like that. For the interactive debugger, bro -d. Vern From yohann.thomas at rd.francetelecom.com Tue Jan 18 08:59:41 2005 From: yohann.thomas at rd.francetelecom.com (Yohann THOMAS) Date: Tue, 18 Jan 2005 17:59:41 +0100 Subject: [Bro] bad_tcp_checksum In-Reply-To: <200501171122.23237.kps@ucsb.edu> References: <41EB6A58.3070803@rd.francetelecom.com> <1105978560.7595.215.camel@localhost> <41EBFE58.20103@rd.francetelecom.com> <200501171122.23237.kps@ucsb.edu> Message-ID: <41ED407D.6070100@rd.francetelecom.com> Hi, The problem finally comes from the "checksum offloading" functionality on the NICs, since when disabled, we don't have any more bad checksums. In fact, checksum offloading is due to eliminate host-side checksumming overheads by performing checksum computation with hardware assist in the NIC, but apparently, it doesn't work perfectly. This functionality was not implemented on our 100Mbps cards, but it is on gig-capable ones. So, the problem is solved on FreeBSD by disabling rxcsum and txcsum options : *ifconfig /iface/ -rxcsum -txcsum* (depending on the NICs...In fact, some controllers have only txcsum functionality and others have both) With Linux, ethtool solves the problem : *ethtool -K /iface/ rx off tx off* Yohann. Kevin Schmidt wrote: >On Monday 17 January 2005 10:05 am, you wrote: > > >>-I confirm the bad tcp checksums when capturing with tcpdump >> >> >... > > >>>> 2.Bro 0.8a37 (package) on FreeBSD 5.3 >>>> >>>> > >Just FWIW, I'm running a FreeBSD 5.3 GENERIC kernel on a Dell and have bad >checksums with tcpdump using an nge interface. I don't have a solution >(haven't really looked), but I thought I'd send a "me too" note to confirm >you're not the only one who has seen this behavior. I'm not running bro on >the 5.3 box so the checksum problem hasn't bothered me too much. The nge >interface is gig-capable but runs at 100Mb as you describe. I've also >noticed an apparent correlation between tcpdumps and panic reboots. Since it >appears the problem exists across interface types (i.e. drivers), I wonder if >it's a problem between libpcap and the drivers. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20050118/b0ae9e45/attachment.html From goeldich at ee.ethz.ch Wed Jan 19 06:14:28 2005 From: goeldich at ee.ethz.ch (Christoph Goeldi) Date: Wed, 19 Jan 2005 15:14:28 +0100 Subject: [Bro] Running Bro with -r option Message-ID: <41EE6B44.4010705@ee.ethz.ch> hi i want to test the ressource consumption of bro (cpu and memory), but i have only tcpdump files with high traffic amounts. is there a possibility to run bro with the -r option and that it goes through the traffic in the tcpdump files according to the timestamps. to make it clear: i want to simulate the real ressource usage how it would occur with the traffic in the tcpdump file. thanx for any help cheers christoph From sommer at in.tum.de Wed Jan 19 06:53:32 2005 From: sommer at in.tum.de (Robin Sommer) Date: Wed, 19 Jan 2005 15:53:32 +0100 Subject: [Bro] Running Bro with -r option In-Reply-To: <41EE6B44.4010705@ee.ethz.ch> References: <41EE6B44.4010705@ee.ethz.ch> Message-ID: <20050119145332.GB30488@net.informatik.tu-muenchen.de> On Wed, Jan 19, 2005 at 15:14 +0100, Christoph Goeldi wrote: > to make it clear: i want to simulate the real ressource usage > how it would occur with the traffic in the tcpdump file. Bro's internal time is based on packet timestamps, i.e. its notion of time is the same regardless whether you're reading a live stream or a trace. In both cases Bro performs the same kind of analysis, and therefore, in general, needs the same amount of CPU and memory. There's one important point, though, that you lose with trace: the real-time behaviour. Most importantly, spikes in the processing time don't do any harm in an offline analysis but may lead to significant packet drops in real-time (and, naturally, when Bro drops packets, it sees a different input stream, and then its analysis may differ, too). If you're interested, we've also done some CPU/memory measurements and summarized them in a paper; see http://www.net.in.tum.de/~robin/papers/ccs04.pdf Robin -- Robin Sommer * Room 01.08.055 * www.net.in.tum.de TU Muenchen * Phone (089) 289-18006 * sommer at in.tum.de From cutty at nb.sympatico.ca Wed Jan 26 06:16:00 2005 From: cutty at nb.sympatico.ca (Zhu,Bin) Date: Wed, 26 Jan 2005 10:16:00 -0400 Subject: [Bro] bro-GUI Message-ID: <004501c503b1$8fb4e960$4417010a@IITFRDZHUBN0> Hello, anybody knows where I can download the GUI for Bro (BrooeryGUI)? thanks Cutty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20050126/28184bf6/attachment.html From christian.kreibich at cl.cam.ac.uk Wed Jan 26 08:52:33 2005 From: christian.kreibich at cl.cam.ac.uk (Christian Kreibich) Date: Wed, 26 Jan 2005 16:52:33 +0000 Subject: [Bro] bro-GUI In-Reply-To: <004501c503b1$8fb4e960$4417010a@IITFRDZHUBN0> References: <004501c503b1$8fb4e960$4417010a@IITFRDZHUBN0> Message-ID: <1106758353.6089.103.camel@localhost> Hi, there hasn't been a public release of the Brooery yet. I'd ask you to hold on a little longer -- we are planning to have a release ready around April that will save you a lot of headaches regarding setup & configuration. Thanks, Christian. On Wed, 2005-01-26 at 10:16 -0400, Zhu,Bin wrote: > Hello, > > anybody knows where I can download the GUI for Bro (BrooeryGUI)? > thanks > > Cutty -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From thodime_raghu at yahoo.com Mon Jan 31 10:11:51 2005 From: thodime_raghu at yahoo.com (Raghavendra Thodime) Date: Mon, 31 Jan 2005 10:11:51 -0800 (PST) Subject: [Bro] SIP Analyzer Message-ID: <20050131181151.10345.qmail@web50110.mail.yahoo.com> Can Bro capture SIP and RTP traffic irrespective of port the streams they use? If it captures does bro provides analyzers on these traffic so that I can write scripts containing different fields in the RTP Header? Thanks -Raghu __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 From vern at icir.org Mon Jan 31 12:24:17 2005 From: vern at icir.org (Vern Paxson) Date: Mon, 31 Jan 2005 12:24:17 -0800 Subject: [Bro] SIP Analyzer In-Reply-To: Your message of Mon, 31 Jan 2005 10:11:51 PST. Message-ID: <200501312024.j0VKOHri029608@jaguar.icir.org> > Can Bro capture SIP and RTP traffic irrespective of > port the streams they use? No. For one, Bro doesn't have RTP or SIP analyzers. In addition, it doesn't have the capability to analyze applications that are not running on known ports, though addressing this is on the to-do list and I believe some students are gearing up to tackle it. Vern