Chris Alton wrote:
Is there anyway to have ethereal or tethereal run as a windows service
when the computer starts up?
Can a Windows service run with a GUI? If not, then there's no way to
have Ethereal run as a service, as it's a GUI-based application.
Can a command-line program be conveniently "wrapped" in some program or
script to make it run as a Windows service? If so, Tethereal could
conceivably be so wrapped.
However...
It would be a lot easier on me to have it
do that than to have to restart it everytime I reboot the computer.
...that raises the question of how you'd *control* this service.
What is it you want to capture with this service? Do you want to have
something running continuously on your machine, logging *all* traffic on
some particular interface to a file? (There's no provision in WinPcap
for capturing simultaneously on all interfaces - i.e., just as most
other UN*Xes don't support the "any" device that's supported on Linux,
Windows doesn't support it, either, as there's nothing in the OS's
networking code to handle that; the "any" device exists in Linux because
you can have a PF_PACKET socket not bound to a device, that therefore
receives traffic from all adapters, but other packet capture/networking
mechanisms require that you bind to a particular device.)
If so, you don't need to control the service. If not, though, you'd
need some way to control it.
If it can't run as a windows service can somebody point me to a sniffer
than can sniff packets and log it to a file that can be viewed by ethereal?
I don't know of one (tcpdump/WinDump would have the same limitations as
Tethereal in this case, so either you could wrap it or you couldn't).
Another question. Is it possible to use ethereal to view a packet
capture file that is being written to at the same time? i.e.: Like when
ethereal is capturing packets and displays them in real time.
Not in that fashion. There are two special things that happen in that mode:
the process writing to the capture file will, after processing each
batch of packets, "sync out" buffered data so it gets written to the
file (rather than having it buffered in its address space);
that process also sends over a control pipe messages to the process
reading the capture file, for each batch of packets, indicating how many
of the packets were in the batch, so it knows how many packets to read.
That mechanism is specialized to the "Update list of packets in real
time" process; it hasn't been exported to other programs. It might be
possible to do that, but it might also be a non-trivial undertaking.
