<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 11/12/16 1:22 PM,
      <a class="moz-txt-link-abbreviated" href="mailto:mrobti@insiberia.net">mrobti@insiberia.net</a> wrote:<br>
    </div>
    <blockquote
      cite="mid:1434a9d4dcbffcf3342a2e18eeaf1fe4@insiberia.net"
      type="cite">On 2016-11-11 04:23, Thomas Markwalder wrote:
      <br>
      <blockquote type="cite">On 11/10/16 11:50 PM, <a class="moz-txt-link-abbreviated" href="mailto:mrobti@insiberia.net">mrobti@insiberia.net</a>
        wrote:
        <br>
        <br>
        <blockquote type="cite">On 2016-11-10 06:12, Thomas Markwalder
          wrote:
          <br>
          On 11/9/16 2:28 PM, <a class="moz-txt-link-abbreviated" href="mailto:mrobti@insiberia.net">mrobti@insiberia.net</a> wrote:
          <br>
          <br>
          On 2016-11-09 07:56, Thomas Markwalder wrote:
          <br>
          On 11/9/16 4:20 AM, <a class="moz-txt-link-abbreviated" href="mailto:mrobti@insiberia.net">mrobti@insiberia.net</a> wrote:
          <br>
          On 2016-11-08 15:44, <a class="moz-txt-link-abbreviated" href="mailto:mrobti@insiberia.net">mrobti@insiberia.net</a> wrote:
          <br>
          I want to assign a client-class using hwaddr, from MySQL
          backend,
          <br>
          and
          <br>
          restrict a subnet for that client-class. In other words, only
          allow
          <br>
          clients with known MAC addresses to use the subnet they are
          trying
          <br>
          to
          <br>
          connect to.
          <br>
          <br>
          DB hosts table has an entry for the client:
          <br>
          dhcp4_subnet_id = 1
          <br>
          dhcp_identifier_type = 0
          <br>
          dhcp_identifier = UNHEX(REPLACE('aa:bb:cc:dd:ee:ff', ':', ''))
          <br>
          hostname = test.local
          <br>
          dhcp4_client_classes = test_class
          <br>
          <br>
          Config file has:
          <br>
          "client-classes": [ {
          <br>
          "name": "test_class"
          <br>
          } ],
          <br>
          "subnet4": [ {
          <br>
          "id": 1,
          <br>
          "subnet": "192.168.1.0/24",
          <br>
          "pools": [ { "pool": "192.168.1.10 - 192.168.1.20" } ],
          <br>
          "client-class": "test_class"
          <br>
          } ],
          <br>
          <br>
          But Kea says (debug level 50):
          <br>
          : client packet has been assigned to the following class(es):
          <br>
          VENDOR_CLASS_MSFT 5.0
          <br>
          : failed to select subnet for the client
          <br>
          : no suitable subnet configured for a direct client
          <br>
          <br>
          It works if I remove "client-class" from the subnet
          definition, so
          <br>
          something is not synchronizing the class somewhere.
          <br>
          <br>
          Could it be a problem that the DB hosts entry has no
          ipv4_address
          <br>
          listed? (that column is NULL)  I don't have any other ideas.
          <br>
          <br>
          I've found this in the logs:
          <br>
          <br>
          : HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations
          using
          <br>
          <br>
          <br>
          identifier: hwaddr=aa:bb:cc:dd:ee:ff
          <br>
          : HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier
          <br>
          hwaddr=aa:bb:cc:dd:ee:ff, found 0 host(s)
          <br>
          <br>
          Why would this happen? Yes, I double checked the MAC address.
          I
          <br>
          enabled MySQL logging, and I can't match up timestamps
          exactly, but
          <br>
          I
          <br>
          do find a query:
          <br>
          <br>
          SELECT host_id, dhcp_identifier, dhcp_identifier_type,
          <br>
          dhcp4_subnet_id, dhcp6_subnet_id, ipv4_address, hostname,
          <br>
          dhcp4_client_classes, dhcp6_client_classes FROM hosts WHERE
          <br>
          dhcp4_subnet_id = ? AND dhcp_identifier_type = ?    AND
          <br>
          dhcp_identifier = ?
          <br>
          <br>
          I don't know if it's possible to see the executed version of
          this
          <br>
          prepared query(?). Is it possible that the value Kea is
          placing in
          <br>
          the
          <br>
          query is not the correct binary string?
          <br>
          _______________________________________________
          <br>
          Kea-users mailing list
          <br>
          <a class="moz-txt-link-abbreviated" href="mailto:Kea-users@lists.isc.org">Kea-users@lists.isc.org</a>
          <br>
          <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/kea-users">https://lists.isc.org/mailman/listinfo/kea-users</a>
          <br>
          <br>
          Hello:
          <br>
          <br>
          We are looking into this for you.  As you probably know,  Kea
          will
          <br>
          look
          <br>
          first for hosts defined its configuration file and then within
          the
          <br>
          hosts
          <br>
          database (if it is specified).  Any log statements you see
          that
          <br>
          contain
          <br>
          "HOSTS_CFG_" pertain to looking at hosts defined via the
          <br>
          configuration
          <br>
          <br>
          file.  In your case, since there are none, you see none
          found.  When
          <br>
          <br>
          Kea
          <br>
          accesses the host database the logs should contain
          <br>
          HOSTS_MGR_ALTERNATIVE_.   The following is a snippet from of
          the log
          <br>
          <br>
          in
          <br>
          a setup I am testing with:
          <br>
          <br>
          2016-11-09 10:18:45.018 DEBUG [kea-dhcp4.hosts/24940]
          <br>
          HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with
          reservation
          <br>
          for
          <br>
          <br>
          subnet id 1 and IPv4 address 178.16.1.101
          <br>
          2016-11-09 10:18:45.018 DEBUG [kea-dhcp4.hosts/24940]
          <br>
          HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for
          IPv4
          <br>
          address 178.16.1.101
          <br>
          2016-11-09 10:18:45.018 DEBUG [kea-dhcp4.hosts/24940]
          <br>
          HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 178.16.1.101,
          found 0
          <br>
          <br>
          host(s)
          <br>
          2016-11-09 10:18:45.018 DEBUG [kea-dhcp4.hosts/24940]
          <br>
          HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using
          <br>
          subnet
          <br>
          id
          <br>
          1 and address 178.16.1.101
          <br>
          2016-11-09 10:18:45.018 DEBUG [kea-dhcp4.hosts/24940]
          <br>
          HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_ADDRESS4 trying alternate
          source
          <br>
          for
          <br>
          host using subnet id 1 and address 178.16.1.101
          <br>
          <br>
          The last log statement indicates that Kea is looking in MySQL
          for
          <br>
          hosts
          <br>
          that have the allocated address.  It just so happens that Kea
          <br>
          actually
          <br>
          <br>
          conducted a search in MySQL prior to the last one show above. 
          This
          <br>
          search is done by subnet id and dhcp identifier.   However the
          <br>
          function
          <br>
          that performs this search happens to be missing a log entry. 
          This
          <br>
          is
          <br>
          why you see  the two selects  you cited in the MySQL log but
          only
          <br>
          one
          <br>
          log message against the alternate.   The original function we
          used
          <br>
          was deprecated without the new one getting a log message. 
          Sorry
          <br>
          about
          <br>
          <br>
          that.
          <br>
          <br>
          On the surface, it looks like Kea should be matching your
          host,
          <br>
          we're
          <br>
          still researching it.  You might try defining your host in the
          <br>
          configuration file, for testing purposes.   Do you have a
          packet
          <br>
          capture
          <br>
          and what version of Kea are you running?
          <br>
          <br>
          Thank you for your response. I don't have a packet capture at
          the
          <br>
          moment, but I do see the HOSTS_MGR_ALTERNATE_ line just like
          yours.
          <br>
          I'm running the ubuntu package which shows version 1.0.0, the
          <br>
          package
          <br>
          name is version 1.0.0-1build1. I know that's behind the curve,
          but
          <br>
          sometimes don't these packages include bugfixes from newer
          versions
          <br>
          than they report?
          <br>
          <br>
          I can begrudgingly compile from source, but would not be happy
          <br>
          taking
          <br>
          it outside the system package manager.
          <br>
          <br>
          I just tried to test by putting the host in the config file,
          got
          <br>
          this
          <br>
          startup error:
          <br>
          DHCP4_PARSER_FAIL failed to create or run parser for
          configuration
          <br>
          element subnet4: unsupported configuration parameter
          <br>
          'client-classes'
          <br>
          <br>
          I think you meant client-classes failed to parse as part of
          the
          <br>
          host
          <br>
          element (not subnet4) ?
          <br>
        </blockquote>
        <br>
        I think so, you mean the host element inside the subnet4
        reservations
        <br>
        list, right? I put "client-classes" in a "reservations" entry in
        the
        <br>
        "subnet4" as such:
        <br>
        <br>
        "subnet4": [ {
        <br>
          "reservations": [ {
        <br>
            "hw-address": "aa:bb:cc:dd:ee:ff",
        <br>
            "client-classes": [ "test_class" ]
        <br>
          }],
        <br>
          "id": 1,
        <br>
          "subnet": "192.168.1.0/24",
        <br>
        ...
        <br>
        <br>
        That's the right way to do it, correct? Version 1.0.0 didn't see
        <br>
        "client-classes" as valid in that context.
        <br>
        <br>
        <blockquote type="cite">But yes, "client-classes" was added in
          1.1.0.
          <br>
          1.1.0 added a good deal more functionality to the RDBMS Host
          <br>
          Reservations implementations, as well as a lot more with
          <br>
          classification expression matching.
          <br>
          <br>
          <blockquote type="cite">Looks like assigning client-classes to
            host reservations was a
            <br>
            feature only added after version 1.0? Can you please confirm
            when
            <br>
            it
            <br>
            was added?
            <br>
            _______________________________________________
            <br>
            Kea-users mailing list
            <br>
            <a class="moz-txt-link-abbreviated" href="mailto:Kea-users@lists.isc.org">Kea-users@lists.isc.org</a>
            <br>
            <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/kea-users">https://lists.isc.org/mailman/listinfo/kea-users</a>
            <br>
          </blockquote>
          <br>
          When an inbound packet is received things happen in this
          order:
          <br>
          <br>
          1. The packet is classified by evaluating it against the test
          <br>
          expression for defined classes
          <br>
          <br>
          2. Subnet matching is conducted based on packet content.  This
          <br>
          includes comparing the classes matched to the packet in step 1
          <br>
          against
          <br>
          the classes specified by the subnet's "client-class" list.
          <br>
          <br>
          3. Look for host reservations
          <br>
          <br>
          The problem you have is two fold.   First, your "test-class"
          does
          <br>
          not
          <br>
          define a "test" expression and thus matching it against a
          packet
          <br>
          always fails.   This causes the subnet selection to fail and
          the
          <br>
          server drops the packet.  The second issue is that you are
          assigning
          <br>
          a
          <br>
          class to the host reservation, but associating the client to a
          <br>
          reservation occurs after the subnet selection.  This is
          something of
          <br>
          a
          <br>
          chicken-and-the-egg situation.
          <br>
        </blockquote>
        <br>
        This question did come up when I was reading the docs. It does
        seem
        <br>
        like the host class assignment needs to happen earlier and in a
        <br>
        different configuration scope.
        <br>
        <br>
        <blockquote type="cite">So while you can specify that a host
          belongs to one or more classes,
          <br>
          <br>
          this currently only means the host inherits options from those
          <br>
          classes.
          <br>
          <br>
          I think it would help to understand what problem you are
          trying to
          <br>
          solve.  Are you trying to ensure that only known clients get
          <br>
          addresses?
          <br>
        </blockquote>
        <br>
        Yes, that's the primary goal.
        <br>
        <br>
        <blockquote type="cite">Are you trying to map specific hosts to
          specific subnets?
          <br>
        </blockquote>
        <br>
        Secondary goal is not mapping hosts to subnets, but to pools
        within
        <br>
        the same subnet. (Later we will add subnets and map to those.)
        <br>
        <br>
        <blockquote type="cite">How any hosts in how many subnets do you
          anticipate having?
          <br>
        </blockquote>
        <br>
        Not many for now, but storing configuration information in a
        database
        <br>
        is a requirement in this case.
        <br>
        <br>
        <blockquote type="cite">If your network isn't large, you could
          define a class for each host
          <br>
          whose "test" expression matches the host's hardware address.
          Then
          <br>
          add
          <br>
          these classes to the desired subnet4 client-class list.   Not
          ideal
          <br>
          but it would work.  This would be akin to ISC DHCP
          sub-classing,
          <br>
          though not quite as neat.   Another alternative would be to
          write a
          <br>
          hook but we would need to understand your problem to offer a
          more
          <br>
          detailed suggestion.  Our example hook library, user-chk, 
          does
          <br>
          something similar to what you're after and is a good starting
          point
          <br>
          for what is possible,
          <br>
          <a class="moz-txt-link-freetext" href="http://kea.isc.org/docs/kea-guide.html#idp54000992">http://kea.isc.org/docs/kea-guide.html#idp54000992</a>.   Hooks
          are
          <br>
          described in detail in our developer's guide:
          <br>
          <br>
        </blockquote>
<a class="moz-txt-link-freetext" href="https://jenkins.isc.org/job/Kea_doc/doxygen/df/d46/hooksdgDevelopersGuide.html">https://jenkins.isc.org/job/Kea_doc/doxygen/df/d46/hooksdgDevelopersGuide.html</a>.
        <br>
        <br>
        Sounds like Kea doesn't support a "known-clients" type of
        <br>
        configuration. I'll read about hooks next, but I wouldn't think
        the
        <br>
        "known-clients" feature is unusual - is this design issue
        something
        <br>
        that will be addressed in a future version without the need for
        <br>
        external hook libraries?
        <br>
        <br>
         This is a feature that is likely to be added.  ISC is a small,
        <br>
        non-profit company and we can only do so much at a time.  Of
        course we
        <br>
        are also an open-source project so contributors are always
        welcome.
        <br>
        As you mention, this is likely a feature many users would like
        to
        <br>
        have.
        <br>
        <br>
        <blockquote type="cite">Now, I read briefly about user-chk.
          Reading a text file upon each
          <br>
          packet arrival doesn't sound efficient, regardless our
          requirement
          <br>
          is using a database. Would it be possible to:
          <br>
          1. remove "client-class" from the subnet so all clients can
          <br>
          initially be assigned to the subnet just for purposes of
          working
          <br>
          around the chicken/egg problem you mentioned
          <br>
          2. assign class names to known clients using the existing
          database
          <br>
          reservations system (note, class would be defined in config
          file
          <br>
          with no "test" expression and our reservations have NULL for
          the IP
          <br>
          address)
          <br>
          3. have the user-chk hook library inspect the assigned class
          and
          <br>
          deny or reassign if the class is empty (not having been
          assigned in
          <br>
          step 2)
          <br>
          <br>
          If this is possible, can I do it in version 1.0 or is 1.1.0
          required
          <br>
          for any of the above?
          <br>
        </blockquote>
        <br>
        The user_chk library as it stands is really meant as a learning
        <br>
        tool/starting point, not as something intended for busy
        production
        <br>
        environment.   You are free to alter it however you like.   You
        may
        <br>
        find it more expedient to use it as guide or skeleton for your
        own new
        <br>
        hook lib.  It likely has a fair amount of stuff you don't need.
        <br>
      </blockquote>
      <br>
      Right, I've put together a library that is only a few lines of
      code that seems to do what we need. Thanks for the examples and
      documentation.
      <br>
      <br>
      <blockquote type="cite">What
        <br>
        you are proposing is doable, but not with 1.0 as it does not
        support
        <br>
        client-classes in the host reservations.
        <br>
        <br>
        If you look at the lease4_select hook point arguments:
        <br>
        <br>
            * ARGUMENTS:
        <br>
        <br>
             * name: QUERY4, type: isc::dhcp::Pkt4Ptr [1], direction: IN
        <br>
             * name: SUBNET4, type: isc::dhcp::Subnet4Ptr [2],
        direction: IN
        <br>
             * name: FAKE_ALLOCATION, type: bool, direction: IN
        <br>
             * name: LEASE4, type: isc::dhcp::Lease4Ptr [3], direction:
        IN/OUT
        <br>
      </blockquote>
      <br>
      I had looked earlier myself, but was not able to find a list of
      hook points. Can you please provide a link to where that is?
      <br>
      <br>
      In any case, thank you for this pointer which has what was needed.
      It appears I have things working, but I ran into a couple problems
      and had a couple questions if you don't mind:
      <br>
      <br>
      1. FYI, on a Debian-based system, the include and lib directories
      for compiling the hook library were somewhat different (especially
      the lib) than the example in the docs:
      <br>
      <br>
      -I /usr/local/include/kea
      <br>
      -L /usr/local/lib
      <br>
      <br>
    </blockquote>
    Our apologies. Could you point us to the specific reference?<br>
    <blockquote
      cite="mid:1434a9d4dcbffcf3342a2e18eeaf1fe4@insiberia.net"
      type="cite">2. There is a bug in the 1.1.0 tarball: the
      dhcpsrv/lease.h file does not get installed, so compiling a hook
      library that does anything with leases is not possible. I had to
      add to the end of src/lib/dhcpsrv/Makefile.am:
      <br>
      <br>
      libkea_dhcpsrv___includedir = $(pkgincludedir)/dhcpsrv
      <br>
      libkea_dhcpsrv___include_HEADERS = \
      <br>
          lease.h
      <br>
      <br>
      Then re-run aclocal, automake and make.
      <br>
      <br>
    </blockquote>
    <br>
    Sorry for the inconvenience, we have a ticket already open for the
    1.2 milestone to correct this.<br>
    <br>
    <blockquote
      cite="mid:1434a9d4dcbffcf3342a2e18eeaf1fe4@insiberia.net"
      type="cite">3. Is using "lease.decline(0)" the best (only) way, at
      least in this hook point, to turn away unknown clients? That's
      what I've done and it works, though the lease is still processed
      and sent to the client, but with what I think is a lease for zero
      seconds.
      <br>
      <br>
      Trimmed log, showing what I think is the 0-second lease (type 51):
      <br>
      <br>
      ... DEBUG [kea-dhcp4.packets] DHCP4_RESPONSE_DATA ... responding
      with packet DHCPOFFER (type 2), packet details: ...
      remote_adress=192.168.1.193:68, msg_type=DHCPOFFER (2) ...
      <br>
      options:
      <br>
        type=001...
      <br>
        type=051, len=004: 0 (uint32)
      <br>
        type=053, len=001: 2 (uint8)
      <br>
        ...
      <br>
      <br>
      [BTW, note you have a typo somewhere in your code "remote_adress"]
      <br>
      <br>
      Is it possible for a client to ignore the lease time and use the
      address it received anyway? Does having done "lease.decline(0)"
      force Kea to update anything it needed to invalidate the lease?
      <br>
      <br>
      I see in the logs that the client came back immediately using the
      assigned address - perhaps asking for a renew of what it thinks
      was only an expired lease? If so, that may not be ideal. Indeed,
      Kea's next response looks to be a renewal(?) (though here, too,
      the lease time (type 51) is sent back as zero seconds). Could this
      create a feedback loop that would burden the server?
      <br>
      I do see that it looks to have been cleaned up, though after the
      client's first couple tries:
      <br>
      <br>
      [kea-dhcp4.alloc-engine] ALLOC_ENGINE_V4_DECLINED_RECOVERED IPv4
      address 192.168.1.193 was recovered after 0 seconds of
      probation-period
      <br>
      <br>
      Some time after that, the client sent a DHCPDECLINE (type 4)
      message, but Kea seems to already have cleaned it up, and I see a
      warning logged:
      <br>
      <br>
      WARN  [kea-dhcp4.dhcp4] DHCP4_DECLINE_LEASE_NOT_FOUND Received
      DHCPDECLINE for addr 192.168.1.193 from client ... but no such
      lease found.
      <br>
      <br>
    </blockquote>
    Declining a lease is intended to be a client initiated action, so I
    don't really think this is direction to go.  If you set the
    lease4_select next step action to SKIP before returning from your
    lease4_select hook:<br>
    <br>
    "<b>Next step status</b>: If any callout installed on the
    "lease4_select" hook sets the next step action to SKIP, the server
    will not assign any lease and the callouts become responsible for
    the lease assignment. If the callouts fail to provide a lease, the
    packet processing will continue, but client will not get an
    address."<br>
    <br>
    If your callout does not then assign a lease using its own decision
    making,  the server will generate a NAK to your client.<br>
    <br>
    <blockquote
      cite="mid:1434a9d4dcbffcf3342a2e18eeaf1fe4@insiberia.net"
      type="cite">If this is not best, is there a way to change the
      assigned subnet (invalid one or sandboxed one) at this late hook
      point?
      <br>
      <br>
      Also, is there a way to change the assigned pool?
      <br>
      <br>
      <br>
    </blockquote>
    If you want to alter the subnet that was selected you'll have to
    intervene in the subnet4_select hook point.    <br>
    <br>
    <blockquote
      cite="mid:1434a9d4dcbffcf3342a2e18eeaf1fe4@insiberia.net"
      type="cite">
      <br>
      <br>
      <blockquote type="cite"> All classes matched to the client,
        including those via host
        <br>
        reservations, are accessible via query4->getClasses()
        (inherited from
        <br>
        isc::dhcp::Pkt).
        <br>
        <br>
        If you want to do something earlier in the process, it would
        have be
        <br>
        in the subnet4_select hook point, but bear in mind two things:
        <br>
        <br>
        1. The host matching as not yet been done, so
        query4->getClasses()
        <br>
        would not contain any classes contributed by a reservation.  You
        can,
        <br>
        however, look for a host reservation yourself via the HostMgr
        <br>
        singleton, which can be accessed
        <br>
        with this static method:
        <br>
        <br>
            HostMgr::instance()
        <br>
        <br>
        and the reservation can be searched for with either of these:
        <br>
        <br>
            virtual ConstHostPtr
        <br>
            get4(const SubnetID& subnet_id, const HWAddrPtr&
        hwaddr,
        <br>
                 const DuidPtr& duid = DuidPtr()) const;
        <br>
        <br>
            virtual ConstHostPtr
        <br>
            get4(const SubnetID& subnet_id, const
        Host::IdentifierType&
        <br>
        identifier_type,
        <br>
                 const uint8_t* identifier_begin, const size_t
        identifier_len)
        <br>
        const;
        <br>
        <br>
            (I would recommend the latter, as the former may eventually
        be
        <br>
        deprecated)
        <br>
        <br>
        2. Host reservations are tied to a subnet via subnet ID.  Kea
        does not
        <br>
        support subnet-less host reservations.  Suppose  you define a
        host
        <br>
        reservation to subnet id 1, and you override the subnet
        selection with
        <br>
        a different subnet, say subnet 23.  When
        <br>
        Kea attempts to match hosts to this client, it will use subnet
        id 23
        <br>
        and fail to find any, unless you add a second reservation for
        the host
        <br>
        with subnet id 23.    On the other hand, if you only want to use
        the
        <br>
        host reservation to attribute hosts to classes,  this may not
        matter
        <br>
        to you, as you're doing the look explicitly in your hook.
        <br>
        <br>
        Thomas Markwalder
        <br>
        ISC Software Engineering
        <br>
        <br>
        <br>
        Links:
        <br>
        ------
        <br>
        [1]
        <br>
<a class="moz-txt-link-freetext" href="https://jenkins.isc.org/job/Kea_doc/doxygen/d5/d8c/namespaceisc_1_1dhcp.html#a3f332dc70d05fbe8e0fb453434c22d93">https://jenkins.isc.org/job/Kea_doc/doxygen/d5/d8c/namespaceisc_1_1dhcp.html#a3f332dc70d05fbe8e0fb453434c22d93</a>
        <br>
        [2]
        <br>
<a class="moz-txt-link-freetext" href="https://jenkins.isc.org/job/Kea_doc/doxygen/d5/d8c/namespaceisc_1_1dhcp.html#a17ccc4cfb9f7534dfcedc83ebe0e5d5a">https://jenkins.isc.org/job/Kea_doc/doxygen/d5/d8c/namespaceisc_1_1dhcp.html#a17ccc4cfb9f7534dfcedc83ebe0e5d5a</a>
        <br>
        [3]
        <br>
<a class="moz-txt-link-freetext" href="https://jenkins.isc.org/job/Kea_doc/doxygen/d5/d8c/namespaceisc_1_1dhcp.html#aec4424838e2e5bb397345cdc32c0ef28">https://jenkins.isc.org/job/Kea_doc/doxygen/d5/d8c/namespaceisc_1_1dhcp.html#aec4424838e2e5bb397345cdc32c0ef28</a>
        <br>
      </blockquote>
      <br>
      _______________________________________________
      <br>
      Kea-users mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:Kea-users@lists.isc.org">Kea-users@lists.isc.org</a>
      <br>
      <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/kea-users">https://lists.isc.org/mailman/listinfo/kea-users</a>
      <br>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>