> Which libc are you using?
Whichever one comes with RH 6.0 - it's not my machine, it's an
engineering compute server, with a standard installation, not some
exotic installed-from-hand-assembled-pieces system.
> Did you bug "\pipe\lanman response?"
Yes.
> If you're making a trace file, would it be a reasonable idea to decouple
> the tracing from the GUI -- I hate running GUI applications setuid root.
"Decouple" in what sense? One could, I guess, have a separate program
doing the capture, along the lines of what's done in "Update list of
packets in real time" mode (although the program it forks and execs is
just Ethereal itself), but do that in both "Update list of packets in
real time" mode and in non-live mode, although one would then have to
have the GUI program send a message or a signal to the other program to
get it to stop, rather than having the process doing the capturing pop
up the monitoring window as is done now.
> Also, it sometimes isn't very responsive...
Splitting it may or may not make a difference here, though.
Part of the problem is that we currently just use the "pcap_dispatch()"
mechanism to do the capturing, rather than using "pcap_fileno()" to get
the raw file descriptor for the live capture stream, adding that to the
list of FDs on which the GTK+ main loop should select, and use
"pcap_dispatch()" with a count of 1 to read a single packet if that FD
is ready.
This means we have to stick a timeout into the "pcap_open_live()" call,
so that, instead of waiting forever for a packet to arrive, it quits
after a while so we run the GTK+ main loop code to check for window
system input events.
The problems with this are
1) it may delay response to input events by the timeout (1/4
second)
and
2) on platforms where the timeout doesn't actually work - for
example, Linux systems where "libpcap" hasn't been patched
with the patch at
http://ethereal.zing.org/~gerald/libpcap-0.4-guy-gerald.patch
response to input events is delayed until a packet arrives.
Splitting it might simplify the process of adding a file descriptor for
incoming packets to GTK+'s list, and might help on a multiprocessor
system (as would multiple threads *if* the kernel knows about threads on
the platform you're on), but could conceivably slow stuff down on a
uniprocessor system (more context switches, blah blah blah).
