> I have set Tethereal up as a service under win2000 and am executing it with
> the -w option to dump data to a file and with the -R option to regulate
> what to dump. My constraints are pretty tight, looking for just a single
> type of traffic so I'm spitting out very little data to the file. However,
> the file doesn't seem to be getting updated in real time. As a matter of
> fact, It's not very consistent as to when it dumps data to the file. The
> constraint I am using is limiting output to AIM traffic. Any clue as to
> when Tethereal writes to the file (is it time based, amount of dat based,
> based on data received from AIM or random)?
Tethereal, like tcpdump/WinDump and Ethereal and various other
packet-capture programs, uses routines from the libpcap/WinPcap library
to do packet capture.
Those routines, in turn, use a packet capture mechanism in the OS on
which they're running or, in the case of Windows, a packet capture
mechanism added to the OS (running atop other OS mechanisms).
That packet capture mechanism, on many OSes, "buffers" packets
internally to code running in kernel mode, rather than immediately
supplying them to code running in user mode, so that, instead of each
packet being delivered in response to a "system call" from user mode to
kernel mode, multiple packets are delivered; this is done to reduce the
system call overhead, and the number of process wakeups, per packet.
The way this works is that there's a buffer in the kernel-mode code, and
a timeout specified by the user-mode code. As packets arrive and pass
whatever packet filter is in the kernel (note, by the way, that "-R"
does *NOT* set up a packet filter in the kernel), they are put into that
buffer; when the buffer fills, or when the timeout expires, the packets
are supplied to user-mode code.
The meaning of the timeout differs between platforms; on some platforms,
the timer starts as soon as the user-mode code tries to read packets,
and, on other platforms (Solaris, for example), the timer starts as soon
as the first packet arrives.
In either case, this means that, on platforms with this buffering
mechanism, packets are *not* delivered to the user-mode code the instant
they arrive - there may be a delay. The maximum delay (if you ignore
any delay between the time the process is woken up and the time that it
runs) is the timeout specified to libpcap.
That timeout is 1 second in both tcpdump/WinDump and Tethereal.
The timeout is not settable, it's hardwired in. Furthermore, there is
no value to which it can be set that will, on all platforms, arrange
that packets be delivered immediately to the user-mode code.
At least on Windows NT (including Windows NT 5.0, which Microsoft
marketing decided to call "Windows 2000"), it is possible to put the
capture mechanism into a mode where packets are delivered immediately;
libpcap/WinPcap would have to be modified to add an API to set this
mode, and the different implementations of that API on different
platforms would do what is appropriate on the platforms in question
(nothing, on platforms with no buffering; a BIOCIMMEDIATE ioctl, on BSD;
a call to PacketSetMinToCopy, on Win32 with WinPcap; an SBIOCSTIME with
a timeout of 0, on Solaris; etc.).
> Is there any way to change it so that data is spit out real time?
One could modify WinPcap and Tethereal to do so. That may happen at
some point, but it's almost certainly not going to happen soon.