30
This shows three parameters that can be examined, although only two can be changed. We can examine an individual parameter by using its name as an argument. For example, we can retrieve the
ARP table as shown here:
sol1 ndd devarp arp_cache_report ifname proto addr proto mask hardware addr flags
elxl0 205.153.060.053 255.255.255.255 00:e0:29:21:3c:0b elxl0 205.153.060.055 255.255.255.255 00:90:27:43:72:70
elxl0 205.153.060.001 255.255.255.255 00:00:a2:c6:0e:42 elxl0 205.153.060.005 255.255.255.255 00:90:27:9c:2d:c6
elxl0 205.153.060.248 255.255.255.255 00:60:97:58:71:b7 PERM PUBLISH MYADDR elxl0 205.153.060.150 255.255.255.255 00:c0:05:04:2d:78
elxl0 224.000.000.000 240.000.000.000 01:00:5e:00:00:00 PERM MAPPING
In this instance, it is fairly easy to guess the meaning of whats returned. This output is for the same ARP table that we looked at with the arp command. Sometimes, whats returned can be quite cryptic.
This example returns the value of the IP forwarding parameter:
ndd devip ip_forwarding
It is far from obvious how to interpret this result. In fact, means never forward,
1
means always forward, and
2
means forward only when two or more interfaces are up. Ive never been able to locate a definitive source for this sort of information, although a number of the options are described in an
appendix to W. Richard Stevens TCPIP Illustrated, vol. 1. If you want to change parameters, you can invoke the program interactively.
Other versions of Unix will have their own files and utilities. For example, BSD has the sysctl command. This example shows that IP forwarding is disabled:
bsd1 sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 0
The manpages provide additional guidance, but to know what to change, you may have to delve into the source code. With AIX, there is the no utility. As I have said before, the list goes on.
This brief description should give you a general idea of whats involved in gleaning information about the kernel, but you will want to go to the appropriate documentation for your system. It should be
clear that it takes a fair degree of experience to extract this kind of information. Occasionally, there is a bit of information that can be obtained only this way, but, in general, this is not the most profitable
place to start.
One last comment—if you are intent on examining the behavior of the kernel, you will almost certainly want to look at the messages it produces when booting. On most systems, these can be
retrieved with the dmesg command. These can be helpful in determining what network hardware your system has and what drivers it uses. For hardware, however, I generally prefer opening the case and
looking inside. Accessing the CMOS is another approach for discovering the hardware that doesnt require opening the box.
2.2.4 Startup Files and Scripts
31
Once the kernel is loaded, the swapper or scheduler is started and then the init process runs. This process will, in turn, run a number of startup scripts that will start the various services and do
additional configuration chores.
After the standard configuration files, these are the next group of files you might want to examine. These will primarily be scripts, but may include configuration files read by the scripts. In general, it is
a bad idea to bury configuration parameters within these scripts, but this is still done at times. You should also be prepared to read fairly cryptic shell code. It is hoped that most of these will be either in
their pristine state, heavily commented, or both.
Look for three things when examining these files. First, some networking parameters may be buried in these files. You will not want to miss these. Next, there may be calls to network configuration utilities
such as route or ifconfig. These are frequently customizations, so read these with a critical eye. Finally, networking applications such as sendmail may be started from these files. I strongly urge that you
create a list of all applications that are run automatically at startup.
For systems derived from BSD, you should look for files in etc beginning with rc. Be sure to look at rc.conf and any rc files with extensions indicating a networking function of interest, e.g., rc.firewall.
Realize that many of these will be templates for services that you may not be using. For example, if you see the file rc.atm, dont be too disappointed when you cant find your ATM connection.
Unix systems can typically be booted in one of several different states or run levels that determine which services are started. For example, run level 1 is single-user mode and is used for system
maintenance. The services started by the different run levels vary somewhat among the different flavors of Unix. If your system is derived from System V, then the files will be in a half dozen or so
directories in etc. These are named rc1.d, rc2.d, and so forth. The digit indicates the run level of the system when booted. Networking scripts are usually in rc2.d. In each directory, there will be scripts
starting with an S or a K and a two-digit number. The rest of the name should give some indication of the function of the file. Files with names beginning with an S are started in numerical order when the
system is rebooted. When the system shuts down, the files with K are run. Some versions of Linux, such as Red Hat, follow this basic approach but group these directories together in the etcrc.d
directory. Others, such as Debian, follow the System V approach.
There is one serious catch with all this. When versions of operating systems change, sometimes the locations of files change. For backward compatibility,
links may be created to old locations. For example, on recent versions of Solaris, the network configuration file etchosts is actually a link to
etcinethosts. There are other important network configuration files that are really in etcinet, not etc. Similarly, some of the startup scripts are really
links to files in etcinit.d. If the link is somehow broken, you may find yourself editing the wrong version of a file and wondering why the system is
ignoring your changes.
2.2.5 Other Files
