On Aug 26, 2004, at 3:43 PM, Chris Reining wrote:
I am running into an interesting promiscuous mode issue on Redhat
Enterprise WS 3, kernel version 2.4.21, libpcap version 0.7.2 and
tcpdump 3.7.2. The issue is unanticipated toggling of promisc state. I
am running Snort version 2.1.2 which itself sets promisc first on the
interface in question and may be a catalyst for the issue or a red
herring.
So, in a default state we have the interface in PROMISC as set by
Snort. I am using 'ip link show eth0' as ifconfig does not show the
PROMISC flag yet:
*Which* PROMISC flag? I think Linux has both a flag you can set with
ifconfig and an internal PROMISC flag.
Libpcap, when built on a system on which PF_PACKET isn't defined even
if you include all of sys/socket.h, sys/ioctl.h, net/if.h,
netinet/in.h, linux/if_ether.h, and net/if_arp.h (it's probably defined
by sys/socket.h) *or* on which PACKET_HOST isn't defined if you include
all of them *and* linux/if_packet.h, or when run on a socket without
PF_PACKET sockets but with PF_INET/SOCK_PACKET sockets, will use the
flag you can set with ifconfig, as it assumes that the newer
mechanism for setting the flag doesn't exist.
2.2 and later kernels should, I think, not have PF_INET/SOCK_PACKET
sockets if they don't have PF_PACKET sockets, so that's probably not
the problem. Systems with 2.2 and later kernels *probably* have
headers that'll cause PF_PACKET and PACKET_HOST to be defined.
With PF_PACKET sockets, the mechanism libpcap uses to turn promiscuous
mode on and off is setsockopt() calls at level SOL_PACKET, using the
PACKET_ADD_MEMBERSHIP option to set the mode to PACKET_MR_PROMISC or
PACKET_MR_ALLMULTI. I don't know what the semantics of that are. (I'd
have to look at the Linux kernel source once again.) It might be that
the interface is put into promiscuous mode if at least one socket with
PACKET_MR_PROMISC is open, or it might be that it just remembers the
*last* request.
Now, if Snort and tcpdump are running with the same version of libpcap,
they use the same mechanism, so it shouldn't matter whether you're
running two Snorts, two tcpdumps, or a tcpdump and a Snort. If they're
running with different versions of libpcap, they *might* be using
different mechanisms.
WS 3 is probably new enough that libpcap will be using the new
mechanism.
If the interface is already in promisc mode, as Snort has set it, why
is tcpdump turning that off?
Probably a kernel bug (or a wacky, but deliberate, notion of how
PACKET_ADD_MEMBERSHIP should work).
Why when running multiple, and the same, tcpdumps does the promisc
flag get flipped back and forth in relation to how many tcpdumps are
running?
See answer to previous question.
Overall, shouldn't tcpdump (without -p) check if the interface is in
promisc mode already (as Snort has set it or another tcpdump) and if
so, not toggle that setting?
Tcpdump should call pcap_open_live() with the the promisc flag
being 1 if it's run without -p and 0 if it's run with -p. That's
all it should do with the promiscuous flag.
Any stuff done to the interface's promiscuous flag should be done by
*libpcap*, not tcpdump; otherwise, you have
1) crufty code in tcpdump
and
2) applications *other* than tcpdump possibly exhibiting the same
behavior.
However, this might ultimately be a bug in the kernel networking code.
Unfortunately, I can not reproduce this behavior all the time. In some
cases running 'tcpdump -i eth0 -nn' on an already promisc interface
does not toggle promisc off. That is the behavior that I am familier
with and expect. Any insight much appreciated.
I'd suggest
1) using the standard tcpdump that comes with WS 3 (which you might
already be doing);
2) reporting this as a bug to Red Hat.
Either
1) the kernel has a bug in the way PACKET_ADD_MEMBERSHIP is
implemented, in which case it should get fixed
or
2) libpcap isn't using PACKET_ADD_MEMBERSHIP correctly, in which case
*it* should be fixed (and if RH fixes it, they should send us the fixes
so they can go into a future release of libpcap). (Oh, and they should
update the packet(7) man page to make it clearer how that stuff is
supposed to work.)
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
