Active Session Management via OMAPI

Tue Aug 17 20:41:43 UTC 2010

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:
>   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:
> > 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:
> >> 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 rgrimsha at syr.edu
> >> ________________________________________ From:
> >> dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org
> >> [dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org] On Behalf Of Bryan
> >> Cheng [bcheng at rescomp.berkeley.edu] 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:
> >>> 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 rgrimsha at syr.edu
> >>>
> >>> ________________________________________ From:
> >>> dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org
> >>> [dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org] On Behalf Of
> >>> Bryan Cheng [bcheng at rescomp.berkeley.edu] Sent: Tuesday, July 20,
> >>> 2010 5:06 PM To: dhcp-users at lists.isc.org 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 dhcp-users at lists.isc.org
> >>> https://lists.isc.org/mailman/listinfo/dhcp-users
> >> _______________________________________________ dhcp-users mailing
> >> list dhcp-users at lists.isc.org
> >> https://lists.isc.org/mailman/listinfo/dhcp-users
> >>
> >>
> >> _______________________________________________
> >> dhcp-users mailing list
> >> dhcp-users at lists.isc.org
> >> https://lists.isc.org/mailman/listinfo/dhcp-users
> 
> 
> -- 
> Joshua West
> Senior Systems Engineer
> Brandeis University
> http://www.brandeis.edu
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100817/28f4686c/attachment.bin>