> And in fact, when I checked on my Linux system, my eth0 was indeed
> in promiscuous mode when it should not have been. After clearing
> promiscuous mode, I was not able to reproduce the case where Ethereal/
> libpcap leaves the interface in promiscuous mode after exiting. I'm
> sure it will happen; I just won't notice it.
>
> I'm not sure what the "additional libpcap bugs" might be.
I was probably the one who put that note in; much of the full sad story
can be found on a thread in "tcpdump-workers" (the mailing list is
archived on the "www.tcpdump.org" Web site) with the title "Another
linux libpcap botch", but the underlying problem is:
The SOCK_PACKET mechanism, which was the only raw packet capture
mechanism in standard 2.0[.x] kernels, and which is the only raw
packet capture mechanism vanilla libpcap uses, doesn't count
requests to go into promiscuous mode, so the kernel has no clue
when promiscuous mode should be on or off *and*, unless
user-mode code maintains shared state amongst all users of a
given interface, it has no clue, either.
The current Linux libpcap just registers an "atexit()" routine,
which opens a SOCK_PACKET socket, and does an SIOCSIFFLAGS to
set the interface flags to the saved value.
However, the saved value is saved *every time* you open a
capture stream in promiscuous mode; given that libpcap doesn't
turn promiscuous mode off in "pcap_close()" - which,
unfortunately, is in "pcap.c" which is platform-*independent*
code, so one would have to throw a hook in there to call
platform-specific code to turn promiscuous mode off - that means
that the first promiscuous capture will leave the interface in
promiscuous mode when it completes, so when you start a *second*
promiscuous-mode capture in the same program, the flags it saves
have the promiscuous-mode flag on, so that when the program
exits, it "restores" the state as of the beginning of the second
capture, and leaves promiscuous mode on.
This means that:
> However, it
> seems more logical to me that libpcap should turn of promiscous mode
> in the pcap_close() call, not by registering a function with atexit()
> like it currently does.
is 150% correct - that'd make it work better (although it'd still have a
problem if you have more than one application turning promiscuous mode
on and off, but, absent shared state between processes, there's nothing
it can do about that; the fix for 2.2 and later is to stop using
SOCK_PACKET and use PF_PACKET/SOCK_RAW sockets instead, as they *do*
have reference-counting of promiscuous mode requests).
> But I suppose the writers of libpcap always
> assumed tcpdump-like usage... a one-shot sniff of the network instead of
> a long-running GUI.
libpcap was originally just the low-level live-capture and
capture-file-reading code lifted from the tcpdump source (tcpdump
antedated libpcap), so, yes, that's probably what happened, in effect.
