<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 05/15/2011 01:39 AM, Nathan Coulson wrote:
    <blockquote
      cite="mid:BANLkTinEFEL=h0OBTJcjtBUg2UCF5cibpw@mail.gmail.com"
      type="cite"><br>
      <br>
      <div class="gmail_quote">On Sat, May 14, 2011 at 9:36 PM, DJ Lucas
        <span dir="ltr"><<a moz-do-not-send="true"
            href="mailto:dj@linuxfromscratch.org">dj@linuxfromscratch.org</a>></span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <div class="im">On 05/14/2011 04:37 PM, DJ Lucas wrote:<br>
            > Everything is covered per this conversation in SVN with
            the exception of<br>
            > accounting for missing /run in LightCube OS, but I
            think it was decided<br>
            > that it would be added. Also no ip flush (I forgot, but
            will get it in a<br>
            > day or two) on down interface, and dhcp calls not
            accounted for.<br>
          </div>
          I'll need to setup both DHCP clients to test functionality for
          this,<br>
          which is why I didn't just do it tonight. The problem I want
          to avoid is<br>
          if we do a flush, but the client daemon is still running, come<br>
          expiration, the client daemon might try to reconfigure the
          device...even<br>
          if it means adding dhcp logic in the lfs scripts (or replacing
          them in<br>
          BLFS). Also, is anyone still using RP for PPPoE, alos simple
          ppp, that<br>
          is willing to test? I unfortunately no longer have a ?DSL
          circuit to<br>
          test with so I'll need some help from somebody who does. I
          would think<br>
          if the link is set down the client daemons for the dhcp
          clients would<br>
          exit, but would ppp attempt to reconnect? I'm also thinking
          that the<br>
          added functionality for ifdown can be done in a modular way in<br>
          /lib/network-services so that it can be divvied up for each
          who needs it.<br>
          <div>
            <div class="h5"><br>
              -- DJ Lucas<br>
            </div>
          </div>
        </blockquote>
        <div><br clear="all">
        </div>
      </div>
      dhclient, and dhcpcd checks,  does get ugly if we test for
      specific programs.  I always liked avoiding package specific
      work.  (and there are other dhcp clients out there.  My openwrt
      has dnsmaq for example)<br>
    </blockquote>
    Yeah, could use a bit of help here actually. I'm thinking about
    providing default service config values in the service script itself
    (to be over ridden by the config file), and a guard at the top of
    the service script for IFCONFIG, and just walking the
    /lib/network-service tree from ifdown. This seems easiest, and more
    importantly, most efficient in that for each service, a generic
    "stop" target can can be called for an interface (as opposed to
    down), and the service script has the logic, not the ifdown script.
    This makes it extensible for whatever you want to throw at it. For
    instance, in the case of both dhcp cleints, you check for the
    appropriate lease file, or just exit 0. Have to explicitly exclude
    ipv4-static and ipv4-static-route, reason being we'll flush all IPs
    on the interface, so ipv4-static is not needed, and when the link is
    dropped, the kernel will drop the static routes as well. Do you see
    anything wrong with that logic?<br>
    <br>
    -- DJ Lucas<br>
    <br>
  </body>
<br />-- 
<br />This message has been scanned for viruses and
<br />dangerous content, and is believed to be clean.

</html>