All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Radek Vokál" <rvokal@redhat.com>
To: lartc@vger.kernel.org
Subject: [LARTC] no PROMISC mode ..
Date: Wed, 02 Aug 2006 13:15:00 +0000	[thread overview]
Message-ID: <44D0A554.1000300@redhat.com> (raw)

Hi,

I'm not convinced I'm facing a bug, I was reading some code and
also reading some threads and finally reached this conclusion, please 
let me know if it's not clear enough and also if you don't agree :
    - The case it shows the flag with iproute is
because it's using a single flag set.
      That was working on kernels linux <2.1.x. (2.0 etc.)
      Basically the mechanism was :
             ---
               strncpy(ifr.ifr_name, our_device, IFNAMSIZ);
               ioctl(sock, SIOCGIFFLAGS, &ifr);
               ifr.ifr_flags |= IFF_PROMISC;
               ioctl(sock, SIOCSIFFLAGS, &ifr);
            ---
      And only one could set the IFF_PROMISC, because if another process
decided to set it too, then it was cleared...
   - Now, with kernels 2.2 and onwards, we have a different 
implementation of it, there's a counter of how many promiscuous requests 
have been set, and therefore a new implementation of the code to handle 
it and remove the one promiscuous limitation, that has been called a 
membership. This allows the kernel to have more than one request and 
remove the above problem.

     Today, a process has to request to be part of that "packet domain"
and use the interface in promiscuous mode, then the counter will know if
there's another request (so it can handle unsets), and then, if the
process does not need anymore this mode, it will just request to be 
removed to that membership, decreasing the counter.

     The code nowadays is fairly close to this :
        -----
                  struct packet_mreq mr;
                  [.....]
                  memset(&amp;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));
        -----

That would explain why I can't see it with ip or older ifconfig, any 
call set by ioctl(SIOCGIFFLAGS) can only bee seen by the same call 
family. I've checked pcap, and seems to do the right thing by setting it :
       ----
       setsockopt(3, SOL_PACKET, PACKET_ADD_MEMBERSHIP,
"\\3\\0\\0\\0\\1\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0", 16) = 0
       ----
Hence I can't see it with neither ip or ifconfig.

  Is there any reason why (ip) is not using a membership check/set 
instead of using ioctl() ?


Radek
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

                 reply	other threads:[~2006-08-02 13:15 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44D0A554.1000300@redhat.com \
    --to=rvokal@redhat.com \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.