Difficulty administering guest hotspots (part 1)

In this small article I will tell you how to get rid of the headache of administering large subnets linked to distribution of the Internet to incoming users.
Basic tools:

• Head
• One more head
• Arms
• Freebsd
• PF
• isc-dhcpd
• memcached
• perl

Those who want to know about everything written under the cat, the rest of the good viewing of other topics.
Link to the second part

The main problems of large dhcp servers

Everyone who dealt with isc-dhcpd knows how problematic it is to steer access within several ip networks. The main problem is the allocation of static entries for certain hosts, prescribing rules in the firewall to provide access, and other sysadmin corresponding routines. This solution was found, written and tested just a couple of months ago. So…

Existing management methods

ISC-DHCPD server has almost no built-in methods for managing its state. The only exception is the omshell appendix, which provides access to the isc-dhcpd internal database and allows you to get and change the values ​​of the internal fields without restarting the server. The EMNIP dhcpd.conf configuration file remains unchanged. Changes are automatically committed to dhcpd.leases. To control the appearance, issuance of addresses and their status, many of you have already tried the methods of parsing the isc-dhcpd system log and maybe even gotten the result, but not that they were 100% satisfied. But as experience shows, many of you missed the possibility of using dhcpd events in manuals.

What is dhcpd events?

At each operation (event) of issue, release and deletion of an address, an internal handler is triggered which can be reassigned. Below is a short excerpt from man dhcpd.conf
')
There are three kinds of events that can happen regarding a lease, and
it is possible to declare statements that occur when any of these
events happen. These events are the commit event, when the server has
made a commitment of a certain lease to a client, the release event,
when the client has released the server from its commitment, and the
expiry event, when the commitment expires.

To declare a set of statements to execute when an event happens, you
must use the on statement, followed by the name of the event, followed
by a series of statements to execute when the event happens, enclosed
in braces. Events are used to implement DNS updates, so you should
not define your own event handlers if you are using the built-in DNS
update mechanism.

The built-in version of the DNS update mechanism is in a text string
towards the top of server/dhcpd.c. If you want to use events for
things other than DNS updates, and you also want DNS updates, you will
have to start out by copying this code into your dhcpd.conf file and
modifying it.

What do these mysterious letters mean?
And they mean the following. isc-dhcpd using its internal events can update the DNS records in BIND and if you want to reassign event handlers, then do not forget to add the DNS update code to your handler.

Entangled? Unraveling!

For any address pool inside the dhcpd.conf configuration file, you can specify an external event handler. In any place of the config it looks like this:
on commit {
}
on release {
}
on expiry {
}

Handlers can be defined for address pools, as well as globally for the entire system. The most interesting thing is that the handlers previously used in the address pool do not overlap with the global one. This way your DNS updates will not be affected.

Practical use

Below you can see my current config for calling handlers. We will not go into details and disassemble the internal format of the data used in the internal dhcpd database, we’ll dwell only on a few points that may be useful.

• clientIP - current address with which the actions occur
• clientMAC - current mac address for clientIP
• host-name is the internal name of the host (can be obtained when issuing an address from the client or set automatically as in our case
• ddns-hostname - the name of the host that will be sent when updating to bind

In our case, the host-name and ddns-hostname entries should be automatically generated if the host name is empty ( Note: the host name in UTF-8 or in any other encoding is not considered empty )
on commit {
set clientIP = binary-to-ascii(10, 8, ".", leased-address);
set clientMAC = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));
if option host-name = "" {
option host-name = concat( "wifi-" , binary-to-ascii( 10, 8, "", substring( reverse( 1, leased-address), 0, 1)));
ddns-hostname = concat( "wifi-" , binary-to-ascii( 10, 8, "", substring( reverse( 1, leased-address), 0, 1)));
}
set clientHostName = option host-name;
execute("/usr/local/etc/dhcp_helper/publish-ip-mac.pl", "commit", clientIP, clientMAC);
execute("/usr/local/etc/dhcp_helper/publish-ip-mac.pl", "hostname", clientIP, clientHostName);
}

on release {
set clientIP = binary-to-ascii(10, 8, ".", leased-address);
set clientMAC = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));
execute("/usr/local/etc/dhcp_helper/publish-ip-mac.pl", "release", clientIP, clientMAC);
}

on expiry {
set clientIP = binary-to-ascii(10, 8, ".", leased-address);
if(exists agent.remote-id) {
set clientMAC = binary-to-ascii(16, 8, ":", substring(option agent.remote-id, 2, 6));
execute("/usr/local/etc/dhcp_helper/publish-ip-mac.pl", "expiry", clientIP, clientMAC);
} else {
execute("/usr/local/etc/dhcp_helper/publish-ip-mac.pl", "expiry", clientIP);
}

Actually, as a piece of the above code shows, a script with parameters is called for each type of operation. Parameters are transferred to ARGV. Anything can be a script (shell script, php, python and any other program).
Well, with release and expiry everything seems to be clear. Why does the commit use 2 script calls separately for the address and for the host name? Because if the host name is not in ANSI, then the handler stupidly crashes and the script is not called.

Well, for the sweet code of the script
#!/usr/bin/perl
use strict;
use warnings;

my $type = shift;
my $ip = shift;
my $mac = shift;

# Fork so we can return control
# to the dhcp server ASAP.
my $pid = fork();

# If we're the child, do whatever we need to do
if($pid == 0) {
open OUT,">>/var/tmp/publish.tmp";
$mac = join(":",map { sprintf("%02s",$_); } split(":",$mac));
print OUT "$type $ip $mac\n";
close OUT;
}


For everyone who wants to learn how to connect pf, dhcpd and web snouts to manage this entire economy, the sequel will be in the second part.
In the meantime, your brain is aware of what is written here, the methods of application and the simplicity of the solution, you can ask questions.

© Aborche 2011