With no options, netconfig prints out values of all the network options that it knows about and can find in the kernel.
Netconfig interprets its command line as a series of requests to set or get a variable's contents. A request to set a variable consists of the name of a kernel variable followed by a value for that variable. A request to get a variable's value consists only of the name of the variable. It is possible to request both a get and a set of a variable; writes are performed before reads, so that would amount to confirmation that a write really has been performed.
Netconfig implements variable typing. Each variable is treated as either numeric or boolean. Numeric variables (such as TCP output buffer size) expect numeric values upon being set. Boolean variables expect either 'on', 'off', or a number as a value; a nonzero numeric value is the same as the 'on' value, and a numeric value of zero is the same as the 'off' value.
Netconfig ignores underscores for purposes of matching variable names on the command line with actual variable names. For example, 'tcpsendspace' would succeed in matching 'tcp_sendspace'.
The kernel memory special device /dev/kmem, which netconfig relies upon to read and write its values, is usually installed with extremely restrictive permissions. Thus, it is suggested that one install netconfig setgid kmem, or setuid root if there is no group kmem. If netconfig is installed setuid or setgid, it only uses the special access to allow anybody to run netconfig and find out what the values of kernel variables are. In order to change kernel variables, the user running the program must already have permission to write to /dev/kmem; normally, one must either be root or in group kmem.
Input Buffer Size (tcp_sendspace): 28672
"Output Buffer Size" is a description of what the variable controls. "tcp_sendspace" is a the actual name of the variable that one would use in configuration. 28672 is the value tcp_sendspace is currently set to in kernel memory.
Many vendors ship machines with values of network configuration variables that track current network technology and memory prices slowly. Some values made sense when a 2 megabyte VAX was pretty impressive. Netconfig can be used to automatically set network variable values upon boot. We place the following invocation in our /etc/rc.local to do this:
if [ -f /usr/local/bin/netconfig ]; then
/usr/local/bin/netconfig `cat /etc/netconfig.conf`
fi
The effect of this is that network variable settings are read from /etc/netconfig.conf upon boot. A sample netconfig.conf is provided with the netconfig distribution.
netconfig tcp_recvspace 28672
Another way to set tcp_recvspace to 28672, making use of the underscore-ignoring feature:
netconfig tcprecvspace 28672
To show the value of tcp_recvspace:
netconfig tcp_recvspace
Tcp_sendspace and tcp_sendspace control TCP maximum window size. For a TCP connection to operate at maximum speed over a given connection, the TCP maximum window must be at least as large as the product of the round-trip delay of the connection and the bandwidth of the connection. For full speed TCP over local Ethernet, that comes out to around 5k, but it goes up for FDDI and remote connections. The maximum window size also potentially controls the maximum time it could take a TCP window to drain over a slow SLIP link. Memory prices suggest that a machine on a LAN should have as large a TCP window size as possible. Unfortunately, limitations on some implementations of TCP and assorted performance quirks reduce the optimal best value to <32k - mbuf cluster length>. Mbuf cluster length varies by OS, but is so far never over 4k in size, yielding a safe value for everyone of:
tcp_sendspace 28672
tcp_recvspace 28672
If you are feeling slightly gutsy or have a need for a larger window size, you could raise these values to 60k each. Environments in which I have heard of trouble with such values are ones in which machines are present that process TCP window sizes using 16-bit signed variables - some PC TCP/IPs. You could push as high as (64k - 1), but most TCP/IP implementations exhibit slightly inefficient behavior when faced with windows that are not even multiples of the cluster mbuf size (64k - 1 is off by one) - and worse still, the inefficiency will affect even connections that do not need a large TCP window size, which is most TCP connections. Contrarily, in an environment in which most packets are sent across a slow link, such as SLIP, one may wish to lower maximum window size to improve response time. The cslip distribution recommends a value of 1024 bytes for dialup slip clients.
Udp_sendspace and udp_recvspace control how large a UDP packet your machine is able to send or receive. In addition, udp_recvspace controls how much UDP data is allowed to enqueue on a given socket awaiting user process reception. I have never seen any reason to limit these in general for most modern workstations (user processes requiring latency limits can override these values on a per-socket basis):
udp_sendspace 65535
udp_recvspace 65535
Ipforwarding controls whether a host is willing to route packets if it has at least two network interfaces. If you do not intend a machine to be used as a router, you can avoid the unexpected by setting ipforwarding on that machine to 'off'. It must be 'on' for routers.
Ipsendredirects controls whether a host should send an ICMP redirect when it receives a datagram that it forwarded to a different router on the same subnet as the subnet it came in on; in effect the redirect tells the host that sent the datagram to update its routing table to send directly to the router to which the datagram was forwarded in the future. This can act, in effect, as a kind of cheap routing protocol, and usually at worst acts to reduce the severity of certain kinds of mistakes made by network administrators. It should probably be set
Ipgateway determines whether a non-routing host should send an ICMP Network Unreachable message when it receives an IP packet not destined for itself (e.g., to be routed).
Udp_cksum controls whether UDP packets sent by the host checksum their data or not. Some vendors ship machines with udp_cksum turned off. That is because the checksumming data is extremely time-consuming and one can improve NFS performance noticeably by doing so. Turning off checksums results in a risk - if packets are corrupted, one can end up with corrupted data. Since almost all NFS is done over LANs with hardware checksum protection, the risk is often worth the benefit. However, any NFS across a long distance (mounting from a remote site, mounting an Internet archive such as wuarchive, mounting across a SLIP link) carries a much larger risk of data corruption. A host that participates as either client or server in such transactions should probably have udp_cksum turned on. If you are uncertain of whether your hosts often send "long-distance" UDP packets, you should set udp_cksum 'on.'
Tcp_cksum decides if a host should checksum TCP packets that it receives. Many TCP connections are over long distances, so by the reasoning of the last paragraph this should almost always be 'on'.
Tcplclsum and udplclsum control whether checksum redundancy avoidance it is used, if it is available in your kernel. Checksum redundancy avoidance is software that avoids the need for the udp_cksum flag above - it detects whether packet transmissions are local or remote and avoids performing data checksums only on packets that cross a single LAN. One can tell if one has checksum redundancy avoidance by checking to see if tcplclsum and udplclsum appear in the list of variables that appears when one runs netconfig with no arguments. For most environments, they should be 'off', which turns checksum redundancy avoidance *on*. If your application requires reliability higher than is normally found in a workstation environment, you should set them to 'on'.
R. Braden, J. Postel, "Requirements for Internet Gateways," Internet Request for Comments 1009.
R. Braden, "Requirements for Internet Hosts -- Communication Layers," Internet Request for Comments 1122.
S. J. Leffler, M. K. Mckusick, M. J. Karels, J. S. Quarterman, "Interprocess Communication," The Design and Implementation of the 4.3BSD UNIX Operating System, Addison-Wesley, Nov. 1989.
Compressed SLIP distribution, available from ftp.ee.lbl.gov.
Fastnet (incl. checksum redundancy avoidance) distribution, available from ucsd.edu:pub/csl/fastnet.
Netconfig should be more portable. Since most vendors' kernel network configuration variables are part of a small pool of common network configuration variables, netconfig should build by searching the kernel for all known network configuration variables, generating a script for the aforementioned fictional general kernel variable accessor. That would reduce the porting effort to addition of vendor-specific variables, and netconfig would usually run on machines to which it had not yet been explicitly ported.
I have not yet made a thorough attempt to find all the useful network configuration variables in Alpha-OSF, since I do not yet have access to source code.
Netconfig attempts to track a moving target, and the author will probably require external assistance to track new network configuration kernel variables (hint!).