> By default interfaces are not set to capture traffic "sent/received by the
> kernel-resident protocol software [for example, IP, ARP, DECnet, LAT] on
> this host" (from pfconfig manpage).
...which makes packet filters useless, by default, on the loopback
device.
> Are you sure to have set
> "copy-all" mode of your loopback interface via the pfconfig +copyall lo0
> command?
Setting that fixed it.
I checked into the libpcap source tree a "README.tru64" that discusses
"pfconfig".
If an attempt to set ENCOPYALL fails, libpcap doesn't treat that as an
error, and doesn't even report the problem by printing a warning to the
console.
Printing to the console isn't perfect, as it doesn't help for, say, GUI
applications, but it's arguably better than nothing (and libpcap already
logs a message to the console saying whether it's using a BPF filter in
the kernel or doing the filtering in userland), so perhaps it should log
such a warning.
Ideally, "pcap_open_live()" should be able to return warnings; *IF*
all versions had always cleared the error message buffer before
returning successfully, we could have the convention be "if the error
message buffer isn't an empty string, the open succeeded, more or less,
but with some problems", but libpcap doesn't currently clear the buffer,
so....
We could, instead, add a "pcap_getwarning()" call; you call it
immediately after a "pcap_open_live()" and, if it returns a non-null
pointer, it points to a string that lists at least one of the problems
"pcap_open_found()" when opening the device. (This could also be used
for attempts to open the Linux "any" device in promiscuous mode.)
Applications would presumably have to check for the presence of
"pcap_getwarning()" in their configure script, and use it only if
HAVE_PCAP_GETWARNING is defined, if they're to work with all versions of
libpcap.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
