Active Session Management via OMAPI

Tue Aug 17 23:26:06 UTC 2010

  Hi Bryan,

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

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.

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.

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

Thanks for your help Bryan!

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100817/05458820/attachment.html>