April 2006 (#125):

• The Front Page, by Heather Stern
• News Bytes, by Howard Dyckoff
• A Brief Introduction to IP Cop, by Edgar Howell
• Implementing a Simple Char Device in Linux, by Ranjeet Mishra
• Digging Secure Tunnels with IPsec, by René Pfeiffer
• uClinux on Blackfin BF533 Stamp - A DSP Linux Port (Part 2), by Pramode C.E.
• How to Give Linux Away, by Scott Ruecker
• HelpDex, by Shane Collinge
• Ecol, by Javier Malonda

The Front Page

By Heather Stern

XTeddy's Summer Vacation

I've used xzoom, but if xzoom worked like they tell it in the movies, you might see something like this in our little plushy's photo collection.

---

Xteddy - a Gund "Tender Teddy" - was born in 1983, fell in love with Stegu's monitor in the 90's sometime, and since 1998 or so has been faithfully using Unix, though he has been seen on a Windows system now and then and even with a Macintosh once in a while. Lately he has been hanging out a lot in #fvwm on freenode, baking cookies, memorizing people's screenshots so as to be helpful, and indulging in a mocha now and then. The regulars there call him a little hug daemon - a ready source of hugs for all processes. Our Weekend Mechanic is one of his biggest fans.

Our regular readers may recall that Xteddy featured in our second cover art picture over a year ago (back in issue 111), but his good pal bear stood in for him.

This image was inspired by some chance comments from some real off-the-wall people on freenode - while it's pouring rain and snowing in my hills here in "sunny" California, they're enjoying a summer heat wave. Xteddy had this great idea for a summer vacation, and Tux brought his surfboard...

---

Tux has been Linux's mascot since shortly after the release of the 2.0 kernel. He's been known to be quite the fellow for the lady penguins, and A Brief History Of Tux - So Far will surely tell you more than you needed to know about this dashing fellow. All too often, it's a working vacation for him, but he's considering a hiking trip - hmmm, looks like some of the LBW folk are getting together for Easter, better join their mailing list - or a cruise sometime this Summer.

---

The beautiful beach shown in this image is Australia's Bells Beach. This image is from Owen Cliffe's summer vacation photos (I hope he doesn't mind) and a delightful little surfing image I found over at YoLinux.

YoLinux.com appears to be a tasty resource of material, in addition to having great cartoon art of Tux. Tux surfing came from their (come on, you can almost guess this without me telling you) Mozilla / Firefox Configuration for Web Surfing with Linux.

Whether Summer's just a short way ahead for you, or you're catching a few more waves before heading into autumn, here's to making Linux just a little more fun. Surf's up!

Talkback: Discuss this article with The Answer Gang

Heather is Linux Gazette's Technical Editor and The Answer Gang's Editor Gal.

---

Heather got started in computing before she quite got started learning English. By 8 she was a happy programmer, by 15 the system administrator for the home... Dad had finally broken down and gotten one of those personal computers, only to find it needed regular care and feeding like any other pet. Except it wasn't a Pet: it was one of those brands we find most everywhere today...

Heather is a hardware agnostic, but has spent more hours as a tech in Windows related tech support than most people have spent with their computers. (Got the pin, got the Jacket, got about a zillion T-shirts.) When she discovered Linux in 1993, it wasn't long before the home systems ran Linux regardless of what was in use at work.

By 1995 she was training others in using Linux - and in charge of all the "strange systems" at a (then) 90 million dollar company. Moving onwards, it's safe to say, Linux has been an excellent companion and breadwinner... She took over the HTML editing for "The Answer Guy" in issue 28, and has been slowly improving the preprocessing scripts she uses ever since.

Here's an autobiographical filksong she wrote called The Programmer's Daughter.

News Bytes

By Howard Dyckoff

Contents: News in General Conferences and Events Distro News Software and Product News Magical Realism....

Please submit your News Bytes items in plain text; other formats may be rejected without reading. [You have been warned!] A one- or two-paragraph summary plus a URL has a much higher chance of being published than an entire press release. Submit items to bytes@linuxgazette.net.

---

Talkback: Discuss this article with The Answer Gang

---

Howard Dyckoff is a long term IT professional with primary experience at Fortune 100 and 200 firms. Before his IT career, he worked for Aviation Week and Space Technology magazine and before that used to edit SkyCom, a newsletter for astronomers and rocketeers. He hails from the Republic of Brooklyn [and Polytechnic Institute] and now, after several trips to Himalayan mountain tops, resides in the SF Bay Area with a large book collection and several pet rocks.

A Brief Introduction to IP Cop

By Edgar Howell

Quite some time ago, a friend mentioned IP Cop to me. At the time, it sounded interesting, but other things kept getting in the way. Now that I have had a chance to play with it a bit, it has become extremely interesting and will likely be a permanent player in my computing environment.

What is IP Cop?

Whoops!
IP Cop?
What is that?
Well, it's a gateway, and a router, and a firewall, and does DHCP...
Actually, in essence, just about everything the small LAN needs to connect safely to the untamed Internet.

Yep, set up IP Cop and you can forget /etc/hosts.
Who cares about IP-addresses, anyhow?
Firewall? Why?
IP Cop is your interface to the outside world and has almost no services running - thus, little or almost nothing to attack.

Seriously, it is no substitute for caution and can't protect you from damage from within, trojans, viruses and the like. So let's look more closely at IP Cop and its installation and configuration and what it can do.

Essentially, as the name implies, IP Cop directs traffic at an intersection without traffic lights - in this case, IP traffic. It is a special-purpose Linux distribution that functions as an interface between you, your internal network(s), and the outside world - the Internet. To the Internet, it has a very small profile, offering almost no services. It also discriminates between your LAN (IP Cop terminology: green), a possible WLAN (blue), and a DMZ (orange).
Oh, yeah, the Internet itself is - surprise! - red.

But it goes far beyond this.
Once you have IP Cop in your network, you can forget assigning IP-addresses. Just tell it the address range to use and it will take over that task dynamically. Well, if the PCs you attach to your network are well-behaved enough to participate in DHCP (dynamic host configuration protocol). Or you can easily do it by hand.

Installation

The IP Cop Installation Manual says that it can be done in about 15 minutes after you gather the required information.
This is correct... but by now, I can probably get a SuSE distribution installed in not a whole lot more than that - blind-folded.
Unfortunately, never having done IP Cop before, it took me a little longer.

So please bear with me if in the following I go into a bit more detail than you might want. I certainly would have appreciated it and the guy next to you might.

IP Cop was designed to make use of modest resources to provide security. According to the installation manual it has been tested with a 386, 32 MB of RAM and 300 MB hard drive. In operation it requires neither keyboard nor monitor. And installation - as opposed to configuration - is equally minimalistic. Both keyboard and monitor are required but in text mode, probably only familiar to old DOS users.

Another consideration in your planning to install IP Cop is the fact that it takes over the entire hard drive. You will be warned and can cancel. IP Cop wants to be sole occupant and owner of the drive it lives on. But this is neat: a 4 GB drive is far more than it really requires and half that likely would be enough for a small LAN.

So here is what I went through during installation:

	Current config: GREEN
Done
	DHCP server configuration
<space>		(to enable)
	Start address:
192.168.1.1
	End address:
192.168.1.30
<OK>
	root password
root
	admin password
admin
	setup is complete
<OK>

This was enough to put IP Cop on the hard drive but it still requires a bit more information using text mode. So we log on as root and enter: setup. (In the following '[' and ']' indicate options on the screen that I ignored.)

[Keyboard mapping]
[Timezone]
[Hostname]
[Domain name]
ISDN configuration
	Protocol/Country
		Euro (EDSS1)
	[Set additional module parameters]
	ISDN card
		*AUTODETECT*
			AVM PCI/PNP (EXPERIMENTAL)
	Local phone number
		02206608913
	Enable ISDN
Networking
	Network configuration Type
		GREEN (RED is modem/IDSN)
	[Drivers and card assignments]
	[Address settings]
	[DNS and Gateway settings]

At this point IP Cop was functional on the PC and could be pinged from other PCs on the network.

Configuration

Besides offering almost no services outside, IP Cop strictly limits what root and admin can do. As root, one can log on to the PC on which IP Cop is running, but can only adjust a few things originally set up during the installation, as in ISDN vs modem and the like.

Administration takes place over the - now secure - network from another machine. So let's attach a notebook with SuSE 10 - as yet unused - and see what has to be done.

Since we haven't done anything about networking on this machine just yet, let's manually contact the DHCP server on IP Cop to get an IP-address and then check things out:

web@LohgoDell:~> su
Password:
LohgoDell:/home/web # dhcpcd -B
LohgoDell:/home/web # ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:14:22:DF:EB:80
          inet addr:192.168.1.30  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::214:22ff:fedf:eb80/64 Scope:Link
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:346 (346.0 b)  TX bytes:1814 (1.7 Kb)
          Interrupt:9
LohgoDell:/home/web # netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.1.0     *               255.255.255.0   U         0 0          0 eth0
loopback        *               255.0.0.0       U         0 0          0 lo
default         ipcop.lohgo     0.0.0.0         UG        0 0          0 eth0
LohgoDell:/home/web #

That looks really good, IP Cop even set itself up as the default gateway! Now we can tell Mozilla to access IP Cop at https://ipcop:445 so we can configure things:

Since we are sitting right next to the IP Cop machine, we know that the identity is correct and it's safe to permanently accept the certificate.

OK, no problem.

No problem there either.

The above is IP Cop's "home administrative window". Merely placing the cursor over any of the boxes in the second of the two lines beginning with "SYSTEM" produces a pop-down with relevant activities. To do anything other than connect (dial) and disconnect (hang up) you will have to enter the name and password of the administrator. My first order of business was System|Backup to save onto diskette what has been done so far.

Here's a little bit of what IP Cop put on the diskette.

At this point I went to Services|Proxy and checked "Enabled on green" and "Transparent on green". Remember that "green" is IP Cop terminology for our LAN, which it is to protect from the rest of the world. Then on to Services|Time Server where I replaced "pool.ntp.org" with something more reasonable:

Then under Network|Dialup it was necessary to establish a dialing profile and specify ISDN as the interface. Under Reconnection I checked "manual" and "Dial on Demand for DNS", and under Authentication I entered the user name and the password for the provider.

At this point establishing a connection to the Internet was very easy: on the home administrative window click on "connect":

And now from another window on the notebook it was possible to "ping -c 3 www.google.com"! All without touching /etc/hosts or doing anything to set up a network other than executing dhcpcd.

Random Remarks

Some of IP Cop's windows are too large to fit on the screen and require scrolling. This makes it easy to miss the "Save" and "Refresh" buttons at the bottom. Be sure to click on them when they are present or your changes will be quietly forgotten.

While you may want to select a different range of IP addresses for IP Cop to manage, it is otherwise a bad idea to change settings that deal with communication over the LAN. It is also a very bad idea to do that after initial configuration, since all administration takes place over a web interface on the network. If communication gets messed up, it may be impossible to repair. It isn't possible to do administration on the machine running IP Cop.

There is far more to IP Cop than what we have looked at here. It includes intrusion detection, numerous logs, traffic shaping and more.

At the moment I still have little experience with IP Cop but will be using it in the future. For the small office/home office (SOHO) it provides many benefits. My problem, as usual, was the documentation.

Not that it was lacking or meager. Essentially everything one needs to know was there. But it wasn't where I needed it!

I was reminded of a trip to a local bureaucracy a number of years ago. I looked at the signs, got in what I thought was the appropriate line, and when my turn came was told that I should be somewhere else. Yeah, the sign could mean that as well... but only to those used to that particular situation.

Bottom line: this software is really impressive, and the documentation includes the information you will need to install and configure and operate it. But - once again - navigating the documentation can be difficult.

Nonetheless, in the long run, for anyone with more than a two-machine installation, IP Cop should be well worth the effort.

Talkback: Discuss this article with The Answer Gang

---

Edgar is a consultant in the Cologne/Bonn area in Germany. His day job involves helping a customer with payroll, maintaining ancient IBM Assembler programs, some occasional COBOL, and otherwise using QMF, PL/1 and DB/2 under MVS.

(Note: mail that does not contain "linuxgazette" in the subject will be rejected.)

Implementing a Simple Char Device in Linux

By Ranjeet Mishra

Device

For the purpose of this article, let's consider a device to be a virtual represention, within Linux, of hardware that one would like to drive by using a piece of software. In the Linux world, devices are implemented in the form of modules. By using modules, we can provide device functionality that can be accessed from userspace.

A userspace entry point to a device is provided by a file node in the /dev directory. As we know, most of the things in Linux world are represented in the form of files. We can do [ls -l] on any device file, which will report the device type - character or block device, as well as its major number and minor number.

The type of device indicates the way data is written to a device. For a character device, it's done serially, byte by byte, and for a block device (e.g., hard disk) in the form of chunks of bytes - just as the name suggests.

The major number is assigned at the time of registering the device (using some module) and the kernel uses it to differentiate between various devices. The minor number is used by the device driver programmer to access different functions in the same device.

Looking at the number of files in the /dev directory, one might think that a very large number of devices are up and running in the system, but only few might be actually present and running. This can be seen by executing [cat /proc/devices]. (One can then see the major numbers and names of devices that are passed at the time of registering.)

Modules

Every device requires a module. Information about the currently loaded modules can be extracted from the kernel through [cat /proc/modules]. A module is nothing more than an object file that can be linked into a running kernel; to accomplish this, Linux provides the [insmod] utility. As an example, let's say that my module's object file is called my_dev.o; we can link it to the kernel using [insmod my_dev.o]. If insmod is successful we can see our module's entry using [cat /proc/modules], or [lsmod]. We can remove the module using the rmmod utility, which takes the object file name as an argument.

Writing a Module to register a Char device

First of all, we should know the basics of generating a module object file. The module uses kernel space functions and since the whole kernel code is written inside the __KERNEL__ directive we need to define it at time of compiling, or in our source code. We need to define the MODULE directive before anything else because Module functions are defined inside it. In order to link our module with the kernel, the version of the running kernel should match the version which the module is compiled with, or [insmod] will reject the request. This means that we must include the [include] directory present in the Linux source code of the appropriate version. Again, if my module file is called my_dev.c, a sample compiler instruction could be [gcc -D__KERNEL__ -I/usr/src/linux.2.6.7/linux/include -c my_dev.c]. A -D is used to define any directive symbol. Here we need to define __KERNEL__, since without this kernel-specific content won't be available to us.

The two basic functions for module operations are module_init and module_exit. The insmod utility loads the module and calls the function passed to module_init, and rmmod removes the module and calls function passed to module_exit. So inside module_init, we can do whatever we wish using our kernel API. For registering the char device, the kernel provides register_chrdev which takes three arguments, namely: the major number, the char string (which gives a tag name to the device), and the file operations struct address which defines all the stuff we would like to do with our char device. struct file_operations is defined in $(KERNELDIR)/linux/include/fs.h which declares the function pointers for basic operations like open, read, write, release, etc. One needs to implement whatever functions are necessary for the device. Finally, inside the function passed to module_exit, we should free the resources using unregister_chrdev which will be called when we do rmmod.

Below is the code listing where the device is nothing but an 80 byte chunk of memory.

Program Listing

• Makefile
• my_dev.c
• my_dev.h

Playing with the char device

Load the device using [insmod my_dev.o]. Look for the entry through /proc/modules and /proc/devices. Create a file node in /dev directory using [mknod /dev/my_device c 222 0]. Look inside the code, we have given the major number as 222. You might think that this number may clash with some other device - well, that's correct, but I have checked whether this number is already occupied by some other device. One could use dynamic allocation of the major number; for that we have to pass 0 as the argument.

Now we can read the data in the device using [cat /dev/my_device] and can write to our device using [echo "something" > /dev/my_device]. We can also write full-fledged userspace code to access our device using standard system calls of open, read, write, close, etc. Sample code is presented below.

-------------------------------------------
/* Sample code to access our char device */

#include<stdio.h>
#include<unistd.h>
#include<sys/types.h>
#include<sys/stat.h>
#include<fcntl.h>

int main()
{
	int fd=0,ret=0;
	char buff[80]="";
	
	fd=open("/dev/my_device",O_RDONLY);
	
	printf("fd :%d\n",fd);
	
	ret=read(fd,buff,10);
	buff[ret]='\0';
	
	printf("buff: %s ;length: %d bytes\n",buff,ret);
	close(fd);
}

-------------------------------------------
Output
fd: 3
buff: hi from kernel ;length: 14 bytes
-------------------------------------------

Conclusion

[ Note: a tarball containing all the code in this article can be downloaded here. ]

In this article I have tried to show how to use the kernel functions to register a character device, and how to invoke it from userspace. There are many issues that have not been touched upon here, such as the concurrency problem where we need to provide a semaphore for the device to do mutual exclusion as more than one process may try to access it. I will try to cover these issues in my future articles.

Talkback: Discuss this article with The Answer Gang

---

I am from New Delhi, India and am a great Linux fan and love the way Linux gives freedom to control the hardware gizmos. I am using Linux since the start of the new millennium but started digging into kernel sources recently after completing the B-Tech from IIT-Guwahati. It all began with a desire to create modules to control the peripheral devices and since then there is no turning back.

I would like to share my experiences and any interesting thing that comes across me during this Linux journey through Linux Gazette Articles.

Digging Secure Tunnels with IPsec

By René Pfeiffer

Introduction

The Internet was born using plain text and no encryption. For a long time the TCP/IP protocol suite had no mechanism for cryptographically protecting transported data. Encryption was added at the application layer — Netscape's Secure Socket Layer (SSL) being a famous example. The design process of IPv6 incorporated encryption into the protocol itself, and the IPsec (IP security) framework came into existence. IPsec provides encryption and authentication at the packet level. While IPsec is obligatory for IPv6, you can optionally use it with IPv4. The Linux 2.6.x kernel series added full IPsec functionality to the main source tree. In this article we will explore how we can use IPsec to build encrypted data paths between networked machines.

The Parts of IPsec

IPsec consists of a number of protocols. Encryption was not the only design criteria. Protection against replay attacks, detection of unauthorised packet modification and correctly authenticating the communication partners are also included in the design requirements. IPSec also offers methods to manage keys used for encrypted communication. The protocols by name have the following task.

• Authentication Header (AH)
  This protocol protects against replay attacks and makes sure that the communication partners are "correct" (it verifies authentication).
• Encapsulating Security Payload (ESP)
  This protocol provides encryption. It also protects against replay attacks and in addition ensures authentication.
• Internet Key Exchange (IKE)
  This is a hybrid protocol that establishes the security policies between two IPsec endpoints and provides the authentication keys for services such as IPsec. If you provide the keys manually, you don't need to use IKE.

AH and ESP packets transport data. Both are new protocols whose protocol numbers can be found in /etc/protocols. AH and ESP are managed by the kernel, while IKE is managed by a userspace program.

Preparing Kernel and System

In order to use IPsec your kernel needs to have some code options enabled. Most modern GNU/Linux distributions have IPsec-capable kernels. If you want to compile your own, make sure that you have the following options set:

• IPsec user configuration interface
• PF_KEY sockets
• IP: AH transformation
• IP: ESP transformation
• IP: IPComp transformation
• IP: tunnel transformation

These options can be found in the section Networking --> Networking options. You also have to enable some or all cryptographic ciphers in the Cryptographic options submenu. You will need at least MD5, SHA1, HMAC, DES, Triple DES EDE and AES. Remember, the encryption is handled by the kernel. If the kernel doesn't know about a cipher, it cannot use it. This is important in case you want to speak to other IPsec devices or hosts (such as MS Windows or Cisco machines). If you want to use IPsec with IPv6, then you have to make sure the IP transformations are set for IPv6 as well. I have two screenshots for you where you can see the make menuconfig menu: screenshot 1 and screenshot 2. If your machine acts as a router, you might wish to consider activating the IP: advanced router option, too. The kernel treats packet queues differently if you use the advanced routing option.

Now our kernel can handle IPsec. We now need some tools to make it work. We will need at least the ipsec-tools package. This is the name of the project and the Debian package. If we want to deal with key management and IKE, we need another program. The Linux IPsec stack can work together with pluto from the Openswan project, OpenBSD's isakmpd or racoon from the KAME project. The use of IKE is optional though. We will use racoon in our examples.

Manual Keying, Policies, Tunnel and Transport Mode

IPsec can be used to link networks via tunnels by using the so-called tunnel mode. In its simplest form it can also be used to encrypt network traffic between two or more hosts by using the transport mode. The only things you need for that are the keys and a way to tell the kernel which packets need to be sent via IPsec. The 2.6.x kernels have no special device for handling IPsec packets. Everything is sent over the already existing network interfaces. The Security Policy Database (SPD) decides which packets are to be handled by IPsec. In order to manipulate this database you need the setkey command from the ipsec-tools package. Usually you prepare a file with all the settings and activate it by using setkey -f /etc/setkey.conf. As an example, let's say we want to enable IPsec between the machines 10.0.0.23 and 10.0.0.42. The policy for telling the kernel looks like this:

#!/usr/sbin/setkey -f
#
# SPD for 10.0.0.23
#
spdadd 10.0.0.23 10.0.0.42 any -P out ipsec
       esp/transport//require
       ah/transport//require;

spdadd 10.0.0.42 10.0.0.23 any -P in ipsec
       esp/transport//require
       ah/transport//require;

The first policy states that any packet coming from 10.0.0.23 and leaving for 10.0.0.42 has to be encapsulated in IPsec packets. Transport mode has to be used. The policy is valid for ESP and AH packets alike (that's why we have to use spdadd twice). IPsec is mandatory as indicated by the keyword "require". If one of the hosts lacks the right key or hasn't initialised its SPD, there won't be any traffic because it can't be encrypted. The second policy is the first one reversed. The IP addresses are swapped and the direction is changed from out to in.

So the kernel knows when to use IPsec. There are still no keys. Apart from that I told you about authentication checks that the IPsec protocols can do for us. Our setkey.conf needs to be extended to include this information as well. setkey also defines the Security Association Database (SAD). The SAD tells the kernel who our neigbours are and how we can make sure that we are not talking to an impostor. Extending our setkey.conf by the following lines enables authentication and encryption. In addition to that we supply the keys for every host.

# AH SAD entries with 160 bit keys
add 10.0.0.23 10.0.0.42 ah 0x200 -A hmac-sha1 0x46915c30ed7e2465b42861b6ab19f2772813020c;
add 10.0.0.42 10.0.0.23 ah 0x300 -A hmac-sha1 0xc4dac594f8228e0b94a54758f7fbf2fdf4e37f3e;

# ESP SAD entries with 192 bit keys
add 10.0.0.23 10.0.0.42 esp 0x201 -E rijndael-cbc 0xa3993b3dfc41ef0a1aa8d168a8bf2c27e48249ac17b61e09;
add 10.0.0.42 10.0.0.23 esp 0x301 -E rijndael-cbc 0x8f6498928ba354bd45cfad147f54c67b3b742896b3bafc02;

Again we have a line for every direction. The IP addresses are reversed, but we use a different key for every IP and protocol. The bit length of the key corresponds to the authentication or encryption algorithm used. The switches -A and -E indicate the algorithm to use for AH and ESP respectively. hmac-sha1 requires a key length of 160 bits or 20 bytes. rijndael-cbc can be used with 128, 192 or 256 bits. The example uses 192 bits or 24 bytes. The man page of setkey has a table with all possible values for every supported algorithm. Bear in mind that the kernel must also have a module for the algorithm in its cryptographic options or else you cannot use this particular algorithm. The hexadecimal value behind the protocol name is called Security Parameters Index (SPI). The SPI identifies a set of parameters used for the IPsec connection in combination with the IP addresses involved. When doing manual keying, make sure that the SPIs are unique. Speaking of unique, make sure that your keys are unique and random. Never use any keys that have been published! I used Ralf's method from the IPsec HOWTO to extract the sample keys from the Linux random device.

# dd if=/dev/random count=24 bs=1 | xxd -ps
24+0 records in
24+0 records out
8f6498928ba354bd45cfad147f54c67b3b742896b3bafc02
24 bytes transferred in 0.000180 seconds (133298 bytes/sec)

Set count to the desired byte amount. The command xxd used to convert the binary output from the device is part of the vim package.

Testing Transport Mode

We are now ready to test our configuration. In order to do this you will need the full setkey.conf. I only added two lines that clear the SAD and SPD before loading new rules, just to be sure.

flush;
spdflush;

Copy it to your hosts. Be careful, we've only created the setkey.conf for 10.0.0.23. If you use this file on 10.0.0.42 you have to swap the policy for the direction of the packet flow (the in and out keywords for the SPD). Now use a root shell on 10.0.0.23 and enter the command:

setkey -f /path/to/setkey.conf

Check if you can ping 10.0.0.42. This should not be possible, because we told 10.0.0.23 to communicate with 10.0.0.42 over IPsec only. If you run the setkey command on 10.0.0.42 as well, you should be able to ping 10.0.0.42 from 10.0.0.23. Take a look with your favourite sniffer in order to make sure the kernel isn't playing unencrypted tricks on you. If you use an ICMP ping, the sniffer should only show you encrypted AH or ESP packets. The same goes for TCP and UDP transmissions.

Next time we will configure an IPsec tunnel to connect two different networks and we will take a look at automatic keying with X.509 certificates.

Further reading

• The official IPsec Howto for Linux
• An Introduction to IP Security (IPSec) Encryption
• IPsec-Tools
• KAME Project
• Openswan

Talkback: Discuss this article with The Answer Gang

---

René was born in the year of Atari's founding and the release of the game Pong. Since his early youth he started taking things apart to see how they work. He couldn't even pass construction sites without looking for electrical wires that might seem interesting. The interest in computing began when his grandfather bought him a 4-bit microcontroller with 256 byte RAM and a 4096 byte operating system, forcing him to learn assembler before any other language.

After finishing school he went to university in order to study physics. He then collected experiences with a C64, a C128, two Amigas, DEC's Ultrix, OpenVMS and finally GNU/Linux on a PC in 1997. He is using Linux since this day and still likes to take things apart und put them together again. Freedom of tinkering brought him close to the Free Software movement, where he puts some effort into the right to understand how things work. He is also involved with civil liberty groups focusing on digital rights.

Since 1999 he is offering his skills as a freelancer. His main activities include system/network administration, scripting and consulting. In 2001 he started to give lectures on computer security at the Technikum Wien. Apart from staring into computer monitors, inspecting hardware and talking to network equipment he is fond of scuba diving, writing, or photographing with his digital camera. He would like to have a go at storytelling and roleplaying again as soon as he finds some more spare time on his backup devices.

uClinux on Blackfin BF533 Stamp - A DSP Linux Port (Part 2)

By Pramode C.E.

In Part 1 of this series, we had examined how to connect a BF533 Stamp board to our GNU/Linux machine and run a simple `hello, world' program. In this article, we shall look at writing simple device drivers to access the LED's and buttons on the board as well as manipulating the on-chip watchdog timer.

Compiling the uClinux kernel

You can download the uClinux kernel (with Blackfin support) from blackfin.uclinux.org/projects/uclinux533 - I am using the 2005R3 release.

Before you start compiling the kernel, make sure that you have set up the GNU toolchain for the Blackfin processor as described in Part 1; the Blackfin uClinux documentation project offers more information.

The kernel compilation process is documented in detail here - it's fairly standard procedure (make menuconfig; make). You can simply use the default settings most of the time; the only change I made was enabling loadable module support.

The kernel binary (in ELF format) will be present under the folder uClinux-dist/images; it will be a file named `linux'. Don't be surprised by the size of the file (around 5.6Mb in my case) - the file contains not only kernel code but also an elementary root file system which gets loaded onto a ramdisk when the board is powered up! It seems that this file system is built from the directory tree rooted at uClinux-dist/romfs/.

Downloading the kernel onto the board

Connect the Stamp board to the serial port of the PC and fire up `minicom'. As soon as you feed power to the board, a boot loader program called `uboot' starts running looking for keystrokes out of the serial port - if you hit `enter' in 5 seconds, `uboot' will suspend the booting process and display a prompt where you can enter some simple commands. The `print' command should show you several lines of the form `name=value'. We are interested in two such `names'; they are `serverip' and `ipaddr'. We shall assign values to them by typing:

set ipaddr 192.168.1.1
set serverip 192.168.1.2

The name `ipaddr' refers to the IP address assigned to the Ethernet controller on the stamp board and `serverip' refers to the IP address of the Ethernet card on the PC to which the board is connected. You should now check whether `uboot' is able to communicate with the PC via the Ethernet link by running:

ping 192.168.1.2

We have to set up a TFTP server on the PC and verify that it is working properly. As I am using Ubuntu, I had to `apt-get' three packages - tftp, tftpd and xinetd. (Note: the `apt-get' command is used to download and install packages on Debian GNU/Linux systems). The `xinetd' program should be instructed to start the TFTP daemon by creating a file called /etc/xinetd.d/tftp which contains entries of the form:

service tftp
{
	socket_type		= dgram
	protocol	= udp
	wait		= yes
	user		= root
	server 	= /usr/sbin/in.tftpd
	server_args = -s /boot
	wait		= yes
	disable	= no
}

The `server_args' line specifies that files to be download via TFTP should be placed under /boot.

Once this file is created, we should verify whether everything is working fine by starting `xinetd', copying the Blackfin uClinux kernel image to /boot and running tftp (on the PC):

$ cd /tmp
$ tftp localhost
tftp> get linux
Received 5676668 bytes in 0.9 seconds

Once we have verified that the Ethernet link between our GNU/Linux machine and the Stamp board is working OK (by pinging from uboot) and that the TFTP server on the PC also has been configured properly, we can reboot the board, hit `enter', get into the `uboot' prompt and type:

tftpboot 0x1000000 linux

This will download the newly created kernel image (called `linux') from /boot of our PC to the memory of the stamp board. Once this is over, we should type:

bootelf 0x1000000

and the board will boot with the downloaded kernel. Once we log onto the board, we should again configure the Ethernet controller with the proper ip address using the `ifconfig' command.

More info regarding `uboot' can be obtained from here.

Our first kernel module

Here is a simple `hello, world' loadable kernel module:

[Listing 1]

#include <linux/module.h>

int init_module()
{
	printk("Hello...\n");
	return 0;
}

void cleanup_module()
{
	printk("World...\n");
}

This module can be compiled with the help of the following `Makefile':

[Listing 2]

obj-m:=test.o
default:
	make -C /usr/local/src/uClinux-dist/linux-2.6.x/ M=`pwd`

We can `ftp' the resulting object file `test.ko' onto the stamp board and load it into the kernel by running `insmod ./test.ko'.

A minor problem

It seems that the file system on the board does not have the `mknod' command. It's very easy to build one ourselves:

[Listing 3]

#include <sys/types.h>
#include  <sys/stat.h>

main(int argc, char *argv[])
{
	int r;
	if(argc != 4) {
		printf("Usage: mknod file major minor");
		exit(1);
	}
	r=mknod(argv[1], S_IFCHR|0777, makedev(atoi(argv[2]), atoi(argv[3])));
	if(r < 0) {
		perror("mknod");
		exit(1);
	}
}

The code should be compiled like this:

bfin-uclinux-gcc -Wl,elf2flt mknod.c -o mknod

It can be ftp'd onto the board or can be made part of the file system by copying to uClinux-dist/romfs/bin and building the kernel once again.

Blinking LED's

The BF533 Stamp board comes with 3 LED's and 3 buttons attached to a few General Purpose I/O pins (or `programmable flags' PF0 to PF15 as per the Blackfin manual) - the LED's are on PF2, PF3 and PF4. The GPIO pins can be programmed via certain memory mapped registers. The pin direction (input or output) can be set by writing to a `direction register' at location 0xFFC00730 - if a bit of this register is `set', the corresponding pin acts as output and if it is clear, the pin acts as an input pin; for example, writing:

*((unsigned short*)0xFFC00730) = 0x1;

will result in PF0 being configured as output and all others as input.

The uClinux kernel for the Blackfin processor comes with macros using which we can access all these registers - the above expression can be rewritten as:

*pFIO_DIR = 0x1;

There are two other registers which we can use to set or clear the GPIO pins - writing a 1 to a bit of the FIO_FLAG_S register results in the corresponding GPIO pin going high and writing a 1 to a bit of the FIO_FLAG_C register results in the pin going low. All these registers can be accessed only from kernel space. Listing 4 is a simple character driver which sets or clears PF2 depending on a value it receives from user space. The file drivers/char/pflags.c in the Blackfin uClinux kernel source is a more complete implementation.

Programming the watchdog

A watchdog timer is a critical part of many applications which depend on the reliable operation of computer software - it's basically a timer which counts down to zero and resets the microprocessor when the count reaches zero - follow this link for more information.

The Blackfin CPU has a 32 bit watchdog timer. The registers associated with this timer are the watchdog count, status and control registers. The status register holds the current watchdog count value which gets decremented by one every clock cycle (the system clock is 100MHz on my board). Writing any value to this register when the watchdog is enabled results in the register being loaded with the value of the count register. Writing a value to the count register when the watchdog is disabled results in that value being copied to the status register. When the status register value becomes zero, the watchdog triggers an event which was previously selected by writing to a few bits of the control register (usually a system reset). The watchdog is enabled by writing any value other than 0xAD to bits D4 to D11 of the control register. Bits D1 and D2 of the control register decide the event to be triggered on timeout - setting the value to 00 chooses `system reset' as the event.

The working of the watchdog can be tested by writing a simple module whose init_module function contains the following lines:

*pWDOG_CNT = 500000000 // timeout in 5 seconds
*pWDOG_CTL = 0; // choose `reset' event and
 // enable watchdog.

The system will reboot five seconds after inserting the module!

Conclusion

We have seen how to do simple kernel programming on the BF533 Stamp board. Myself and Jesslyn (my student and author of the first part) would love to share with LG readers many more experiments using the Stamp board in later parts of this series!

Talkback: Discuss this article with The Answer Gang

---

As a student, I am constantly on the lookout for fun and exciting things to do with my GNU/Linux machine. As a teacher, I try to convey the joy of experimentation, exploration, and discovery to my students. You can read about my adventures with teaching and learning here.

How to Give Linux Away

By Scott Ruecker

As a community, we would like to see large computer manufacturers sell PCs with Linux already on them. Is this the only option worth considering?

I work as a sales representative for one of the large PC manufacturers, at many different technology retail stores. Three years ago, I heard about Open Source and Linux. My first exposure came in the form of the Firefox browser. When I speak with customers, I talk about my experiences using Linux. I ask them if their computer is running slow, and the answer is always "Yes". They tell me how it is running really slow no matter what they do, or how they can't seem to create any free room on their hard drive.

People often ask me if MS-Office comes with the computer, and I say "No, but have you ever heard of OpenOffice.org?" I tell them how it can read and save the MS formats, and how I have been using it at college even though MS-Office dominates on campus. I tell them what it can do and that it doesn't cost a dime. That usually gets their attention.

I also will often hear the customer say, "As soon as I get home I am going to throw the old computer away". What I say at that point - and what I think we should all be saying - is "You know that old computer that can't run Windows the way you need it to anymore? Give it to me, and I'll fix it up and give it to someone or some family that does not have a computer."

I have had several conversations with customers that have led to them giving me their old computers when buying a new one. I fixed one up and gave it to a friend of mine who lives on a ranch in Colorado, and because of it he has been able to stay in contact with friends and family here in Phoenix. What if we all did that? All of us? What if everyone who used Linux fixed up an old computer, configured it for common uses, and gave it to someone or some family who did not have one? Think about it.

We would not only double the number of people who use Linux, but have a very positive effect on society. We all know that having a computer in the home makes everyone who uses it read better. It is my belief that that the ability to read well does as much or more for that person as going to school. Someone who knows how to read can find what they need to learn the skills and teach themselves anything they want. If a child can be positively affected by having a computer, so can an entire family.

I am not trying to proclaim some kind of "call to arms" to join me in some crusade - not at all. I just want to share some of the things I say, and some of the questions I ask, that have introduced Open Source Software to new people in a positive way. As the saying goes, "You never get a second chance to make a first impression". I hope that what I say in this article will help you make that first impression a good one. Over the last two years, I have gone from not knowing how to pronounce "Linux" correctly to... well, still not knowing how to pronounce SuSE correctly.

You gotta admit, though - fixing up and giving away computers is at least good karma (I hope).

Part 2 - Changing Opinions

If someone has already made up their mind not to give something new a try, then there is no sense in wasting your time trying make them re-think their decision. However, there are plenty of other people around - and some of them are only held back by excuses.

Among those who give such excuses, there are those who are just repeating what they have heard or read and really do not have any of their own information or experience to draw from. They are easy to pick out - once you have heard hundreds of different people say almost the exact same thing like I have. It's not that hard; all you have to do is ask a few questions and you can easily determine if they are just repeating what they have heard or actually have their own reasons for not wanting to give Linux a try.

Here is what I do:

1. Ask them if they use IE, WMP (Windows Media Player), Quicktime, iTunes, Word, Excel, PowerPoint, Access... and always ask them how many types of Anti-Virus programs they are using. Make sure that you always end with the Anti-Viruses - trust me, I'll tell you why in a moment.

   You will find that roughly 99% of the people you talk to do not even use all of those programs I listed - and very, very few use any programs that are not on that list. Most people only use IE, Word, WMP, and maybe Quicktime a little - and whatever Anti-Virus software they have installed.

2. Ask them how many types of Anti-Virus programs they use.

After you ask, most people will repeat it back to you saying, "How many types of Anti-Virus programs do I use?" "Do you have more than one Anti-Virus program on your computer?" Some people do not - but many do use more than one. This is where I tell them,

"When I ran Windows, I used Ad-Aware, Zone Alarm, AVG, McAfee (the free version), Spybot, Spywareblaster, Spyware-Doctor, Webroot, and Registry Mechanic."

Which is true: I had all of them on my computer at the same time and between them I could keep my system fairly safe. Fairly.

3. Ask them if they have ever heard of Firefox.

Some will ask, "What is Firefox?" - "Firefox is a browser." "What is a browser?" - "It is a program that you use to surf the Internet." "You mean like IE?" - "Exactly, only it is a lot safer than IE." This is where I go into the features, how it imports favorites and why it is safer than IE. Something like:

"Because it is not a part of the operating system, it is a lot harder for spyware to damage your system when using Firefox."

Again, technically true.

4. Ask them if they have ever heard of OpenOffice.org.

Then say to them,

"OpenOffice allows you to view, modify, save, and send the changed document in MS format and it does not cost $500... actually, it does not cost a dime."

I will tell you that a lot of people are not happy when they buy a new computer and then are told by the store employee that it does not come with Word or Office - and that if they want it, it will cost hundreds of dollars. If you can get people to listen to you about OpenOffice's compatibility features and price, of lack thereof, many will not leave until they get the web address from you.

If I can get most of the way through these steps, then I know I can re-visit the Linux question and stand a chance of success. I can show them that it just might be something that could work for them. When I explain the Root and User separation built into Linux - how it makes the computer safer and that they will not need multiple Anti-Virus programs or have to re-format their hard drive every six months because Windows does not actually delete anything - they start to actually look at the retail Linux box I have already handed them.

Is this system perfect? No. You may talk about one thing before another or skip over something or do it in reverse - every conversation is unique. I want to inform them of choices they may not have known of, open them up to new ways of doing something and not make them feel like they were wrong or stupid. If I do it right, they do not even feel their own shift in opinion or preference.

I could expand on this some more, and I will, but I thought that giving you the basics of what I do might help others in getting past the FUD without alienating the person you are talking to. Changing someone's opinion or stance without making them feel stupid takes practice - and I get a lot of practice.

Talkback: Discuss this article with The Answer Gang

---

Scott Ruecker a.k.a. "sharkscott" lives in Phoenix, Arizona; he is a Special Education Major at Arizona State University and claims to have taken way too many History Classes. He works as a sales rep for a large OEM, tries to pronounce "Linux" correctly and plays Drums in a rock-n-roll band every Saturday night.

First exposed to OSS when he heard about "This Linux Thing" in 2002. Got his start on the Fedora Cores, Ku-Ubuntu and then to SuSE. Has used SuSE since 9.1 and thinks he likes it.

HelpDex

By Shane Collinge

These images are scaled down to minimize horizontal scrolling.

All HelpDex cartoons are at Shane's web site, www.shanecollinge.com.

Talkback: Discuss this article with The Answer Gang

---

Part computer programmer, part cartoonist, part Mars Bar. At night, he runs around in his brightly-coloured underwear fighting criminals. During the day... well, he just runs around in his brightly-coloured underwear. He eats when he's hungry and sleeps when he's sleepy.

Ecol

By Javier Malonda

The Ecol comic strip is written for escomposlinux.org (ECOL), the web site that supports es.comp.os.linux, the Spanish USENET newsgroup for Linux. The strips are drawn in Spanish and then translated to English by the author.

These images are scaled down to minimize horizontal scrolling.

All Ecol cartoons are at tira.escomposlinux.org (Spanish), comic.escomposlinux.org (English) and http://tira.puntbarra.com/ (Catalan). The Catalan version is translated by the people who run the site; only a few episodes are currently available.

These cartoons are copyright Javier Malonda. They may be copied, linked or distributed by any means. However, you may not distribute modifications. If you link to a cartoon, please notify Javier, who would appreciate hearing from you.

Talkback: Discuss this article with The Answer Gang

---