Re: Interface promiscuity obscurity in Linux

[Frédéric Raynal <frederic.raynal () inria fr>]

        Hello,

This is a well knwon issue and C. Grenier and I have understood why
very recently. In fact, this due to the changing of the handling of 
promiscuous mode in kernel space.

With kernel 2.0, one had to perform the following to set the interface
to promiscuous mode:
  
  strncpy(ifr.ifr_name, "eth0", IFNAMSIZ);
  ioctl(sock, SIOCGIFFLAGS, &ifr);
  ifr.ifr_flags |= IFF_PROMISC;
  ioctl(sock, SIOCSIFFLAGS, &ifr);

The trouble was that the promiscuous mode was handled by a flag.  Each
time a process sets this mode, the flag is set. But if another process
removes this mode, the flag is cleared. Rather bad behavior.

Since kernel 2.2, a processus must ask to enter in a membership of
process (setsockopt(..., PACKET_ADD_MEMBERSHIP,...)) using the
interface in promiscuous mode. A counter is then increased. One a
process of the membership does not need the promiscuous mode anymore,
it drops the membership (setsockopt(..., PACKET_DROP_MEMBERSHIP, ...))
the counter is decreased, and promiscuous mode is disabled as soon as
the counter is 0. 

  struct packet_mreq mr;
  ...
  memset(&mr,0,sizeof(mr));
  mr.mr_ifindex = ifr.ifr_ifindex;
  mr.mr_type =  PACKET_MR_PROMISC;
  setsockopt(sock, SOL_PACKET, PACKET_ADD_MEMBERSHIP, (char *)&mr, sizeof(mr));



The call to ioctl(SIOCGIFFLAGS) reports only promiscuous mode sets by
ioctl(SIOCSIFFLAGS).


--
Frederic RAYNAL, Ph.D.
http://minimum.inria.fr/~raynal
Chief Editor of M.I.S.C.
Multi-Systems & Internet Security Cookbook



On Thu, Jul 25, 2002 at 12:20:19AM +0400, Ricardo Branco wrote:
> This affects Linux 2.2 and 2.4
>
> Using libpcap to put the interface in promiscuous mode, will cause that
> ifconfig(8) doesn't show it!
>
> libpcap uses setsockopt(..., SOL_PACKET, PACKET_ADD_MEMBERSHIP, ...) with
> PACKET_MR_PROMISC to set the interface in promiscuous mode.
>
> I notified this to the tcpdump-workers mailing list and the problem is
> that the setsockopt() sets the promisc flag in a variable that is not the
> same as the one that the SIOCGIFFLAGS ioctl() reads. I don't have the
> kernel source right now to make this advisory more precise.
>
> Well, sorry for my not-so-good english
> Enjoy