> One of those is the RH6.1 pcap "feature", as you call it :-), but
> I've still haven't understood what exactly you did to work around
> it, and I don't even know whether it would apply, since I'm giving
> gdk a file descriptor to listen to and I think you use a
> different technique.
Well, the main RH 6.1 libpcap "feature" we've had to work around is the
fact that its capture files have the standard libpcap magic number but
are *not* standard libpcap files - the code has to look at the file to
see if it's normal or not.
However, etherape doesn't read capture files (there's no call to
"pcap_open_offline()") so that particular problem isn't an issue for
etherape.
There's a *generic* issue with libpcap on Linux (and, I suspect, on some
other platforms as well) - the "to_ms" argument to "pcap_open_live()" is
ignored on many platforms, so programs that expect a "pcap_dispatch()"
to return in "to_ms" milliseconds, regardless of whether any packets
arrive in that time interval, won't work.
We have a patch to libpcap to make it implement the "to_ms" argument on
Linux with a "select()"; that patch doesn't apply to RH 6.1, but we have
a version of the RH 6.1 libpcap that has a variant of that patch applied
to it.
*However*, it looks as if etherape shouldn't depend on a
"pcap_dispatch()" timing out! As you note, you add the file descriptor
for the capture to GDK's list of input sources; that should cause the
main loop to do a "select()" (or "poll()") that includes that file
descriptor *as well as* the connection to the X server, and it should
only call etherape's "packet_read()" routine if that file descriptor is
ready to read, so "packet_read()" shouldn't block in "pcap_next()".
The bug note for bug 102377, which appears to be the bug in question,
says:
Summary:
Nothing shows up in the window.
Does that mean that the etherape window shows up blank, without
*anything* drawn in it (no menu bar, for example), and doesn't respond
to mouse or keyboard input?
If so, that could mean that the program is blocked doing something other
than waiting in the main loop, which *could* be due to it being blocked
in "pcap_next()"; you might try running it under "strace", and see where
it blocks when it's in that state.
> So here is my call for advise, and an invitation to developers
> to have a look at etherape. I could really use some help. :-)
I would, but I don't yet have the GNOME libraries installed on my
home machine, so "configure" just dies fairly quickly.
I *suspect* it'll never see any traffic on my home machine's
most-commonly-used partition (the FreeBSD 3.x partition), as,
unfortunately, "select()" doesn't work on BSD "/dev/bpf" devices when
they're used the way libpcap uses them, sigh (and fixing that would
require kernel changes, so etherape would have problems depending on
that - I also suspect other OSes that implement the timer that "to_ms"
uses as a timer that starts when a read is first done would have the
same problem).