Re: undesired promiscuous mode toggling

[Guy Harris <guy () alum mit edu>]

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.