Tuning

You need to set up your ${DPCONF_DIR}/conf file and any script and access files for what makes sense in your environment. The primary tuning comes in getting your dialing scripts to work, selecting appropriate timeouts in your access file, and monitoring what happens.

The file ${DPLOG_DIR}/call.log can be used to give you a one line summary of each successful call. The file ${DPLOG_DIR}/dp.log can be used to show you a blow by blow description of calls in progress. The amount of logging can be increased by invoking dpd with "-d N" where N can be anywhere from 0 for minimal logging to 3 for verbose logging. In addition, the log level can be set for individual systems in the configuration file by using the LOG_LEVEL variable.

Debug Tracing

If you encounter problems with the kernel modules, you can turn on very verbose debugging output by setting the following kernel variables: 
dp streams driver	    (dp.o (Sol 2.X))
    dp_debug			General info
    dp_debug_dump_msg		Print trace of packets
    dp_debug_lists		Print linked lists after updates

vjc streams module	    (vjc.o)
    vjc_debug			General info

pppasync streams module	    (ppp_async.o)
    ppp_async_debug		General info
    ppp_async_input_debug	input packet dump of N bytes
These variables are all int variables and should be set to 0 or 1, to have the reporting off or on, respectively. The ppp_async_input_debug variable can be given a value greater than 1 to indicate the number of bytes printed in a packet trace.

When running adb on the kernel, you must be sure to specify the correct object file so that you get the correct symbols. Under Solaris 1.X, you must link a new object file using the "mksyms" shell script in the sys directory. This will create a file called vmunix.syms that can be used as an object file. Under Solaris 2.X, the kernel already provides access to all loaded symbols via the device "/dev/ksyms".

Here is a typical adb session: 

    # adb -w -k /dev/ksyms /dev/mem
    physmem fe9
    ppp_async_input_debug/X
    _ppp_async_input_debug:	0
    /W0t32
    _ppp_async_input_debug:	0x0	=	0x20
    $q
    #
In order to set a variable to remain in effect after the next reboot, you must adb the individual module files. Under Solaris 2.X, these are located in 
	/usr/kernel/drv/dp
	/usr/kernel/strmod/vjc
	/usr/kernel/strmod/pppasync

Broadcast programs

Some programs broadcast information on a regular basis to all connected interfaces. If a program is found to generate frequent output on PPP interfaces, it should be reconfigured, modified, or just not run at all, depending on the circumstances.

rwhod

A common example of a talkative program is rwhod. If you must run rwhod, it should be modified to ignore PPP links. Context diffs for rwhod are available. Once applying these diffs to rwhod sources, you should be able to run rwhod with the "-p" flag to suppress all output on Point to Point interfaces.

Nameserver (DNS)

If you are on the Internet, you are basically mandated to use DNS. Typically, this is implemented in a program called named or in.named. If you are relying solely on DNS (no NIS or host tables), you should set up nameservers at the remote sites. Care should be taken in the configuration of the nameservers. There are at least a couple of ways that you can set things up.

Secondary nameservers

You can set up secondary nameservers on each of the remote sites. They can zone load your organization-wide zones on a regular basis. Please note that zones have a refresh time at which point a connection will be made to check for updates. This can vary, but it may be 12 hours or so. This interval is specified in the zone file on the primary nameserver. At this interval, the remote secondary nameserver will contact the primary nameserver (generating a call in our case). It will verify that the primary has the most recent version of each zone of interest.

Primary nameservers

For remote sites that are placing toll calls, a refresh interval of 12 hours would result in 2 extra toll calls per day. This may be a problem. If so, consider making the remote system a primary nameserver. When the central nameserver file is updated, it needs to be distributed to all remote primary nameservers, but this may be preferable compared to all the long distance toll charges of the more automatic scheme employed by the secondary nameservers.

In general the remote primary servers should not be listed in the nameserver data contained in the zone data. Otherwise, distant Internet hosts may try to use them for information about the zone, generating unnecessary traffic. They should exist as primary nameservers, but not be advertised as such.

Kirk Smith / ks@acn.purdue.edu Last updated: 28 July 1995