|
Host Services
After the software is installed, some additional configuration steps are necessary to get the packages in running order. This part goes through configuring each of the services and how to perform some testing and trouble shooting. The time you devote to making sure the services work as expected is well spent, because the boot loader provides little feedback in the event of failure. Knowing that software is in a working state removes one thing from the list when you're troubleshooting.
Turn Off Your Firewall
Some systems run a firewall by default; this should be turned off. The system used for booting an embedded board shouldn't be on the public side of the firewall, subject to attack from the general Internet. Turning off the firewall is as easy as
$ sudo /etc/init.d/iptables off
That command turns off the firewall until the next reboot. To turn it off forever, delete the symlink used to run the service during system startup:
$ sudo chkconfig iptables off
Firewalls work silently, so if the board attempts a TFTP connection that the firewall blocks, the board reports that it can't make a connection. This is accurate but not a complete description.
TFTP
TFTP, a lightweight file transfer protocol, uses other software to get running: xinetd. The xinetd program performs a neat job: it waits for network connections on ports (as specified in the /etc/services file) and, when a connection occurs, remaps the standard in and out to the read and write of the network connection. This trick means that the program run by xinetd has code that uses file semantics (like scanf() and printf()) and reads and writes over a network connection. Not all distributions have xinetd installed by default, so you may need to install it using your distribution's package-management system. The configuration file for the TFTP service handled by xinetd resides at /etc/xinetd.d/tftp. Listing the files reveals the following:
# default: off
# description: The tftp server serves files using the trivial file transfer
# protocol. The tftp protocol is often used to boot diskless
# workstations, download configuration files to network-aware printers,
# and to start the installation process for some operating systems.
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
disable = yes
per_source = 11s
cps = 100 2
}
The lines of interest in this file are server_args, which indicates the directory where TFTP stores and looks for files. The kernel that is downloaded to the board needs to be placed in this directory. Change the default value /tftpboot to something more convenient for you. The second line of interest is
disable = yes
At first glance, you may think that yes means it's enabled, but it means the opposite. Sneaky! Change this line to read
disable = no
After you've made the changes, restart the xinet.d service:
$ sudo /etc/init.d/xinet.d restart
If the /etc/xinetd.d/tftp file contains errors, a message appears. Testing the TFTP server is as easy as creating a file and trying a put and a get:
$ date > /tmp/tftptest $ tftp tftp> connect localhost tftp> put /tmp/tftptest tftp> get tftptest /tmp/get.tftptest
You can try the same test on another computer on the network, to ensure that you can connect to the host from another machine (across the wire, as a network-person would say). If TFTP works from localhost but not from another computer, chances are the firewall is still running. Stop this service, and try again.
DHCP
Some boards request an IP address during initialization. If the board is using an NFS-mounted file system, it certainly needs the network stack up and running. The DCHP protocol works by having a host send a broadcast packet requesting an address from a DHCP server and waiting for a reply. If an answer comes back before the timeout ends, the board uses the information in the reply to configure the network adapter. Take care when starting a DHCP server, because a typo in the configuration can result in the server merrily assigning addresses to computers other than the target board. The following configuration only assigns addresses based on Media Access Control (MAC) addresses. The MAC address is a unique number assigned to the board by the manufacturer, so the chance of two machines on the network having the same MAC address is close to zero. It's not exactly zero, because sometimes MAC address are duplicated across vendors (that is, Vendor B issues MAC addresses that only Vendor A should issue); more commonly, the board is given a MAC address during configuration that matches an existing address on the network. Duplicate IP addresses result in general network mayhem, result in at least three all-hands IT meetings; it's not the type of attention you want. The software providing the reply is called the DHCP server and gets its settings from a file stored in /etc/dhcpd.conf. This file is read when the DHCP service starts, so this server must be restarted in order for changes to take effect. A typical /etc/dhcpd.conf file looks like this:
ddns-update-style ad-hoc;
authoratative;
subnet 10.0.0.0 netmask 255.0.0.0 {
You structure the DHCP file to supply information on a per-host basis. A DCHP configuration file can have many of these host parts:
host myboard {
hardware ethernet 02:03:04:f5:d6:07;
fixed-address 10.0.0.2;
server-name "10.0.0.1";
option router “10.0.0.1”;
option root-path "/var/board/rfs";
The root path is used by boards that mount an NFS file system. The host name can be different from the host part of this definition. This is the value that Linux writes into /etc/hostname:
option host-name "board";
Configuring a DHCP service for an enterprise is a complex business; however, for the case of booting a board, the configuration is as minimal as possible. In this example, the file has been configured so that it replies only to hosts with a MAC address of 02:03:04:f5:d6:07. You need to change this value for the board being booted. There are several ways to get the IP address for the board:
• Look at the board: The MAC address is occasionally printed on a sticker. This is the low-tech solution.
• When the board boots, the boot loader may show you the MAC address: Or, at the boot loader prompt, you can ask for the state of the environment. The exact method varies per boot loader; however, many boards use U-Boot, and the bdi command shows the following output along with some other information:
ethaddr = :02:03:04:f5:d6:07;
If you're new to embedded systems, U-Boot is boot-loader software that runs after the board boots but before the operating system as started.
• If all else fails, you can attach the board to the network, start the board, and have it attempt to find an address while running a packet sniffer on your desktop. This is the most hackerish way of getting the address; for some boards with primitive boot loaders, it's sometimes the fastest way.
• To sniff the network, use a tool called tcpdump to print out all broadcast packets on the network, and wait for the output. The tcpdump utility reports the MAC address of the machines broadcasting for a DHCP reply. For example:
# tcpdump ip broadcast tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 22:30:39.791184 IP localhost.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request
from :02:03:04:f5:d6:07 (oui Unknown), length 300
After obtaining the MAC address, the next interesting line is
fixed-address 10.0.0.2;
This is the address that is assigned to the host. The address should be one that is acceptable on your network and shouldn't clash with other addresses. Specifying fixed-address means that when the DHCP server sees a request for an address from the MAC address in this part, it always returns the same IP address. Experimentation shows that a DHCP server frequently assigns the same IP address to a computer; this isn't guaranteed by the specification but is an implementation artifact. By associating a MAC address with a fixed IP address, the board always gets the same IP address assignment.
NFS
The Network File System (NFS) protocol is a way for a machine to make a storage location (the so-called export in NFS parlance) available to other hosts on the network. NFS isn't a requirement for embedded development, although it does make development easier because the root file system used by the target board can be easily updated when it's stored as a directory somewhere on the development host. Embedded boards that use flash memory (the same technology as USB drives) must have their file systems built and then placed on the board, and that process can be time consuming early in the development process when changes are frequent. NFS exports are mounted like any other device in Linux, via mount:
# mount –t nfs nfsserver.yourdoman.com:/some/path a-directory/that-exists
After mounting, you can read or write to /mnt/nfs according to the permissions granted to you. Informing the NFS server of a mount is done through the /etc/exports file. The format of this file is very simple; for example, to export a directory containing a root file system to be mounted by a board, the file contains the following line:
/var/rfs *(rw,no_root_squash)
This line says, “export /var/rfs, allow anyone to connect, allow reads and writes, and if a user with UID=0 connects, don't attempt to remap the UID to something less dangerous.” The * means to allow connections from any host. Reading the man page for this file reveals that the user has great control over what hosts can mount an export: the user can enter host names, IP addresses, and IP address masks. All this is necessary for NSF servers deployed in an enterprise or public network, but is overkill for the purposes of booting a board, and is a generator of problems. Restart the NFS server by doing the following:
# /etc/init.d/nfs-user-server restart
You should test the NFS server from another Linux host, to duplicate how the board mounts the share. Here's the command:
# mkdir –p /mnt/nfs # mount –t nfs :/var/nfs /mnt/nfs
Of course, replace nfs-server-host-name with the host name or IP address of the NFS server. After you've connected, test the connection by writing a file and printing the contents:
# echo 1 > /mnt/nfs/file # cat /mnt/nfs/file
The most common problem with NFS is not having permissions to write files on the NFS server or misspelling name of the export in the /etc/exports file or the mount command. When you make changes, remember to restart the NFS server after changing the /etc/exports file.