Active Session Management via OMAPI

Bryan Cheng bcheng at rescomp.berkeley.edu
Wed Aug 18 00:22:19 UTC 2010 

Hey Joshua,

> Hmm what kind of issues have you run into with OMAPI?  And what version 
> of ISC DHCPD?

My colleague Jeff found that when he specified a client identifier in 
our perl scripts, the dhcp server would not return the same ip address the 
client had before. This would lead omapi to return a "more than one 
object matches key" error, effectively nullifying our ability to 
lookup data from the dhcp server. He worked around this issue by 
querying the dhcp server for the client's mac address, and sending a 
DHCPRequest for the old lease if one is returned.

We are running 3.1.2p1 issued from the FreeBSD ports tree for 
FreeBSD 8.0. An upgrade is in the pipeline, but I've been waiting for a 
lull in active development on Jeff's side to do a full upgrade of the 
system.
 
> 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.
> 
> 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.
 
Interesting approach. Are you using OMAPI to comb through the IP 
addresses? 

We don't require a list of active sessions except for session garbage 
collection which occurs via cronjob every few minutes. The current 
system utilizes a filesystem-based session store that is fast enough to 
allow us to reclaim public-facing ip addresses every minute; however 
this rate of collection is by no means necessary.

> 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.
> 
> 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.

This sounds like an excellent alternative.

> 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)?

Our captive portal system relies upon NAT and Netgraph (in conjunction 
with IPFW) in order to give authenticated clients in our private ip pool 
access to the internet. In this configuration, we have two sets of dhcp 
servers: one which assigns dhcp leases on an RFC1918 subnet to all 
clients regardless of state, and a pair in a failover cluster which 
assign addresses out of our pool of public ip addresses.

This failover cluster does not directly communicate with the clients; 
instead, each captive portal runs a set of perl scripts which 
mimic dhcp client operation using Net::DHCP::Packet. When we recieve a 
login request, the requisite DHCPDiscover (or DHCPRequest for returning 
clients) is sent from the captive portal itself, using the client's MAC 
address. We populate the giaddr field with the captive portal's ip 
address and set the hops variable so that return packets are sent to the 
captive portal (acting as a relay).

The DHCPRelease we send when a client logs out is sent from these 
captive portal perl scripts. This allows us to reclaim the 
public-facing ip for the client and destroy the relevant NAT rules. The 
client may still occupy the lease on its RFC1918 address, so we allow 
the client and the dhcp server on the captive portal to communicate 
organically with no intervention.


> Thanks for your help Bryan!

No problem. I hope this discussion has been as informative for you as it 
has been for us.

> 
> On 08/17/10 16:41, Bryan Cheng wrote:
> > 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
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
> 

> _______________________________________________
> 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/20100817/a2773e99/attachment.bin>

More information about the dhcp-users mailing list