Actually, we're *about* to do the same thing. I posted some stuff about this to the
list earlier this week. :-)
Fortunately, we're going to be monitoring less traffic than you are (~150Mb/s
altogether), so what we decided to do was use a port mirror rather than an optical tap.
Many switches c
Or just don't run Windows. You can get a complete Pentium 4 system from
Office Depot for less than $500. Just build a Linux or BSD machine and have done with
it.
Use Windows for MS Office. :-)
--J
> -Original Message-
> From: Paul Hoffman / VPNC [mailto:[EMAIL PROTECTED]
> Sent: T
What we're doing at the moment is running a 10-file ring buffer, then running a script
to check that buffer once per minute to see if the files have rolled one or more
times. Any files that have rolled are copied and gzipped into another directory.
Catches:
1) The last packet in the file is a
Do a
'dmesg | grep promisc' and make sure the interface is actually going into
promiscuous mode. Also check the output of 'ifconfig -a'. You should
see confirmation there as well.
But
I'll bet that the problem is that the port mirror is not set up correctly, or
that the port mirror is n
Title: Message
Yes. Do something like this:
tethereal -n -a filesize:1 -b 20 -w
/your/output/files/go/here/capture.file.name -f "host or host
"
So
you'll see all traffic to AND from host "ip1" and you'll see all traffice to AND
from host "ip2". Since the traffic between these two
Yes. We have done it on both Windows and RedHat Linux 8.0. I have the RedHat box
running right now, capturing on two Intel Pro 1000 (multimode fiber) NICs using "link
bonding". I'm capturing on interface "bond0". Works like a champ.
I might point out, though, that once the NICs are bonded to
I would like to point out that the Remote Desktop Client for MacOS X will let you use
16- or 24-bit color on connections to Windows machines. This might be a way around
the Terminal Services client limitations.
--J
> -Original Message-
> From: Joerg Mayer [mailto:[EMAIL PROTECTED]
> Se
I have found a bug in the SMB dissectors. Attached is a pair of packets that crash
ethereal and tethereal when both are read. If you split them apart via editcap or
some similar means, either can be dissected separately, but both together cause
t/ethereal to seg fault. Ethereal for Windows cr
creating .libs/etherealS.c
(cd .libs && gcc -c -fno-builtin -fno-rtti -fno-exceptions "etherealS.c")
rm -f .libs/etherealS.c .libs/ethereal.nm .libs/ethereal.nmS .libs/ethereal.nmT
gcc -DINET6 "-D_U_=__attribute__((unused))" -Wall -W -g -O2 -I/usr/local/include
-I/usr/include/gtk-1.2 -I/usr/includ
Ethereal is not actually hung. Just very, very slow. If you run a caching name
server somewhere locally, you might be able to make this much faster, or as you say,
you can turn off DNS resolution and work around the problem.
Either one will work well. If you go for the workaround, but you sti
If you can get your capture filter set correctly, you could just write a script that
does something like this:
WatchForTCN.pl
#!/usr/bin/perl
# Start the capture and put it in the background.
system("/usr/bin/tethereal -n -w capture.file.pcap (ring buffer args) 1>/dev/null
2>/dev/null
> On some platforms (Linux) Ethereal can capture from the
> virtual ALL device which makes it capture from all network devices.
Yup. I've seen that before (and I'm using Linux), which is what made me think perhaps
I just hadn't figured out a way to capture from only two.
> There is no support
Okay, here's a new twist:
To properly capture on a gigabit fiber connection, one uses a fiber tap, which slices
off some of the optical signal and redirects it. This means that you have to tap two
physical fibers (RX and TX), each of which must be connected to the RX connector on a
separate NI
> I understand your requirement and it sounds like a great
> utility. Many a
> time I've been stuck in a testbed with a large trace file and
> a stack of
> floppies, and I spend far too much time fluffing about with
> WinZip. Short
> of adding new features to editcap.c (which isn't too
> insur
> >Again, editcap only gives a single segment. It does not
> break up the file
> into many arbitrary-sized or -length chunks. See 'man
> >split' for a text
> version of what I'm talking about.
>
> 1, Loop oer the huge capture with editcap
That has been suggested, but this is quite inefficient
> Here's my perl code to do the split. It's tested on a
> smallish trace file,
> although I can't guarantee it's efficiency when re-reading a 2GB file
> multiple times.
Yes, editcap is inefficient that way, but the code is sound. Thanks!
[code snipped]
We do indeed need something more like the
> > > 1) I have a 2GB capture file that I need to split. I don't
> > > particularly care if it's split into chunks of NN packets or
> > > files of some size, but I certainly can't analyze the file as
> > > it is. Second best would be a suggestion for an algorithm I
> > > could implement in Perl
1) I have a 2GB capture file that I need to split. I don't particularly care if it's
split into chunks of NN packets or files of some size, but I certainly can't analyze
the file as it is. Second best would be a suggestion for an algorithm I could
implement in Perl that would allow me to use
Actually, it isn't in this case, because a dial-up connection is not a
MAC-based network. In other words, the modem doesn't have a MAC
address. Only IEEE 802 networks (Ethernet, Token Ring, some wireless) have
MAC addresses.
What I
used to do in this case was I added a script to the end
Hey all,
I've got this telnet packet that makes ethereal (and tethereal) hang when trying to
decode it. Thanks to editcap, I was able to show that it is this packet and only this
packet that is creating the problem (attached).
Thoughts?
Here is what tcpdump thinks of it (rather long):
[EMAI
20 matches
Mail list logo
