Active Session Management via OMAPI

[Bryan Cheng]

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
-------------- 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/20100720/d494e3f0/attachment.bin>