Display or specify the default domain name suffix to be appended to a host
name when it contains no periods. For example, if the suffix is set to
aaaammmmpppprrrr....oooorrrrgggg.... and the user enters tttteeeellllnnnneeeetttt kkkkaaaa9999qqqq, the domain resolver will attempt
to find kkkkaaaa9999qqqq....aaaammmmpppprrrr....oooorrrrgggg..... If the host name being sought contains one or more
periods, however, the default suffix is NOT applied if the last part of the
name is less than 5 characters and contains only letters; e.g.,
tttteeeellllnnnneeeetttt ffffoooooooo....bbbbaaaarrrr would NOT be turned into ffffoooooooo....bbbbaaaarrrr....aaaammmmpppprrrr....oooorrrrgggg.....
tttteeeellllnnnneeeetttt ffffoooooooo....kkkkaaaa9999qqqq will be turned into ffffoooooooo....kkkkaaaa9999qqqq....aaaammmmpppprrrr....oooorrrrgggg..... Note that a
- 16 -
trailing dot (.) is required for the suffix. If the suffix is the string
nnnnoooonnnneeee (without trailing period) the current suffix is cleared and forgotten.
Set the IP address to aaaaddddddddrrrr for this interface. This might be nessesary when a
system acts as a gateway. Like an system with IP address 44.137.1.8 has an
Internet access via its ethernet. The Internet IP address could be
129.179.122.10. An iiiiffffccccoooonnnnffffiiiigggg eeeecccc0000 iiiippppaaaaddddddddrrrreeeessssssss 111122229999....111177779999....111122222222....11110000 sets the correct
address for that interface. Now routing to that system will work. (Note that
the 44.x.x.x address is NOT connected to the Internet.) See also the hhhhoooosssstttt----
nnnnaaaammmmeeee and iiiipppp aaaaddddddddrrrreeeessssssss commands.
If only the time is specified, the dialer pauses for the desired number of
milliseconds.
Otherwise, the dialer reads until the test string is detected on the inter-
face. If the string is not detected within the desired time, the autodialer
will reset. The string quote marks are required, and the string may not con-
tain embedded control characters. However, the standard C string escape
sequences are recognized (\0 should not be used).
Finally, if the _s_p_e_e_d parameter is specified, the dialer will continue to
read characters until a non-digit is detected. The string read is converted
to an integer, and used to set the interface speed. If the trailing non-
digit is not detected within the desired time, or the integer value is not a
valid speed, the autodialer will reset.
- 57 -
_7. _I_n_s_t_a_l_l_a_t_i_o_n
NNNNoooossss uses the following file and directory structure:
~/alias
~/autoexec.nos
~/dialer
~/domain.txt
~/ftpusers
~/net.rc
~/netron.sav
~/popusers
~/finger/
~/spool/areas
~/spool/mail.log
~/spool/net.log
~/spool/forward.bbs
~/spool/history
~/spool/rewrite
~/spool/help/
~/spool/mail/
~/spool/mqueue/
~/spool/news/
~/spool/rqueue/
~/spool/signatur/
The ~ in front of all files is a directory offset definable with the ----dddd
option on the NNNNoooossss command line. Any name may be chosen and is default empty.
(eg. just /) If for example ----dddd ////nnnneeeetttt is given, the structure shifts to
/net/... The aaaalllliiiiaaaassss,,,, aaaauuuuttttooooeeeexxxxeeeecccc....nnnnoooossss,,,, ddddiiiiaaaalllleeeerrrr,,,, ddddoooommmmaaaaiiiinnnn....ttttxxxxtttt nnnneeeetttt....rrrrcccc,,,, ppppooooppppuuuusssseeeerrrrssss and
ffffttttppppuuuusssseeeerrrrssss configuration files are located here. The nnnneeeettttrrrroooommmm....ssssaaaavvvv file will be
created there.
The "/spool" directory and its sub-directories are used by the bbs, SMTP and
NNTP services. The aaaarrrreeeeaaaassss,,,, ffffoooorrrrwwwwaaaarrrrdddd....bbbbbbbbssss,,,, hhhhiiiissssttttoooorrrryyyy,,,, mmmmaaaaiiiillll....lllloooogggg and rrrreeeewwwwrrrriiiitttteeee confi-
guration files are located here. The /spool/news directory can have many
subdirectories and each subdirectory can have subdirectories. Newsgroups are
split into heirarchical directory structures. A news article in newsgroup
rec.amateur.radio.packet will end up in
/spool/news/rec/amateur/radio/packet.txt.
_7._1. _T_h_e /_f_t_p_u_s_e_r_s _F_i_l_e
Since MS-DOS is a single-user operating system (some might say it is a glori-
fied bootstrap loader), it provides no access control; all files can be read,
written or deleted by the local user. It is usually undesirable to give such
open access to a system to remote network users. Net therefore provides its
own access control mechanisms.
The file ffffttttppppuuuusssseeeerrrrssss controls remote FTP and mailbox access. The FTP default is
_n_o access; if this file does not exist, the FTP server will be unusable. A
remote user must first "log in" to the system with the USER and PASS com-
mands, giving a valid name and password listed in ffffttttppppuuuusssseeeerrrrssss, before he or she
can transfer files.
Each entry in ffffttttppppuuuusssseeeerrrrssss consists of a single line of the form
username password /path permissions
- 58 -
There must be exactly four fields, and there must be exactly one space
between each field. Comments may be added after the last field. Comment
lines begin with '#' in column one.
uuuusssseeeerrrrnnnnaaaammmmeeee is the user's login name.
ppppaaaasssssssswwwwoooorrrrdddd is the required password. Note that this is in plain text; there-
fore it is not a good idea to give general read permission to the root direc-
tory. A password of '*' (a single asterisk) means that any password is
acceptable.
////ppppaaaatttthhhh is the allowable prefix on accessible files. Before any file or direc-
tory operation, the current directory and the user- specified file name are
joined to form an absolute path name in "canonical" form (i.e., a full path
name starting at the root, with "./" and "../" references, as well as redun-
dant /'s, recognized and removed). The result MUST begin with the allowable
path prefix; if not, the operation is denied. This field must always begin
with a "/", i.e., at the root directory. Multiple directories can be speci-
fied by separating them with a ";" caracter and no whitespace around them.
ppppeeeerrrrmmmmiiiissssssssiiiioooonnnnssss is a decimal number granting permission for read, create and
write operations. If the low order bit (0x1) is set, the user is allowed to
read a file subject to the path name prefix restriction. If the next bit
(0x2) is set, the user is allowed to create a new file if it does not
overwrite an existing file. If the third bit (0x4) is set, the user is
allowed to write a file even if it overwrites an existing file, and in addi-
tion he may delete files. Again, all operations are allowed subject to the
path name prefix restrictions. Permissions may be combined by adding bits,
for example, 0x3 (= 0x2 + 0x1) means that the user is given read and create
permission, but not overwrite/delete permission.
Additional permission bits used by the mailbox and PPP are:
1 Read files
2 Create new files
4 Overwrite and delete existing files
8 AX.25 gateway operation allowed
16 Telnet gateway operation allowed
32 NET/ROM gateway operation allowed
64 Remote sysop access allowed (DANGEROUS)
128 This user is banned from BBS access (illegal user)
256 Priv bit for PPP connection
512 Priv bit for peerID/pass lookup
1024 disallow send commands (except to SYSOP)
2048 disallow read commands
4096 disallow 3rd party mail
8192 This station is a known BBS
A username of uuuunnnniiiivvvvppppeeeerrrrmmmm has special meaning in the validation meganism. If
uuuunnnniiiivvvvppppeeeerrrrmmmm is included as a valid user in ffffttttppppuuuusssseeeerrrrssss then any unknown user (not
in ffffttttppppuuuusssseeeerrrrssss) will be mapped into uuuunnnniiiivvvvppppeeeerrrrmmmm and get its permission bits and
file path. If uuuunnnniiiivvvvppppeeeerrrrmmmm is not included in ffffttttppppuuuusssseeeerrrrssss unknown users are not per-
mitted nor validated.
For example, suppose ffffttttppppuuuusssseeeerrrrssss on machine pc.ka9q.ampr.org contains the line
friendly test /testdir 7
A session using this account would look like this:
according to the maximum expected frame size, so it is important that these
devices be configured with the correct bbbbuuuuffffssssiiiizzzzeeee. To do this, you must know the
size of the largest possible frame that can be received. The ppppaaaacccclllleeeennnn parameter
controls only the size of the data field in an I-frame and not the total size
of the frame as it appears on the air. The AX.25 spec allows up to 8 digi-
peaters, so the largest possible frame is (ppppaaaacccclllleeeennnn + 72) bytes. So you should
make bbbbuuuuffffssssiiiizzzzeeee at least this large.
Another important consideration is that the more recent versions of NOS
improve interrupt response by maintaining a special pool of buffers for use
by the receive routines. These buffers are currently fixed in size to 2048
bytes and this can be changed only by editing config.h and recompiling NOS.
This limits bbbbuuuuffffssssiiiizzzzeeee; in fact, attempting to set a larger value may cause the
driver not to work at all. This situation can be detected by running the
mmmmeeeemmmmoooorrrryyyy ssssttttaaaattttuuuussss command and looking for a non-zero count of IIIIbbbbuuuuffffffffaaaaiiiillll events,
although these events can also occur occasionally during normal operation.
One of the drawbacks of AX.25 that there is no way for one station to tell
another how large a packet it is willing to accept. This requires the sta-
tions sharing a channel to agree beforehand on a maximum packet size. TCP is
different, as we shall see.
_8._4._3. _S_e_t_t_i_n_g _M_a_x_f_r_a_m_e
For best performance on a half-duplex radio channel, mmmmaaaaxxxxffffrrrraaaammmmeeee should always
be set to 1. The reasons are explained in the paper _L_i_n_k _L_e_v_e_l _P_r_o_t_o_c_o_l_s
_R_e_v_i_s_i_t_e_d by Brian Lloyd and Phil Karn, which appeared in the proceedings of
the ARRL 5th Computer Networking Conference in 1986.
_8._4._4. _S_e_t_t_i_n_g _M_T_U
TCP/IP header overhead considerations similar to those of the AX.25 layer
when setting ppppaaaacccclllleeeennnn apply when choosing an MTU. However, certain subnetwork
types supported by NNNNoooossss have well-established MTUs, and these should always be
used unless you know what you're doing: 1500 bytes for Ethernet, and 508
bytes for ARCNET. The MTU for PPP is automatically negotiated, and defaults
to 1500. Other subnet types, including SLIP and AX.25, are not as well
- 66 -
standardized.
SLIP has no official MTU, but the most common implementation (for BSD UNIX)
uses an MTU of 1006 bytes. Although NNNNoooossss has no hard wired limit on the size
of a received SLIP frame, this is not true for other systems. Interoperabil-
ity problems may therefore result if larger MTUs are used in NNNNoooossss.
Choosing an MTU for an AX.25 interface is more complex. When the interface
operates in datagram (UI-frame) mode, the ppppaaaacccclllleeeennnn parameter does not apply.
The MTU effectively becomes the ppppaaaacccclllleeeennnn of the link. However, as mentioned
earlier, large packets sent on AX.25 _c_o_n_n_e_c_t_i_o_n_s are automatically segmented
into I-frames no larger than ppppaaaacccclllleeeennnn bytes. Unfortunately, as also mentioned
earlier, NNNNoooossss is so far the only known implementation of the new AX.25 segmen-
tation procedure. This is fine as long as all of the NET/ROM nodes along a
path are running NNNNoooossss, but since the main reason NNNNoooossss supports NET/ROM is to
allow use of existing NET/ROM networks, this is unlikely.
So it is usually important to avoid AX.25 segmentation when running IP over
NET/ROM. The way to do this is to make sure that packets larger than ppppaaaacccclllleeeennnn
are never handed to AX.25. A NET/ROM transport header is 5 bytes long and a
NET/ROM network header takes 15 bytes, so 20 bytes must be added to the size
of an IP datagram when figuring the size of the AX.25 I-frame data field. If
ppppaaaacccclllleeeennnn is 256, this leaves 236 bytes for the IP datagram. This is the default
MTU of the nnnneeeettttrrrroooommmm pseudo-interface, so as long as ppppaaaacccclllleeeennnn is at least 256
bytes, AX.25 segmentation can't happen. But if smaller values of ppppaaaacccclllleeeennnn are
used, the nnnneeeettttrrrroooommmm MTU must also be reduced with the iiiiffffccccoooonnnnffffiiiigggg command.
On the other hand, if you're running IP directly on top of AX.25, chances are
all of the nodes are running NNNNoooossss and support AX.25 segmentation. In this
case there is no reason not to use a larger MTU and let AX.25 segmentation do
its thing. If you choose an MTU on the order of 1000-1500 bytes, you can
largely avoid IP-level fragmentation and reduce TCP/IP-level header overhead
on file transfers to a very low level. And you are still free to pick what-
ever ppppaaaacccclllleeeennnn value is appropriate for the link.
_8._4._5. _S_e_t_t_i_n_g _M_S_S
The setting of this TCP-level parameter is somewhat less critical than the IP
and AX.25 level parameters already discussed, mainly because it is automati-
cally lowered according to the MTU of the local interface when a connection
is created. Although this is, strictly speaking, a protocol layering viola-
tion (TCP is not supposed to have any knowledge of the workings of lower
layers) this technique does work well in practice. However, it can be
fooled; for example, if a routing change occurs after the connection has been
opened and the new local interface has a smaller MTU than the previous one,
IP fragmentation may occur in the local system.
The only drawback to setting a large MSS is that it might cause avoidable
fragmentation at some other point within the network path if it includes a
"bottleneck" subnet with an MTU smaller than that of the local interface.
(Unfortunately, there is presently no way to know when this is the case.
There is ongoing work within the Internet Engineering Task Force on a "MTU
Discovery" procedure to determine the largest datagram that may be sent over
a given path without fragmentation, but it is not yet complete.) Also, since
the MSS you specify is sent to the remote system, and not all other TCPs do
the MSS-lowering procedure yet, this might cause the remote system to gen-
erate IP fragments unnecessarily.
On the other hand, a too-small MSS can result in a considerable performance
loss, especially when operating over fast LANs and networks that can handle
- 67 -
larger packets. So the best value for MSS is probably 40 less than the larg-
est MTU on your system, with the 40-byte margin allowing for the TCP and IP
headers. For example, if you have a SLIP interface with a 1006 byte MTU and
an Ethernet interface with a 1500 byte MTU, set MSS to 1460 bytes. This
allows you to receive maximum-sized Ethernet packets, assuming the path to
your system does not have any bottleneck subnets with smaller MTUs.
_8._4._6. _S_e_t_t_i_n_g _W_i_n_d_o_w
A sliding window protocol like TCP cannot transfer more than one window's
worth of data per round trip time interval. So this TCP-level parameter con-
trols the ability of the remote TCP to keep a long "pipe" full. That is, when
operating over a path with many hops, offering a large TCP window will help
keep all those hops busy when you're receiving data. On the other hand,
offering too large a window can congest the network if it cannot buffer all
that data. Fortunately, new algorithms for dynamic controlling the effective
TCP flow control window have been developed over the past few years and are
now widely deployed. NNNNoooossss includes them, and you can watch them in action
with the ttttccccpppp ssssttttaaaattttuuuussss <<<<ttttccccbbbb>>>> or ssssoooocccckkkkeeeetttt <<<<ssssoooocccckkkknnnnoooo>>>> commands. Look at the ccccwwwwiiiinnnndddd
(congestion window) value.
In most cases it is safe to set the TCP window to a small integer multiple of
the MSS, (eg. 4times), or larger if necessary to fully utilize a high
bandwidth*delay product path. One thing to keep in mind, however, is that
advertising a certain TCP window value declares that the system has that much
buffer space available for incoming data. NNNNoooossss does not actually preallocate
this space; it keeps it in a common pool and may well "overbook" it, exploit-
ing the fact that many TCP connections are idle for long periods and gambling
that most applications will read incoming data from an active connection as
soon as it arrives, thereby quickly freeing the buffer memory. However, it
is possible to run NNNNoooossss out of memory if excessive TCP window sizes are adver-
tised and either the applications go to sleep indefinitely (eg. suspended
Telnet sessions) or a lot of out-of-sequence data arrives. It is wise to
keep an eye on the amount of available memory and to decrease the TCP window
size (or limit the number of simultaneous connections) if it gets too low.
Depending on the channel access method and link level protocol, the use of a
window setting that exceeds the MSS may cause an increase in channel colli-
sions. In particular, collisions between data packets and returning ack-
nowledgements during a bulk file transfer may become common. Although this
is, strictly speaking, not TCP's fault, it is possible to work around the
problem at the TCP level by decreasing the window so that the protocol
operates in stop-and-wait mode. This is done by making the window value
equal to the MSS.
_8._5. _S_u_m_m_a_r_y
In most cases, the default values provided by NNNNoooossss for each of these parame-
ters will work correctly and give reasonable performance. Only in special
circumstances such as operation over a very poor link or experimentation with
high speed modems should it be necessary to change them.
