> > > Since the version 0.7.8 I�m trying to get it run on my PC, but the
> > > program always hangs, and I don�t know why. I applied all patches
> > > (newest GTK+, patch for libpcap) and still the program freezes when I go
> > > to capture and press start.
> >
> > What OS are you using? (If it's a Linux distribution, what
> > distribution, and what kernel if you're not using the kernel that comes
> > with the distribution?)
>
> Thx for the fast answer,
>
> I�m using Redhat 6.1 (Cartman) with the 2.2.13 Kernel.
> Further I use:
> gtk+ 1.2.5-2
> gtk+ devel 1.2.5-2
> libpcap 0.4-16 (downloaded from ethereal page)
> ethereal 0.8
Freezes as in "doesn't respond to mouse or keyboard events, and doesn't
update", or freezes as in "it responds to input, but no packets show up
even though there are packets coming in and going out"?
Some people have reported that the libpcap patch fixes the first
problem, but not all of them then see captured packets show up, and I
think we have seen other reports of the hangs persisting even after
libpcap was patched, so I'm not sure what's going on.
Developers:
I'm on the verge of saying "let's stop working around this" and looking
into
grabbing the raw file descriptor from the "pcap_t" I get back
from "pcap_open_live()", and adding it to the list of sockets
on which the GTK+/GLib main loop selects (on Linux and IRIX it's
a socket so "select()" and/or "poll()" should work, on Solaris
and HP-UX and perhaps eventually AIX it's a DLPI STREAMS file
descriptor so "poll()" and hopefully "select()" should work, on
*BSD* it's a "/dev/bpf" device but Berkeley *invented*
"select()" so it should work);
make that file descriptor non-blocking (see previous comments,
except that AT&T invented non-blocking FDs, but hopefully I'm
not misreading the test for IO_NDELAY in FreeBSD 3.3's
"bpfread()" and it supports non-blocking I/O, and hopefully that
wasn't added by the FreeBSD folk);
having Ethereal just block in the main loop while a capture is
going on, and have it read from that FD if it's readable;
so that we no longer depend on the timeout argument to
"pcap_open_live()" actually arranging that it return every .25 seconds
even if no packets have arrived, and thus no longer depend on "libpcap"
being patched.
Of course, the patch to libpcap may not be what's causing the "it
doesn't hang, but it doesn't see any packets, either" problem, so it may
not get rid of *all* our Linux problems. (Sigh, packet capture
mechanisms are such a pain; I'm not sure we've seen any *yet* with BPF
on BSD, and I think we've had only one report of a Solaris problem, but
HP-UX has some minor irritations - for which I think I have a "libpcap"
fix, and for which 0.8.0's not giving up if it can't open any of the
interfaces it found with SIOCGIFCONF at least renders it usable - and
IRIX has a minor irritation, and AIX has more-than-minor irritations,
and Linux has irritations....)
I just hope doing so doesn't break packet capture on Windows; it looks
as if the Win32 GTK+ port is at least intended to allow you to use
"gtk_input_add_full()" - it'll use "MsgWaitForMultipleObjects()", which,
if I remember correctly, waits either for a window-system message for
for a file descriptor^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hhandle to be ready
for I/O.
One possibly-nice side-effect is that we might then be able to avoid one
copy when doing an "Update list of packets in real time" capture - we
could perhaps do the initial dissection on the packet we read into
memory from the OS's capture mechanism, and then write it out, rather
than writing it out in a subprocess and reading it back in from the main
process.
Anybody have any comments, either pro or con?