<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Hi Bryan,<br>
    <br>
    Hmm what kind of issues have you run into with OMAPI?  And what
    version of ISC DHCPD?<br>
    <br>
    I've started getting a list of active leases by just combing through
    all IP's in our DHCP pool ranges.  The response is actually pretty
    quick.  I mean, its too long for an end-user to wait on if they're
    visiting from some web portal (unless you limit the combing scope to
    just the subnet they're visiting from...), but its good enough for
    backend processing.<br>
    <br>
    Right now we've not been searching leases by mac address + state
    (since it doesn't work).  Instead I'm doing what I mentioned above;
    just combing through all IP's in a range and examining its state. 
    If the state is active, then I can snag the MAC address.<br>
    <br>
    I've made some progress in DHCP lease "removal".  I've discovered I
    can just set the lease state to 4 (aka RELEASED in ISC DHCPD
    4.1.1-P1), and the failover peer gets updated accordingly, DDNS
    delete operations ensue, etc.  However, and of course, this doesn't
    actually let the client know that their lease is no longer valid. 
    At least, not until the next time their DHCP client checks in.<br>
    <br>
    BTW the lease "removal" is only for dynamic clients.  For our
    clients that have fixed-address's, I can just remove their host
    entry with OMAPI.<br>
    <br>
    What is this DHCPRELEASE method via direct packet injection?  Are
    you sending the DHCPRELEASE to the DHCP server (forging information
    from the client) in order to force a release, as an alternative to
    using OMAPI?  Or is that packet going instead to the DHCP client,
    which in some cases actually causes the client to check in with the
    DHCP server (and discover its lease is no longer valid)?<br>
    <br>
    Thanks for your help Bryan!<br>
    <br>
    On 08/17/10 16:41, Bryan Cheng wrote:
    <blockquote
      cite="mid:20100817204143.GA94168@hal.rescomp.berkeley.edu"
      type="cite">
      <pre wrap="">Hey Joshua,

We haven't yet moved forward on implementing session-state lookups 
because we've run into a number of issues pertaining to integrating 
OMAPI into our captive portal authentication process. My colleague Jeff 
Bair has made some progress bringing dhcp lease acquisition into our 
login/logout scripts. Acquiring a list of all active leases has been 
somewhat of a lower priority than a working login/logout implementation 
at the moment.

However, we've reached the point where we are beginning to consider 
writing a patch, and weighing it against other options including the 
middleware mentioned earlier in this thread. Has your team reached any 
conclusions regarding the functionality offered by querying by 
session-state? Is there currently an alternative method your team is 
using?

As for removing leases by OMAPI, we have not had a need for this 
functionality and therefore I can't comment on its usage. Everything 
I've read seems to indicate that OMAPI does not allow the removal of an 
active lease. Our implementation involves sending a DHCPRelease with the 
ciaddr field populated with the public ip we wish to revoke.


On 13:38 Tue 17 Aug     , Joshua West wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">  Hey Bryan,

We're doing a similar thing with DHCP and shared-networks (private IP 
space for captive portal, public IP space for the real deal).

Was a patch ever written / submitted for the ability to query by 
session-state?

Also, do you know if its possible to remove a lease via OMAPI?  I seem 
to not be able to do so, or to be able to adjust when the lease 
expires.  Doing things like changing the state of the lease ends up 
crashing the failover cluster.

We're on ISC DHCPD 4.1.1-P1.

Thanks.

On 07/24/10 15:30, Bryan Cheng wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">Hey Randall,

Thanks for the additional information.

I had one last question. You note that OMAPI had a memory leak which
forced the use of middleware that kept a persistent connection open.
Could you comment on this a bit further?

We are currently investigating creating a patch for the ISC-dhcp server
that would allow a query by session-state (in addition to the current lookup
methods), but if this memory leak is problematic we may abandon this
path in favor of an alternative implementation, eg. the middleware you
have described.

Thanks,

Hao Bryan Cheng

On 21:40 Tue 20 Jul , Randall C Grimshaw wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">A really good way to approach these kinds of logs is 'first seen -
last seen audit trail. These are very compact and very effective. We
stored this in mysql.


Randall Grimshaw <a class="moz-txt-link-abbreviated" href="mailto:rgrimsha@syr.edu">rgrimsha@syr.edu</a>
________________________________________ From:
<a class="moz-txt-link-abbreviated" href="mailto:dhcp-users-bounces+rgrimsha=syr.edu@lists.isc.org">dhcp-users-bounces+rgrimsha=syr.edu@lists.isc.org</a>
[<a class="moz-txt-link-abbreviated" href="mailto:dhcp-users-bounces+rgrimsha=syr.edu@lists.isc.org">dhcp-users-bounces+rgrimsha=syr.edu@lists.isc.org</a>] On Behalf Of Bryan
Cheng [<a class="moz-txt-link-abbreviated" href="mailto:bcheng@rescomp.berkeley.edu">bcheng@rescomp.berkeley.edu</a>] Sent: Tuesday, July 20, 2010 9:19
PM To: Users of ISC DHCP Subject: Re: Active Session Management via
OMAPI

Hey Randall:

This is very interesting, thanks for the information.

We were wondering if you could provide a bit of clarification
regarding the middleware that you implemented? This is an appoach we
have considered, but we have yet to make a final decision regarding
the direction we would like to focus our efforts. Specifically, how is
the middleware acquiring and keeping a record of the active sessions?

Thanks,

--Bryan

On 19:10 Tue 20 Jul , Randall C Grimshaw wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="">You will find that the dhcp server also makes a very good session
watchdog for firewall garbage collection. Unfortunately there has
been a persistent memory leak in OMAPI which necessitated a piece of
middleware. The middleware simplly maintained a persistent
connection to OMAPI and subsequently provided some additional
logging functionality. In this design it is not difficult to pull a
list of users from the firewall and query them individually in DHCP
(IP and Mac associations)..We used the DHCP assigned address and
assigned QOS to the IP/MAC in the firewall. There is a bit more to
describe in the firewall if you continue. We also implemented a high
availability cluster configuration that would re-arp the gateway
address to the failover and instantly re-build the firewall rules
from the session log. Each of the clustered machines ran one of the
dhcp failover servers. Our weakest link was the clustering software
itself as the gateway was very reliable. hopefully it has matured by
now. We have just retired the application because we have been very
successful in implementing an 802.1x network that uses Impulse Safe
Connect for continuous assessment. Compliance checking in what
remained as a guest portal was deprecated. Concerned with the lack
of developers my manager replaced the remaining guest access
functionality with blue_socket who was willing to implement a
required feature.

Randall Grimshaw <a class="moz-txt-link-abbreviated" href="mailto:rgrimsha@syr.edu">rgrimsha@syr.edu</a>

________________________________________ From:
<a class="moz-txt-link-abbreviated" href="mailto:dhcp-users-bounces+rgrimsha=syr.edu@lists.isc.org">dhcp-users-bounces+rgrimsha=syr.edu@lists.isc.org</a>
[<a class="moz-txt-link-abbreviated" href="mailto:dhcp-users-bounces+rgrimsha=syr.edu@lists.isc.org">dhcp-users-bounces+rgrimsha=syr.edu@lists.isc.org</a>] On Behalf Of
Bryan Cheng [<a class="moz-txt-link-abbreviated" href="mailto:bcheng@rescomp.berkeley.edu">bcheng@rescomp.berkeley.edu</a>] Sent: Tuesday, July 20,
2010 5:06 PM To: <a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a> Subject: Active Session
Management via OMAPI

Hi,

We're a small team working at the University of California, Berkeley
on an implementation of our open-source network access control
software designed to regulate our wireless network and our in-room
connections.

We are investigating replacing our current (filesystem-based)
session store system with the ISC dhcp server. In this setup, a pair
of dhcp servers in a failover configuration communicate with perl
scripts running on our captive portals. While the dhcp servers do
not actively grant leases to our clients, we use the information
contained in the return dhcp packet in order to determine which ip
address to allocate to a given client. This allows us to take
advantage of features in the dhcp server, such as failover, session
management, ip address allocation, and omapi, for the purposes of
facilitating a high-availability configuration for our captive
portals.

However, the version of the dhcp server that we run (3.1) does not
support recovering a list of all active sessions over omapi.
Examining the release notes for later versions does not seem to
indicate that this support was added. Are there plans to include
support for this in later revisions of the omapi implementation?

Additionally, we were wondering what methods, if any, others have
used in order to obtain a complete list of all active leases on a
given dhcp server.

Thanks,

Bryan Cheng

_______________________________________________ dhcp-users mailing
list <a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a>
</pre>
            </blockquote>
            <pre wrap="">_______________________________________________ dhcp-users mailing
list <a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a>


_______________________________________________
dhcp-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a>
</pre>
          </blockquote>
        </blockquote>
        <pre wrap="">

-- 
Joshua West
Senior Systems Engineer
Brandeis University
<a class="moz-txt-link-freetext" href="http://www.brandeis.edu">http://www.brandeis.edu</a>

</pre>
        <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
dhcp-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a></pre>
      </blockquote>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Joshua West
Senior Systems Engineer
Brandeis University
<a class="moz-txt-link-freetext" href="http://www.brandeis.edu">http://www.brandeis.edu</a>
</pre>
  </body>
</html>