Router Expert: Building a WLAN proxy server, Part 2

Read about Michael

What is a kernel?
In essence, the kernel is the Unix/Linux operating system. The kernel controls the hardware, I/O, memory management, system and user processes. On whole, it manages all the critical aspect of the computer necessary for operation. Applications, such as shells, services like sshd, text editors and the like all operate "around" the kernel, which allocates the processor and memory resources the programs need to function, hence the name kernel. All Linux distributions come with a kernel. But, like the OpenSSL and OpenSSH distributions, the kernel on the Linux distribution is often behind the current build. Each new kernel build or sub-build adds new feature and driver support, along with correcting any bugs or security vulnerabilities. We are building a kernel to ensure that the networking support we need to support our proxy server is in place. For some, building a kernel is a somewhat daunting task, this was true with earlier versions of the Linux kernel. Since the release of the 2.4 kernel, which is now essentially "General Deployment," there are a number of resources on Web on how to build a Linux kernel. Our goal is cover all of the elements you need to include in the kernel build to support the proxy server environment.

There are three basic steps to building the kernel: Prep, compile and install.

Before starting the kernel build, you need to get some basic information on the server your building the kernel for. There are two resources you can use to gather this data. The first is the output /bin/dmesg that prints the output of the kernel load process, allowing you to see which drivers were loaded by the kernel that is currently running. The /bin/dmesg output is sent right to command shell; to save it to a text file, you can redirect the output. Here is the syntax to save the output to a file and then print the output to the shell:

/bin/dmesg > harddep.txt; more harddep.txt

Here are some other command output options you can use with /bin/dmesg to collect specfic information.

• To determine the Ethernet hardware: /bin/dmesg | more | grep eth
• To determine the root partition: /bin/dmesg | more | grep "/dev/hd"
• To determine the file-system type: /bin/dmesg | more | grep EXT

The other command is /sbin/lspci, which displays information about all of the PCI busses on the server and the cards connected to them. It operates the same way the /bin/dmesg does, here is command syntax that saves the output and prints it to the command shell:

/sbin/lspci > pci_info.txt; more pci_info.txt 

Once you have collected and reviewed the hardware information its time to unpack the kernel source tree. Now, the location of the kernel source distribution needs to be in a specific location /usr/src/kernel. Now since is fair to say that more the one kernel distribution could be on a system. The best approach is to untar the kernel distribution, move it to the /usr/src directory and then create a symbolic link from the distribution to /usr/src/linux:

1. tar xvfz linux-2.4.31.tar.gz
2. mv linux-2.4.31 /usr/src
3. cd /usr/src
4. ln –s /usr/src/linux-2.4.31 /usr/src/linux
5. cd /usr/src/linux

Once you are in the top level of the kernel source tree, the first command you want to run is:

make mrproper

make config 
make oldconfig 
make menuconfig
make xconfig

The make config option is the most tedious; it is a shell script that asks configuration questions sequentially. Simple to use, unless you make a mistake, then you need to start all over again. The make oldconfig option reads an existing .config file (located in the top of the kernel source tree) and uses that as a basis to build a new kernel config file. What is nice about this option is that if there are any inconsistencies between the old config and new kernel options you will be prompted to resolve them. This is a great way to start building a config file. Once the basics have been "filled" in you can use make menuconfig, an ncursus shell menu to tweak the config. Or, if you have XWindows (which you don't) installed you can use the make xconfig option to get a GUI menu interface. Since this a new kernel, use the make menuconfig option.

make menuconfig

Selecting which options to build is largely dependent on the type of hardware your server is comprised of. Here is the Main Menu for the 2.4.31 kernel distribution:

If you have a basic Pentium/AMD server with IDE and built-in graphics you can go with the default settings for the following:

Loadable Module Support: Enabled by default, provides the ability to load drivers and kernel level services. The /etc/modules.conf file defines which modules are loaded at boot. The modules themselves are located in /lib/modules/.

Processor type and features: Specifies which processor the kernel is built for. Pentium-III/Celeron with Symmetric multi-processing support is defined by default. To verify which CPU processor your server is running. Check /proc/cpuinfo, using the command:

cat /proc/cpuinfo

Block Devices: Defines options for legacy Hard Disk support, certain types of Hard Drive arrays, RAM Disk and floppy support.

Multi-device support (RAID and LVM) : Defines support for RAID support.

ATA/IDE/MFM/RLL support: Defines options pertaining to IDE/ATA support, IDE-ATA-2 and IDE/ATAPI support is enabled by default.

SCSI support: Defines options for SCSI support. If your hard disk, CD ROM, etc is SCSI you will need to build in support for these devices along with the SCSI controller into the kernel.

File Systems: Defines support for file systems quotas, Ext2, Ext3, DOS, NFS, etc. The Ext3 file system is used by the Red Hat distribution, we need to build in support for the Ext3 file in the kernel:

File systems ---->
   [*] Quota support
   [*] Ext3 journaling file system support
   [*] Microsoft Joliet CDROM extensions

Networking Options: Defines kernel supported network options, such as IP firewalling, 802.1Q and 802.1d support. This option is the focal point for the type of server we are building. To ensure speed and performance the following options are built into the kernel:

Networking options  --->
<*> Packet socket

[*] Network packet filtering (replaces ipchains) 
[*]  Socket Filtering 
[*] IP: advanced router
  [*] IP: policy routing
  [*] IP: use TOS value as routing key 
  [*] IP: verbose route monitoring 
[*] IP: tunneling                                                                  
[*] IP: GRE tunnels over IP
[*] IP: broadcast GRE over IP (NEW)
  IP: Netfilter Configuration  --->
   [*] Connection tracking (required for masq/NAT) (NEW) 
   [*] IP tables support (required for filtering/masq/NAT) (NEW) 
   [*] MAC address match support
   [*] Packet type match support
   [*] Multiple port match support
   [*] tcpmss match support
   [*] Connection state match support
   [*] Connection tracking match support
   [*] Packet filtering
   [*] Full NAT 
    [*] MASQUERADE target support
    [*] REDIRECT target support
   [*] ARP tables support 
    [*]ARP packet filtering
 [*] 802.1Q VLAN Support 
 [*] 802.1d Ethernet Bridging

Networking Device Support: Defines the kernel support for network device drivers. This option is particularly critical because without the proper driver support the kernel will not recognize the servers network interfaces. The output from the /bin/dmesg | more | grep eth command will provide you with information you need to select the correct drivers to build into the kernel.

Once the kernel build options have been defined. The last step before building is to assign a unique kernel name. This is done by setting the name in EXTRAVERSION field of the default Makefile located in the root of the kernel distribution tree.

VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 31
EXTRAVERSION = -SPS-V2

KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)

There are two reasons for customizing the kernel name. First, it makes it easy identify the kernel. Second, the full kernel name is used to identify the kernel modules. Using custom names for each kernel version build from the same core kernel source makes it possible to have different module trees for each variation. Without the custom variable, each new install with overwrites the modules of the previous build.

With the kernel build customizations complete, the build process is a four-step process:

1. make depend – builds any supporting components needed by the kernel.
2. make bzImage – builds a compressed version of the kernel file.
3. make modules – builds any loadable kernel modules defined as part of the kernel configuration.
4. make install modules – builds the module directory in /lib/modules and copies the modules over.

Installing the new kernel involves a few steps. First, the new compressed kernel image file, usr/src/linux/arch/i386/boot/bzImage needs to be installed in the /boot directory, renamed in the following format:
vmlinuz.version.patchlevel.sublevel.extravesrion.

cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.4.31-SPS-V2

Once the new kernel file is installed, the next step is to copy over the System.map file. Located in the root of the kernel source tree, into the /boot directory using the same naming format used for the kernel image.

 cp /usr/src/linux/System.map /boot/System.map-2.4.31-SPS-V2

Then new symbolic links for the /boot/System.map and /boot/vmlinuz point to the newly installed System.map and kernel files.

rm -f  /boot/System.map
ln -s /boot/System.map-2.4.31-SPS-V2 /boot/System.map
ln –s /boot/vmlinuz-2.4.31-SPS-V2 /boot/vmlinuz

The last step is to update the boot loader configuration and add our new kernel into the boot loader menu. We configured our server to use the GRUB boot loader. To add our kernel, we need to edit the boot loader configuration file /etc/grub.conf. The file will have the configuration for the kernel we booted the system up with.

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/hda2
#          initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title Red Hat Enterprise Linux WS (2.4.21-4.EL)
        root (hd0,0)
        kernel /vmlinuz-2.4.21-4.EL ro root=LABEL=/
        initrd /initrd-2.4.21-4.EL.img

Now we need install our kernel boot information above the default configuration so, the server will boot the new kernel by default when the system is rebooted. This is easy to do, by inserting our configuration information, bellow the splashimage= definition. We can use the current boot configuration as a template and just change the kernel definition and provide a new boot loader menu title:

title WLAN Proxy Server Image (2.4.31)
        root (hd0,0)
        kernel /vlminuz-2.4.31 ro root= LABEL=/

The syntax of GRUB is a little confusing. For starters kernel definition assumes /boot as the root of the directory tree. So in the example above the kernel file location is an actually /boot/vlminuz-2.4.31. When defining drives and partitions, GRUB counts drive controllers and drive partitions starting with 0, not 1. So above the actual location of the root partition is on the first controller, first partition. And, were done! Our kernel is built and installed -- now all we need to do is reboot.

If all went as planned you should be running on a freshly minted kernel and are now ready to start the next phase of the server build, configuring networking and building and configuring ISC DHCP, BIND (DNS), SQUID (HTTP Proxy) and Web Proxy Automatic Discovery (WPAD) service. Stay tuned…

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. Digg This!     StumbleUpon     Del.icio.us    RELATED CONTENT Routing and Switching How to test LAN switch energy efficiency Testing LAN switch power consumption: A best practices guide 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 Wireless LAN Implementation University tackles large-scale 802.11n wireless network management Why is my network adapter not working after a Vista Business upgrade? How many wireless base stations can connect to 802.11g access points? 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? Network Hardware Unified wireless network still a work in progress for vendors 3Com acquisition confirms HP-Cisco battle for China Juniper to CIOs: Invest in internal cloud computing networks 802.11n wireless APs bring IP video to sprawling Illinois high school 802.11n upgrade: College ditches legacy network for new vendor Network device management overload: Engineers managing too many boxes What is network infrastructure and what is a hybrid network? What preventative maintenance procedures for network devices exist? Can wireless adapters operate as client access points to make SoftAPs? Is there VLAN software recommend for Realtek NICs? Network Hardware Research 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) patch antenna  (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.