NEW FEATURES:
- Vastly improved portability - works on SGI, BSDI, and SVR4
- Improved range of known variables
LOCATION (available by anonymous FTP)
ucsd.edu:pub/csl/netconfig/netconfig2.2.tar.Z
WHAT IS NETCONFIG?
Netconfig is a program intended to make management of network
configuration options such as TCP maximum window size a part of
routine system administration. Berkeley Unix based networking
software is configurable to a surprising degree by means of assorted
kernel variables such as 'tcp_recvspace' and 'ipforwarding'. One can
raise TCP max window size to raise performance over FDDI or long
connections, or one can lower it to improve SLIP performance.
When run with no arguments, it prints out a list of all the network
configuration variables that both the program knows about and are
present in the currently running kernel so that a system administrator
can easily see what variables are available to be changed. For
example, it prints out the following on my Alpha running a slightly
modified version of DEC OSF/1 1.3:
Sockets:
Max socket buffer size (sb_max): 253952
Large mbuf use threshold (mbufthreshold): 1024
Max listen queue len (somaxconn): 8
IP:
Routing (ipforwarding): off
Ipgateway (ipgateway): off
ICMP:
Redirects (ipsendredirects): on
TCP:
Output Buffer Size (tcp_sendspace): 253952
Input Buffer Size (tcp_recvspace): 253952
Retransmit Threshold (tcprexmtthresh): 3
Default Max Seg Size (tcp_mssdflt): 1460
Keepalive Idle Time (tcp_keepidle): 14400
Keepalive Interval (tcp_keepintvl): 150
Default TTL (tcp_ttl): 64
Don't scale windows (tcp_dont_winscale): off
Local Checksum (tcplclsum): off
Subnets Are Local (subnetsarelocal): on
UDP:
Checksum (udpcksum): on
Max Send Msg Size (udp_sendspace): 253952
Max Rcv Buffer (udp_recvspace): 253952
Default TTL (udp_ttl): 64
Local Checksum (udplclsum): off
TCP/IP Misc.:
Internet checksum routine active (nocksum): off
Netconfig allows for easy change of the variables involved. I set a
number of the values above using the following commands:
$ netconfig tcp_sendspace 253952 tcp_recvspace 253952 udp_sendspace 65535
$ netconfig udp_recvspace 65535 udp_cksum on
The manual page includes a short description of the impact of some of
the variables and suggestions on configuration values.
PORTING
Netconfig has been explicitly tested on the following machine/OS pairs:
Architecture OS
-----------------------------------------
DECstation Ultrix
Vax Ultrix
Sun 3 SunOS
Sun 4 SunOS
Alpha OSF/1
SGI Irix 5.1
386 BSDI
386 SVR4
It should work on HPs and RS6000s as well. I haven't had an
opportunity to try it, though. I would love to hear from people
trying it out.
Netconfig is surprisingly portable, and is getting more so. The body of the
program compiled and ran without complaint on every machine I tried it
on except for Linux and Solaris (even then, it ran but didn't find
anything). Unlike the previous version, it does *not* need a valid
list of variables to work on a given machine; it always tries all
variables it knows about.
So far, the only Unix-like OSes that do have networking and I've tried and to
which porting turned out to be difficult (read: I gave up) is Linux, because
its networking software is not based on BSD in the same sense as most Unixes'
networking software.
One aspect of porting that would be quite useful is keeping track of
platform-dependent network variables. If you know about a network variable
that netconfig doesn't, please tell me about it. I am only interested in
single integer type variables at this stage (I am well aware that ability to
manage, say, interface MTUs would have its uses, but netconfig just isn't
that smart).
HISTORY
2.2 -- Second major release. Tue Sep 20 16:46:15 PDT 1994
1.2 -- First major release. Wed Sept 2 22:58:20 PDT 1993
I originally had the idea for this program because two problems were
pestering me. One problem was that I kept trying out new
implementation techniques for TCP/IP. Of course, I needed to be able
to easily flip between running with and without each technique so I
could see if it was working out - and in some cases, because the
technique might not work well enough yet to make it through booting
without a crash. The other problem was that a major project in which
which I'm involved (Sequoia 2000) was to get a T3 network, and our
machines are unable to take advantage of those kinds of bandwidths
without considerable tuning. But most people on the project would not
want to run my (experimental) kernel.
Thus netconfig.
It turns out that netconfig solves a third problem. It's
excruciatingly difficult to keep track of all the *&%$ nitty variables
out there; the vendors themselves probably have difficulty, and it's
unreasonable to expect system administrators to find this stuff out.
It's impossible in a multivendor environment without a number ofsource
code trees. Fortunately, the University of California is one of the
few institutions that comes close.
Why always release .2 releases? Well, this reflects internal
releases. .0 always barely works (of course). I always intend to
release .1, but it proves not to be there yet under wider testing, and
.2 is finally there.
AUTHOR
Jon Kay (jkay@ucsd.edu)
Computer Systems Lab
University of California
San Diego, CA 92093-0114
ACKNOWLEDGEMENTS
I gratefully acknowledge help from Kimberly Claffy, of the University of
California, San Diego Computer Systems Lab (kc@sdsc.edu) with
the documentation.
I'd also like to thank the numerous people who contributed ports,
bugfixes, pointers to bugs, and access to machines.
COPYRIGHT
Copyright (c) 1993,1994 Regents of the University of California.
All rights reserved.
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without written agreement is
hereby granted, provided that the above copyright notice and the following
paragraph appears in all copies of this software.
THIS SOFTWARE IS PROVIDED BY THE REGENTS ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT SHALL THE REGENTS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Version 2.2. Tue Sep 20 16:46:15 PDT 1994
