lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.21.1808260323310.26500@localhost.localdomain>
Date:   Sun, 26 Aug 2018 03:39:15 -0400 (EDT)
From:   "Robert P. J. Day" <rpjday@...shcourse.ca>
To:     Linux kernel netdev mailing list <netdev@...r.kernel.org>
Subject: want to clarify understanding of IFF_{UP,RUNNING} and "volatile"


  if you can tolerate another question on the topic, based on an
earlier post by stephen hemminger, i wrote a userspace program that
opened a netlink socket to track the status changes for an interface,
and i just want to clarify how the up/running status of an interface
is determined, as i think i'm finally getting the hang of this.

  as stephen mentioned, ifconfig gets its info (ultimately) from
dev_get_flags() in net/core/dev.c:

  unsigned int dev_get_flags(const struct net_device *dev)
  {
        unsigned int flags;

        flags = (dev->flags & ~(IFF_PROMISC |
                                IFF_ALLMULTI |
                                IFF_RUNNING |
                                IFF_LOWER_UP |
                                IFF_DORMANT)) |
                (dev->gflags & (IFF_PROMISC |
                                IFF_ALLMULTI));

        if (netif_running(dev)) {
                if (netif_oper_up(dev))
                        flags |= IFF_RUNNING;
                if (netif_carrier_ok(dev))
                        flags |= IFF_LOWER_UP;
                if (netif_dormant(dev))
                        flags |= IFF_DORMANT;
        }

        return flags;
  }

i don't care (yet) about IFF_{PROMISC,ALLMULTI} so i'll ignore those.

  so, as i read it, whether or not the interface is *administratively*
up is read directly from the IFF_UP bit in dev->flags. so far, so
good. on the other hand, all of IFF_{RUNNING,LOWER_UP,DORMANT} are not
read from dev->flags, but instead are "volatile" and are determined
via those function calls.

  so i'm guessing that shows the difference between the
administrative and the operational states of an interface -- the
administrative state of "up" is something selected by, say, ifconfig,
and can therefore be stored in the flags field, while the operational
state (running) is volatile and must be determined at each query.

  this suggests that volatile flags such as running or dormant have no
value if read from dev->flags -- the code above doesn't even look at
them in that location and instead invokes the respective functions. do
i have that about right, before i crawl further down this rabbit hole?

  it's all starting to make sense.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                  http://crashcourse.ca/dokuwiki

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ