ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng)/ProfitPress-MegaCDROM2.B6I/MISC/NETWORK/KA9QBGN.ZIP/USERMAN.TXT

Text File | 1991-04-28 | 111.7 KB | 3,421 lines

             NET User Reference Manual (NOS Version)





                        Phil Karn, KA9Q













1.  The NET.EXE Program



The MS-DOS executable file net.exe  provides  Internet  (TCP/IP),

NET/ROM  and AX.25 facilities.  Because it has an internal multi-

tasking operating system, net.exe can  act  simultaneously  as  a

client, a server and a packet switch for all three sets of proto-

cols. That is, while a local user accesses remote  services,  the

system can also provide those same services to remote users while

also switching IP, NET/ROM and AX.25 packets and  frames  between

other client and server nodes.



The keyboard and display is used by the local operator to control

both host and gateway level functions, for which a number of com-

mands are provided.



1.1.  Installation



Net.exe uses the following directory structure:



        /net

        /net/spool

        /net/spool/help

        /net/spool/mail

        /net/spool/mqueue

        /net/spool/rqueue

        /net/spool/news





The "/net" directory is not strictly necessary, and  defaults  to

the  root of the current drive.  Any name may be chosen using the

-d   command-line   option   (described   below).   The    alias,

autoexec.net, dialer, domain.txt and ftpusers configuration files

are located here.



The "/spool" directory and its sub-directories are  used  by  the

bbs,  SMTP  and  NNTP  services. The areas, forward.bbs, history,

mail.log, rewrite and signatur configuration  files  are  located

here.



The alias, forward.bbs and rewrite files  are  described  in  the

document "maildoc", which should be found at the same location as







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 2 -





this file.



1.2.  net [-b] [-s <sockets>] [-d <directory>] [<startup file>]



1.2.1.  -b



The -b option specifies the use of BIOS for console  output;  the

default  is  to  write  directly to the video display buffer. Use

this option if you are running under a windowing package and have

trouble with output "bleeding through" on top of other windows.



1.2.2.  -s



The -s option specifies the size of the socket array to be  allo-

cated  within  net.exe. This limits the number of network connec-

tions that may exist simultaneously. The default is 40.



1.2.3.  -d



The -d option allows the user to specify a directory for the con-

figuration  and spool files; it defaults to the root directory of

the system.



1.2.4.  Startup file



After all command-line options, the name of a startup file may be

specified.  If  no startup file is specified, net.exe attempts to

open a file named autoexec.net in the configuration directory  of

the current drive. If the file exists, it is read and executed as

though its contents were typed on the console as  commands.  (See

the  Commands chapter.) This feature is useful for attaching com-

munication interfaces, configuring network addresses, and  start-

ing the various services.

















































updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 3 -





2.  Console modes



The console may be in one of two modes: command mode and converse

mode.  In  command  mode, the prompt net> is displayed and any of

the commands described in the Commands chapter may be entered. In

converse  mode,  keyboard  input  is  processed  according to the

current session.



Sessions come in many types, including Telnet, FTP, AX25, NETROM,

Ping,  More,  Hopcheck and Tip. In a Telnet, AX25, NETROM, or Tip

session, keyboard input is sent to the remote system and any out-

put from the remote system is displayed on the console.  In a FTP

session, keyboard input is first examined to see if it is a known

local  command;  if  so  it  is  executed locally.  If not, it is

"passed through" to the remote FTP server. (See the  FTP  Subcom-

mands chapter). In a Ping session the user may test the path to a

remote site, and in a More session, the user may examine a  local

file. A Hopcheck session is used to trace the path taken by pack-

ets to reach a specified destination.



The keyboard also has cooked and raw  states.  In  cooked  state,

input  is line-at-a-time; the user may use the line editing char-

acters ^U, ^R and backspace to erase the line, redisplay the line

and  erase  the  last  character,  respectively.   Hitting either

return or line feed passes the complete line up to  the  applica-

tion.  In  raw state, each character is immediately passed to the

application as it is typed.



The keyboard is always in cooked state in  command  mode.  It  is

also  cooked in converse mode on an AX25, FTP or NET/ROM session.

In a Telnet session it depends on  whether  the  remote  end  has

issued  (and  the  local  end  has accepted) the Telnet WILL ECHO

option (see the echo command).



On the IBM-PC, the user may escape back to command mode  by  hit-

ting  the  F10  key.  On  other  systems, the user must enter the

escape character, which is by default control-]  (hex  1d,  ASCII

GS).  (Note that this is distinct from the ASCII character of the

same name). The escape character can be changed (see  the  escape

command).



In the IBM PC version, each session (including the command  "ses-

sion")  has  its  own  screen. When a new session is created, the

command display is saved in memory and  the  screen  is  cleared.

When  the  command  escape  key (usually F10) is hit, the current

session screen is saved and the command screen is restored.  When

a  session  is  resumed,  its  screen  is  restored exactly as it

appeared when it was last current.



















updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 4 -





3.  Commands



This chapter describes the commands recognized in  command  mode,

or within a startup file such as autoexec.net. These are given in

the following notation:



        command

        command literalparameter

        command subcommand <parameter>

        command [<optionalparameter>]

        command a | b





Many commands  take  subcommands  or  parameters,  which  may  be

optional  or  required.  In  general, if a required subcommand or

parameter is omitted, an error message will summarize the  avail-

able  subcommands or required parameters.  (Giving a '?' in place

of the subcommand will also generate the message.  This is useful

when  the  command  word  alone is a valid command.) If a command

takes an optional value parameter, issuing  the  command  without

the  parameter  generally displays the current value of the vari-

able. (Exceptions to this rule are noted in the  individual  com-

mand descriptions.)



Two or more parameters separated  by  vertical  bar(s)  denote  a

choice  between  the  specified  values.  Optional parameters are

shown enclosed in [brackets], and a parameter enclosed in  <angle

brackets> should be replaced with an actual value or string.  For

example, the notation <hostid> denotes an actual host or gateway,

which  may  be  specified  in  one  of  two ways: as a numeric IP

address in dotted decimal notation (eg. 44.0.0.1), or as  a  sym-

bolic name listed in the file domain.txt.



All commands and many subcommands may be  abbreviated.  You  only

need  type enough of a command's name to distinguish it from oth-

ers that begin with the same series of letters. Parameters,  how-

ever, must be typed in full.



Certain FTP subcommands (eg. put, get, dir, etc)  are  recognized

only  in converse mode with the appropriate FTP session; they are

not  recognized  in  command  mode.  (See  the  FTP   Subcommands

chapter.)



3.1.  <CR>



Entering a carriage return (empty line)  while  in  command  mode

puts  you  in converse mode with the current session. If there is

no current session, net.exe remains in command mode.



3.2.  !



An alias for the shell command.











updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 5 -





3.3.  #



Commands starting with the hash mark (#)  are  ignored.  This  is

mainly useful for comments in the autoexec.net file.



3.4.  abort [<session #>]



Abort a FTP get, put or dir  operation  in  progress.  If  issued

without  an  argument, the current session is aborted. (This com-

mand works only on FTP sessions.) When receiving  a  file,  abort

simply  resets the data connection; the next incoming data packet

will generate a TCP RST (reset)  response  to  clear  the  remote

server.   When  sending  a  file, abort sends a premature end-of-

file. Note that in both cases abort will leave a partial copy  of

the  file on the destination machine, which must be removed manu-

ally if it is unwanted.



3.5.  arp



Display the  Address  Resolution  Protocol  table  that  maps  IP

addresses to their subnet (link) addresses on subnetworks capable

of broadcasting. For each IP address entry the subnet  type  (eg.

Ethernet, AX.25), subnet address and time to expiration is shown.

If the link address  is  currently  unknown,  the  number  of  IP

datagrams awaiting resolution is also shown.



3.5.1.  arp add <hostid> ethernet |  ax25  <ethernet  address>  |

<ax25address>



Add a permanent entry to the table. It will not time out as  will

an  automatically-created entry, but must be removed with the arp

drop command.



3.5.2.  arp publish <hostid> ethernet | ax25 <ethernet address> |

<ax25address>



This command is similar to the arp add command, but  system  will

also respond to any ARP request it sees on the network that seeks

the specified address.  (Use this feature with great care.)



3.5.3.  arp drop <hostid> ax25 | ethernet



Remove the specified entry from the ARP table.



3.5.4.  arp flush



Drop all automatically-created entries in  the  ARP  table;  per-

manent entries are not affected.



3.6.  asystat



Display statistics on attached asynchronous communications inter-

faces  (8250  or  16550A), if any. The display for each port con-

sists of three lines. The first line gives the port label and the







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 6 -





configuration  flags; these indicate whether the port is a 16550A

chip, the trigger character if any, whether CTS flow  control  is

enabled,  whether  RLSD (carrier detect) line control is enabled,

and the speed in bits per second. (Receiving the trigger  charac-

ter causes the driver to signal upper layer software that data is

ready; it is automatically set to the appropriate frame end char-

acter for SLIP, PPP and NRS lines.)



The second line of the status display shows receiver  (RX)  event

counts:  the total number of receive interrupts, received charac-

ters, receiver overruns (lost characters) and the  receiver  high

water  mark. The high water mark is the maximum number of charac-

ters ever read from the device during a single interrupt. This is

useful  for  monitoring  system  interrupt  latency margins as it

shows how close the port hardware has come to overflowing due  to

the  inability  of  the CPU to respond to a receiver interrupt in

time. 8250 chips have no FIFO, so the high water mark  cannot  go

higher  than  2  before overruns occur. The 16550A chip, however,

has a 16-byte receive FIFO which the software programs to  inter-

rupt  the  CPU  when the FIFO is one-quarter full. The high water

mark should typically be 4 or 5 when a  16550A  is  used;  higher

values  indicate  that  the  CPU  has  at least once been slow to

respond to a receiver interrupt.



When the 16550A is  used,  a  count  of  FIFO  timeouts  is  also

displayed  on  the  RX status line. These are generated automati-

cally by the 16550A when three character  intervals  go  by  with

more  than  0  but  less than 4 characters in the FIFO. Since the

characters that make up a SLIP or NRS frame are normally sent  at

full  line speed, this count will usually be a lower bound on the

number of frames received on the port, as only the last  fragment

of a frame generally results in a timeout (and then only when the

frame is not a multiple of 4 bytes long.)



Finally, the software fifo  overruns  and  high  water  mark  are

displayed.  These indicate whether the <bufsize> parameter on the

attach command needs to be  adjusted  (see  the  Attach  Commands

chapter).



The third line shows transmit (TX) statistics, including a  total

count  of transmit interrupts, transmitted characters, the length

of the transmit queue in bytes, the number of status  interrupts,

and  the number of THRE timeouts. The status interrupt count will

be zero unless CTS flow control or RLSD  line  control  has  been

enabled.  The  THRE  timeout  is  a stopgap measure to catch lost

transmit interrupts, which seem to happen when there is a lot  of

activity (ideally, this will be zero).



3.7.  attach <hw type> ...



Configure and attach a hardware interface to the system. Detailed

instructions  for each driver are in the Attach Commands chapter.

An easy way to obtain a summary of the parameters required for  a

given  device  is  to  issue a partial attach command (eg. attach







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 7 -





packet). This produces a usage message giving the  complete  com-

mand format.



3.8.  ax25 ...



These commands are used for AX25 interfaces.



3.8.1.  ax25 blimit [<count>]



Display or set the AX25 retransmission  backoff  limit.  Normally

each successive AX25 retransmission is delayed by twice the value

of the previous interval; this is called binary exponential back-

off.  When  the  backoff reaches the blimit setting it is held at

that value, which defaults to 30. To prevent the  possibility  of

"congestive  collapse"  on a loaded channel, blimit should be set

at least as high as the number of stations sharing  the  channel.

Note  that this is applicable only on actual AX25 connections; UI

frames will never be retransmitted by the AX25 layer.



3.8.2.  ax25 digipeat [on | off]



Display or set the digipeater enable flag.



3.8.3.  ax25 flush



Clear the AX.25 "heard" list (see ax25 heard).



3.8.4.  ax25 heard



Display the AX.25 "heard" list. For each interface that  is  con-

figured  to use AX.25, a list of all callsigns heard through that

interface is shown, along with a count of the number  of  packets

heard  from  each station and the interval, in hr:min:sec format,

since each station was  last  heard.  The  local  station  always

appears  first in the listing; the packet count actually reflects

the number of packets transmitted. This entry is  always  present

even if no packets have been sent.



3.8.5.  ax25 irtt [<milliseconds>]



Display or set the initial value of smoothed round trip  time  to

be  used  when  a new AX25 connection is created. The value is in

milliseconds. The actual round trip time will be learned by meas-

urement once the connection has been established.



3.8.6.  ax25 kick <axcb>



Force a retransmission on the specified AX.25 control block.



3.8.7.  ax25 maxframe [<count>]



Establish the maximum number of frames that will  be  allowed  to

remain  unacknowledged at one time on new AX.25 connections. This

number cannot be greater than 7.







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 8 -





3.8.8.  ax25 mycall [<call>]



Display or set the local AX.25 address.  The standard  format  is

used  (eg. KA9Q-0 or WB6RQN-5). This command must be given before

any attach commands using AX.25 mode are given.



3.8.9.  ax25 paclen [<size>]



Limit the size of I-fields  on  new  AX.25  connections.   If  IP

datagrams  or  fragments  larger  than this are transmitted, they

will be transparently fragmented at the AX.25 level,  sent  as  a

series  of  I  frames,  and  reassembled  back into a complete IP

datagram or fragment at the other end of the link.  To  have  any

effect  on  IP  datagrams,  this parameter should be less than or

equal to the MTU of the associated interface.



3.8.10.  ax25 pthresh [<size>]



Display or set the poll threshold to be used for new  AX.25  Ver-

sion  2  connections.  The poll threshold controls retransmission

behavior as follows. If the oldest unacknowledged I-frame size is

less  than  the poll threshold, it will be sent with the poll (P)

bit set if a timeout occurs. If the oldest unacked  I-frame  size

is  equal  to  or  greater  than  the threshold, then a RR or RNR

frame, as appropriate, with the poll bit set will be  sent  if  a

timeout occurs.



The idea behind the poll threshold is that the extra time  needed

to  send  a  "small"  I-frame instead of a supervisory frame when

polling after a timeout is small, and since there's a good chance

the  I-frame  will  have to be sent anyway (i.e., if it were lost

previously) then you might as well send it as the  poll.  But  if

the I-frame is large, send a supervisory (RR/RNR) poll instead to

determine first if retransmitting the  oldest  unacknowledged  I-

frame  is necessary; the timeout might have been caused by a lost

acknowledgement.  This is obviously  a  tradeoff,  so  experiment

with  the  poll  threshold setting. The default is 128 bytes, one

half the default value of paclen.



3.8.11.  ax25 reset <axcb>



Delete the  AX.25  connection  control  block  at  the  specified

address.



3.8.12.  ax25 retry [<count>]



Limit  the  number  of  successive  unsuccessful   retransmission

attempts  on  new  AX.25  connections. If this limit is exceeded,

link re-establishment is attempted. If this  fails  retry  times,

then the connection is abandoned and all queued data is deleted.



3.8.13.  ax25 route



Display the AX.25 routing table that specifies the digipeaters to







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 9 -





be used in reaching a given station.



3.8.13.1.  ax25 route add <target> [digis ... ]



Add an entry to the AX.25 routing table.  An automatic ax25 route

add  is  executed if digipeaters are specified in an AX25 connect

command, or if a connection is received from a remote station via

digipeaters.  Such automatic routing table entries won't override

locally created entries, however.



3.8.13.2.  ax25 route drop <target>



Drop an entry from the AX.25 routing table.



3.8.14.  ax25 status [<axcb>]



Without an argument, display a one-line  summary  of  each  AX.25

control  block.  If  the address of a particular control block is

specified, the contents of that control block are dumped in  more

detail.  Note  that  the  send  queue units are frames, while the

receive queue units are bytes.



3.8.15.  ax25 t3 [<milliseconds>]



Display or set the AX.25 idle "keep alive"  timer.  Value  is  in

milliseconds.



3.8.16.  ax25 version [1 | 2]



Display or set the version of the AX.25 protocol  to  attempt  to

use  on  new connections. The default is 1 (the version that does

not use the poll/final bits).



3.8.17.  ax25 window [<size>]



Set the number of bytes that can be pending on an  AX.25  receive

queue  beyond  which I frames will be answered with RNR (Receiver

Not Ready) responses.  This presently applies only  to  suspended

interactive  AX.25  sessions,  since incoming I-frames containing

network (IP, NET/ROM) packets are  always  processed  immediately

and  are  not placed on the receive queue. However, when an AX.25

connection carries both interactive and network  packet  traffic,

an  RNR  generated because of backlogged interactive traffic will

also stop network packet traffic from being sent.



3.9.  cd [<dirname>]



Change the current working directory, and display  the  new  set-

ting.  Without an argument, cd simply displays the current direc-

tory without change. The pwd command is an alias for cd.



3.10.  close [<session>]



Close the specified  session;  without  an  argument,  close  the







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 10 -





current  session.  On  an AX.25 session, this command initiates a

disconnect.  On a FTP or Telnet session, this command sends a FIN

(i.e.,  initiates a close) on the session's TCP connection.  This

is an alternative to asking the remote server to initiate a close

(QUIT  to  FTP,  or the logout command appropriate for the remote

system in the case of Telnet).  When either FTP  or  Telnet  sees

the  incoming  half  of  a TCP connection close, it automatically

responds by closing the outgoing half of the  connection.   Close

is  more  graceful  than  the  reset  command, in that it is less

likely to leave the remote TCP in a "half-open" state.



3.11.  connect <iface> <callsign> [<digipeater> ... ]



Initiate a "vanilla" AX.25 session to  the  specified  call  sign

using the specified interface. Data sent on this session goes out

in conventional AX.25 packets with no upper layer protocol.   The

de-facto  presentation  standard  format  is  used,  in that each

packet holds one line of text, terminated by a  carriage  return.

A  single  AX.25 connection may be used for terminal-to-terminal,

IP and NET/ROM traffic. The three types of data are automatically

separated by their AX.25 Level 3 Protocol IDs.



Up to 7 optional digipeaters may be given; note that the word via

is  NOT  needed. If digipeaters are specified, they are automati-

cally added to the AX25 routing table as though  the  ax25  route

add command had been given before issuing the connect command.



3.12.  delete <filename>



Delete a filename in the current working directory.



3.13.  detach <iface>



Detach a previously attached interface from the  system.  All  IP

routing  table  entries  referring to this interface are deleted,

and forwarding references by any other interface to  this  inter-

face are removed.



3.14.  dialer <iface> <seconds> <hostid> <pings> <dialer-file>



Setup an autodialer  session  for  the  interface.  Whenever  the

interface  is  idle for the interval in <seconds>, the autodialer

will ping the <hostid>. If  there  is  no  answer  after  <pings>

attempts,  the  autodialer will execute the special commands con-

tained in the <dialer-file>.



If the interval in <seconds> is zero, a previous  dialer  command

process  will  be  removed. If the number of <pings> is zero, the

<dialer-file> will be executed without pinging the <hostid>.



The file may have any valid name, and must be located in the con-

figuration  directory  (see the Installion section). The commands

in the file are described in the Dialer Subcommands chapter.









updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 11 -





3.15.  dir [<dirname>]



List the contents of the specified directory on the  console.  If

no  argument is given, the current directory is listed. Note that

this command works by first listing the  directory  into  a  tem-

porary  file,  and  then  creating  a more session to display it.

After this completes, the temporary file is deleted.



3.16.  disconnect [<session #>]



An alias for the close command (for the benefit of AX.25 users).



3.17.  domain ...



These commands are used for access to the Domain Name Service.



3.17.1.  domain addserver <hostid>



Add one or more  domain  name  server(s)  to  the  list  of  name

servers.



3.17.2.  domain dropserver <hostid>



Remove one or more domain name server(s) from the  list  of  name

servers.



3.17.3.  domain listservers



List the currently configured domain  name  servers,  along  with

statistics  on  how  many queries and replies have been exchanged

with each one, response times, etc.



3.17.4.  domain query <hostid>



Send a query to a domain server asking for all  resource  records

associated with this <hostid>, and list the records.



3.17.5.  domain retry [<count>]



Display or set the number of attempts to reach each server on the

list  during one call to the resolver. If this count is exceeded,

a failure indication is returned. If set  to  0,  the  list  will

cycle  forever;  this may be useful for unattended operation. The

default is 3.



3.17.6.  domain suffix [<domain suffix>]



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 ampr.org and the user enters  telnet  ka9q,  the

domain  resolver  will attempt to find ka9q.ampr.org. If the host

name being sought contains one  or  more  periods,  however,  the

default  suffix  is  NOT applied (eg. telnet foo.bar would NOT be

turned into foo.bar.ampr.org).







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 12 -





3.17.7.  domain trace [on | off]



Display or set the flag controlling the tracing of domain  server

requests  and  responses.  Trace  messages will be seen only if a

domain name being sought is not found in the  local  cache  file,

domain.txt.



3.17.8.  domain cache ...



These commands are used for the use of the resource  record  file

domain.txt, and the local memory cache.



3.17.8.1.  domain cache clean [on | off]



Display or set the  flag  controlling  the  removal  of  resource

records  from  the domain.txt file whose time-to-live has reached

zero.



When  clean  is  off  (the  default),  expired  records  will  be

retained;  if  no replacement can be obtained from another domain

name server, these records will continue to be used.



When clean is on, expired records will be removed from  the  file

whenever any new record is added to the file.



3.17.8.2.  domain cache list



List the current contents of the local memory cache.



3.17.8.3.  domain cache size [<count>]



Display or set the nominal  maximum  size  of  the  local  memory

cache. The default is 20.



(Note: The cache may be temporarily larger when waiting  for  new

records to be written to the domain.txt file.)



3.17.8.4.  domain cache wait [<seconds>]



Display or set the interval in seconds  to  wait  for  additional

activity before updating the domain.txt file.  The default is 300

seconds (5 minutes).



3.18.  echo [accept | refuse]



Display or set the flag controlling client Telnet's response to a

remote WILL ECHO offer.



The Telnet presentation protocol specifies that in the absence of

a  negotiated  agreement to the contrary, neither end echoes data

received from the other. In this mode, a  Telnet  client  session

echoes  keyboard input locally and nothing is actually sent until

a carriage return is typed. Local line editing is also performed:

backspace  deletes  the  last  character  typed,  while control-U







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 13 -





deletes the entire line.



When communicating from keyboard to keyboard the  standard  local

echo  mode  is  used,  so  the  setting  of this parameter has no

effect. However, many timesharing systems (eg. UNIX) prefer to do

their own echoing of typed input. (This makes screen editors work

right, among other things). Such systems send a Telnet WILL  ECHO

offer  immediately  upon  receiving an incoming Telnet connection

request. If echo accept is in effect,  a  client  Telnet  session

will automatically return a DO ECHO response. In this mode, local

echoing and editing is turned off and each  key  stroke  is  sent

immediately  (subject  to  the  Nagle tinygram algorithm in TCP).

While this mode is just fine across an Ethernet,  it  is  clearly

inefficient and painful across slow paths like packet radio chan-

nels. Specifying echo refuse causes an incoming WILL  ECHO  offer

to  be  answered  with  a  DONT  ECHO;  the client Telnet session

remains in the local echo mode.  Sessions already in  the  remote

echo  mode are unaffected. (Note: Berkeley Unix has a bug in that

it will still echo input even after the client  has  refused  the

WILL ECHO offer. To get around this problem, enter the stty -echo

command to the shell once you have logged in.)



3.19.  eol [unix | standard]



Display or set Telnet's end-of-line behavior when in remote  echo

mode.  In  standard  mode,  each key is sent as-is. In unix mode,

carriage returns are translated to line feeds.  This  command  is

not  necessary  with  all UNIX systems; use it only when you find

that a particular system responds to line feeds but not  carriage

returns.   Only SunOS release 3.2 seems to exhibit this behavior;

later releases are fixed.



3.20.  escape [<char>]



Display or set the current command-mode escape character in  hex.

(This  command  is  not  provided  on  the IBM-PC; on the PC, the

escape char is always F10.)



3.21.  etherstat



Display 3-Com Ethernet controller statistics (if configured).



3.22.  exit



Exit the net.exe program and return to MS-DOS.



3.23.  finger <user@hostid> [<user@hostid> ...]



Issue a network finger request for user user at host hostid. This

creates  a  client  session  which  may  be interrupted, resumed,

reset, etc, just like a Telnet client session.













updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 14 -





3.24.  ftp <hostid>



Open an FTP control channel to  the  specified  remote  host  and

enter  converse  mode  on  the  new  session.  Responses from the

remote server are displayed directly on the screen. See  the  FTP

Subcommands chapter for descriptions of the commands available in

a FTP session.



3.25.  help



Display a brief summary of top-level commands.



3.26.  hop ...



These commands are used to test the connectivity of the network.



3.26.1.  hop check <hostid>



Initiate a hopcheck session to the specified host.  This  uses  a

series  of  UDP  "probe" packets with increasing IP TTL fields to

determine the sequence of gateways in the path to  the  specified

destination. This function is patterned after the UNIX traceroute

facility.



ICMP message tracing should be turned off before this command  is

executed (see the icmp trace command).



3.26.2.  hop maxttl [<hops>]



Display or set the maximum TTL value to be used in hop check ses-

sions. This effectively bounds the radius of the search.



3.26.3.  hop maxwait [<seconds>]



Display or set the maximum interval that a hopcheck session  will

wait  for  responses at each stage of the trace. The default is 5

seconds.



3.26.4.  hop queries [<count>]



Display or set the number of UDP probes that will be sent at each

stage of the trace. The default is 3.



3.26.5.  hop trace [on | off]



Display or set the flag that controls the display  of  additional

information during a hop check session.



3.27.  hostname [<name>]



Display or set the local host's name. By convention  this  should

be  the  same  as  the host's primary domain name. This string is

used only  in  the  greeting  messages  of  the  various  network

servers; note that it does NOT set the system's IP address.







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 15 -





If <name> is the same as an  <iface>  (see  the  Attach  commands

chapter),  this  command  will search for a CNAME domain resource

record which corresponds to the IP address of the <iface>.



3.28.  hs



Display statistics about the HS high speed HDLC driver  (if  con-

figured and active).



3.29.  icmp ...



These commands are used for the Internet Control Message Protocol

service.



3.29.1.  icmp echo [on | off]



Display or set the flag controlling the asynchronous  display  of

ICMP  Echo Reply packets. This flag must be on for one-shot pings

to work (see the ping command.)



3.29.2.  icmp status



Display statistics about the Internet  Control  Message  Protocol

(ICMP),  including  the number of ICMP messages of each type sent

or received.



3.29.3.  icmp trace [on | off]



Display or set the flag controlling the  display  of  ICMP  error

messages.  These informational messages are generated by Internet

routers in response to routing, protocol or congestion  problems.

This  option  should  be  turned  off  before using the hop check

facility because it relies on ICMP Time  Exceeded  messages,  and

the  asynchronous  display of these messages will be mingled with

hop check command output.



3.30.  ifconfig



Display a list of interfaces, with a short status for each.



3.30.1.  ifconfig <iface>



Display an extended status of the interface.



3.30.2.  ifconfig <iface> broadcast <address>



Set the broadcast address for the interface. The <address>  takes

the  form  of  an  IP  address  with  1's in the host part of the

address. This is related to the netmask sub-command. See also the

arp command.



3.30.3.  ifconfig <iface> encapsulation <name>



Not fully implemented.







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 16 -





3.30.4.  ifconfig <iface> forward <forward-iface>



Set a forwarding interface for multiple  channel  interfaces.  To

remove the forward, set <forward-iface> to <iface>.



3.30.5.  ifconfig <iface> ipaddress <hostid>



Set the IP address for this interface. It  is  standard  Internet

practice  that each interface has its own address. For hosts with

only one interface, the interface address is usually the same  as

the host address. See also the hostname and ip address commands.



3.30.6.  ifconfig <iface> linkaddress <hardware-dependant>



Set the hardware dependant address for this interface.



3.30.7.  ifconfig <iface> mtu <mtu>



Set the MTU for this interface. See the Setting ... MTU, MSS  and

Window chapter for more information.



3.30.8.  ifconfig <iface> netmask <address>



Set the sub-net mask for this interface. The <address> takes  the

form of an IP address with 1's in the network and subnet parts of

the address, and 0's in the host part of  the  address.  This  is

related to the broadcast sub-command. See also the route command.



3.30.9.  ifconfig <iface> rxbuf <?>



Not yet implemented.



3.31.  ip ...



These commands are used for the Internet Protocol service.



3.31.1.  ip address [<hostid>]



Display or set the default local IP address. This command must be

given before an attach command if it is to be used as the default

IP address for the interface.



3.31.2.  ip rtimer [<seconds>]



Display or set the IP  reassembly  timeout.  The  default  is  30

seconds.



3.31.3.  ip status



Display Internet Protocol (IP) statistics, such as  total  packet

counts and error counters of various types.













updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 17 -





3.31.4.  ip ttl [<hops>]



Display or set the time-to-live value placed in each outgoing  IP

datagram. This limits the number of switch hops the datagram will

be allowed to take. The idea is to  bound  the  lifetime  of  the

packet  should  it  become  caught in a routing loop, so make the

value slightly larger than the number of hops across the  network

you  expect to transit packets. The default is set at compilation

time to the official recommended value for the Internet.



3.32.  isat [on | off]



Display or set the AT flag. Currently, there is no sure-fire  way

to  determine  the  type of clock-chip being used.  If an AT type

clock is in use, this command will allow measurement of  time  in

milliseconds,  rather than clock ticks (55 milliseconds per clock

tick).



3.32.1.  kick [<session>]



Kick all sockets associated with a session;  if  no  argument  is

given,  kick  the  current session. Performs the same function as

the ax25 kick and tcp kick commands, but is easier to type.



3.33.  log [stop | <filename>]



Display or set the filename for logging server sessions. If  stop

is  given  as  the  argument,  logging is terminated (the servers

themselves are unaffected). If a file name is given as  an  argu-

ment, server session log entries will be appended to it.



3.34.  mbox



Display the status of the mailbox server system (if configured).



3.35.  memory ...



These commands are used for memory allocation.



3.35.1.  memory free



Display the storage allocator free list. Each entry consists of a

starting address, in hex, and a size, in decimal bytes.



3.35.2.  memory sizes



Display a histogram of storage allocator request sizes. Each his-

togram bin is a binary order of magnitude (i.e., a factor of 2).



3.35.3.  memory status



Display a summary of storage allocator statistics. The first line

shows the base address of the heap, its total size, the amount of

heap memory available in bytes and as a percentage of  the  total







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 18 -





heap  size,  and the amount of memory left over (i.e., not placed

on the heap at startup) and therefore available for shell subcom-

mands.



The second line shows the total number of calls to  allocate  and

free  blocks of memory, the difference of these two values (i.e.,

the number of allocated blocks outstanding), the number of  allo-

cation  requests  that were denied due to lack of memory, and the

number of calls to free() that attempted to free garbage (eg.  by

freeing the same block twice or freeing a garbled pointer).



The third line shows the number of calls to malloc and free  that

occurred  with  interrupts off. In normal situations these values

should be zero. The fourth line shows statistics for the  special

pool of fixed-size buffers used to satisfy requests for memory at

interrupt time. The variables shown are  the  number  of  buffers

currently  in  the  pool,  their size, and the number of requests

that failed due to exhaustion of the pool.



3.36.  mkdir <dirname>



Create a sub-directory in the current working directory.



3.37.  mode <iface> [vc | datagram]



Control the default transmission  mode  on  the  specified  AX.25

interface. In datagram mode, IP packets are encapsulated in AX.25

UI frames and transmitted without any other  link  level  mechan-

isms, such as connections or acknowledgements.



In vc (virtual circuit) mode,  IP  packets  are  encapsulated  in

AX.25  I  frames and are acknowledged at the link level according

to the AX.25 protocol.  Link  level  connections  are  opened  if

necessary.



In both modes, ARP is used to map IP  to  AX.25  addresses.   The

defaults can be overridden with the type-of-service (TOS) bits in

the IP header. Turning on the "reliability" bit causes  I  frames

to  be used, while turning on the "low delay" bit uses UI frames.

(The effect of turning on both bits is undefined and  subject  to

change).



In both modes, IP-level fragmentation is done if the datagram  is

larger  than  the  interface  MTU.  In virtual circuit mode, how-

ever, the resulting datagram (or fragments) is further fragmented

at  the  AX.25  layer  if  it (or they) are still larger than the

AX.25 paclen parameter. In  AX.25  fragmentation,  datagrams  are

broken into several I frames and reassembled at the receiving end

before being passed to IP. This is preferable to IP fragmentation

whenever  possible  because  of decreased overhead (the IP header

isn't repeated in each fragment) and increased robustness (a lost

fragment is immediately retransmitted by the link layer).











updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 19 -





3.38.  more <file> [<file> ...]



Display the specified file(s) a screen at a time. To  proceed  to

the  next screen, press the space bar; to cancel the display, hit

the 'q' key. The more command creates  a  session  that  you  can

suspend and resume just like any other session.



3.39.  param <iface> [<param> ...]



Invoke a device-specific control routine.  On a KISS  TNC  inter-

face,  this  sends  control  packets  to the TNC.  Data bytes are

treated as decimal.  For example, param ax0 1 255  will  set  the

keyup timer (type field = 1) on the KISS TNC configured as ax0 to

2.55 seconds (255 x .01 sec).  On a  SLIP  interface,  the  param

command  allows  the  baud rate to be read (without arguments) or

set.  The implementation of this command for the  various  inter-

face drivers is incomplete and subject to change.



3.40.  ping <hostid> [<length> [<seconds> [<incflag>]]]



Ping (send ICMP Echo Request packets to) the specified  host.  By

default  the data field contains only a small timestamp to aid in

determining round trip time; if the optional length  argument  is

given,  the  appropriate  number of data bytes (consisting of hex

55) are added to the ping packets.



If interval is specified, pings will be repeated indefinitely  at

the  specified  number of seconds; otherwise a single, "one shot"

ping is done. Responses to one-shot pings  appear  asynchronously

on the command screen, while repeated pings create a session that

may be suspended and resumed. Pinging continues until the session

is manually reset.



The incflag option causes a repeated ping to increment the target

IP  address  for  each  ping;  it  is an experimental feature for

searching blocks of IP addresses for active hosts.



3.41.  ppp ...



These commands are used for Point to Point Protocol interfaces.



This implementation of PPP is designed to be as complete as  pos-

sible.  Because  of  this,  the  number  of options can be rather

daunting. However, a typical PPP configuration might include  the

following commands:

























updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 20 -







        attach asy 0x3f8 4 ppp pp0 4096 1500 9600

        dial pp0 30 <hostid> 3 dialer.pp0

        #

        ppp pp0 lcp local accm 0

        ppp pp0 lcp local compress address on

        ppp pp0 lcp local compress protocol on

        ppp pp0 lcp local magic on

        ppp pp0 lcp open active

        #

        ppp pp0 ipcp local compress tcp 16 1

        ppp pp0 ipcp open active

        #

        route add default pp0





3.41.1.  ppp <iface>



Display the status of the PPP interface.



3.41.2.  ppp <iface> lcp ...



These commands are used for the LCP [Link Control Protocol]  con-

figuration.



3.41.2.1.  ppp <iface> lcp close



Shutdown the PPP interface.



3.41.2.2.  ppp <iface> lcp local ...



These commands control the configuration of the local side of the

link.  If  an option is specified, the parameters will be used as

the initial values in configuration requests. If  not  specified,

that option will not be requested.



For each of these options, the allow parameter  will  permit  the

remote  to  include  that  option  in its response, even when the

option is not included in the request. By  default,  all  options

are allowed.



3.41.2.2.1.  ppp <iface> lcp local accm [ <bitmap> | allow [on  |

off] ]



Display or set the Async Control Character Map.  The  default  is

0xffffffff.



3.41.2.2.2.  ppp <iface> lcp local authenticate [ pap  |  none  |

allow [on | off] ]



Display or set the authentication protocol. The default is none.













updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 21 -





3.41.2.2.3.  ppp <iface> lcp local cfor hardware interrupt events will turn off this  flag;  this  is

done to avoid critical sections and missed interrupts. The W flag

indicates that the process is waiting for  an  event;  the  event

column will be non-blank. Note that although there may be several

runnable processes at any time (shown in the ps listing as  those

without  the W flag and with blank event fields) only one process

is actually running at any one instant  (The  Refrigerator  Light

Effect  says  that  the ps command is always the one running when

this display is generated.)



3.43.  pwd [<dirname>]



An alias for the cd command.



3.44.  record [off | <filename>]



Append to filename all data  received  on  the  current  session.

Data  sent  on  the current session is also written into the file

except for Telnet sessions in  remote  echo  mode.   The  command

record off stops recording and closes the file.



3.45.  remote [-p <port>] [-k  <key>]  [-a  <kickaddr>]  <hostid>

exit | reset | kick



Send a UDP packet to the specified host commanding it to exit the

net.exe  program,  reset the processor, or force a retransmission

on TCP connections.  For this command to be accepted, the  remote

system  must  be  running  the  remote server and the port number

specified in the remote command must match the port number  given

when  the  server  was  started on the remote system. If the port

numbers do not match, or if the remote server is not  running  on

the  target  system,  the command packet is ignored.  Even if the

command is accepted there is no acknowledgement.



The kick command forces a retransmission timeout on all TCP  con-

nections  that  the  remote node may have with the local node. If

the -a option is used, connections  to  the  specified  host  are

kicked instead. No key is required for the kick subcommand.



The exit and reset subcommands are mainly useful  for  restarting

the  net.exe program on a remote unattended system after the con-

figuration file has  been  updated.   The  remote  system  should







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 25 -





invoke the net.exe program automatically upon booting, preferably

in an infinite loop.  For example, under  MS-DOS  the  boot  disk

should contain the following in autoexec.net:



        :loop

        net

        goto :loop







3.46.  remote -s <key>



The exit and reset subcommands of remote require a password.  The

password  is  set on a given system with the -s option, and it is

specified in a command to a remote system with the -k option.  If

no  password  is  set with the -s option, then the exit and reset

subcommands are disabled.



Note that remote is an experimental feature in NOS; it is not yet

supported by any other TCP/IP implementation.



3.47.  rename <oldfilename> <newfilename>



Rename oldfilename to newfilename.



3.48.  reset [<session>]



Reset the specified session; if no argument is given,  reset  the

current  session.  This command should be used with caution since

it does not reliably inform the remote end that the connection no

longer  exists.   (In TCP a reset (RST) message will be automati-

cally generated should the remote TCP send anything after a local

reset  has been done.  In AX.25 the DM message performs a similar

role.  Both are used to get rid of a lingering half-open  connec-

tion after a remote system has crashed.)



3.49.  rip ...



These commands are used for the RIP service.



3.49.1.  rip accept <gateway>



Remove the specified gateway from the RIP filter table,  allowing

future broadcasts from that gateway to be accepted.



3.49.2.  rip add <hostid> <seconds> [<flags>]



Add an entry to the RIP broadcast table.  The  IP  routing  table

will be sent to hostid every interval seconds. If flags is speci-

fied as 1, then "split horizon" processing will be performed  for

this  destination. That is, any IP routing table entries pointing

to the interface that will be used to send this  update  will  be

removed  from  the  update.   If  split horizon processing is not

specified, then all routing table  entries  except  those  marked







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 26 -





"private" will be sent in each update. (Private entries are never

sent in RIP packets).



Triggered updates are always done. That is,  any  change  in  the

routing  table  that causes a previously reachable destination to

become unreachable will trigger an  update  that  advertises  the

destination with metric 15, defined to mean "infinity".



Note that for RIP packets to be  sent  properly  to  a  broadcast

address,  there  must  exist  correct  IP  routing  and ARP table

entries that will first steer the broadcast to the correct inter-

face  and  then place the correct link-level broadcast address in

the link-level destination field.  If  a  standard  IP  broadcast

address  convention  is  used  (eg. 128.96.0.0 or 128.96.255.255)

then chances are you already have the necessary IP routing  table

entry,  but  unusual  subnet  or  cluster-addressed  networks may

require special attention. However, an arp add  command  will  be

required  to translate this address to the appropriate link level

broadcast address.  For example,





arp add 128.96.0.0 ethernet ff:ff:ff:ff:ff:ff





for an Ethernet network, and





arp add 44.255.255.255 ax25 qst-0





for an AX25 packet radio channel.



3.49.3.  rip drop <dest>



Remove an entry from the RIP broadcast table.



3.49.4.  rip merge [on | off]



This flag controls  an  experimental  feature  for  consolidating

redundant  entries  in  the IP routing table. When rip merging is

enabled, the table is scanned after processing each  RIP  update.

An entry is considered redundant if the target(s) it covers would

be routed identically by a less "specific" entry already  in  the

table.  That is, the target address(es) specified by the entry in

question must  also  match  the  target  addresses  of  the  less

specific  entry  and the two entries must have the same interface

and gateway fields. For example, if the routing table contains





Dest            Len Interface    Gateway          Metric  P Timer  Use

1.2.3.4         32  ethernet0    128.96.1.2       1       0 0      0

1.2.3           24  ethernet0    128.96.1.2       1       0 0      0











updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 27 -





then the first entry would be deleted as redundant since  packets

sent  to  1.2.3.4  will  still  be routed correctly by the second

entry. Note that the relative metrics of the entries are ignored.



3.49.5.  rip refuse <gateway>



Refuse to accept RIP updates from the specified gateway by adding

the gateway to the RIP filter table. It may be later removed with

the rip accept command.



3.49.6.  rip request <gateway>



Send a RIP Request packet to the specified gateway, causing it to

reply with a RIP Response packet containing its routing table.



3.49.7.  rip status



Display RIP status, including a count of the  number  of  packets

sent  and  received,  the  number  of requests and responses, the

number of unknown RIP packet types, and the number of refused RIP

updates  from  hosts in the filter table. A list of the addresses

and intervals to which periodic RIP updates  are  being  sent  is

also shown, along with the contents of the filter table.



3.49.8.  rip trace [0 | 1 | 2]



This variable controls the tracing of incoming and  outgoing  RIP

packets.  Setting  it to 0 disables all RIP tracing. A value of 1

causes changes in the routing table to be displayed, while  pack-

ets  that  cause no changes cause no output. Setting the variable

to 2 produces maximum output, including tracing  of  RIP  packets

that cause no change in the routing table.



3.50.  rmdir <dirname>



Remove a sub-directory from the current working directory.



3.51.  route



With no arguments, route displays the IP routing table.



3.51.1.   route  add  <desthostid>[/bits]  |   default   <iface>

[<gatewayhostid> [<metric>]]



This command adds an entry to the routing table. It  requires  at

least  two  more  arguments, the hostid of the target destination

and the name of the interface to  which  its  packets  should  be

sent.   If  the  destination  is  not local, the gateway's hostid

should also be specified. (If the interface is  a  point-to-point

link,  then  gatewayhostid  may be omitted even if the target is

non-local because this  field  is  only  used  to  determine  the

gateway's  link  level  address,  if  any.  If the destination is

directly reachable, gatewayhostid is also unnecessary since  the

destination  address  is  used  to  determine  the interface link







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 28 -





address).



The optional /bits suffix to the destination  host  id  specifies

how  many leading bits in the host id are to be considered signi-

ficant in the routing comparisons.  If  not  specified,  32  bits

(i.e., full significance) is assumed.  With this option, a single

routing table entry may refer to many hosts all sharing a  common

bit  string prefix in their IP addresses. For example, ARPA Class

A, B and C networks would use suffixes of /8, /16 and /24 respec-

tively; the command



route add 44/8 sl0 44.64.0.2





causes any IP addresses beginning with "44" in the first  8  bits

to  be  routed  to  44.64.0.2;  the remaining 24 bits are "don't-

cares".



When an IP address to be routed matches more than  one  entry  in

the  routing  table, the entry with largest bits parameter (i.e.,

the "best" match) is used. This allows individual hosts or blocks

of  hosts  to  be  exceptions to a more general rule for a larger

block of hosts.



The special destination default is used  to  route  datagrams  to

addresses  not matched by any other entries in the routing table;

it is equivalent to specifying a /bits suffix of /0 to any desti-

nation hostid.  Care must be taken with default entries since two

nodes with default entries pointing  at  each  other  will  route

packets to unknown addresses back and forth in a loop until their

time-to-live (TTL) fields expire.  (Routing  loops  for  specific

addresses  can  also be created, but this is less likely to occur

accidentally).



Here are some examples of the route command:



# Route datagrams to IP address 44.0.0.3 to SLIP line #0.

# No gateway is needed because SLIP is point-to point.

route add 44.0.0.3 sl0



# Route all default traffic to the gateway on the local Ethernet

# with IP address 44.0.0.1

route add default ec0 44.0.0.1



# The local Ethernet has an ARPA Class-C address assignment;

# route all IP addresses beginning with 192.4.8 to it

route add 192.4.8/24 ec0



# The station with IP address 44.0.0.10 is on the local AX.25 channel

route add 44.0.0.10 ax0















updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 29 -





3.51.2.  route addprivate <dest hostid>[/bits] | default  <iface>

[<gateway hostid> [<metric>]]



This command is identical to route add except that it also  marks

the  new  entry as private; it will never be included in outgoing

RIP updates.



3.51.3.  route drop <dest hostid>



route drop deletes an entry from the table. If a  packet  arrives

for the deleted address and a default route is in effect, it will

be used.



3.52.  session [<session #>]



Without arguments, displays the list of current sessions, includ-

ing  session  number, remote TCP or AX.25 address and the address

of the TCP or AX.25 control block.  An asterisk (*) is shown next

to  the current session; entering a blank line at this point puts

you in converse mode  with  that  session.   Entering  a  session

number as an argument to the session command will put you in con-

verse mode with that session.  If the Telnet server  is  enabled,

the  user is notified of an incoming request and a session number

is automatically assigned.  The user may then select the  session

normally  to  converse with the remote user as though the session

had been locally initiated.



3.53.  shell



Suspends net.exe and executes a  sub-shell  ("command  processor"

under  MS-DOS).  When the sub-shell exits, net.exe resumes (under

MS-DOS,  enter  the  exit  command).  Background  activity   (FTP

servers, etc) is also suspended while the subshell executes. Note

that this will fail unless there is sufficient unused memory  for

the sub-shell and whatever command the user tries to run.



3.54.  smtp ...



These commands are used for the Simple Message Transport Protocol

service (that is, mail).



3.54.1.  smtp gateway [<hostid>]



Displays or sets the host to be used as a "smart" mail relay. Any

mail sent to a host not in the host table will instead be sent to

the gateway for forwarding.



3.54.2.  smtp kick



Run through the outgoing mail queue and attempt  to  deliver  any

pending  mail.  This  command  allows the user to "kick" the mail

system manually. Normally, this command is  periodically  invoked

by a timer whenever net.exe is running.









updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 30 -





3.54.3.  smtp maxclients [<count>]



Displays or sets the maximum number of simultaneous outgoing SMTP

sessions  that  will  be allowed. The default is 10; reduce it if

network congestion is a problem.



3.54.4.  smtp timer [<seconds>]



Displays or sets the interval between scans of the outbound  mail

queue. For example, smtp timer 600 will cause the system to check

for outgoing mail every 10 minutes and attempt  to  deliver  any-

thing  it  finds, subject of course to the smtp maxclients limit.

Setting a value of zero disables queue scanning altogether,  note

that  this  is  the default!  This value is recommended for stand

alone IP gateways that never handle mail, since it saves wear and

tear on the floppy disk drive.



3.54.5.  smtp trace [<value>]



Displays or sets the trace flag in the SMTP client, allowing  you

to  watch  SMTP's  conversations  as it delivers mail.  Zero (the

default) disables tracing.



3.55.  socket [<socket #>]



Without an argument, displays all active  sockets,  giving  their

index  and  type,  the address of the associated protocol control

block and the and owner process ID and name. If the index  to  an

active socket is supplied, the status display for the appropriate

protocol is called. For example, if the socket refers  to  a  TCP

connection, the display will be that given by the tcp status com-

mand with the protocol control block address.



3.56.  start ax25 | discard | echo | ftp | netrom | remote | smtp

| telnet | ttylink



Start the specified Internet server, allowing  remote  connection

requests.



3.57.  stop ax25 | discard | echo | ftp | netrom | remote |  smtp

| telnet | ttylink



Stop the specified Internet server, rejecting any further  remote

connect  requests.  Existing  connections are allowed to complete

normally.



3.58.  tcp ...



These commands are used for  the  Transmission  Control  Protocol

service.



3.58.1.  tcp irtt [<milliseconds>]



Display  or  set  the  initial  round  trip  time  estimate,   in







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 31 -





milliseconds,  to  be used for new TCP connections until they can

measure and adapt to the actual value.  The default is 5000  mil-

liseconds  (5  seconds). Increasing this when operating over slow

channels will avoid the flurry of retransmissions that would oth-

erwise occur as the smoothed estimate settles down at the correct

value. Note that this command should be given before servers  are

started in order for it to have effect on incoming connections.



TCP also keeps a cache of measured  round  trip  times  and  mean

deviations (MDEV) for current and recent destinations. Whenever a

new TCP connection is opened, the  system  first  looks  in  this

cache.  If  the  destination  is  found, the cached IRTT and MDEV

values are used. If not, the default IRTT value  mentioned  above

is used, along with a MDEV of 0. This feature is fully automatic,

and it can improve performance greatly when a series  of  connec-

tions  are opened and closed to a given destination (eg. a series

of FTP file transfers or directory listings).



3.58.2.  tcp kick <tcbaddr>



If there is unacknowledged data on the send queue of  the  speci-

fied TCB, this command forces an immediate retransmission.



3.58.3.  tcp mss [<size>]



Display or set the TCP Maximum Segment Size in bytes that will be

sent  on  all  outgoing TCP connect request (SYN segments).  This

tells the remote end the size of the largest segment (packet)  it

may  send. Changing MSS affects only future connections; existing

connections are unaffected.



3.58.4.  tcp reset <tcbaddr>



Deletes the TCP control block at the specified address.



3.58.5.  tcp rtt <tcbaddr> <milliseconds>



Replaces the automatically computed round trip time in the speci-

fied TCB with the rtt in milliseconds.  This command is useful to

speed up recovery from a series of lost packets since it provides

a  manual  bypass around the normal backoff retransmission timing

mechanisms.



3.58.6.  tcp status [<tcbaddr>]



Without arguments, displays several TCP-level statistics, plus  a

summary  of  all existing TCP connections, including TCB address,

send and receive queue sizes, local and remote sockets, and  con-

nection  state. If tcbaddr is specified, a more detailed dump of

the specified  TCB  is  generated,  including  send  and  receive

sequence numbers and timer information.













updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 32 -





3.58.7.  tcp window [<size>]



Displays or sets the default receive window size in bytes  to  be

used  by  TCP when creating new connections. Existing connections

are unaffected.



3.59.  telnet <hostid>



Creates a Telnet session to the specified host  and  enters  con-

verse mode.



3.60.  tip <iface>



Creates a tip session that connects to the specified interface in

"dumb  terminal"  mode.  The  interface  must  have  already been

attached  with  the  attach  command.  Any  packet  traffic   (IP

datagrams, etc) routed to the interface while this session exists

will be discarded. To close a tip session, use the reset command.

It will then revert to normal slip, nrs or kiss mode operation.



This feature is primarily useful for manually  establishing  SLIP

connections.  At  present,  only  the built-in "com" ports can be

used with this command.



3.61.  trace [<iface> [off | <btio> [<tracefile>]]]



Controls packet tracing by the interface drivers.  Specific  bits

enable tracing of the various interfaces and the amount of infor-

mation produced. Tracing is controlled on a per-interface  basis;

without  arguments,  trace gives a list of all defined interfaces

and their tracing status. Output  can  be  limited  to  a  single

interface  by  specifying it, and the control flags can be change

by specifying them as well. The flags are given as a  hexadecimal

number which is interpreted as follows:



    O - Enable tracing of output packets if 1, disable if 0

    I - Enable tracing of input packets if 1, disable if 0

    T - Controls type of tracing:

        0 - Protocol headers are decoded, but data is not displayed

        1 - Protocol headers are decoded, and data (but not the

            headers themselves) are displayed as ASCII characters,

            64 characters/line. Unprintable characters are displayed

            as periods.

        2 - Protocol headers are decoded, and the entire packet

            (headers AND data) is also displayed in hexadecimal

            and ASCII, 16 characters per line.

    B - Broadcast filter flag. If set, only packets specifically addressed

        to this node will be traced; broadcast packets will not be displayed.



If tracefile is not specified, tracing will be to the console.



3.62.  udp status



Displays the status of all UDP receive queues.







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 33 -





3.63.  upload [<filename>]



Opens filename and sends it on the current session as  though  it

were typed on the terminal.



3.64.  watch



Displays the current software stopwatch values, with min and  max

readings  for  each. This facility allows a programmer to measure

the execution time of critical sections of code with  microsecond

resolution. This command is supported only on the IBM PC, and the

meaning of each stopwatch value depends on where the  calls  have

been inserted for test purposes; the distribution copy of net.exe

usually has no stopwatch calls.



3.65.  ?



Same as the help command.















































































updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 34 -





4.  Attach Commands



This chapter details the attach commands for the various hardware

interface  drivers.  Not  all  of these drivers may be configured

into every net.exe binary; a list of the available types  may  be

obtained by entering the command attach ?.



Some parameters are accepted by several drivers. They are:



4.0.1.  <bufsize>



For asynchronous devices (eg. COM ports operating in SLIP or  NRS

mode)  this  parameter  specifies the size of the receiver's ring

buffer. It should be large enough to hold incoming data  at  full

line  speed  for  the longest time that the system may be busy in

MS-DOS or the BIOS doing a slow I/O operation (eg.  to  a  floppy

disk). A kilobyte is usually more than sufficient.



For synchronous devices (eg. the scc, hs, pc100,  hapn  and  drsi

interfaces  operating in HDLC mode), the bufsize parameter speci-

fies the largest packet that may be received  on  the  interface.

This should be set by mutual agreement among stations sharing the

channel. For standard AX.25 with a maximum I-frame data  size  of

256  bytes, a value of 325 should provide an adequate safety mar-

gin. On higher speed channels (eg. 56kb/s) larger values (eg.  2K

bytes)  will provide much better performance and allow full-sized

Ethernet packets to be carried without fragmentation.



4.0.2.  <ioaddr>



The base address of the interface's control registers, in hex.



4.0.3.  <vector>



The interface's hardware interrupt (IRQ) vector, in hex.



4.0.4.  <iface>



The name (an arbitrary character string) to be assigned  to  this

interface.  It  is used to refer to the interface in ifconfig and

route commands and in trace output.



4.0.5.  <mtu>



The Maximum Transmission Unit size, in bytes.   Datagrams  larger

than  this  limit will be fragmented at the IP layer into smaller

pieces. For AX.25 UI frames, this limits the size of the informa-

tion  field. For AX.25 I frames, however, the ax25 paclen parame-

ter is also relevant.  If  the  datagram  or  fragment  is  still

larger  than paclen, it is also fragmented at the AX.25 level (as

opposed to the IP level)  before  transmission.   (See  the  ax25

paclen command for further information).











updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 35 -





4.0.6.  <speed>



The speed in bits per second (eg. 2400).



4.1.  attach 3c500 <ioaddr> <vector> arpa  <iface>  <qlen>  <mtu>

[<ipaddr>]



Attach a 3Com 3C501 Ethernet  interface.   qlen  is  the  maximum

allowable transmit queue length.  If the ipaddr parameter is not

given, the value associated with a prior ip address command  will

be used.



The use of this driver is not recommended; use the packet  driver

interface with the loadable 3C501 packet driver instead.



4.2.  attach asy <ioaddr> <vector>  ax25  |  nrs  |  ppp  |  slip

<iface> <bufsize> <mtu> <speed> [<crv>]



Attach a standard PC "com port" (asynchronous serial port), using

the  National  8250 or 16550A chip. Standard values on the IBM PC

and clones for ioaddr and vector are 0x3f8 and 4  for  COM1,  and

0x2f8  and 3 for COM2. If the port uses a 16550A chip, it will be

detected automatically and the FIFOs enabled.



4.2.1.  ax25



Similar to slip, except that an AX.25 header and a KISS TNC  con-

trol  header  are  added to the front of the datagram before SLIP

encoding.  Either UI (connectionless) or I  (connection-oriented)

AX.25 frames can be used; see the mode command for details.



4.2.2.  nrs



Use the NET/ROM asynchronous framing technique for  communication

with a local NET/ROM TNC.



4.2.3.  ppp



Point-to-Point-Protocol. Encapsulates datagrams in  an  HDLC-like

frame. This is a new Internet standard for point-to-point commun-

ication, compatible with CCITT standards.



4.2.4.  slip



Serial Line Internet Protocol. Encapsulates IP datagrams directly

in  SLIP  frames  without a link header. This is for operation on

point-to-point lines and is compatible with 4.2BSD UNIX SLIP.



4.2.5.  <crv>



The optional flags are a string of characters  "crv":  c  enables

RTS/CTS  detection, r enables RLSD (Carrier Detect) physical line

sensing, v enables Van Jacobson TCP/IP Header Compression, and is

valid only for SLIP.







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 36 -





4.3.  attach drsi <ioaddr> <vector> ax25 <iface> <bufsize>  <mtu>

<chaspeed> <chbspeed>



N6TTO driver for the Digital Radio Systems PCPA 8530 card.  Since

there are two channels on the board, two interfaces are attached.

They will be named iface with 'a' and 'b'  appended.  bufsize  is

the  receiver  buffer  size  in bytes; it must be larger than the

largest frame to be received. chaspeed and chbspeed  are  the

speeds, in bits/sec, for the A and B channels, respectively.



4.4.  attach eagle <ioaddr> <vector> ax25 <iface> <bufsize> <mtu>

<speed>



WA3CVG/NG6Q driver for the Eagle Computer card (Zilog 8530).



4.5.  attach hapn <ioaddr> <vector> ax25 <iface> <bufsize>  <mtu>

csma | full



KE3Z driver for  the  Hamilton  Amateur  Packet  Network  adapter

(Intel  8273).  The  csma  | full parameter specifies whether the

port should operate in carrier sense multiple access (CSMA)  mode

or in full duplex.



4.6.  attach hs <ioaddr> <vector> ax25  <iface>  <bufsize>  <mtu>

<keyupdelay> <p>



Attach a DRSI PCPA or Eagle Computer interface card using a  spe-

cial  "high  speed" 8530 driver. This driver uses busy-wait loops

to send and receive each byte instead of  interrupts,  making  it

usable  with  high speed modems (such as the WA4DSY 56kb/s modem)

on slow systems. This does have the side effect of "freezing" the

system whenever the modem transmitter or receiver is active. This

driver can operate only in CSMA mode, and it is recommended  that

no  other  interfaces  requiring  small  interrupt  latencies  be

attached to the same machine.



The keyupdelay parameter specifies the transmitter  keyup  delay

in  byte  time  intervals.  The p value specifies the transmitter

persistence value in the range 1-255; the corresponding slot time

is fixed at one hardware clock tick, about 55 ms on the PC.



As with the other 8530 drivers, this driver actually attaches two

interfaces, one for each 8530 channel.



4.7.  attach packet <intvec> <iface> <txqlen> <mtu>



Driver for use with separate software  "packet  drivers"  meeting

the  FTP Software, Inc, Software Packet Driver specification. The

driver must have already been installed before the attach command

is given. Packet drivers in the Ethernet, ARCNET, SLIP, SLFP, and

KISS/AX25 classes are supported.



intvec is the software interrupt vector used for communication to

the  packet  driver,  and txqlen is the maximum number of packets







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 37 -





that will be allowed on the transmit queue.



4.8.  attach  pc100  <ioaddr>  <vector>  ax25  <iface>  <bufsize>

<speed>



Driver for the PACCOMM  PC-100  (Zilog  8530)  card.  Only  AX.25

operation is supported.



4.9.  attach scc <devices> init <addr>  <spacing>  <Aoff>  <Boff>

<Dataoff> <intack> <vec> [p|r]<clock> [<hdwe>] [<param>]



PE1CHL driver to initialize a generic SCC (8530) interface  board

prior to actually attaching it. The parameters are as follows:



4.9.1.  <devices>



The number of SCC chips to support.



4.9.2.  <addr>



The base address of the first SCC chip (hex).



4.9.3.  <spacing>



The spacing between the SCC chip base addresses.



4.9.4.  <Aoff>



The offset from a chip's base address to its  channel  A  control

register.



4.9.5.  <Boff>



The offset from a chip's base address to its  channel  B  control

register.



4.9.6.  <Dataoff>



The offset from each  channel's  control  register  to  its  data

register.



4.9.7.  <intack>



The address of the INTACK/Read Vector port. If none, specify 0 to

read from RR3A/RR2B.



4.9.8.  <vec>



The CPU interrupt vector for all connected SCCs.



4.9.9.  <clock>



The clock frequency (PCLK/RTxC) of all SCCs in hertz. Prefix with

'p' for PCLK, 'r' for RTxC clock (for baudrate gen).







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 38 -





4.9.10.  <hdwe>



Optional hardware type. The following values are  currently  sup-

ported:  1  -  Eagle card, 2 - PACCOMM PC-100, 4 - PRIMUS-PC card

(DG9BL), 8 - DRSI PCPA card.



4.9.11.  <param>



Optional extra parameter. At present, this is used only with  the

PC-100  and PRIMUS-PC cards to set the modem mode. The value 0x22

is used with the PC-100 and 0x2 is used with the PRIMUS-PC card.



The attach scc ... init command must be given before  the  inter-

faces are actually attached with the following command.



4.10.  attach scc <chan> slip | kiss | nrs | ax25  <iface>  <mtu>

<speed> <bufsize> [<call>]



Attach an initialized SCC port to the system. The parameters  are

as follows:



4.10.1.  <chan>



The SCC channel number to attach, 0 or 1 for the first  chip's  A

or B port, 2 or 3 for the second chip's A or B port, etc.



4.10.2.  slip | kiss | nrs | ax25



The operating mode of the  interface.  slip,  kiss  and  nrs  all

operate   the   port  hardware  in  asynchronous  mode;  slip  is

Internet-standard serial line IP mode, kiss generates SLIP frames

containing  KISS  TNC  commands  and  AX.25  packets and nrs uses

NET/ROM local serial link framing conventions  to  carry  NET/ROM

packets.  Selecting ax25 mode puts the interface into synchronous

HDLC mode that is suitable for direct connection to a half duplex

radio modem.



4.10.3.  <speed>



The interface speed in bits per second (eg.  1200).  Prefix  with

'd'  when  an  external  divider  is available to generate the TX

clock. When the clock source is PCLK, this can be a  /32  divider

between  TRxC  and  RTxC.  When the clock is at RTxC, the TX rate

must be supplied at TRxC. This is needed  only  for  full  duplex

synchronous  operation.  When  this  arg  is  given as 'ext', the

transmit and receive clocks are external, and the  internal  baud

rate generator (BRG) and digital phase locked loop (DPLL) are not

used.



4.11.  Attach Examples



Here are some examples of the attach command:











updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 39 -







# Attach a 3Com Ethernet controller using the standard 3Com address and

# vector (i.e., as it comes out of the box) to use ARPA-standard encapsulation.

# The receive queue is limited to 5 packets, and outgoing packets larger

# than 1500 bytes will be fragmented

attach 3c500 0x300 3 arpa ec0 5 1500



# Attach the PC asynch card normally known as "com1" (the first controller)

# to operate in point-to-point slip mode at 9600 baud, calling it "sl0".

# A 1024 byte receiver ring buffer is allocated. Outgoing packets larger

# than 256 bytes are fragmented.

attach asy 0x3f8 4 slip sl0 1024 256 9600



# Attach the secondary PC asynch card ("com2") to operate in AX.25 mode

# with an MTU of 576 bytes at 9600 baud with a KISS TNC, calling it "ax0".

# By default, IP datagrams are sent in UI frames

attach asy 0x2f8 3 ax25 ax0 1024 576 9600



# Attach the packet driver loaded at interrupt 0x7e

# The packet driver is for an Ethernet interface

attach packet 0x7e ethernet 8 1500









































































updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 40 -





5.  FTP Subcommands



During converse mode with an FTP server, everything typed on  the

console  is  first  examined to see if it is a locally-known com-

mand. If not, the line is passed intact to the remote  server  on

the control channel. If it is one of the following commands, how-

ever, it is executed locally. (Note that this generally  involves

other  commands  being  sent  to the remote server on the control

channel.)



5.1.  dir [<file> | <directory> [<local file>]]



Without arguments, dir requests that a full directory listing  of

the  remote  server's  current directory be sent to the terminal.

If one argument is given, this is passed along in the  LIST  com-

mand;  this  can be a specific file or subdirectory that is mean-

ingful to the remote file system. If two arguments are given, the

second  is taken as the local file into which the directory list-

ing should be put (instead of being sent  to  the  console).  The

PORT command is used before the LIST command is sent.



5.2.  get <remote file> [<local file>]



Asks the remote server to send the file specified  in  the  first

argument.  The second argument, if given, will be the name of the

file on the local machine; otherwise it will have the  same  name

as  on the remote machine. The PORT and RETR commands are sent on

the control channel.



5.3.  hash



A synonym for the verbose 3 command.



5.4.  ls [<file> | <directory> [<local file>]]



ls is identical to the dir command except that the "NLST" command

is sent to the server instead of the "LIST" command. This results

in an abbreviated directory listing, i.e., one showing  only  the

file names themselves without any other information.



5.5.  mget <file> [<file> ...]



Fetch a collection of files  from  the  server.  File  names  may

include  wild  card  characters;  they  will  be  interpreted and

expanded into a list of files by the remote system using the NLST

command.  The  files  will have the same name on the local system

that they had on the server.



5.6.  mkdir <remote directory>



Creates a directory on the remote machine.













updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 41 -





5.7.  mput <file> [<file> ...]



Send a collection of files to the server. File names may  include

wild  card  characters; they will be expanded locally into a list

of files to be sent. The files will have the  same  name  on  the

server as on the local system.



5.8.  put <local file> [<remote file>]



Asks the remote server to accept data, creating the file named in

the  first  argument.  The second argument, if given, will be the

name of the file on the remote machine; otherwise  it  will  have

the  same  name  as on the local machine.  The PORT and STOR com-

mands are sent on the control channel.



5.9.  rmdir <remote directory>



Deletes a directory on the remote machine.



5.10.  type [a | i | l <bytesize>]



Tells both the local client and remote server the  type  of  file

that is to be transferred.  The default is 'a', which means ASCII

(i.e., a text file).  Type 'i' means  image,  i.e.,  binary.   In

ASCII  mode,  files  are  sent as varying length lines of text in

ASCII separated by cr/lf sequences; in IMAGE mode, files are sent

exactly  as they appear in the file system.  ASCII mode should be

used whenever transferring text between dissimilar  systems  (eg.

UNIX  and  MS-DOS)  because of their different end-of-line and/or

end-of-file conventions.   When  exchanging  text  files  between

machines  of  the same type, either mode will work but IMAGE mode

is usually faster.  Naturally, when exchanging raw  binary  files

(executables,  compressed archives, etc) IMAGE mode must be used.

Type 'l' (logical byte size) is used when exchanging binary files

with  remote servers having oddball word sizes (eg. DECSYSTEM-10s

and 20s). Locally it works exactly like  IMAGE,  except  that  it

notifies  the  remote system how large the byte size is. bytesize

is typically 8. The type command sets the local transfer mode and

generates the TYPE command on the control channel.



5.11.  verbose [0 | 1 | 2 | 3]



Set or display the level of message  output  in  file  transfers.

Verbose 0 gives the least output, and verbose 3 the most, as fol-

lows:



0 - Display error messages only.

1 - Display error messages plus a one-line summary after each transfer

    giving the name of the file, its size, and the transfer time and rate.

2 - Display error and summary messages plus the progress messages generated

    by the remote FTP server. (This setting is the default.)

3 - Display all messages. In addition, a "hash mark" (#) is displayed for

    every 1,000 bytes sent or received.









updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 42 -





If a command is sent to the  remote  server  because  it  is  not

recognized  locally, the response is always displayed, regardless

of the setting of verbose. This is necessary  for  commands  like

pwd (display working directory), which would otherwise produce no

message at all if verbose were set to 0 or 1.









































































































updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 43 -





6.  Dialer Subcommands



Each dialer command may (should) have a  different  dialer  file.

The  file resides in the configuration directory, as specified in

the Installation section (see chapter 1). A typical  dialer  file

might be:



        # Set the speed, and toggle DTR to ensure modem is in command mode.

        control down

        wait 3000

        speed 2400

        control up

        wait 3000

        # Dial, and wait for connection

        send "atdt555-1212"

        wait 45000 "CONNECT " speed

        wait 2000

        # PAD specific initialization

        send ""

        wait 15000 "Terminal ="

        send "ppp"

        wait 10000 "





6.0.1.  control down | up



Control asy interface. The down option drops DTR and RTS. The  up

option asserts DTR and RTS.



6.0.2.  send "string"



This dialer command will write the specified string to the inter-

face. The string quote marks are required, and the string may not

contain embedded control  characters.  However,  the  standard  C

string escape sequences are recognized (\0 should not be used).



6.0.3.  speed [ 9600 | 4800 | 2400 | 1200 | 300 ]



This dialer command will set the speed of the interface to one of

the  available speeds. If the speed is missing, the speed will be

displayed in the dialer session window.



6.0.4.  wait <milliseconds> [ "test string" ] [ speed ]



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  interface.  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 contain embedded control charac-

ters. However, the standard C string escape sequences are  recog-

nized (\0 should not be used).









updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 44 -





Finally, if the speed 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.







































































































updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 45 -





7.  The /ftpusers File



Since MS-DOS is a single-user operating system (some might say it

is  a glorified 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.exe therefore provides its own  access

control mechanisms.



The file /ftpusers controls remote FTP and  mailbox  access.  The

FTP  default  is  no 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 commands, giving a valid name

and password listed in /ftpusers, before he or she  can  transfer

files.



Each entry in /ftpusers consists of a single line of the form



username password /path permissions





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.



username is the user's login name.



password is the required password.  Note that this  is  in  plain

text;  therefore  it is not a good idea to give general read per-

mission to the root directory.   A  password  of  '*'  (a  single

asterisk) means that any password is acceptable.



/path is the allowable prefix on accessible  files.   Before  any

file  or directory 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 redundant /'s,  recog-

nized 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.



permissions 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  pre-

fix  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 sub-

ject 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.









updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 46 -





For example, suppose /ftpusers on machine  pc.ka9q.ampr.org  con-

tains the line



friendly test /testdir 7





A session using this account would look like this:



net> ftp pc.ka9q.ampr.org

Resolving pc.ka9q.ampr.org... Trying 128.96.160.1...

FTP session 1 connected to pc.ka9q.ampr.org

220 pc.ka9q.ampr.org FTP version 900418 ready at Mon May 7 16:27:18 1990

Enter user name: friendly

331 Enter PASS command

Password: test [not echoed]

230 Logged in

ftp>





The user now has read, write, overwrite and delete privileges for

any file under /testdir; he may not access any other files.



Here are some more sample entries in /ftpusers:



karn foobar / 7         # User "karn" with password "foobar" may read,

                        # write, overwrite and delete any file on the

                        # system.



guest bletch /g/bogus 3 # User "guest" with password "bletch" may read

                        # any file under /g/bogus and its subdirectories,

                        # and may create a new file as long as it does

                        # not overwrite an existing file. He may NOT

                        # delete any files.



anonymous * /public 1   # User "anonymous" (any password) may read files

                        # under /public and its subdirectories; he may

                        # not create, overwrite or delete any files.





This last entry is the standard convention for keeping a  reposi-

tory  of public files; in particular, the username "anonymous" is

an established ARPA convention.































updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 47 -





8.  The domain.txt File



Net.exe translates domain names (eg.  "pc.ka9q.ampr.org")  to  IP

addresses  (eg.  128.96.160.3)  through  the  use  of an Internet

Domain Name resolver and a local "cache" file, domain.txt.  When-

ever  the  user  specifies  a  domain  name,  the  local cache is

searched for the desired entry. If it is present, it is used;  if

not,  and  if domain name server(s) have been configured, a query

is sent over the network to the current  server.  If  the  server

responds,  the  answer is added to the domain.txt file for future

use. If the server does not respond, any  additional  servers  on

the  list  are tried in a round-robin fashion until one responds,

or the retry limit is reached (see the domain retry command).  If

domain.txt  does  not  contain the desired entry and there are no

configured domain name  servers,  then  the  request  immediately

fails.



If a domain name server is available, and if  all  references  to

host-ids  in  your  /autoexec.net  file are in IP address format,

then it is possible to start with a completely  empty  domain.txt

file  and have net.exe build it for you. However, you may wish to

add your own entries to domain.txt, either because you prefer  to

use symbolic domain names in your /autoexec.net file or you don't

have access to a domain server and you need to create entries for

all of the hosts you may wish to access.



Each entry takes one line, and the fields are  separated  by  any

combination of tabs or spaces. For example:



pc.ka9q.ampr.org.       IN      A       128.96.160.3



IN is the class of the record. It means Internet, and it will  be

found  in  all entries. A is the type of the record, and it means

that this is an  address  record.  Domain  name  pc.ka9q.ampr.org

therefore has Internet address 128.96.160.3.



Another possible entry is the CNAME (Canonical Name) record.  For

example:



ka9q.ampr.org.          IN      CNAME   pc.ka9q.ampr.org.



This says that domain name "ka9q.ampr.org" is actually  an  alias

for   the   system  with  (primary,  or  canonical)  domain  name

"pc.ka9q.ampr.org." When a domain name having a CNAME  record  is

given  to net.exe, the system automatically follows the reference

to the canonical name and returns the IP address associated  with

that entry.



Entries added automatically by net.exe will  have  an  additional

field  between  the  domain  name  and the class (IN) field.  For

example:



pc.ka9q.ampr.org.       3600    IN      A       128.96.160.3









updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 48 -





This is the time-to-live value, in seconds, associated  with  the

record  received from the server. Clients (such as net.exe) cach-

ing these records are supposed to delete them after the  time-to-

live  interval has expired, allowing for the possibility that the

information in the record may become out of date.



This implementation of net.exe will decrement the  TTL  to  zero,

but will not delete the record unless the "clean" flag is on (see

the domain cache clean command). When  a  remote  server  is  not

available, the old entry will be used.



When the TTL value is missing (as in  the  examples  above),  the

record  will  never  expire,  and  must be managed by hand. Since

domain.txt is a plain text file, it may be easily edited  by  the

user to add, change or delete records.



Additional types of records, include NS  (name  server)  and  SOA

(start  of authority) may appear in domain.txt from remote server

responses. These are  not  currently  used  by  net.exe  but  are

retained  for  future development (such as the incorporation of a

domain name server into net.exe itself).









































































updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 49 -





9.  Setting Bufsize, Paclen, Maxframe, MTU, MSS and Window



Many net.exe users are confused by these parameters  and  do  not

know  how  to  set  them properly. This chapter will first review

these parameters and then discuss how to choose values for  them.

Special  emphasis  is given to avoiding interoperability problems

that may appear when communicating with  non-net.exe  implementa-

tions of AX.25.



9.1.  Hardware Parameters





9.1.1.  Bufsize



This parameter is required by most  of  net.exe's  built-in  HDLC

drivers  (eg. those for the DRSI PCPA and the Paccomm PC-100). It

specifies the size  of  the  buffer  to  be  allocated  for  each

receiver  port.  HDLC  frames  larger  than  this value cannot be

received.



There is no default bufsize; it must be specified in  the  attach

command for the interface.



9.2.  AX25 Parameters



9.2.1.  Paclen



Paclen limits the size of the data field  in  an  AX.25  I-frame.

This  value  does  not include the AX.25 protocol header (source,

destination and digipeater addresses).



Since unconnected-mode (datagram)  AX.25  uses  UI  frames,  this

parameter has no effect in unconnected mode.



The default value of paclen is 256 bytes.



9.2.2.  Maxframe



This parameter controls the number of I-frames that  net.exe  may

send  on  an AX.25 connection before it must stop and wait for an

acknowledgement. Since the AX.25/LAPB sequence number field is  3

bits wide, this number cannot be larger than 7.



Since unconnected-mode (datagram) AX.25 uses UI  frames  that  do

not  have  sequence  numbers,  this  parameter  does not apply to

unconnected mode.



The default value of maxframe in net.exe is 1 frame.



9.3.  IP and TCP Parameters



9.3.1.  MTU



The MTU (Maximum Transmission Unit)  is  an  interface  parameter







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 50 -





that  limits the size of the largest IP datagram that it may han-

dle.  IP datagrams routed to an interface that  are  larger  than

its  MTU are each split into two or more fragments. Each fragment

has its own IP header and is handled by the network as if it were

a distinct IP datagram, but when it arrives at the destination it

is held by the IP layer until all of the other fragments  belong-

ing to the original datagram have arrived. Then they are reassem-

bled back into the complete, original IP  datagram.  The  minimum

acceptable  interface MTU is 28 bytes: 20 bytes for the IP (frag-

ment) header, plus 8 bytes of data.



There is no default MTU in net.exe; it must be explicitly  speci-

fied for each interface as part of the attach command.



9.3.2.  MSS



MSS (Maximum Segment Size) is a TCP-level parameter  that  limits

the  amount of data that the remote TCP will send in a single TCP

packet. MSS values are exchanged in the SYN (connection  request)

packets that open a TCP connection. In the net.exe implementation

of TCP, the MSS actually used by TCP is further reduced in  order

to  avoid  fragmentation  at the local IP interface. That is, the

local TCP asks IP for the MTU of the interface that will be  used

to reach the destination. It then subtracts 40 from the MTU value

to allow for the overhead of the  TCP  and  IP  headers.  If  the

result  is  less than the MSS received from the remote TCP, it is

used instead.



The default value of MSS is 512 bytes.



9.3.3.  Window



This is a TCP-level parameter that controls  how  much  data  the

local  TCP  will allow the remote TCP to send before it must stop

and wait for an acknowledgement. The actual window value used  by

TCP  when  deciding  how much more data to send is referred to as

the effective window. This is the smaller of two values: the win-

dow advertised by the remote TCP minus the unacknowledged data in

flight, and the  congestion  window,  an  automatically  computed

time-varying estimate of how much data the network can handle.



The default value of Window is 2048 bytes.



9.4.  Discussion





9.4.1.  IP Fragmentation vs AX.25 Segmentation



IP-level fragmentation often makes it  possible  to  interconnect

two  dissimilar  networks, but it is best avoided whenever possi-

ble. One reason is that when a single IP fragment  is  lost,  all

other  fragments  belonging  to the same datagram are effectively

also lost and the entire datagram must be  retransmitted  by  the

source.  Even  without  loss, fragments require the allocation of







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 51 -





temporary buffer memory at the destination, and it is never  easy

to decide how long to wait for missing fragments before giving up

and discarding those that  have  already  arrived.  A  reassembly

timer  controls  this  process.  In net.exe it is (re)initialized

with the ip rtimer parameter (default 30 seconds)  whenever  pro-

gress is made in reassembling a datagram (i.e., a new fragment is

received). It is not necessary that all of the fragments  belong-

ing  to  a datagram arrive within a single timeout interval, only

that the interval between fragments be less than the timeout.



Most subnetworks that carry IP have MTUs of 576 bytes or more, so

interconnecting  them  with subnetworks having smaller values can

result in considerable fragmentation. For this reason, IP  imple-

mentors  working  with  links  or  subnets having unusually small

packet size limits are encouraged to use  transparent  fragmenta-

tion,  that  is, to devise schemes to break up large IP datagrams

into a sequence of link or subnet  frames  that  are  immediately

reassembled  on the other end of the link or subnet into the ori-

ginal, whole IP datagram without the use of  IP-level  fragmenta-

tion.  Such  a  scheme  is provided in AX.25 Version 2.1.  It can

break a large IP or NET/ROM datagram into  a  series  of  paclen-

sized  AX.25 segments (not to be confused with TCP segments), one

per AX.25 I-frame, for transmission and reassemble  them  into  a

single datagram at the other end of the link before handing it up

to the IP or NET/ROM  module.   Unfortunately,  the  segmentation

procedure  is a new feature in AX.25 and is not yet widely imple-

mented; in fact, net.exe is so far the only known implementation.

This  creates  some interoperability problems between net.exe and

non-net.exe nodes, in particular, standard  NET/ROM  nodes  being

used  to carry IP datagrams. This problem is discussed further in

the section on setting the MTU.



9.4.2.  Setting paclen and bufsize



The more data you put into an AX.25  I  frame,  the  smaller  the

AX.25  headers  are in relation to the total frame size. In other

words, by increasing paclen, you lower the AX.25  protocol  over-

head. Also, large data packets reduce the overhead of keying up a

transmitter, and this can be  an  important  factor  with  higher

speed modems. On the other hand, large frames make bigger targets

for noise and interference. Each link has  an  optimum  value  of

paclen that is best discovered by experiment.



Another thing to remember when setting paclen is that  the  AX.25

version  2.0  specification  limits  it  to  256  bytes. Although

net.exe can handle much larger values, some other AX.25 implemen-

tations (including digipeaters) cannot and this may cause intero-

perability problems. Even net.exe may have trouble  with  certain

KISS  TNCs  because  of fixed-size buffers. The original KISS TNC

code for the TNC-2 by K3MC can handle frames limited in size only

by the RAM in the TNC, but some other KISS TNCs cannot.



Net.exe's built-in HDLC drivers (SCC, PC-100, DRSI, etc) allocate

receive  buffers according to the maximum expected frame size, so







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 52 -





it is important that these devices be configured with the correct

bufsize. To do this, you must know the size of the largest possi-

ble frame that can be received.  The  paclen  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 digipeaters, so the largest possible frame is (paclen +

72) bytes. So you should make bufsize 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  buf-

size;  in  fact,  attempting  to set a larger value may cause the

driver not to work at all. This situation can be detected by run-

ning  the  memory status command and looking for a non-zero count

of Ibuffail events, although these events can  also  occur  occa-

sionally during normal operation.



One of the drawbacks of AX.25 that there is no way for  one  sta-

tion  to tell another how large a packet it is willing to accept.

This requires the stations sharing a channel to agree  beforehand

on a maximum packet size. TCP is different, as we shall see.



9.4.3.  Setting Maxframe



For best performance on a  half-duplex  radio  channel,  maxframe

should always be set to 1. The reasons are explained in the paper

Link Level Protocols Revisited by  Brian  Lloyd  and  Phil  Karn,

which  appeared  in the proceedings of the ARRL 5th Computer Net-

working Conference in 1986.



9.4.4.  Setting MTU



TCP/IP header overhead considerations similar  to  those  of  the

AX.25 layer when setting paclen apply when choosing an MTU.  How-

ever, certain subnetwork types supported by  net.exe  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 standardized.



SLIP has no official MTU, but the most common implementation (for

BSD  UNIX)  uses  an  MTU of 1006 bytes.  Although net.exe has no

hard wired limit on the size of a received SLIP  frame,  this  is

not  true for other systems. Interoperability problems may there-

fore result if larger MTUs are used in net.exe.



Choosing an MTU for an AX.25 interface is more complex. When  the

interface operates in datagram (UI-frame) mode, the paclen param-

eter does not apply. The MTU effectively becomes  the  paclen  of

the  link.   However, as mentioned earlier, large packets sent on

AX.25 connections are automatically segmented  into  I-frames  no







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 53 -





larger  than  paclen bytes. Unfortunately, as also mentioned ear-

lier, net.exe is so far the only known implementation of the  new

AX.25  segmentation procedure. This is fine as long as all of the

NET/ROM nodes along a path are running  net.exe,  but  since  the

main  reason net.exe 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  run-

ning  IP  over  NET/ROM.  The way to do this is to make sure that

packets larger than paclen 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 paclen is 256, this leaves 236 bytes for the IP datagram. This

is  the default MTU of the netrom pseudo-interface, so as long as

paclen is at least 256 bytes, AX.25  segmentation  can't  happen.

But  if  smaller  values  of paclen are used, the netrom MTU must

also be reduced with the ifconfig command.



On the other hand, if you're running IP directly on top of AX.25,

chances  are  all  of  the  nodes are running net.exe 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 whatever paclen value is appropriate for the link.



9.4.5.  Setting MSS



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 automatically lowered according to the MTU  of  the

local  interface  when a connection is created. Although this is,

strictly speaking, a protocol layering violation (TCP is not sup-

posed 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 pro-

cedure yet, this might cause the remote  system  to  generate  IP

fragments unnecessarily.









updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 54 -





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 larger packets. So the  best  value  for

MSS is probably 40 less than the largest MTU on your system, with

the 40-byte margin allowing for the TCP and IP headers. For exam-

ple,  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, assum-

ing the path to your system does not have any bottleneck  subnets

with smaller MTUs.



9.4.6.  Setting Window



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 controls 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 control-

ling the effective TCP flow control window  have  been  developed

over  the  past  few  years  and are now widely deployed. Net.exe

includes them, and you can watch them  in  action  with  the  tcp

status  <tcb>  or  socket  <sockno>  commands.  Look at the cwind

(congestion window) value.



In most cases it is safe to set the TCP window to a small integer

multiple  of  the  MSS  (eg.  4 times), 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  avail-

able  for  incoming  data.  Net.exe does not actually preallocate

this space; it keeps it in a common pool and may well  "overbook"

it,  exploiting  the  fact that many TCP connections are idle for

long periods and gambling that most applications will read incom-

ing data from an active connection as soon as it arrives, thereby

quickly freeing the buffer memory. However, it is possible to run

net.exe  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 collisions. In particular, collisions between

data  packets  and  returning acknowledgements 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.







updated by Bill Simpson April 15, 1991 March 3, 1991











                           - 55 -





9.5.  Summary



In most cases, the default values provided by net.exe for each of

these  parameters will work correctly and give reasonable perfor-

mance. 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.





































































































updated by Bill Simpson April 15, 1991 March 3, 1991