Home > Networking Tips > Routing and Switching > Router Expert: DHCP services for WLANs
Networking Tips:
EMAIL THIS
 TIPS & NEWSLETTERS TOPICS 

ROUTING AND SWITCHING

Router Expert: DHCP services for WLANs


Michael J. Martin
04.24.2006
Rating: -5.00- (out of 5)


Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us   


Our router expert continues his series on building a secure wireless LAN with a Linux base. The previous article discussed supporting 802.1q interfaces on Linux and Cisco IOS. This month, we will be configuring Dynamic Host Configuration Protocol (DHCP) services.

When it comes to implementing DHCP services, we have a choice between utilizing the DHCP service provided by Cisco IOS (which I have covered implementing in previous articles) or the Internet Systems Consortium's (ISC) DHCP which can run on the Linux server. We will be using the following network diagram for our implementation discussion:

Two key features about this implementation are:

  • It uses a single network interface on the Linux server, requiring the use of 802.1q
  • It uses multiple gateways on WLAN/LAN segments

The first feature requires us to set up 802.1q networking on the Linux server, assuming that the server's kernel has 802.1q support built in (and it should if you have been reading this series). We must configure the server's switch port to support 802.1q trunking and the server's interface to support VLANs. The switch part is easy. First, the port's trunk encapsulation protocol needs to be set. Once that's done, the port can be set as a trunk port and the permitted VLANs can be defined:

outlan-sw01#config t
Enter configuration commands, one per line.  End with CNTL/Z.
outlan-sw01(config)#interface FastEthernet 0/21
outlan-sw01(config-if)#switchport trunk encapsulation dot1q
outlan-sw01(config-if)#switchport mode trunk
outlan-sw01(config-if)# switchport trunk allowed vlan 40
outlan-sw01(config-if)#switchport trunk allowed vlan add 80
outlan-sw01(config-if)#^Z

If you don't define the VLANs that are permitted, the switch will permit all of the VLANs configured on the switch to potentially send traffic across the port. This is not necessarily wrong, but it is better to define what traffic can traverse the port, then to leave it up to the uplink device. Here is what the final port configuration looks like:

outlan-sw01#sh run | begin interface FastEthernet0/21
interface FastEthernet0/21
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 40,80
 switchport mode trunk
!

Now we must configure the server. Red Hat does not by default support 802.1q. The quickest way to get VLAN interfaces up and running is to disable the bootstrap network process /etc/rc3.d/S10network by renaming the /etc/rc3.d/S10network bootstrap file to /etc/rc3.d/s10network. We can then create our own network bootstrap script, like this example:

#!/bin/sh
# Install this script in /etc to load VLAN interfaces as part of the 
# bootstrap process using /etc/rc3.d/S99local
#
# System Variables
host=trident
domain=open.outlan.net
gateway=172.30.80.1

# App Variables
vlan=/sbin/vconfig
ifc=/sbin/ifconfig
hn=/bin/hostname
dn=/bin/domainname
rt=/sbin/route

echo "Activating eth0...."
$ifc eth0 up
$ifc eth0 mtu 1460

# Define 802.1q vlans here:
$vlan add eth0 80
$vlan add eth0 40
#
#
echo "Enabling Vlan Interfaces"
$ifc eth0.80 172.30.80.101 netmask 255.255.255.0 up
$ifc eth0.80 mtu 1460
#
$ifc eth0.40 172.30.40.6 netmask 255.255.255.0 up
$ifc eth0.80 mtu 1460
#
echo Setting hostname....
$hn $host
echo Setting Domain Name....
$dn $domain
echo Setting Default Route....
$rt add default gw $gateway

The script can be loaded at the end of the bootstrap process by adding the script to the /etc/rc3.d/S99local bootstrap process file (this will also be where we start the DHCP service):

[root@tridant rc3.d]# vi S99local
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local
echo Starting Network
/etc/start-net.sh



:wq
[root@tridant rc3.d]#

With the server's networking out of the way, we can back to the decision about using Cisco vs. ISC DHCP. The Cisco implementation is great for most standard DHCP environments that require only the "basic" client options:

  • Subnet mask (option 1)
  • Router/default gateway (option 3)
  • DNS server (option 6)
  • Hostname (option 12)
  • Domain name (option 15)
  • NetBIOS name server (option 44)
  • NetBIOS node type (option 46)

All of the above options are recognized by just about every DHCP client implementation available today and are generally all that is required to get a Windows, Mac OS X or Unix/Linux-based workstation on the network. That said, there are over 100 DHCP client options defined in the current IANA (Internet Assigned Numbers Authority) DHCP parameters document. The Cisco DHCP implementation supports 12 of them. So, if you are planning to support any DHCP options beyond the basics, such as Web proxy auto discovery or static route distribution, then ISC DHCP is the way to go.

Building the DHCP server
The ISC DHCP service is freely available from the ISC Web site. (ISC is also responsible for the BIND Domain Name Service daemon.) The ISC implementation is considered by most as the "reference" DHCP distribution (as many of the developers are members of the DHCP standard working group) and is part of many core Unix/Linux distributions. The ISC DHCP service runs as a root "owned" service. This creates a potential security exploit if ever there is a vulnerability discovered with DHCP. One way to minimize this risk is to run DHCP in a chroot "jail." This involves creating a directory tree "cell" where all of the configuration, log, and database files, along with the executables and libraries needed for the service to operate, exist apart from the rest of the system. ISC DHCP does not, however, support the chroot option as part of the native implementation.

Luckily, programmer Ari Edelkind has written a code patch called "paranoia" that adds support for running ISC DHCP in a chroot cell. To start the build process, we first need to download the patch file using wget. This can be done from the root directory, or you can create a build directory using the following:

[root@tridant root]# wgethttp://www.episec.com/people/edelkind/patches/dhcp/dhcp-3.0+paranoia.patch
-bash: wgethttp://www.episec.com/people/edelkind/patches/dhcp/dhcp-
3.0+paranoia.patch: No such file or directory
[root@tridant root]# wget http://www.episec.com/people/edelkind/patches/dhcp/dhcp-3.0+paranoia.patch
--08:51:27--  http://www.episec.com/people/edelkind/patches/dhcp/dhcp-
3.0+paranoia.patch
           => `dhcp-3.0+paranoia.patch'
Resolving www.episec.com... done.
Connecting to www.episec.com[69.55.237.141]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5,366 [text/plain]

100%[==============================================================
========================================================>] 
5,366         56.35K/s    ETA 00:00

08:51:33 (56.35 KB/s) - `dhcp-3.0+paranoia.patch' saved [5366/5366]

[root@tridant root]# 

The current version of ISC DHCP is 3.0.3. The "paranoia" chroot patch was tested by the patch author on ISC DHCP versions up to 3.0.1.rc4. There were some security vulnerabilities discovered in ISC DHCP versions 3.0p1, 3.0.1rc8 and 3.0.1rc12 and 3.0.1rc13. The patch fails on ISC DHCP versions 3.0.1.rc14 and higher. So in order to run a secure version of the ISC DHCP code and support the chroot option, we must use version 3.0.1rc11. Just like the patch file, we can download the code using wget:


[root@tridant root]# wget http://ftp.isc.org/isc/dhcp/dhcp-3.0-
history/dhcp-3.0.1rc11.tar.gz
--09:36:06--  http://ftp.isc.org/isc/dhcp/dhcp-3.0-history/dhcp-3.0.1rc11.tar.gz
           => `dhcp-3.0.1rc11.tar.gz'
Resolving ftp.isc.org... done.
Connecting to ftp.isc.org[204.152.184.110]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 853,934 [application/x-gzip]

100%[=========================================================
=========================================================
====>] 853,934      267.71K/s    ETA 00:00

09:36:09 (267.71 KB/s) - `dhcp-3.0.1rc11.tar.gz' saved [853934/853934]

[root@tridant root]# 

Uncompress and extract the tar ball:

[root@tridant root]# tar xfz dhcp-3.0.1rc11.tar.gz

Move the patch file into the server directory of the DHCP source code directory:

[root@tridant root]# mv dhcp-3.0+paranoia.patch dhcp-3.0.1rc11/server
[root@tridant root]# cd dhcp-3.0.1rc11/server

Then apply the patch to dhcpd.c. If there are problems, the patch application will report errors. Otherwise, you should just get a simple notice and the program should exit:


[root@tridant root]# cd dhcp-3.0.1rc11/server
[root@tridant server]# patch dhcpd.c dhcp-3.0+paranoia.patch 
patching file dhcpd.c
[root@tridant server]#

With the patch file successfully applied, we run the configure command from the root of the source tree directory with the patch flags:


[root@tridant dhcp-3.0.1rc11]# ./configure --copts "-DPARANOIA"
System Type: linux-2.2
make[1]: Entering directory `/root/dhcp-3.0.1rc11/work.linux-2.2'
Making links in common
make[2]: Entering directory `/root/dhcp-3.0.1rc11/work.linux-2.2/common'
make[2]: Leaving directory `/root/dhcp-3.0.1rc11/work.linux-2.2/common'
make[1]: Leaving directory `/root/dhcp-3.0.1rc11/work.linux-2.2'
….
[root@tridant dhcp-3.0.1rc11]# 

Then build the source:

[root@tridant dhcp-3.0.1rc11]# make
….
make[2]: Leaving directory `/root/dhcp-3.0.1rc11/work.linux-2.2/dhcpctl'
make[1]: Leaving directory `/root/dhcp-3.0.1rc11/work.linux-2.2'

[root@tridant dhcp-3.0.1rc11]#

Once the code is built, you have two options. You can run make install, which will move the binaries, man page, and configuration files into their default install locations. Or, you can move into the work.linux-2.2 directory:


[root@tridant work.linux-2.2]# ls
client  common  dhcpctl  dst  Makefile  minires  omapip  relay  server
[root@tridant work.linux-2.2]# 

You then manually install the server and man page files where you want them (for instance, into the chroot cell we are about to build). The first step is creating the user and group we want the dhcpd services to run under:


[root@tridant root]# /usr/sbin/groupadd dhcpd
[root@thumper root]# adduser dhcpd -s /bin/nologin

Then build the directories:


[root@thumper root]# mkdir -m 700 /usr/local/dhcpd
[root@thumper root]# mkdir -p /usr/local/dhcpd/etc
[root@thumper root]# mkdir -p /usr/local/dhcpd/lib
[root@thumper root]# mkdir -p /usr/local/dhcpd/dev
[root@thumper root]# mkdir -p /usr/local/dhcpd/sbin
[root@thumper root]# mkdir -p /usr/local/dhcpd/var
[root@thumper root]# mkdir -p /usr/local/dhcpd/var/state
[root@thumper root]# mkdir -p /usr/local/dhcpd/var/state/dhcp
[root@thumper root]# mkdir -p /usr/local/dhcpd/var/run

Now we need to create some special files and copy the libraries the daemon needs in order to run. Let's start with the device files:

[root@thumper root]# mknod -m 666 /usr/local/dhcpd/dev/null c 1 3
[root@thumper root]# mknod -m 666 /usr/local/dhcpd/dev/random c 1 3

Now we copy the /etc/localtime file to /usr/local/dhcpd/etc so the syslog messages have the correct time stamp information.

[root@thumper root]# cp /etc/localtime /usr/local/dhcpd/etc/localtime

Once the device files are complete, we need to figure out what libraries we need and copy them into the chroot directory tree:

[root@tridant root]#cd /dhcp-3.0.1rc11/work.linux-2.2/server
[root@tridant server]# ldd dhcpd
        libc.so.6 => /lib/tls/libc.so.6 (0x4001e000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[root@tridant server]# cp /lib/ld-linux.so.2 /usr/local/dhcpd/lib/
[root@tridant server]# mkdir /usr/local/dhcpd/lib/tls/
[root@tridant server]# cp /lib/tls/libc.so.6 /usr/local/dhcpd/lib/tls/
[root@tridant server]# ln -s /usr/local/dhcpd/lib/tls/libc.so.6 
/usr/local/dhcpd/lib/libc.so.6

Now, let's install the daemon and create the dhcpd.leases file:


[root@tridant server]# cp dhcpd /usr/local/dhcpd/sbin/dhcp-3.0.1rc11
[root@tridant server]# /usr/local/dhcpd/var/state/dhcp/dhcpd.leases

Now that all of the files are in place, we need to set the user and group the permissions correctly:

[root@tridant server]# chgrp -R dhcpd /usr/local/dhcpd/
[root@tridant server]# chown -R dhcpd /usr/local/dhcpd/

With the daemon installed and the chroot jail built, all that's left to do is get the service started and set to run when the system boots. We also must set up our dhcp scopes in the dhcpd.conf file. But those are projects for next time, so stay tuned.

>>Read the rest of the series.

Rate this Tip
To rate tips, you must be a member of SearchNetworking.com.
Register now to start rating these tips. Log in if you are already a member.


Submit a Tip




Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us   



RELATED CONTENT
Wireless LAN Implementation
802.11n wireless APs bring IP video to sprawling Illinois high school
No data cable? Wireless mesh networking the answer for Wi-Fi backhaul
Integrated wireless and wired LAN: Brocade-Motorola deal ups the ante
802.11n WLAN architecture strategies: The 2.4 vs. 5 GHz band debate
802.11n upgrade: College ditches legacy network for new vendor
802.11n ratification will drive down wireless LAN prices
How does Wi-Fi ad-hoc mode react when 802.11n and legacy peers are present?
How to plan for 802.11n wireless LAN upgrades
Wireless LAN supply chain shortages: Vendors struggle to deliver
Can wireless adapters operate as client access points to make SoftAPs?

IP Networking
What is the definition of ATM (Asynchronous Transfer Mode)?
Do I have to disable DHCP on my router to create a DHCP server?
Windows Server 2008 IP routing configuration: Static and dynamic RIPv2
What is IP?
Connect your LAN to the Internet using static or dynamic NAT
Using tracert and TTL to troubleshoot network connectivity problems
Test your TCP/IP protocol stack to troubleshoot network connectivity
IP addressing and subnetting explained
Checking IP configuration to troubleshoot Windows network connectivity
Does IPv6 abandon TCP/IP fragmentation?

Routing and Switching
Dynamic IP routing and routing protocols
Monitor your network traffic with MRTG
How routers work: An overview for networking pros
Secure Cisco routers against IOS flaw attack
Network summarization -- Supernetting and wildcard masks
Routing: Five common, easily avoided errors
Router Expert: Building a WLAN proxy server, implementing ASR
Router Expert: Building a WLAN proxy server, implementing WPAD
Cisco IOS IP routing: Static routes
Router Expert: Building a WLAN proxy server, DHCP services: Part 2

RELATED GLOSSARY TERMS
Terms from Whatis.com − the technology online dictionary
802.11a  (SearchNetworking.com)
Asynchronous Pulsed Radiated Incident Light  (SearchNetworking.com)
beamforming  (SearchNetworking.com)
cognitive radio  (SearchNetworking.com)
direct sequence spread spectrum  (SearchNetworking.com)
frequency-hopping spread spectrum  (SearchNetworking.com)
phase-locked loop  (SearchNetworking.com)
radio frequency  (SearchNetworking.com)
wireless mesh network  (SearchNetworking.com)

RELATED RESOURCES
2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems
Search Bitpipe.com for the latest white papers and business webcasts
Whatis.com, the online computer dictionary

DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.



Networking Solutions for Business

Alcatel-Lucent Network Business Communications Solutions

About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
SEARCH 
TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of technology-specific websites, events and online magazines.

TechTarget Corporate Web Site  |  Media Kits  |  Site Map




All Rights Reserved, Copyright 2000 - 2009, TechTarget | Read our Privacy Policy
  TechTarget - The IT Media ROI Experts