home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 2 / HACKER2.BIN / 486.USERMAN.DOC < prev    next >
Text File  |  1988-04-07  |  196KB  |  4,743 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.                       The KA9Q Internet Software Package
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.                              Preliminary Version
  28.  
  29.                                January 20, 1988
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.                                       by
  43.  
  44.                              Bdale Garbee, N3EUA
  45.  
  46.                              using material from
  47.  
  48.                                Phil Karn, KA9Q
  49.                              Brian Lloyd, WB6RQN
  50.  
  51.                        and suggestions from many others
  52.  
  53.  
  54.           Copyright 1988 by Bdale Garbee, Phil Karn and Brian Lloyd.
  55.                              All Rights Reserved.
  56.  
  57.                   This Document may be reproduced in whole
  58.                  or in part for any non-commercial purpose,
  59.                    as long as credit is given the authors.
  60.                                     - 2 -
  61.  
  62.  
  63. 1.  Background and Overview
  64.  
  65. 1.1.  What's TCP/IP All About?
  66.  
  67. Charles Hedrick of RUTGERS, the State University of New Jersey, has written  a
  68. very important document... a description of the "world of TCP/IP" that manages
  69. to be both a reasonable introduction for the non-technical or mildly technical
  70. individual,  and an excellent starting point for anyone interested in learning
  71. more about  the  family  of  networking  protocols  commonly  referred  to  as
  72. "TCP/IP".
  73.  
  74. The only difficulty with this document for those who are trying to learn  more
  75. about TCP/IP in the Amateur Radio "Packet" environment, is that the experience
  76. Mr. Hedrick works from is almost entirely with the wired  networks  common  in
  77. universities  and  businesses,  where  various  computer systems are networked
  78. together using some form of wire (usually coaxial cable  as  in  Ethernet,  or
  79. fiber optic cabling as in Pronet).
  80.  
  81. The individual who is familiar with radio transmission will  easily  recognize
  82. differences  between  the  wired environment and the on-air environment.  This
  83. does not mean that the protocols are unfit for use on the air, it simply means
  84. that  we  need to be careful when *implementing* the protocols in software for
  85. use on the radio that we don't make assumptions that aren't valid on the  air!
  86. In  particular,  wired  networks allow the assumption that every host can hear
  87. every other host on the wire... quite unlike the  situation  in  radio,  where
  88. one-way propagation paths are often the norm.
  89.  
  90. Mr. Hedrick mentions several protocols that can "ride on top of" IP,  such  as
  91. Sun's Network File System, NFS.  Some of the applications that he talks about,
  92. including NFS, while wonderful on wired networks,  are  somewhat  unreasonable
  93. for  packet  radio  until or unless we have *much* higher speed modems.  Wired
  94. networks can easily run at 10 million bits per  second,  while  packet  ranges
  95. from  300  bits  per second on HF, to perhaps 56 thousand bits per second with
  96. the WA4DSY modems on UHF.  Therefore, some of the protocols such as  NFS  that
  97. like  to eat lots of network bandwith won't be as neat on current packet radio
  98. as they are on current wired networks, but they certainly provides a  dramatic
  99. improvement in potential services for the "next generation" of packet radio.
  100.  
  101. The KA9Q Internet Package is currently the most common  TCP/IP  implementation
  102. (if  not the only one!) in use on Amateur Packet Radio.  The software supports
  103. the IBM PC and clones, the Apple Macintosh, the Commodore Amiga, and both  BSD
  104. and  System 5 Unix variants.  The package provides IP, ICMP, TCP, UDP, and ARP
  105. as basic services, and implements the  FTP,  Telnet,  and  SMTP  protocols  as
  106. applications.   The  package also includes a separate mail user interface pro-
  107. gram by N3EUA called BM, and software from WA3PXX  for  forwarding  PBBS  mail
  108. over  TCP.   An  associated  set  of software packages provide replacement ROM
  109. firmware for several TNC's, allowing them to be  used  with  the  KA9Q  TCP/IP
  110. Package.   At least two commercial manufacturers, AEA and Kantronics, now sup-
  111. port the KISS protocol in their TNC's, making them usable with TCP/IP.
  112.  
  113. Charles Hedrick's excellent introduction to TCP/IP can be found  in  the  same
  114. place  you found this document, named TUTORIAL.DOC. If you're new to all this,
  115. go find and read that before you get too wound up in the bits...
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.                                     - 3 -
  127.  
  128.  
  129. 1.2.  What's In the KA9Q Package
  130.  
  131. This is an overview of the various modules making up the  KA9Q  Amateur  Radio
  132. Internet  Protocol  package. Each section first describes the protocol that is
  133. supported, followed by a description of the implementation.
  134.  
  135. 1.2.1.  Subnet Layer
  136.  
  137. 1.2.1.1.  Standard 10 megabit Ethernet
  138.  
  139. The driver provided is for the 3-Com 3C500 (IE) controller for the PC.   Tight
  140. assembler  loops  are  used  instead of DMA for copying data in and out of the
  141. controller's buffer; this seems fast enough.  Only the receiver  is  interrupt
  142. driven; incoming packets are placed on a queue which is then emptied at a more
  143. leisurely pace by the  main  loop  code.   Since  Ethernet  is  so  fast,  the
  144. transmitter  routine  busy-waits  for completion. The IE controller has only a
  145. single buffer which is shared between receive and transmit. Packets  occasion-
  146. ally  get  lost  under heavy load, especially when several TCP connections are
  147. active at once and/or the TCP receive window sizes are  larger  than  the  MSS
  148. values.  This  is  very  hard to fix without going to a newer, more reasonably
  149. designed controller.
  150.  
  151. 1.2.1.2.  Serial Line IP (SLIP)
  152.  
  153. SLIP is a very simple technique for sending Internet Datagrams across ordinary
  154. asynchronous  lines  (e.g., modems). Its only function is to delimit datagrams
  155. with framing characters, which are "byte stuffed" for transparency.  No  error
  156. checking  is  provided;  the  checksums  that  are part of IP, TCP and UDP are
  157. relied on for this.  SLIP is popular on UNIX systems that support  TCP/IP,  so
  158. this  represented  the easiest way to get my package up and talking with other
  159. Internet sites.  It also allows the use of existing AX.25 TNCs without modify-
  160. ing  the  latter,  although  this  is should only be done as a stopgap measure
  161. until an HDLC link level driver can be integrated directly into the package.
  162.  
  163. 1.2.1.3.  AX.25/KISS TNC
  164.  
  165. Sends and receives IP and  ARP  datagrams  encapsulated  in  AX.25  Unnumbered
  166. Information (UI) frames. This allows an unlimited number of simultaneous users
  167. on the local radio channel, since there are no connections at link level.  The
  168. special AX.25 Level 3 Protocol ID values of hex CC (IP) and CD (ARP) are used.
  169.  
  170. With the 871225.0 release, support has also been added  for  encapsulating  IP
  171. datagrams  in  "normal"  AX.25 connected-mode packets.  This was a natural by-
  172. product of adding full AX.25 level 2 session support to the package.
  173.  
  174. This mode of operation requires that the TNC run special "KISS TNC" code. Ver-
  175. sions  for  the TNC-2, TNC-1, and VADCG/ASHBY boards are included in this dis-
  176. tribution.  Some manufacturers, including AEA and Kantronics, are adding  sup-
  177. port  for  KISS  into  their commercial TNC products.  Note that this style of
  178. operation is NOT compatible with a "stock" TNC carrying SLIP format  datagrams
  179. in connected mode.
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.                                     - 4 -
  193.  
  194.  
  195. 1.2.1.4.  AX.25/PACCOMM PC-100 Interface (NOT YET WORKING)
  196.  
  197. The PC-100 is an I/O adapter card for the PC containing a  Zilog  8530  Serial
  198. Communications  Controller and two AMD 7910 World Chip modems.  The encapsula-
  199. tion method is identical to (and compatible with) the AX.25/KISS TNC interface
  200. driver.
  201.  
  202. 1.2.1.5.  AX.25/Eagle Interface
  203.  
  204. There is a card available at some swapfests made  by  Eagle  Computer  Company
  205. that implements two ports using the Zilog 8530.  External modems are required.
  206. This driver is very similar to (and may eventually be merged with) the  PC-100
  207. driver.
  208.  
  209. 1.2.1.6.  Address Resolution Protocol (ARP)
  210.  
  211. ARP is used for the automatic mapping  of  IP  addresses  to  link  or  subnet
  212. addresses.  While  originally  designed for the specific task of mapping IP to
  213. Ethernet addresses, the protocol is general enough to be used on any  link  or
  214. subnet that supports a broadcast facility.  ARP is described in ARPA RFC-826.
  215.  
  216. Both Ethernet and AX.25 format addresses are currently supported.  Instead  of
  217. discarding  a packet when an ARP request is sent, this implementation holds it
  218. on a queue for a limited time, pending a response to the request.
  219.  
  220. 1.2.2.  Internet layer
  221.  
  222. 1.2.2.1.  Internet Protocol (IP)
  223.  
  224. IP is the universal network-level datagram protocol of the ARPA  Internet.  It
  225. corresponds  roughly to level 3 of the ISO Reference Model (ISORM). (Actually,
  226. IP belongs to the 3B internetwork sublayer if you follow the  amoeboid  proli-
  227. feration  of  ISO  sublayers).  Routines are provided to generate, receive and
  228. route (i.e., packet switch) IP datagrams. IP is specified in ARPA RFC-791  and
  229. MIL-STD-1777.
  230.  
  231. IP datagram fragmentation and reassembly is fully implemented. The IP  options
  232. Loose  Source  Routing,  Strict Source Routing and Record Route are supported;
  233. Stream ID, Security and Timestamp are ignored. (Few, if any,  IP  options  are
  234. used  extensively  in  the  ARPA  Internet).  The IP module includes a routing
  235. (packet switching) facility; currently this consists of a table  containing  a
  236. list  of  host-specific  destinations along with a "default" entry that may be
  237. used when the desired destination is not found in the table.  No  protocol  is
  238. yet provided to actually manage the table; currently it must be done manually,
  239. either locally or remotely.  NB! "Networks" (in the  ARPA  Class-A/B/C  sense)
  240. are  not  yet understood, in that all entries in the routing table (except for
  241. the default entry) must be host-specific.  This will be fixed  in  the  future
  242. with a "generalized subnetting" scheme that will allow each entry in the table
  243. to have an arbitrary, variable length "subnet mask."
  244.  
  245. 1.2.2.2.  Internet Control Message Protocol (ICMP)
  246.  
  247. ICMP is the error reporting adjunct to IP. It appears as a pseudo-protocol  on
  248. top  of  IP,  but  is  actually  considered  to be part of IP. The IP routines
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.                                     - 5 -
  259.  
  260.  
  261. automatically generate ICMP messages whenever an error occurs in the  process-
  262. ing  of  IP datagrams; incoming ICMP messages are passed up to the originating
  263. end-to-end protocol for appropriate action. ICMP is specified in ARPA RFC-792.
  264.  
  265. This ICMP supports all options except ICMP Timestamps.
  266.  
  267. 1.2.3.  Host-Host Layer
  268.  
  269. 1.2.3.1.  Transmission Control Protocol (TCP)
  270.  
  271. TCP provides a reliable, sequenced "virtual circuit" or  "connection-oriented"
  272. service  atop IP on an end-to-end basis. It corresponds to the Transport layer
  273. (level 4) of the OSI model.  Since a single TCP module supports multiple  con-
  274. nections  through  the use of port numbers, it also provides Session (level 5)
  275. functionality without the need for a distinct layer. (Or it makes the  session
  276. layer  unnecessary, depending on your point of view). TCP is specified in ARPA
  277. RFC-793 and MIL-STD-1778.
  278.  
  279. The implementation supports an arbitrary number of  simultaneous  connections,
  280. limited  only  by  memory  space  for control blocks. An "upcall" mechanism is
  281. available to notify the user of three events: connection state change, receive
  282. data  available  and transmit buffer space available. The Maximum Segment Size
  283. option is understood and used when it is received, and a  global  variable  is
  284. used  for generating MSS in outgoing segments. There is currently no provision
  285. for sending URGent data.  The latest recommendations on  "tinygram"  avoidance
  286. (Nagle, ARPA RFC-896) are implemented and work quite well.
  287.  
  288. 1.2.3.2.  User Datagram Protocol (UDP)
  289.  
  290. UDP provides only a simple, unguaranteed "datagram" or  "connectionless"  ser-
  291. vice,  adding only checksums and port multiplexing to the raw service provided
  292. by IP. As an alternative to TCP, UDP also sits at  level  4  (and  5)  of  the
  293. ISORM. UDP is specified in ARPA RFC-768.
  294.  
  295. The implementation supports the creation of queues on local sockets. An upcall
  296. mechanism  similar  to  that used in TCP notifies the user when datagrams have
  297. arrived.
  298.  
  299. 1.2.4.  Application Layer
  300.  
  301. 1.2.4.1.  File Transfer Protocol (FTP)
  302.  
  303. FTP is for transfer of binary or text files between hosts. FTP  uses  two  TCP
  304. connections  -  one for exchanging commands and responses in the form of ASCII
  305. strings, and the other for the actual data transfers. FTP is defined  in  ARPA
  306. RFC-959.
  307.  
  308. FTP is implemented in two parts, a server half and a client half.  The  server
  309. half supports multiple simultaneous remote users, although at the moment there
  310. is no access control; anyone may access, delete or overwrite any file  on  the
  311. machine.  The client half is invoked by the "ftp" command.
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.                                     - 6 -
  325.  
  326.  
  327. 1.2.4.2.  Remote login protocol (Telnet)
  328.  
  329. Telnet is for logging into remote systems  and  negotiating  various  options,
  330. such  as remote vs local echoing. Telnet itself is documented in ARPA RFC-854,
  331. with the many options defined in other RFCs.
  332.  
  333. The client half supports the ECHO and TRANSMIT-BINARY options; it  is  invoked
  334. by  the "telnet" command. A telnet "server" has been written, but since MS-DOS
  335. isn't a timesharing system it is used for  keyboard-to-keyboard  conversations
  336. instead.  An incoming connect request to the local Telnet port creates a local
  337. Telnet session and notifies the local user. He may then select the new session
  338. and carry out a conversation with the remote initiator.
  339.  
  340. 1.2.4.3.  Simple Mail Transfer Protocol (SMTP)
  341.  
  342. As the name implies, is used for  the  transfer  of  electronic  mail  between
  343. hosts.  SMTP commands and responses are strings of ASCII characters resembling
  344. those used by FTP. SMTP uses a single TCP connection for both control and  the
  345. actual mail messages.  SMTP is described in ARPA RFC-821; headers in mail mes-
  346. sages are described in RFC-822.
  347.  
  348. A simple version server (receiver) is implemented;  it  accepts  mail  from  a
  349. remote sender and appends it to a mailbox. Mail forwarding, which accounts for
  350. much of the complexity in other mail  servers,  is  not  implemented.  A  mail
  351. client  ("user  agent")  for composing and sending messages developed by Bdale
  352. Garbee, N3EUA, and others is included.  It is called 'BM', and  is  documented
  353. elsewhere.
  354.  
  355. 1.2.5.  Session control
  356.  
  357. The user may manage several simultaneous Telnet and  FTP  client  invocations.
  358. Only  one client session is "active" at any one time, but the user may quickly
  359. switch between them. Terminal output arriving for an inactive session is  held
  360. until  that  session  is again made active.  (Note that this is in addition to
  361. the multiple server sessions which go on automatically  "in  the  background",
  362. i.e., without operator intervention).
  363.  
  364. The Internet package has been tested with and works  under  DoubleDos  4.0  by
  365. SoftLogic  Solutions,  allowing  the  system to be simultaneously "on the net"
  366. while executing conventional MS-DOS commands.  The net program uses  the  spe-
  367. cial  DoubleDos  function  call 0EEH to relinquish the processor when it isn't
  368. needed; this speeds up the task running in the other partition.  This function
  369. is a "no-op" when DoubleDos isn't active.
  370.  
  371. 2.  Administrivia
  372.  
  373. 2.1.  What an "IP Address" is and How to Get One
  374.  
  375. IP Addresses are 32 bit numbers that uniquely identify  a  given  machine  (or
  376. "host") running the TCP/IP protocol suite.  All of the possible 32 bit numbers
  377. are coordinated by an entity known as the Network Information Center, or  NIC.
  378. Amateur Radio operators are fortunate in that a "Class A Subnet" consisting of
  379. 24 bits of address, in the range 44.X.X.X, has  been  reserved  for  our  use.
  380. Brian  Kantor,  WB6CYT  of  San  Diego,  CA,  now  serves  as  the  top  level
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.                                     - 7 -
  391.  
  392.  
  393. administrator of the 44.X.X.X address space, and assigns blocks  of  addresses
  394. to regional coordinators from around the world.
  395.  
  396. You need to have a unique address before you can link in with the rest of  the
  397. networked world.
  398.  
  399. <insert info on how to get address>
  400.  
  401. 2.2.  Obtaining Software Updates
  402.  
  403. The KA9Q Internet software package  is  still  evolving  and  growing.   As  a
  404. result,  we  occasionally  issue  updates to the software that fix bugs and/or
  405. update functionality.  Announcements are always made to the USENET news  group
  406. rec.ham-radio.packet,  and  in  the bulletins on N3EUA's telephone BBS system.
  407. They usually also show up on Compuserve within a day or two.  There  is  never
  408. any charge for the software.  A small charge may exist for copying floppies if
  409. you want the bits on disk, and of course you'll have to pay the long  distance
  410. if you grab the bits over the phone!
  411.  
  412. If several people are running the software in  your  area,  get  together  and
  413. decide on one person to get the new bits, then copy it around.  We won't mind.
  414.  
  415. 2.2.1.  From N3EUA's Phone BBS
  416.  
  417. The HIP Shack phone BBS, running Opus software, is reachable as  Fidonet  node
  418. 128/19,  303/495-2061.   The  BBS  supports  300,  1200  and  2400 baud, is up
  419. 24hrs/day, and is configured to allow first-time users  more  than  sufficient
  420. time to download the entire package in one phone call at 1200 baud.
  421.  
  422. The BBS is always the first place  that  the  software  is  available.   Beta-
  423. release executables for the PC can also occasionally be found here.  You down-
  424. load and use these at your own risk!  (Known as the "you get what you pay for"
  425. principle).
  426.  
  427. 2.2.2.  From N3EUA's Unix Machine
  428.  
  429. For those running Unix machines with UUCP capability, there  is  an  anonymous
  430. UUCP  login on winfree, N3EUA's BSD Unix machine, that can be used to download
  431. the software.  This machine is up 24hrs/day, but only has one modem,  and  the
  432. modem stays fairly busy.  A typical L.sys entry might be:
  433.  
  434.         winfree Any ACU 2400 1-303-495-0492 ogin: Uanon word: notFTP
  435.  
  436.  
  437. Start by transferring the file /usr/spool/uucppublic/pub/README for a list  of
  438. the files available, and current release notes.
  439.  
  440. 2.2.3.  Via FTP on the Internet
  441.  
  442. The current revision of the software is available on  SIMTEL20.ARPA  within  a
  443. few  days  of  each  release.   The  files  usually  reside  in  the directory
  444. PD:<MSDOS.PACKET>.  Questions on the files on  Simtel20  can  be  directed  to
  445. W8SDZ@SIMTEL20.ARPA.  Anonymous FTP's are allowed.
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.                                     - 8 -
  457.  
  458.  
  459. Beta-releases are often available on the machine LOUIE.UDEL.EDU, in the direc-
  460. tory  tree rooted at pub/ka9q.  Anonymous FTP's are allowed, but unless you're
  461. working on the software, the bits on louie can be "dangerous", as  they  often
  462. include  incompletely implemented features, and can have serious bugs.  Caveat
  463. Emptor.
  464.  
  465. 2.2.4.  On PC Floppies
  466.  
  467. The Tucson Amateur Packet Radio association (TAPR) now provides floppy  copies
  468. of  the  software  on  360k PC floppies, and can provide KISS ROMs for various
  469. TNC's, at a nominal charge for duplication and  shipping.   Contact  TAPR  for
  470. more information.
  471.  
  472. 2.2.5.  On Native Media for Other Machines
  473.  
  474. Copies of the software for the Macintosh and Amiga are best obtained by  down-
  475. loading  from  an  online  source, or by copying a friend's disk.  If all else
  476. fails, Mikel Matthews (the author of the Mac/Amiga port) is willing to make  a
  477. small number of copies on native media for the Mac and/or Amiga.  Mikel can be
  478. reached via UUCP mail at ...uiucdcs!addamax!mikel.
  479.  
  480. 3.  Installation of the Software
  481.  
  482. Installing the KA9Q Internet Package on your computer is not very hard, but if
  483. you  haven't  tried  to do it before, it can be a bit confusing.  The greatest
  484. efforts made so far towards making the process simple and understandable  have
  485. been  made  by  Brian  Lloyd,  WB6RQN.  Much of this installation section is a
  486. direct copy of portions of his HOWTO.DOC document.  Information about  instal-
  487. lation  on  machines  other  than  the  IBM clone family has come from various
  488. sources.
  489.  
  490. 3.1.  Configuring Your TNC for Network Operation:
  491.  
  492. If you are using this software in a University or other wired-network environ-
  493. ment, you may want to skip past the TNC installation section.  All Hams should
  494. keep reading!
  495.  
  496. There are now several choices for TNCs to be  used  with  the  TCP/IP  network
  497. code.  Versions of the Keep It Simple Stupid TNC interface software (KISS) are
  498. available for the TNC-1, the TNC-2, the VADCG board and  clones  (Ashby),  the
  499. Kantronics  family  of  TNCs,  and  the  AEA TNCs. Following are the different
  500. setup/configuration modes for the different TNCs.
  501.  
  502. 3.1.1.  TNC-1 or Heath HD-4040
  503.  
  504. The firmware for the TNC-1 is available in either a downloadable version or  a
  505. stand  alone  version.   I  will  describe  only the stand alone version here.
  506. Locate the ROM labeled E000 and remove it.  Insert the KISS PROM in its  place
  507. making  sure  that you orient the prom in the same direction (failure to do so
  508. will result in smoked PROM).  Connect your TNC-1 to  your  computer  using  an
  509. RS-232 cable.  A cable that passes the signals from pins 2, 3, and 7 is suffi-
  510. cient.
  511.  
  512. Since the TNC-1 has no switches for setting the baud rate to the computer  the
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.                                     - 9 -
  523.  
  524.  
  525. firmware has been "hard wired" to 4800 baud.  See the documentation that comes
  526. with the TNC-1 version of KISS for instructions on how to patch the .HEX  file
  527. for other baud rates.
  528.  
  529. 3.1.2.  TNC-2 and Clones
  530.  
  531. First step is to prepare  your  TNC-2  for  use  with  TCP/IP.   The  standard
  532. firmware for the TNC-2 is not very computer friendly and, as such, is not very
  533. useful when it comes time to make your computer speak  with  other  computers.
  534. To  that  end Mike Chepponis, K3MC, wrote the KISS (Keep It Simple Stupid) TNC
  535. code.  There are two ROM versions for the TNC-2. The first is contained  in  a
  536. type  2764  or  27C64  EPROM.  This version contains the KISS code in it.  The
  537. second version is contained in a type 27256 or 27C256 EPROM and contains  both
  538. the standard TAPR 1.1.3 TNC code and a loader that will permit you to download
  539. the KISS code into the TNC.  Check the EPROM you have received  and  determine
  540. which  type  you have.  If you are burning your own EPROMs you probably do not
  541. need these instructions.
  542.  
  543. Open up your TNC and locate the ROM.  It is in the socket labeled "U23." Using
  544. a  small  nail file or screwdriver gently pry up the existing EPROM. Carefully
  545. press the new EPROM into place being sure that the orientation  is  the  same.
  546. If  you  are  installing  the 2764 type of EPROM you will need to make a small
  547. modification to the TNC.  There is a location on  the  board  just  above  the
  548. first RAM socket labeled JMP-6.  Turn the board over and cut the trace joining
  549. the two pads.  Solder a two-pin jumper header in place.   When  using  a  type
  550. 2764  the  jumper  at  JMP-6 should be removed and installed when a type 27256
  551. EPROM is being used.  That should complete the hardware part of the  installa-
  552. tion.  As an alternative you may choose to burn the KISS code into a 27256 and
  553. not bother with jumpers.
  554.  
  555. Attach your TNC to your PC using an RS-232C cable.  You can use the same cable
  556. that you were using to connect your PC to your TNC.  If you are doing this for
  557. the first time and are not sure about your cabling, a cable with just pins  2,
  558. 3, and 7 passed through is sufficient.  Some PCs like to see the signals Clear
  559. To Send (CTS, pin 5), Data Set Ready (DSR, pin 6),  and  Data  Carrier  Detect
  560. (DCD,  pin  8) asserted.  You can set this up by jumpering pin 4 to 5, and pin
  561. 20 to pins 6 and 8 at the female DB-25 connector that goes to the PC.
  562.  
  563. Now to verify that the TNC still works.  Apply power to the TNC  and  turn  it
  564. on.   The  STA,  CON,  and  PWR LEDs should come on and the STA and CON lights
  565. should go out again about 1 second later.  If you have  the  type  2764  EPROM
  566. with  the  KISS  code  in it one or both of the STA and CON LEDs will begin to
  567. flash.  If the CON LED flashes you have 8Kb of RAM in the TNC.  If the STA LED
  568. flashes  you have 16Kb of RAM.  If both LEDs flash you have 32 Kb of RAM.  The
  569. flashing of the LEDs verifies the proper operation of the TNC.
  570.  
  571. If you got the combined loader and TAPR version EPROM, checkout is a  slightly
  572. different  process.   You  can  test  your TNC-2 using two methods.  The first
  573. method is to connect your TNC to a terminal program and send the character 'h'
  574. or  'H'  to  the  TNC.  The result should be the standard TNC startup message.
  575. Exit from the 1.1.3 mode of operation by issuing the reset command to the TNC.
  576. The second method involves downloading the KISS code to the TNC.  Use the mode
  577. command to set the baud rate of the comm port to the  proper  value,  e.g.  it
  578. matches  the  DIP  switch  setting  on  the back of the TNC, and copy the file
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.                                     - 10 -
  589.  
  590.  
  591. tnc2kiss.hex to the appropriate comm port.   The  following  command  sequence
  592. will serve to download the KISS code to the TNC:
  593.  
  594.         mode com1:4800
  595.         copy tnc2kiss.hex com1:
  596.  
  597. If the download was successful (it takes about one minute) the STA and/or  CON
  598. LEDs will begin flashing as described in the previous paragraph.  If the down-
  599. load is not successful check the cable from computer to TNC,  check  the  baud
  600. rate  on the TNC, and check to ensure that the computer is indeed sending data
  601. to the TNC.  Once this is done the TNC is ready to use with the NET program.
  602.  
  603.      NOTE: running KISS causes the stored parameters  in  the  TNC,  i.e.
  604.      MYCALL,  NEWMODE,  TXDELAY,  etc.,  to be destroyed.  Every time you
  605.      shift from KISS to TAPR modes you MUST reset the parameters.
  606.  
  607.  
  608. 3.1.3.  AEA PK-232, PK-87, or new Heath TNC (PK-232 clone)
  609.  
  610. If you have one of these boxes, congratulations!  You do not  have  to  change
  611. PROMS!   KISS  is already installed as a standard feature if you have a recent
  612. release of the firmware, 4-MAR-87 or later for the  PK-232,  or  21-JAN-87  or
  613. later for the PK-87, you have KISS in your TNC already.  To make it work first
  614. ensure that your computer can communicate with  the  TNC  in  standard  packet
  615. mode.   This  will  ensure  that the computer, TNC, cabling, and radio are all
  616. operating properly.
  617.  
  618. [Please note that one of the commands "PACKET" is not valid on the  PK-87  and
  619. will only elicit a "Huh?" response.  Please note that comments have been added
  620. to the commands.  Do not type the information following  the  double  dash  or
  621. type the double dash itself.]
  622.  
  623. Here is the sequence of commands that will turn on the KISS mode for  the  AEA
  624. products:
  625.  
  626.         AWLEN 8         -- ensure it can speak 8 bit data
  627.         PARITY 0        -- no parity
  628.         RESTART         -- warm reset; make the previous commands take effect
  629.         PACKET          -- PK-232 or Heath only
  630.         TONE 3          -- PK-87 only
  631.         START 0         -- start, stop, xon, xoff, xflow to disable software
  632.         STOP 0             flow cont
  633.         XON 0
  634.         XOFF 0
  635.         XFLOW off
  636.         CONMODE trans   -- pass through all characters
  637.         HPOLL off       -- disable host polling
  638.         KISS on         -- enable KISS version of host mode
  639.         RAWHDLC on      -- turn off AX25L2 (the protocol is now handled by the PC)
  640.         PPERSIST on     -- turn off DWAIT and enable p-persistence
  641.         HOST on         -- start KISS running
  642.  
  643.  
  644. The PK-87 or the PK-232 will remain in the KISS mode until you  send  a  break
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.                                     - 11 -
  655.  
  656.  
  657. (~200ms of spacing) or until you send the command character three times (^C ^C
  658. ^C) in quick succession.  Beware!  Some terminal emulators  (like  YAPP)  will
  659. send  a  break  signal  when you exit from them.  That will undo your work and
  660. cause all manner of confusion.  The terminal program  PROCOMM  seems  to  work
  661. just  fine.  The TNC may also be switched back to ordinary AX.25 mode by issu-
  662. ing the following command from within NET.EXE:
  663.  
  664.         param ax0 255
  665.  
  666.  
  667. 3.1.4.  Kantronics
  668.  
  669. Kantronics has recently begun to offer KISS on their products.  It is the sim-
  670. plest of the commercial implementations of KISS to configure and use.
  671.  
  672. First setup and operate your KAM, KPC-II, or KPC-4 for standard packet  opera-
  673. tion.  This will ensure that the computer, TNC, cabling, and radio are operat-
  674. ing properly.  Use your terminal program to send the following commands:
  675.  
  676.         ABAUD 4800      -- set the baud rate to whatever you will be using when
  677.                            net is running (set by the attach command)
  678.         DWAIT 0         -- disable DWAIT
  679.         PERSIST 50      -- enable persistence and set it to about 20%
  680.         SLOTTIME 16     -- set the slot time to 160 ms
  681.         KISS ON         -- Enable KISS mode at the next reset
  682.         PERM            -- make the above command permanent so that KISS
  683.                            will be entered whenever the TNC is powered up
  684.         RESET           -- start KISS
  685.  
  686.  
  687. If you wish to have the the TNC revert back to ordinary AX.25 mode  of  opera-
  688. tion  you  should  omit the PERM command from the above sequence. That way the
  689. TNC will revert back to ordinary AX.25 mode when  the  power  is  removed  and
  690. restored  to  the TNC.  The TNC may be switched back to ordinary AX.25 mode by
  691. issuing the command:
  692.  
  693.         param ax0 255
  694.  
  695.  
  696. This command will work even if the PERM command has been used to make KISS the
  697. default mode of operation.
  698.  
  699. 3.2.  Installation of NET.EXE on an IBM PC or Clone
  700.  
  701. Create a directory called EXE and set that  as  the  default  directory.   Use
  702. PKXARC  to  extract the files from EXE.ARC into the new directory.  Should you
  703. not have PKXARC already, run the program PKX35A35.EXE provided with  the  dis-
  704. tribution.  This program will create the extraction utility and its documenta-
  705. tion.
  706.  
  707. There are two programs that make up the network software:  NET.EXE  (the  net-
  708. working code) and BM.EXE (the mail program).  Copy these programs from the EXE
  709. directory to the place on your hard disk where you keep command programs.   If
  710. you  are  running on a floppy based system you should create a bootable floppy
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.                                     - 12 -
  721.  
  722.  
  723. and copy these programs to the floppy.
  724.  
  725. Test to make sure that everything is there by executing  the  programs.   Type
  726. the command "net" and, if the installation of the network code was successful,
  727. the message "KA9Q internet protocol package" and the prompt "net>" will appear
  728. on  the screen.  This means that the network code is running and awaiting com-
  729. mands.
  730.  
  731. Exit from the net code with the command "exit." Now run the command "bm."  The
  732. screen  should  display  the message "Bdale's Messy-DOS Mailer" and the prompt
  733. "Brian"> will appear (this prompt or something like it is a  function  of  the
  734. content  of  the  bm.rc configuration file).  If all this has occurred, all is
  735. well so far.  If you do not get this response from bm, do  not  be  concerned.
  736. Try again after you have configured bm in the following steps.
  737.  
  738. 3.2.1.  Installing the Mail Directories used by BM
  739.  
  740. First step is to configure the mailer (BM).  To make BM work properly you must
  741. create the following directories on your disk:
  742.  
  743.         //spool
  744.         //spool//mail
  745.         //spool//mqueue
  746.  
  747.  
  748. Copy the file SEQUENCE.SEQ to the /spool/mqueue  directory.   Copy  the  files
  749. HOSTS.NET  and  BM.RC to the root directory of the default drive used when net
  750. is running.  If you are on a floppy based system you need to  put  BM.RC  with
  751. NET.EXE,  BM.EXE,  AUTOEXEC.NET,  HOSTS.NET,  and AUTOEXEC.BAT in the root (/)
  752. directory (more on AUTOEXEC.NET later).
  753.  
  754. 3.2.2.  HOSTS.NET
  755.  
  756. You will need to edit the file HOSTS.NET to know about all  the  systems  with
  757. which  you  will  exchange mail.  This is how net will translate the name into
  758. the IP address.  Here is an example of some  of  the  entries  I  have  in  my
  759. machine for other local TCP/IP stations:
  760.  
  761.         44.96.0.2       wb2sef.ampr
  762.         44.96.0.16      n8fjb.ampr
  763.         44.96.0.17      ka3lyq.ampr Roel
  764.  
  765.  
  766. All this does is translate the symbolic name to the IP  address,  e.g.  WB2SEF
  767. gets  translated  to  44.96.0.2  so that IP can route it to the proper network
  768. node.  This saves you from having to remember lots of numbers.  You  may  note
  769. that  the  last  entry has two aliases, either of which may be used to specify
  770. the IP address 44.96.0.17.  There is essentially no limit  to  the  number  of
  771. aliases  that  may  be listed for a single IP address.  Just be sure that they
  772. are all on one line.
  773.  
  774. 3.2.3.  BM.RC
  775.  
  776. Next edit the file BM.RC.  This file lets the mail  system  know  about  local
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786.                                     - 13 -
  787.  
  788.  
  789. host name, user name, and editor name.  Here are some example entries:
  790.  
  791.         host wb6rqn.ampr
  792.         user brian
  793.         edit emacs
  794.  
  795.  
  796. The edit entry should contain the name of your favorite editor, such as  edlin
  797. (edlin is not your favorite editor?).  This editor will be used to construct a
  798. mail message when you invoke that function of bm.  You may use any DOS  compa-
  799. tible  editor just so long as it has the capability to prepare ascii files (be
  800. careful if you specify a word processor -- some word processors embed  special
  801. characters in the file).
  802.  
  803. Later on you can read the documents BM.DOC and SMTP.DOC to get  more  informa-
  804. tion.  You at least have enough info to get your mailer running now.
  805.  
  806. 3.2.4.  FTPUSERS
  807.  
  808. Now you need to possibly modify the /FTPUSERS file to permit users to send and
  809. receive  files  from  your system.  The FTPUSERS file contains the information
  810. about users in the following format:
  811.  
  812.         user password /directory permission-code
  813.  
  814.  
  815. The 'user' entry is the user's name, 'password' is the password for that user,
  816. '/directory'  is  the directory to which the user will have access (all of the
  817. subdirectories too), and permission-code is a number  between  0  and  7  that
  818. defines what the user may do.
  819.  
  820. The permission-code is a bit-map where the three least significant  bits  each
  821. have a specific meaning.  Here is a table:
  822.  
  823.         1 - read and directory access
  824.         2 - create access
  825.         4 - overwrite and delete access
  826.  
  827.  
  828. The protection bits are added together to  create  the  permission-code.   For
  829. example  3  (1+2)  permit  the user to read files and create new files but not
  830. overwrite or delete and existing file.  A permission-code of 7  (1+2+4)  would
  831. permit full access.  Here are some examples:
  832.  
  833.         guest * /public 3
  834.         brian xyzzy / 7
  835.  
  836.  
  837. In these examples guest may log in with any password and  may  copy  files  or
  838. create  new  files  in the directory /public while user brian must log in with
  839. password xyzzy but will be granted full access, e.g. read,  write,  overwrite,
  840. and delete, to all files in the system.
  841.  
  842. If you are running in a radio-based environment  I  would  not  give  out  the
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.                                     - 14 -
  853.  
  854.  
  855. latter  user/password  combination  because it will give anyone access to your
  856. entire disk.  Also remember that the user/password combination  are  broadcast
  857. in-the-clear  for anyone to read (if they have trace turned on). It is wise to
  858. segregate your radio-link users in a separate directory tree  and  not  permit
  859. delete or overwrite access.  That should prevent malicious mischief.
  860.  
  861. 3.2.5.  Configuring NET and the AUTOEXEC.NET file:
  862.  
  863. Now you need to configure and run NET.  Configuring NET to  run  may  be  per-
  864. formed manually every time you start up NET.EXE but that gets old pretty fast.
  865. There are usually many commands that must be typed the same way every time net
  866. is  started.   Fortunately  Phil thought of this and provided the AUTOEXEC.NET
  867. file.  The intention here is to place all the commands that you always execute
  868. in  a  file to be read and executed by NET.EXE whenever you start up.  To this
  869. end you will want to edit the file  AUTOEXEC.NET  prior  to  running  NET.EXE.
  870. Just use a text editor to enter the commands into the file AUTOEXEC.NET as you
  871. would type them at the "net>" prompt.
  872.  
  873. 3.2.5.1.  Setting the IP address:
  874.  
  875. When NET.EXE first starts up you need to tell it about many things,  i.e  what
  876. comm  ports  you  have,  what your IP address is, what your host name is, what
  877. other systems you will communicate with, what services you  wish  to  provide,
  878. etc.   The  first  thing  to do is to tell net who we are with the ip address,
  879. hostname, and ax25 mycall commands.  Enter your ip address in  dotted  decimal
  880. notation or give the symbolic name from your HOSTS.NET file.  Here is an exam-
  881. ple:
  882.  
  883.         ip address [44.96.0.1]
  884.  
  885.  
  886. The selection of an address is very important.  If you are going to be part of
  887. a network you must have a unique address.  Talk to the person in your area who
  888. is responsible for coordinating addresses.  If you  are  not  a  part  of  the
  889. Internet  and  are  just  using  this with your own computers, pick any unique
  890. address that suits you.
  891.  
  892.      NOTE:  Throughout this document names and IP  addresses  are  inter-
  893.      changeable.   Net differentiates between the two by requiring you to
  894.      enclose IP addresses in square brackets [].
  895.  
  896.  
  897. 3.2.5.2.  Hostname:
  898.  
  899. The hostname command is used  to  set  the  name  of  your  system.   This  is
  900. displayed  when someone initiates an FTP session with your system.  Again here
  901. is an example:
  902.  
  903.         hostname wb6rqn.ampr
  904.  
  905.  
  906. This corresponds to my system in my local domain.  For the purposes of amateur
  907. packet  radio your call sign followed by "ampr" (amateur packet radio network)
  908. is probably sufficient.
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.                                     - 15 -
  919.  
  920.  
  921. 3.2.5.3.  AX25 Mycall (packet radio only):
  922.  
  923. Since I also run net on the air  (amateur  packet  radio  networking)  I  must
  924. specify my amateur call sign with the ax25 mycall command.  Again, here is the
  925. entry from my AUTOEXEC.NET file:
  926.  
  927.         ax25 mycall WB6RQN-0
  928.  
  929.  
  930. The call sign is entered in the same form that is used with the standard  TAPR
  931. TNC software, e.g. the call sign is followed by the SSID field.
  932.  
  933. If you are going to run TCP/IP on the air using  the  ax25  driver  (described
  934. below  with  the  attach command) the ax25 mycall entry MUST precede the first
  935. attach command that uses the ax25 driver.   Otherwise  there  is  no  required
  936. order for these commands.
  937.  
  938. 3.2.5.4.  Attach command
  939.  
  940. The attach command tells net about your comm ports and in what mode the  ports
  941. will  operate.   Currently four types of comm hardware are supported: standard
  942. PC async comm adapters, the HAPN TNC board for  the  PC,  the  Eagle  RS-232/2
  943. card,  and  the  3Com  Ethernet controller.  Each of these devices has its own
  944. version of the attach command.  Here  is  the  attach  command  for  an  async
  945. adapter  card  acting as COM1:.  You would use this to attach your pc to a TNC
  946. running the KISS code:
  947.  
  948.         attach asy 0x3f8 4 ax25 ax0 1024 256 4800
  949.  
  950.  
  951. This means attach an asynchronous adapter whose port address is 3F8 hex  using
  952. interrupt  line  4  (both  standard  for com1:), as an ax25 device (KISS TNC),
  953. using a buffer size of 1024 and  a  maximum  transmission  unit  (the  largest
  954. packet you are allowed to send) of 256 bytes, running at 4800 baud.  The media
  955. name for this device will be ax0, a name that will be used in the route,  con-
  956. nect,  and  param  commands  to  refer  to this comm port.  This is probably a
  957. pretty good place to start.  If you also wish to use COM2  instead  of  or  in
  958. addition to COM1 you would add the line:
  959.  
  960.         attach asy 0x2f8 3 ax25 ax1 1024 256 4800
  961.  
  962.  
  963. If you are instead going to use COM2 to connect with another PC using  a  hard
  964. wired  connection  (some  of  us  do have multiple PC's) you might want to use
  965. COM2: to connect to the other PC.  We would want to use SLIP to do this so the
  966. attach command would be:
  967.  
  968.         attach asy 0x2f8 3 slip sl0 1024 576 4800
  969.  
  970.  
  971.      NOTE:  IBM-PCs and clones all use I/O port address 0x3f8 and  inter-
  972.      rupt  request  line  4 for COM1 and port address 0x2f8 and interrupt
  973.      request line 3 for COM2.  There are other comm cards that  implement
  974.      COM3,  COM4,  etc.,  but  these  cards  may  use  non-standard  port
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.                                     - 16 -
  985.  
  986.  
  987.      addresses and interrupt request lines for these  ports.   Check  the
  988.      documentation that came with your comm card if you are trying to use
  989.      COM3 or higher.
  990.  
  991. If you have an HAPN TNC card for your PC you will want to enter the  following
  992. attach command:
  993.  
  994.         attach hapn 0x3f8 4 ax25 h0 1024 256 csma
  995.  
  996.  
  997. This tells net to use an HAPN board with the port address 3F8h  and  interrupt
  998. request  line  4.   The  speed  of the board is determined by the board so the
  999. software has no control over that function.  The  last  parameter,  listed  as
  1000. operation.
  1001.  
  1002. Recently the Eagle RS-232/2 card  has  become  available  at  very  reasonable
  1003. prices.   This two-channel card generates HDLC frames directly and may be con-
  1004. nected to a modem for direct packet radio operation without a TNC. Normally it
  1005. would be connected to a Bell-202-type half-duplex asynchronous modem.
  1006.  
  1007. The attach command for the Eagle board is almost  identical  to  that  of  the
  1008. standard async comm card.  Here is an example:
  1009.  
  1010.         attach eagle 0x300 5 ax25 eg0 2048 256 1200
  1011.  
  1012.  
  1013. Two items must be as shown in the example: the mode must always be  ax25  (not
  1014. SLIP)  and  the  media  name must begin with 'eg' and end with a single digit.
  1015. The first Eagle card must be called eg0 and the second must be called eg1.
  1016.  
  1017. The Eagle card is hard wired for a base address of 0x300 and IRQ5.  The use of
  1018. IRQ5  conflicts  with  the  disk  controller on the PC/XT (no problem with the
  1019. PC/AT).  If you wish to use the Eagle card with a PC/XT or compatible you will
  1020. need  to locate the trace from pin 3 of the 74LS125 (U12) to B23 (IRQ5) on the
  1021. edge connector.  Cut this trace at the edge connector and  reroute  it  to  B4
  1022. (IRQ2)  on the edge connector.  This will eliminate the conflict and allow you
  1023. to use IRQ2.
  1024.  
  1025. If you happen to have more than one PC you may wish to connect them  using  an
  1026. Ethernet.   The  net  software supports the 3Com 3C500 or 3C501 boards for the
  1027. PC.  The command to attach this board is:
  1028.  
  1029.         attach 3c500 0x300 3 arpa ec0 5 1500
  1030.  
  1031.  
  1032. This tells net that there is a 3Com 3C500 board  at  I/O  address  300h  using
  1033. interrupt  request  line  3  with the media name ec0.  Net should reserve five
  1034. buffers and the largest Ethernet packet may be 1500 bytes long.
  1035.  
  1036. A word about the selection of the value for  the  maximum  transmission  unit.
  1037. For standard TNCs and radios 256 is probably the largest value you should use.
  1038. This ensures compatibility with the rest of the AX.25  community  and  ensures
  1039. that you are legal if you are operating unattended (part 97 of the FCC regula-
  1040. tions specifically  mentions  the  AX.25  protocol  in  permitting  unattended
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.                                     - 17 -
  1051.  
  1052.  
  1053. digital  operation above 50 MHz).  The smallest value you may use is 64.  Per-
  1054. formance improves with larger values IF you can get  them  to  the  other  end
  1055. without  errors.   I suggest you stick with 256 until you can run some experi-
  1056. ments of your own.  If you have a good transmission path and all the  stations
  1057. and  gateways are attended, feel free to use larger values.  It will result in
  1058. improved performance (see the discussion of the mss and window parameters).
  1059.  
  1060. 3.2.5.5.  Param command:
  1061.  
  1062. If you are using a TNC running the KISS code (you  probably  are  if  you  are
  1063. operating  amateur  packet  radio)  you will need to set the parameters in the
  1064. TNC.  This is accomplished with the param command.
  1065.  
  1066. There are five settable parameters in the kiss code.  They are:
  1067.  
  1068. 1.   Transmitter keyup delay (TXD).  This is how long the TNC will wait  after
  1069.      keying the transmitter prior to beginning to send data.  The proper value
  1070.      for this parameter is dependent on your configuration.  This value is  in
  1071.      10's  of  milliseconds.   Acceptable  values  range  from 0 (0 ms) to 255
  1072.      (2,550 ms or 2.55 seconds).
  1073.  
  1074. 2.   Persistence (p).  This is the probability that  the  TNC  will  key  your
  1075.      transmitter  if  a slot is found empty (the channel is free).  Acceptable
  1076.      values range from 0 (p = (0+1)/256 = 0.4%) to 255 (p = 255+1/256 = 100%).
  1077.      The  default  value is 63 (25%).  The optimum value is somewhere close to
  1078.      1/n where n is the number of users on the channel.
  1079.  
  1080. 3.   Slot time (ts).  This is how long that the TNC will wait between  samples
  1081.      of  the  channel.  Acceptable values range from 0 (0 ms) to 255 (2,550 ms
  1082.      or 2.55 seconds).
  1083.  
  1084. 4.   Tail timer (tt).  This is how long the  TNC  will  keep  the  transmitter
  1085.      keyed  after  the  last  character  has been transferred to the HDLC con-
  1086.      troller.  This has become an outdated command since most of the TNCs  now
  1087.      set this value automatically based on data rate.
  1088.  
  1089. 5.   Full Duplex.  A zero value (the default value) means operate the  TNC  in
  1090.      half-duplex  CSMA  mode  (listen  before you transmit).  A non-zero value
  1091.      means transmit whenever there is data to send.
  1092.  
  1093. Let us assume that on the channel associated with ax0 that I have a radio that
  1094. requires  a  transmit  keyup  delay  of  200  ms, I want persistence to be 20%
  1095. (p=0.2), and I want the slot time to be 160 ms.  These are the values that  we
  1096. use  in the DC area and make us "good neighbors" who do not "hog" the channel.
  1097. I would enter the following commands:
  1098.  
  1099.         param ax0 1 20
  1100.         param ax0 2 51
  1101.         param ax0 3 16
  1102.  
  1103.  
  1104. Note that the parameters are now specified as decimal values.
  1105.  
  1106.      NOTE: The 'param' command will be used  for  issuing  other  device-
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.                                     - 18 -
  1117.  
  1118.  
  1119.      dependent  commands  as  the need arises.  Right now it is used only
  1120.      for setting the parameters for kiss TNCs and the speed of  SLIP  and
  1121.      AX25  links.  Other versions of the 'param' command will be added as
  1122.      the need arises.
  1123.  
  1124. If you are dealing with a SLIP link (you used the entry slip instead  of  ax25
  1125. in  the  attach  command)  the param command is used to change the speed (baud
  1126. rate) for the line.  If you wanted to change the speed  of  your  second  slip
  1127. link to 4800 baud you would enter:
  1128.  
  1129.         param sl1 4800
  1130.  
  1131.  
  1132. 3.2.5.6.  ax25 digipeat command (packet radio only):
  1133.  
  1134. If you are currently an active digipeater in your area you can also make  your
  1135. system  continue  to  be  a  digipeater for those poor souls unlucky enough to
  1136. still be running ordinary AX.25.  The command for this is:
  1137.  
  1138.         ax25 digipeat on
  1139.  
  1140.  
  1141. 3.2.5.7.  Mail Gateway:
  1142.  
  1143. The mail subsystem (SMTP) needs to know where to send mail should the destina-
  1144. tion be unknown to the sending system.  This is handled by the gateway command
  1145. as follows:
  1146.  
  1147.         smtp gateway wa3pxx
  1148.         - or -
  1149.         smtp gateway [44.96.0.13]
  1150.  
  1151.  
  1152. Should you try to send mail to a host that is not in your HOSTS.NET  file  the
  1153. mailer will route the mail to the system specified in the gateway entry.  This
  1154. presumes that the gateway system is smart enough to figure  out  to  whom  the
  1155. mail  is addressed so that the mail can be forwarded.  At this time the mailer
  1156. in NET.EXE is not "smart" enough to act as a mail forwarding node.  This field
  1157. is only here should you be lucky enough to have another computer accessible to
  1158. you with a smart SMTP mailer or another host that acts as a gateway to another
  1159. network.   Any UNIX 4.2 or 4.3 BSD system has such a mailer.  A PC running the
  1160. WA3PXX BBS gateway also will serve.
  1161.  
  1162. For packet radio enthusiasts another use for the gateway command  is  to  send
  1163. mail  on  to  your  local  BBS  gateway station.  Bob Gibson, WA3PXX, has con-
  1164. structed a gateway program that will permit the  transfer  of  mail  from  the
  1165. WA7MBL  BBS  to  SMTP  and back again.  By having your local BBS run DoubleDos
  1166. with the WA7MBL BBS in one partition and NET in the other  you  can  automati-
  1167. cally move mail between the two domains.
  1168.  
  1169. 3.2.5.8.  Construction of Routing Tables:
  1170.  
  1171. Now you need to construct the routing table.  This table is used by the IP  to
  1172. determine  how  to  forward your packets.  Each entry consists of two or three
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179.  
  1180.  
  1181.  
  1182.                                     - 19 -
  1183.  
  1184.  
  1185. parts, the IP address of the destination, the link upon which it is to be for-
  1186. warded,  and  the  IP address of the next station in line if there can be more
  1187. than one IP address on the link (used if the mode is ax25 and not used if  the
  1188. mode is slip).  Here are three sample entries, one for a station more than one
  1189. hop away via ax25 to be forwarded by 44.96.0.7, one for station one  hop  away
  1190. on ax25, and one for a station on the other side of a slip link:
  1191.  
  1192.         route add [44.96.0.5] ax0 [44.96.0.7]
  1193.         route add [44.96.0.2] ax0
  1194.         route add [44.96.0.12] sl0
  1195.         route add n3ja ax0
  1196.  
  1197.  
  1198. The first string following the command  'route  add'  is  the  destination  IP
  1199. address.   The  second  field, i.e. ax0 or sl0, is the media and must match up
  1200. with one of your previous attach commands.  The last field is the next station
  1201. in the path if the destination is more than one hop away.  This is an optional
  1202. field and only needs to be used if the media is a broadcast media such as Eth-
  1203. ernet or AX.25 and the destination is more than one hop away.
  1204.  
  1205. Note that the address may be specified as  either  an  IP  address  in  dotted
  1206. decimal notation or it may be a symbolic address from your hosts.net file.  If
  1207. you choose the latter technique you must enter the symbolic address  precisely
  1208. as it was entered in the hosts.net file, e.g.  upper and lower case characters
  1209. in the name are significant.
  1210.  
  1211. If you are using an Eagle RS-232/2 board your  media  is  named  eg0  or  eg1.
  1212. There  is  still a problem because there are two ports on the board.  In order
  1213. to solve this problem you will need to add the letters 'a' or 'b' to the media
  1214. name.   For  instance, if you have a single Eagle card your media names become
  1215. 'eg0a' and 'eg0b' for the A and B ports of the card  respectively.   Remember,
  1216. take  the  media  name from the attach command and append either A or B to the
  1217. end of the name to select the appropriate port.  Here are some examples:
  1218.  
  1219.         route add [44.96.0.22] eg0a
  1220.         route add aj9x eg0b wb3ffv
  1221.  
  1222.  
  1223. There are two other special types of route entries; the default  entry  and  a
  1224. cluster entry.  Here is a default entry:
  1225.  
  1226.         route add default ax0 [44.96.0.99]
  1227.  
  1228.  
  1229. This means that if the address does not match any entry in your  table,  route
  1230. the  packet to 44.96.0.99 via ax0.  Hopefully the switch at 44.96.0.99 will be
  1231. able to forward the packet to its destination.  This generally works  well  if
  1232. you  are  merely an end node (a leaf) in the network and all your traffic goes
  1233. to a single gateway.
  1234.  
  1235. 3.2.5.8.1.  Cluster Routing and its Associated Concepts:
  1236.  
  1237. The other option for routing is cluster routing.  It allows you to send blocks
  1238. of  addresses  in  a  certain direction.  This is useful if all the users in a
  1239.  
  1240.  
  1241.  
  1242.  
  1243.  
  1244.  
  1245.  
  1246.  
  1247.  
  1248.                                     - 20 -
  1249.  
  1250.  
  1251. given area have some common part to their IP addresses.  Here is  an  explana-
  1252. tion of cluster routing and addresses in general.
  1253.  
  1254. The IP address is thirty-two (32) bits long.  It is generally  represented  as
  1255. four 8-bit numbers, with each number being written in decimal form.  For exam-
  1256. ple, my IP address is 44.96.0.1.  This number can be represented as the  hexa-
  1257. decimal  value 2C600001 or 00101100011000000000000000000001 in binary.  We can
  1258. break this out as follows:
  1259.  
  1260.         decimal           44        96         0         1
  1261.         hexadecimal       2C        60        00        01
  1262.         binary         00101100  01100000  00000000  00000001
  1263.  
  1264.  
  1265. Normally when you make an entry in the routing table, all bits of the  address
  1266. are  significant,  e.g.  an exact match is needed for the address to be recog-
  1267. nized.  On the other end there is the  default  route  in  which  any  address
  1268. matches.
  1269.  
  1270. Cluster routing falls somewhere between these two extremes.   Cluster  routing
  1271. allows  you  to specify how much of the address is to be considered valid.  In
  1272. order to determine how many bits in  the  address  are  valid  you  enter  the
  1273. address in a special format:
  1274.  
  1275.         route add [44.96.0.64]/26 ax0
  1276.  
  1277.  
  1278. This means that only the first 26 bits of the address  are  to  be  considered
  1279. significant.   This  is  a  form  of  wild card for the address.  Here is that
  1280. address in binary to show the mapping:
  1281.  
  1282.         00101100  01100000  00000000  01??????
  1283.  
  1284.  
  1285. The question marks in the above address show the least  significant  six  bits
  1286. being  "wild,"  or  matching  any corresponding bits in the address.  Here are
  1287. some examples:
  1288.  
  1289.         44.96.0.67     00101100  01100000  00000000  01000111  (a match)
  1290.         44.96.0.89     00101100  01100000  00000000  01011001  (a match)
  1291.         44.96.0.01     00101100  01100000  00000000  00000001  (no match)
  1292.  
  1293.  
  1294. This works because the routing process in the net code  will,  when  presented
  1295. with  an  address, search for an exactly matching entry.  Failing to find that
  1296. it will then look for an address that matches on the most significant 31 bits,
  1297. then  30  bits, and so on.  If presented with the address 44.96.0.67 IP would,
  1298. after 6 tries, match the address to the example given above.
  1299.  
  1300. By judiciously assigning addresses we can make the address aid us  in  routing
  1301. the  packets.   The  users within a LAN should have something in common in the
  1302. high order part of the address so that we can use a single entry in the  rout-
  1303. ing  table  to make things go in the proper direction.  Here in the Washington
  1304. DC area all addresses begin with 44.96.0.  This identifies this  general  area
  1305.  
  1306.  
  1307.  
  1308.  
  1309.  
  1310.  
  1311.  
  1312.  
  1313.  
  1314.                                     - 21 -
  1315.  
  1316.  
  1317. and may be used to provide routing to us.  Once the packet arrives in our gen-
  1318. eral area cluster routing is then used to further route  the  packets  to  the
  1319. appropriate  area.  In DC and the parts of Maryland immediately surrounding DC
  1320. the low order byte ranges from 0 to 63.  Northern Virginia users  get  numbers
  1321. in  the range of 64 to 127.  The Baltimore users get 128 to 191 while the Har-
  1322. risburg, PA, users get 192 to 255.  The idea being that we can use the top two
  1323. bits in the low order byte of the address to identify LANs within the address.
  1324. That way the bits in the high order part of the address will get you into  the
  1325. general area, the next part of the address will get you to the proper LAN, and
  1326. the least significant bits will get you to the proper host or user.
  1327.  
  1328. 3.2.5.9.  Routing Loops and the Time To Live (TTL) Command:
  1329.  
  1330. It is quite possible (and likely!) to make  errors  when  setting  up  routing
  1331. tables  that  will cause a routing loop to occur (a routing loop is a circular
  1332. path that never reaches the intended destination).  Imagine what would  happen
  1333. if two stations had their default routing pointing at each other like this:
  1334.  
  1335.         host 1 (44.96.0.1): route add default ax0 [44.96.0.2]
  1336.         host 2 (44.96.0.2); route add default ax0 [44.96.0.1]
  1337.  
  1338.  
  1339. In this case a packet that got routed using the  default  route  would  bounce
  1340. back  and forth between the two stations forever.  There is a command that can
  1341. prevent this from going on forever: the Time-To-Live (ttl) command.  Every  IP
  1342. packet  has a ttl field in it that is decremented by 1 at every hop.  When the
  1343. ttl field reaches zero and the packet is not at the destination the packet  is
  1344. discarded and an ICMP message explaining the fact is sent to the sending host.
  1345. Normally net sets the ttl field to 255.  If you know that no host is more than
  1346. 5 hops away you might issue the following command:
  1347.  
  1348.         ip ttl 5
  1349.  
  1350.  
  1351. This means that all packets from your host/station are sent with ttl set to an
  1352. initial  value  of  5.   These  packets  will now be discarded if they haven't
  1353. reached their destination after 5 hops.  This limits the traffic in  the  net-
  1354. work should somebody inadvertently create a routing loop.
  1355.  
  1356. 3.2.6.  Using Digipeaters and the ARP Add Command (packet radio only):
  1357.  
  1358. Since there may not be many TCP users in your area you may need to use a digi-
  1359. peater  (or  two) to reach the other users in your area.  This is now possible
  1360. by adding entries to the ARP (Address Resolution Protocol) tables.  ARP serves
  1361. to map IP addresses into Ethernet or AX25 address, whichever is appropriate to
  1362. the media in use.  ARP  normally  does  its  work  automatically  by  directly
  1363. conversing  with  the other station but it cannot do that if the other station
  1364. is reachable only via a digipeater. In that case you must "hard-wire"  an  ARP
  1365. table entry with the ARP ADD command.
  1366.  
  1367. Before you can use the ARP ADD command you must know the  path  to  the  other
  1368. station.   Let us assume that the station with whom you wish to communicate is
  1369. WA4OIE (Other Internet Experimenter) whose address  is  44.96.0.247,  but  the
  1370. only path available is via WB3PID (Poor Inefficient Digipeater).  In this case
  1371.  
  1372.  
  1373.  
  1374.  
  1375.  
  1376.  
  1377.  
  1378.  
  1379.  
  1380.                                     - 22 -
  1381.  
  1382.  
  1383. you will use the following ARP ADD command:
  1384.  
  1385.         arp add [44.96.0.247] ax25 wa4oie wb3pid
  1386.         - or -
  1387.         arp add wa4oie ax25 wa4oie wb3pid
  1388.  
  1389.  
  1390. From this point on packets sent over an AX25 link to address 44.96.0.247  will
  1391. use  the  AX25  destination  address of WA4OIE with an intermediate digipeater
  1392. address of WB3PBD.  If you need to use more than one digipeater it is  permis-
  1393. sible.   Just  place  the call signs of the digipeaters sequentially following
  1394. the destination AX.25 address.
  1395.  
  1396. 3.2.7.  Window and Maximum Segment Sizes:
  1397.  
  1398. The next information we want to include is some information  used  by  TCP  to
  1399. determine  how much data it can send at one time and how much data may be out-
  1400. standing before it stops to wait for an ack from the other end.  Here are  the
  1401. example values:
  1402.  
  1403.         tcp mss 216
  1404.         tcp window 648
  1405.  
  1406.  
  1407. The parameter mss stands for maximum segment size and represents  the  largest
  1408. single  segment  that  TCP  will send.  Mss should be set as a function of the
  1409. quality of the link over which you are running.  Relatively  error-free  links
  1410. should  use  larger values of mss.  If you are running on amateur packet radio
  1411. and wish to operate unattended you should probably limit this value to 216 (an
  1412. mss of 216 will cause you to send AX.25 packets that are 256 bytes long.
  1413.  
  1414. The net program now compares the mss value and the mtu  values  given  in  the
  1415. attach command for the media being used.  Since TCP and IP each have a 20 byte
  1416. header (a total of 40 bytes), an mss of 216 corresponds to an mtu of 256.   If
  1417. you  are using mixed mtu's, i.e. 256 for AX.25, 1500 for Ethernet, and 576 for
  1418. SLIP, set the mss to correspond to the largest mtu you are using and  let  net
  1419. adjust the mss downward for the media that are using smaller values for mtu.
  1420.  
  1421. The 'window' parameter is how many bytes may be outstanding at  any  one  time
  1422. before  you  wait for an ack.  If you have a pretty good link you can increase
  1423. the value of mss.  If window is larger than mss TCP will run as a sliding win-
  1424. dow  protocol, e.g.  continue to send packets while waiting for ACKs on previ-
  1425. ously sent packets.  Since TCP uses selective reject (resend ONLY  those  seg-
  1426. ments that were damaged or lost) this is not a very expensive proposition.  In
  1427. any case window should always be a multiple of mss to prevent the transmission
  1428. of small packets every once in a while.
  1429.  
  1430. If you are running on a radio channel at 1200 baud remember that a  1024  byte
  1431. transmission  will  take  seven seconds, a time that can make you unpopular if
  1432. you have to share the frequency with AX.25 TNCs that cannot adapt to the  high
  1433. channel  utilization.   In  those cases it is probably better to reduce window
  1434. and/or mss values.  The above values will make you fit in reasonably with your
  1435. other AX.25 neighbors.  Remember that the efficiency of large packets and long
  1436. transmissions are probably not worth having your neighbors so angry that  they
  1437.  
  1438.  
  1439.  
  1440.  
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.                                     - 23 -
  1447.  
  1448.  
  1449. tie a rope between your coax and the bumper of a pickup truck so that they can
  1450. non-surgically remove your station from your shack.
  1451.  
  1452. One last point before we move on; the mss and window values that you set  will
  1453. be the ones that your TCP will ask the OTHER station to use.  When the session
  1454. is initially set up the two TCPs will exchange mss and  window  values.   This
  1455. permits stations to automatically adjust to the capabilities of the other sta-
  1456. tion.  For this reason it is best to get everyone in your LAN to use the  same
  1457. values.
  1458.  
  1459. 3.2.8.  Starting the Servers:
  1460.  
  1461. Next you need to decide what services you will provide to other users  in  the
  1462. network.   You  must  start the servers or others won't be able to make use of
  1463. your system for mail or file transfers.  You will simply be a switch for other
  1464. users  (in  fact, for a switch on a hill that may be just what you want).  You
  1465. will still be able to initiate file transfers or telnet sessions  but  no  one
  1466. will  be  able to initiate one with you.  Should you fail to start the servers
  1467. anyone trying to access those services on your machine  will  just  receive  a
  1468. "Closed, (reset)" message.  For the sake of consistency you will probably want
  1469. to use the start command to enable the following services:
  1470.  
  1471.         start telnet
  1472.         start ftp
  1473.         start smtp
  1474.         start echo
  1475.         start discard
  1476.  
  1477.  
  1478. Telnet is the terminal-to-host and terminal-to-terminal mode, ftp is the  file
  1479. transfer  protocol,  smtp  is the mail system (simple mail transfer protocol),
  1480. and echo is the echo server (it just sends back any  packets  it  receives  --
  1481. good for finding out if a switch is out there and running). The discard server
  1482. simply throws away anything it receives.  The echo  and  discard  servers  are
  1483. generally used for testing a link.
  1484.  
  1485. 3.3.  Running the network program NET.EXE
  1486.  
  1487. Start the networking program running by issuing the command "net."  You should
  1488. be rewarded by having the "net>" prompt appear on your screen. If you prepared
  1489. AUTOEXEC.NET as described in the previous section then you don't need to issue
  1490. any configuration commands.  If you have not set up AUTOEXEC.NET you will want
  1491. to read that section of the manual prior to proceeding with this section.
  1492.  
  1493. 3.3.1.  Operating Modes:
  1494.  
  1495. Net provides two modes of operation: command and session.  In the command mode
  1496. you  are  interacting  with the command interpreter to permit you to establish
  1497. sessions, retrieve status information, establish new  routing  table  entries,
  1498. etc.   Please  consider  the  commands  you  were  required  to  enter  in the
  1499. AUTOEXEC.NET file.  All of those commands were directed at the command  inter-
  1500. preter.   You  can  tell  that  the NET.EXE command interpreter is waiting for
  1501. input because it will present this prompt:
  1502.  
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.                                     - 24 -
  1513.  
  1514.  
  1515.  
  1516.         net>
  1517.  
  1518.  
  1519. The session mode is unique to the session with which you wish to  communicate.
  1520. TELNET  (terminal-to-host and terminal-to-terminal) and FTP (the File Transfer
  1521. Protocol) are the two types of sessions with which you may interact  and  each
  1522. has its own sets of commands and operating modes.
  1523.  
  1524. Before you get too carried away with trying things it is probably a good  idea
  1525. to  read  at  least  as  far as the discussion on multiple sessions. That will
  1526. explain how to start and use TELNET and FTP as well as how  to  keep  straight
  1527. all the activity from multiple users.
  1528.  
  1529. 3.3.2.  Running TELNET:
  1530.  
  1531. TELNET is used to provide terminal mode access to a host computer  system  but
  1532. may  also be used to have a terminal-to-terminal "chat" with another operator.
  1533. There are three commands directly associated  with  the  TELNET  service:  the
  1534. 'telnet', the 'eol', and the 'echo' commands.  ,NH 4 The 'telnet' command:
  1535.  
  1536. The 'telnet' command is used to establish a TELNET session with a  remote  TCP
  1537. socket,  usually  the  TELNET  server on a remote host.  To establish a TELNET
  1538. session you would issue the 'telnet' command as follows:
  1539.  
  1540.         telnet wb2sef
  1541.         telnet [44.96.0.2]
  1542.  
  1543.  
  1544. Both of these commands would establish a TELNET session with the TELNET server
  1545. at  WB2SEF  because  WB2SEF  is  defined  in  HOSTS.NET  as having the address
  1546. 44.96.0.2.  Note that we merely specified that we wished to establish a TELNET
  1547. session  and  the TELNET client then connected us with the TELNET server which
  1548. resides at TCP port address 23.  There is an extended syntax for the  'telnet'
  1549. command  that will let you specify the port number at the remote host to which
  1550. you wish to be connected.  Here is an example of the extended syntax:
  1551.  
  1552.         telnet [44.96.0.2] 7
  1553.         telnet wb2sef 9
  1554.  
  1555.  
  1556. In the first example TELNET is being asked to establish a  session  with  port
  1557. number  7, the echo server, at the host whose address is 44.96.0.2. The second
  1558. example also is a request to connect to the host whose  address  is  44.96.0.2
  1559. but  this  time  the  connection  is  to be made to port number 9, the discard
  1560. server.  These two ports are regularly used for test purposes, the echo server
  1561. echoing  back  everything it receives and the discard server discarding every-
  1562. thing it receives but returning a proper acknowledgement.
  1563.  
  1564. Once you have issued the 'telnet' command you will see the message "SYN  sent"
  1565. followed  a  short time later by the message "Established" (assuming that your
  1566. destination was reachable).  At this point you would be in communication  with
  1567. the  TELNET server on the other end.  If the remote host is a timesharing com-
  1568. puter (possibly running UNIX) you would very shortly be presented with a login
  1569.  
  1570.  
  1571.  
  1572.  
  1573.  
  1574.  
  1575.  
  1576.  
  1577.  
  1578.                                     - 25 -
  1579.  
  1580.  
  1581. screen.  You may consider your keyboard and screen to be directly connected to
  1582. the remote computer at this point.
  1583.  
  1584. On the other hand maybe you were attempting to  establish  a  connection  with
  1585. another  computer  running  the  net  code.   In  that  case  you  would be in
  1586. keyboard-to-screen communication with the operator at the remote host  (assum-
  1587. ing  that  he/she  selected  the new session as the current session; a subject
  1588. that will be discussed later).  Whatever you type will  appear  on  the  other
  1589. screen and vice-versa.
  1590.  
  1591. 3.3.2.1.  The ECHO Command
  1592.  
  1593. In addition to the 'telnet' command there are the 'eol' and  'echo'  commands.
  1594. The  'echo'  command  determines  what the TELNET client will do if the remote
  1595. host offers to echo characters (what we would consider full duplex).  Here  is
  1596. the command syntax:
  1597.  
  1598.         echo accept    [the default value]
  1599.         echo reject
  1600.  
  1601.  
  1602. If the remote host is a timesharing computer you probably want it to echo your
  1603. characters back to you rather than let your local TELNET client echo the char-
  1604. acters.  This  permits  you  to  use  sophisticated  screen-oriented  programs
  1605. without  having  your  local echoing disrupt the screen display.  On the other
  1606. hand you may prefer to reject echoing in the case of a very slow network where
  1607. having  what you type appear on the screen several seconds later could be very
  1608. annoying.  Please note that the setting of this parameter has no  effect  when
  1609. entering a TELNET session with another copy of NET since NET always refuses to
  1610. echo characters.
  1611.  
  1612. 3.3.2.2.  The EOL Command
  1613.  
  1614. The 'eol' command is also used  to  adjust  the  keyboard  functionality  when
  1615. remote  echoing  has  been  negotiated.   It is used to select the appropriate
  1616. end-of-line character to be sent when the  operator  presses  the  <ENTER>  or
  1617. <RETURN> key.  Here are examples of the two options:
  1618.  
  1619.         eol standard         [the default value]
  1620.         eol unix
  1621.  
  1622.  
  1623. Should you set 'eol' to 'unix' and remote echoing is  negotiated  by  the  two
  1624. systems,  the  <RETURN>  or <ENTER> key will send an ASCII line feed character
  1625. rather than the carriage return character.  Normally this will not  be  needed
  1626. but  some UNIX system demand this.  Should the remote host not respond to your
  1627. <RETURN> key you might want to try this option.
  1628.  
  1629. To exit back to the command prompt from within a telnet session press the  F10
  1630. key.   The  'net>' prompt will appear.  This does not close the TELNET session
  1631. but merely suspends it.  Incoming data addressed to your TELNET  session  will
  1632. be  saved  until you re-enter the session (see the discussion of changing ses-
  1633. sions that follows later).
  1634.  
  1635.  
  1636.  
  1637.  
  1638.  
  1639.  
  1640.  
  1641.  
  1642.  
  1643.  
  1644.                                     - 26 -
  1645.  
  1646.  
  1647. The last item of interest to the TELNET user is how to terminate a TELNET ses-
  1648. sion.   That  is  accomplished with the 'close' command.  To close the session
  1649. simply press the F10 key to return to the command prompt and enter the 'close'
  1650. command.  You should be rewarded with the sequence of messages:
  1651.  
  1652.         FIN wait 1
  1653.         FIN wait 2
  1654.         Time wait    [followed by a delay period of about 30 seconds]
  1655.         Closed (Normal)
  1656.  
  1657.  
  1658. 3.3.3.  File Transfer (FTP):
  1659.  
  1660. The File Transfer Protocol (FTP) permits you to send  and  receive  both  text
  1661. (ASCII)  and  binary (image) files.  The FTP application accepts many commands
  1662. that will permit you to create files, delete files,  change  directories,  and
  1663. copy files.  This section will guide you through the most used FTP commands.
  1664.  
  1665. 3.3.3.1.  Establishing a Session:
  1666.  
  1667. To establish an FTP session with a remote host you use the 'ftp' command.   To
  1668. establish  an  FTP  session  with WB2SEF I would use one of the following com-
  1669. mands:
  1670.  
  1671.         ftp wb2sef
  1672.         ftp [44.96.0.2]
  1673.  
  1674.  
  1675. Both commands do the same thing because of the  information  contained  in  my
  1676. HOSTS.NET  file.   After  issuing  one of the above commands you would see the
  1677. usual 'SYN sent' and 'Established' messages.  You would then be greeted  by  a
  1678. message from the remote FTP server that looked something like this:
  1679.  
  1680.         220 wb2sef.ampr FTP version 871225.5 ready at Tue Jan 19 17:57:23 1987
  1681.  
  1682.  
  1683. This message tells you that the remote FTP is ready to  accept  commands  from
  1684. you.   FTP gives you no prompt so at this point you must understand that after
  1685. issuing a command you will be notified of  the  command's  completion  but  no
  1686. further prompting for messages will occur.  One thing to note is that when FTP
  1687. sends you a message it will always be  prefixed  with  a  three-digit  number.
  1688. This  is for the benefit of computer programs that may be driving the FTP sys-
  1689. tem.  The number is for the benefit of the computer and the text  is  for  the
  1690. benefit of the user.
  1691.  
  1692. The first thing you will need to do is to log in to the remote host with  your
  1693. user  ID and your password.  Unless you have been given a specific user ID and
  1694. password by someone at the remote host you will probably log in with the guest
  1695. user ID and password.  You will send the 'user' and Here is an example:
  1696.  
  1697.         user guest
  1698.         331 Enter PASS command
  1699.         pass xyzzy
  1700.         230 Logged in
  1701.  
  1702.  
  1703.  
  1704.  
  1705.  
  1706.  
  1707.  
  1708.  
  1709.  
  1710.                                     - 27 -
  1711.  
  1712.  
  1713. This exchange presumes that your user ID is "guest" and that your password  is
  1714. "xyzzy."   If  the  user  ID does not require a password you may or may not be
  1715. prompted for the password.  NET always prompts for  the  password  whether  it
  1716. needs  it  or  not.  If the remote host is running NET and has in its FTPUSERS
  1717. file an entry that uses an asterisk (*) for the password, any password will be
  1718. accepted.
  1719.  
  1720. If you enter either an invalid user ID or an invalid password the  remote  FTP
  1721. will return the following message:
  1722.  
  1723.         550 Permission denied
  1724.  
  1725.  
  1726. Simply reenter the 'user' and 'pass' commands with the proper values  and  you
  1727. will  be  logged in.  You may also enter new 'user' and 'pass' commands at any
  1728. time to change your user ID and hence your permissions as far  as  the  remote
  1729. host is concerned.
  1730.  
  1731. 3.3.4.  Manipulating Directories on the Remote Host:
  1732.  
  1733. When you log into the remote host you will be set in "your" directory  (I  put
  1734. the  word your in quotes because many people may be using that directory since
  1735. many people may be allowed to log in concurrently with the same user ID).  You
  1736. can get a directory listing of files within that directory with the 'dir' com-
  1737. mand (just like DOS).  What you will receive back from the remote host will be
  1738. a  standard  DOS directory listing.  If you would prefer a short listing, e.g.
  1739. only the names of the files, you can use the 'ls' command.  Both commands will
  1740. accept wild cards so the following commands are all valid:
  1741.  
  1742.         dir
  1743.         ls *.*
  1744.         dir *.com
  1745.         ls test*.dat
  1746.  
  1747.  
  1748. After issuing the command you will see the  following  sequence  of  responses
  1749. from the remote host:
  1750.  
  1751.         200 Port command okay
  1752.         150 Opening data connection for LIST /public
  1753.         Your directory listing will be displayed here
  1754.         Get complete, nnnn bytes received
  1755.         226 File sent OK
  1756.  
  1757.  
  1758. The end of the "150 Opening data connection ..." response will differ  depend-
  1759. ing  on  the  directory  request  you made.  If you used the 'dir' command you
  1760. would see the word "LIST."  If you used the 'ls' command  you  would  see  the
  1761. word  "NLST."   What  followed  the  "LIST" or "NLST" would be the name of the
  1762. directory you are listing.
  1763.  
  1764. In addition to listing directories you can change the directory and query  for
  1765. the  current directory.  Let us assume that for your user ID (guest) your root
  1766. directory is /public.  Let us also assume that in public you  would  find  the
  1767.  
  1768.  
  1769.  
  1770.  
  1771.  
  1772.  
  1773.  
  1774.  
  1775.  
  1776.                                     - 28 -
  1777.  
  1778.  
  1779. three  subdirectories tcp, games, and utils. When you log in your directory is
  1780. set to /public.  Now you issue one of the following commands:
  1781.  
  1782.         cd tcp
  1783.         cd /public/tcp
  1784.  
  1785.  
  1786. The result would be the same since you were already in directory /public.  FTP
  1787. would then send you the response:
  1788.  
  1789.         257 "/public/tcp" is current directory
  1790.  
  1791.  
  1792. You may use the 'cd' command to change directory  to  any  subdirectory  below
  1793. your  home  directory  in the same way that the DOS cd command will also allow
  1794. you change directories.
  1795.  
  1796. If you are not sure what directory you are in you may  use  the  'pwd'  (print
  1797. working directory) command.  If we were to issue the command:
  1798.  
  1799.         pwd
  1800.  
  1801.  
  1802. the remote FTP would then respond:
  1803.  
  1804.         257 "/public/tcp" is current directory
  1805.  
  1806.  
  1807. as if you had just changed directories.
  1808.  
  1809. Now we get down to the meat of the matter: sending and receiving files.  Prior
  1810. to  doing  a  file transfer you need to tell FTP what type of transfer to use.
  1811. You have two choices: ASCII (text files) or Image (binary files).   To  select
  1812. what type of transfer to do you use the
  1813.  
  1814.         type i
  1815.         type a
  1816.  
  1817.  
  1818. The former will set all subsequent transfers to image mode for sending  binary
  1819. files.  The latter will set all subsequent transfers to ASCII mode for sending
  1820. or receiving text files.  If you use the 'type' command by itself like:
  1821.  
  1822.         type
  1823.  
  1824.  
  1825. FTP will respond with  either  the  word  "Image"  or  "Ascii,"  whichever  is
  1826. appropriate.   If  you  do  not  specify  a  type of transfer FTP will use the
  1827. default value "ASCII."
  1828.  
  1829. Files transferred with type set to ASCII  will  have  their  newline  sequence
  1830. translated  to  that expected by the remote host.  Files transferred with type
  1831. set to image will have no translation performed at all.  All bytes in the file
  1832. will be transferred with no changes whatsoever.
  1833.  
  1834.  
  1835.  
  1836.  
  1837.  
  1838.  
  1839.  
  1840.  
  1841.  
  1842.                                     - 29 -
  1843.  
  1844.  
  1845. Once you select the type of transfer you desire you may then send  or  receive
  1846. files.   The  'put'  and  'get'  commands  are  used to send and receive files
  1847. respectively.  Let us assume that I have a file on my  system  in  my  current
  1848. directory  called  "foo" and I want to transfer it to the remote host and have
  1849. it placed in my current directory there.  To do this I would use the following
  1850. command:
  1851.  
  1852.         put foo
  1853.  
  1854.  
  1855. FTP would then transfer file "foo" from the local to the  remote  system.  You
  1856. would know the status of the transfer from the following sequence of messages:
  1857.  
  1858.         200 Port command okay
  1859.         150 Opening data connection for STOR foo
  1860.         Put complete, nnn bytes sent
  1861.         226 File received OK
  1862.  
  1863.  
  1864. Now let us fetch file "bar" from the remote system.  Here is your command  the
  1865. the responses from FTP:
  1866.  
  1867.         get bar
  1868.         200 Port command okay
  1869.         150 Opening data connection for RETR bar
  1870.         Get complete, nnn bytes received
  1871.         226 File sent OK
  1872.  
  1873.  
  1874. Now it may not be convenient to have the file retain its file name when it  is
  1875. copied.  Perhaps there is already a file with the same name at the destination
  1876. and you do not wish to, or may not be permitted to, overwrite  the  file.   In
  1877. that  case  you would add the destination file name to the get or the put com-
  1878. mand as follows:
  1879.  
  1880.         put foo bar
  1881.         get /public/tcp/herfile herfile
  1882.  
  1883.  
  1884. In the first example the local file "foo" would be copied to file "bar" on the
  1885. remote  system.  In the second example the file "/public/tcp/herfile" would be
  1886. copied to "herfile" on the remote system.  The reason for doing it this way in
  1887. the   second   example  is  to  avoid  having  FTP  try  to  create  the  file
  1888. "/public/tcp/herfile" on the remote end.  Perhaps there is no directory "/pub-
  1889. lic"  or "/public/tcp" or perhaps you are in an FTP session with a system that
  1890. has completely different file naming conventions (remember  that  you  may  be
  1891. communicating with systems other than PC's).
  1892.  
  1893. It is also possible to get a file and type it to your CRT  directly.   If  you
  1894. want  to  get the file to your screen use "con" as the name of the destination
  1895. file.  Here is an example that will fetch file "foo" and send it to the CRT:
  1896.  
  1897.         get foo con
  1898.  
  1899.  
  1900.  
  1901.  
  1902.  
  1903.  
  1904.  
  1905.  
  1906.  
  1907.  
  1908.                                     - 30 -
  1909.  
  1910.  
  1911. You may at some point want to terminate a transfer that is currently  in  pro-
  1912. gress.   The 'abort' command is used for this.  There are no parameters on the
  1913. abort command.  Just type 'abort' and the current transfer will be aborted.
  1914.  
  1915. The last command of interest to FTP users is the dele command.  The dele  com-
  1916. mand  is  used to delete a file on the remote system.  Here is an example that
  1917. will delete the file foo on the remote system:
  1918.  
  1919.         dele foo
  1920.  
  1921.  
  1922. Remember that in order to use the  dele  command  you  must  have  delete  and
  1923. overwrite permission on the remote system.
  1924.  
  1925. When done using FTP use the command 'quit.'  'Quit' will get you the following
  1926. message sequence:
  1927.  
  1928.         221 Goodbye!
  1929.         Close wait
  1930.         Last ACK
  1931.         Closed (Normal)
  1932.  
  1933.  
  1934. All of this indicates  that  FTP  has  properly  terminated  the  session  and
  1935. returned  you  to  the command interpreter.  Alternatively, you can just close
  1936. the session by hitting F10 and typing "close".
  1937.  
  1938. 3.3.5.  Multiple Sessions:
  1939.  
  1940. One of the many advantages of NET is that it permits you to establish  several
  1941. sessions  concurrently.  For instance, you could establish an FTP session with
  1942. a host and then switch back to the command interpreter so that you could start
  1943. another  session.   The  nice thing about this is that it in no way interferes
  1944. with any sessions that are already running.  Your  FTP  session  continues  to
  1945. transfer  data  even  while you enter into a TELNET session with the same or a
  1946. different host.  Any screen output that arrives for a session that is not  the
  1947. currently  selected  session will be held until you again select that session.
  1948. This prevents you from losing any output while you interact with another  ses-
  1949. sion or with the command interpreter.
  1950.  
  1951. As mentioned, in order to start a new session (or issue any other type of com-
  1952. mand  for  that  matter) you must be interacting with the command interpreter.
  1953. To get to the command prompt you need only press  F10.  Once  at  the  command
  1954. prompt  you  can  examine  or select a new session using the 'session' command
  1955. (abbreviated 'se').
  1956.  
  1957. The session command when used by itself will  give  you  a  list  of  all  the
  1958. currently open session.  Here are two examples:
  1959.  
  1960.         session
  1961.         se
  1962.  
  1963.  
  1964. The result will be a display similar to the following:
  1965.  
  1966.  
  1967.  
  1968.  
  1969.  
  1970.  
  1971.  
  1972.  
  1973.  
  1974.                                     - 31 -
  1975.  
  1976.  
  1977.  
  1978.          #  &CB  Type    Rcv-Q  State        Remote socket
  1979.          0  c7a8 Telnet      0  Established  w3fws:23
  1980.         *1  c434 FTP         0  Established  44.96.0.13:21
  1981.  
  1982.  
  1983. The first field (#) is the session number.  The asterisk  (*)  identifies  the
  1984. current  session.   CB is the protocol control block associated with this ses-
  1985. sion (these are explained in detail as part of the tcp status and ax25  status
  1986. commands later in this document).  The Type field identifies the session as an
  1987. FTP, a TELNET, or an AX.25 connected mode  (TNC)  session.   The  state  field
  1988. indicates  the  state of the "connection" as far as this session is concerned.
  1989. A value of SYN Sent indicates that the "connection" is in the process of being
  1990. constructed.   A  value  of  Established  indicates  that the "connection" and
  1991. therefore the session is open and ready to transfer  information.   Values  of
  1992. FIN  Wait  1,  FIN  Wait 2, or Time Wait indicate that the connection is being
  1993. closed.  The last field, Remote Socket, identifies the host and port with whom
  1994. the session was initiated.
  1995.  
  1996. Once you start a session it becomes your current session unless you  close  it
  1997. or switch to another session.  To get back to a session from the 'net>' prompt
  1998. all you need to do is press the <RETURN> or <ENTER> key.  If you  happened  to
  1999. close  the  current  session  there  will be no current session.  In that case
  2000. pressing <RETURN> or <ENTER> will have no effect.  You will need to explicitly
  2001. select a new session with the session command.
  2002.  
  2003. If you follow the session command with a number, the session command will make
  2004. the session whose number was specified, the current session and then turn con-
  2005. trol of the keyboard and screen over to that session.  Here are two examples:
  2006.  
  2007.         session 0
  2008.         se 0
  2009.  
  2010.  
  2011. Both of these examples change the current session to session 0.  At that point
  2012. you will be interacting with the desired session.
  2013.  
  2014. As mentioned in the section on the 'telnet' command you close a  session  with
  2015. the  close  command.  If the session you wish to close is not the current ses-
  2016. sion you need to issue the command 'close n' where n is the number of the ses-
  2017. sion you wish to close.
  2018.  
  2019. Last of all you may need to abort a session or an open socket.  This may occur
  2020. when you have a session with another host and that host goes away for whatever
  2021. reason (power failure, hardware failure, link failure, etc.).   In  that  case
  2022. you  must resort to the 'reset' command.  The without having to go through the
  2023. normal closing sequence.  There are two forms. The first  is  the  command  or
  2024. 'ax25  reset'  followed  by  the  address  of  TCP  or AX.25 control block, as
  2025. appropriate.  Here are several examples:
  2026.  
  2027.         tcp reset c7a8
  2028.         reset 0
  2029.  
  2030.  
  2031.  
  2032.  
  2033.  
  2034.  
  2035.  
  2036.  
  2037.  
  2038.  
  2039.  
  2040.                                     - 32 -
  2041.  
  2042.  
  2043. Either command would force TCP to close the socket associated with the session
  2044. with  44.96.0.13 and hence close that session.  It would give no indication to
  2045. the other end that the socket had been closed.  The only indication  that  the
  2046. other  end  would receive would be to receive a reset instead of an ACK packet
  2047. the next time the remote end sent a packet of data.
  2048.  
  2049. 3.3.6.  Status Monitoring and Other Commands:
  2050.  
  2051. There are quite a few commands in NET.EXE.  Many of  them  were  explained  in
  2052. conjunction  with  the installation instructions and, in fact, have little use
  2053. beyond initialization.  Commands in this category include:
  2054.  
  2055.         ip address------setting your IP address
  2056.         ax25 mycall-----setting your AX.25 link address
  2057.         ip ttl----------initial time-to-live field for IP packets
  2058.         attach----------starting a driver for a particular hardware device
  2059.         tcp mss---------setting the maximum size for a TCP segment (packet)
  2060.         tcp window------setting the maximum number of un-acked bytes
  2061.         ax25 digipeat---enable/disable AX.25 digipeating
  2062.         hostname--------set the name for your system (used by FTP)
  2063.  
  2064.  
  2065. On the other hand there are quite a few commands that you will be using exten-
  2066. sively.  Let's start by covering the status commands.
  2067.  
  2068. 3.3.6.1.  Getting Status Information:
  2069.  
  2070. 3.3.6.1.1.  ip status
  2071.  
  2072. The first of the status commands is 'ip status' and may be abbreviated  'ips'.
  2073. This  returns  information  about  the  status  of IP packets that have passed
  2074. through your system: e.g. originated, received, or passed through  (switched).
  2075. The format for the ip status response looks like this:
  2076.  
  2077.         total 973 runt 0 len err 0 vers err 0 chksum err 5 badproto 0
  2078.  
  2079.  
  2080. The 'total' field (973 in this case) identifies the  number  of  IP  datagrams
  2081. that  have passed through your system.  The next field, 'runt', identifies the
  2082. number of packets that were below minimum acceptable size.  'Len err'  identi-
  2083. fies  the number of packets with length errors.  'Vers err' identifies packets
  2084. that came from a system running a version of IP that is incompatible with  the
  2085. one  that  you are running (unlikely to occur unless the Internet adopts a new
  2086. standard for IP).  'Chksum err' is the number of packets that arrived  with  a
  2087. checksum  error  on the IP header (these packets will be discarded because the
  2088. system has no way of knowing if any of the information is valid).   'Badproto'
  2089. identifies the number of packets that arrived with the protocol identifier set
  2090. to an upper layer protocol (ULP) that is not either ICMP, TCP or UDP (the only
  2091. three ULP's currently supported in NET.EXE).
  2092.  
  2093. Of all these possible errors you are likely to see only the runt, len err, and
  2094. chksum  err  fields increment.  Version and bad protocol errors can only occur
  2095. if you are communicating with a system that supports a different version or  a
  2096. different set of ULP's.  This is unlikely to happen.
  2097.  
  2098.  
  2099.  
  2100.  
  2101.  
  2102.  
  2103.  
  2104.  
  2105.  
  2106.                                     - 33 -
  2107.  
  2108.  
  2109. 3.3.6.1.2.  tcp status
  2110.  
  2111. Another often used command is the tcp status command.  tcp  status  returns  a
  2112. great  deal  of  information  on the current status of your TCP "connections."
  2113. Upon entering the command 'tcp status' (abbreviated 't  s')  the  system  will
  2114. print  a  General status on the TCP activity and an abbreviated display on the
  2115. status of each TCP session.  The top line looks like this:
  2116.  
  2117.         Conout 5 Conin 17 Reset out 2 Runt 0 Checksum err 1 bdcsts 0
  2118.  
  2119.  
  2120. at your system while 'conin' is the number of incoming "connections" that have
  2121. been  made  with  your  system.  'Reset out' is the number of resets that were
  2122. sent to remote systems (this would happen if a remote system attempted to send
  2123. data  to  a  socket  that had been closed).  The 'Runt' field is the number of
  2124. undersized packets that were received.  The 'Checksum err' field is the number
  2125. of  TCP segments that were discarded because the segment failed the TCP check-
  2126. sum check (IP checksums only the packet header while TCP  applies  a  checksum
  2127. test  to  the  entire TCP segment including header).  The last field indicates
  2128. the number of broadcast messages that have been received.
  2129.  
  2130. Following the header line a table is presented,  one  line  per  socket.   The
  2131. headings appear as follows:
  2132.  
  2133.         &TCB  Rcv-Q  Snd-Q   Local Socket      Remote Socket   State
  2134.  
  2135.         f784    17      0    44.96.0.1:1001    44.96.0.2:23    Established
  2136.         eb30     0      0    44.96.0.1:23      0.0.0.0:0       Listen (S)
  2137.  
  2138.  
  2139. In the above example there are two open sockets.  The first,  associated  with
  2140. the TCP Control Block (TCB) at address f784, is a TELNET (terminal-to-terminal
  2141. or terminal-to-host) session with the system whose address is 44.96.0.2.   The
  2142. second  socket, described by the TCB at location eb30, is a passive ("server")
  2143. open that exists to  accept  incoming  TELNET  connections.  Now  for  a  more
  2144. comprehensive description of the fields.
  2145.  
  2146. The TCB is the TCP control block.  The number, in hex, is the address  of  the
  2147. TCB  in  memory and serves to identify a particular open socket.  Rcv-Q is the
  2148. number of octets (8-bit things that we normally call  bytes)  that  have  been
  2149. received  and are waiting to be processed (this is one way to tell if you have
  2150. received information from another station if you are involved in more than one
  2151. TELNET or FTP session).
  2152.  
  2153. The next two fields, Local Socket and Remote Socket, make up  the  identifica-
  2154. tion of the connection as far as TCP is concerned.  The first part of a socket
  2155. number is the IP address.  The second part of the socket number, the part fol-
  2156. lowing  the colon, is the port number.  There are many "standard" port numbers
  2157. in use.  Here are some of the more common:
  2158.  
  2159.  
  2160.  
  2161.  
  2162.  
  2163.  
  2164.  
  2165.  
  2166.  
  2167.  
  2168.  
  2169.  
  2170.  
  2171.  
  2172.                                     - 34 -
  2173.  
  2174.  
  2175.  
  2176.         Port    Application
  2177.  
  2178.          7     Echo server
  2179.          9     Discard server
  2180.         20     FTP server data port
  2181.         21     FTP server command port
  2182.         23     TELNET server
  2183.         25     SMTP server
  2184.  
  2185.  
  2186. You may see other port numbers used such as 1001, 1002, etc.  These  are  tem-
  2187. porary  ports that are used to form a unique connection (TCP identifies a con-
  2188. nection by combining the remote and local socket address in order to guarantee
  2189. uniqueness).
  2190.  
  2191. Since no two systems have the same network address the  combination  of  local
  2192. socket (address + port) and remote socket forms a unique combination.  This is
  2193. how the TCP on both ends of a "connection" identifies that connection.
  2194.  
  2195. It is possible to get even more information about a specific socket by  adding
  2196. the TCB address to the end of the tcp status command like this:
  2197.  
  2198.         tcb status f784
  2199.  
  2200.  
  2201. This will return the detailed TCP status information about the socket that  is
  2202. described by the TCB at address f784 (you get this address from the tcp status
  2203. command without a parameter).  Here is the sample format:
  2204.  
  2205. Local: 44.96.0.1:1001 Remote: 44.96.0.2:23 State: Established
  2206.       Init Seq   Unack     Next      WL1      WL2  Wind   MSS Queue   Total
  2207. Send:  328b740 328b741  328b741 dffde2e1  328b741   864   216     0       0
  2208. Recv: dffde2e0         dffde4e1                    1024           0     512
  2209. Retry 0 Timer stopped Smoothed round trip time  5500 ms
  2210.  
  2211.  
  2212. The 'Init Seq', 'Unack', 'Next', 'WL1', and 'WL2' fields have to do with TCP's
  2213. internal  flow control and sequence numbering mechanisms.  Continuous monitor-
  2214. ing of these fields gives you a good idea of the performance of the network in
  2215. terms  of  the  number  of packets lost.  The 'Wind' field shows the number of
  2216. bytes that the receiver is  ready  to  accept,  as  of  the  last  TCP  packet
  2217. received.   The  'effective  window' (the number of bytes that the transmitter
  2218. may send) is the 'Wind' value reduced by the number of bytes  "in  the  pipe",
  2219. that  is,  already sent but not yet acknowledged. This is found by subtracting
  2220. the 'Unack' value from the 'Next' value.
  2221.  
  2222. TCP often defers transmitting when it theoretically could, i.e., when there is
  2223. data  on  the  send  queue and a non-zero effective window.  This is done when
  2224. there is already data "in the pipe" but there is not enough new data to fill a
  2225. maximum  size  packet.   In this case, TCP waits for an acknowledgment for the
  2226. data already sent before sending more. This results in a stream of a few rela-
  2227. tively  large  packets instead of many small packets ("tinygrams"), for a con-
  2228. siderable efficiency improvement.
  2229.  
  2230.  
  2231.  
  2232.  
  2233.  
  2234.  
  2235.  
  2236.  
  2237.  
  2238.                                     - 35 -
  2239.  
  2240.  
  2241.      NOTE: A good understanding of sliding window protocols  is  required
  2242.      to  make use of the information presented in these particular fields
  2243.      and a complete explanation is beyond the  scope  of  this  document.
  2244.      See  RFC-793  or  MIL-1778  for more details on the specific sliding
  2245.      window algorithms  used  in  TCP,  and  RFC-896  for  the  "tinygram
  2246.      avoidance" transmission strategy.
  2247.  
  2248. The 'MSS' field displays the maximum segment size; the maximum number of bytes
  2249. that may be sent as a single TCP segment (packet).
  2250.  
  2251. Both the maximum window size and MSS are "negotiated" by the TCPs  running  in
  2252. the  two  communicating  system.   Essentially  this  means  that the two ends
  2253. "agree" on the best values to use for these parameters.  When you set a  value
  2254. for window size and a value for MSS in your machine, those values are communi-
  2255. cated to the remote end when a socket is opened.  That allows the  remote  end
  2256. to  know  how  much  information you are prepared to accept and to prevent the
  2257. remote end from sending you too much information.  Remember,  the  values  for
  2258. window  and  MSS that you set on your system will be the values that the other
  2259. station will use when sending to you.  Also remember that the two ends may set
  2260. different values and still work effectively.
  2261.  
  2262. As an aside, you are permitted to change the value of MSS or WINDOW while  the
  2263. net  program is running.  On the other hand, changing the value of MSS or WIN-
  2264. DOW after a socket has been opened will have no effect on any  currently  open
  2265. sockets.   Open sockets will continue to use the value for MSS that they nego-
  2266. tiated when the socket was opened.  The changed values will be used  when  TCP
  2267. opens a new socket.
  2268.  
  2269. The Queue field indicates how many bytes of data are waiting at  a  particular
  2270. socket.   In  the  case  of  the send queue this field indicates the number of
  2271. bytes transmitted but not yet acknowledged.  During SMTP and FTP  sessions  it
  2272. is not unusual to see this value equal to the window size.  In the case of the
  2273. receive queue the value indicates the number of bytes that have been  received
  2274. but have not been "picked-up" by the application.
  2275.  
  2276. The Total field indicates the number of  bytes  that  have  been  received  or
  2277. transmitted on a socket since the socket was opened.  This information is very
  2278. useful during an FTP session because it will tell  you  the  total  number  of
  2279. bytes transferred on the file (FTP opens a new data socket for every transfer,
  2280. closing the socket when the transfer is complete).  If you know  the  size  of
  2281. the  file  ahead of time you can use this information to determine how much of
  2282. the file has reached the receiving end -- nice information to know when  doing
  2283. a long file transfer over a slow or unreliable link.
  2284.  
  2285. The next field is the retry counter.  If a segment is not acknowledged  within
  2286. an  appropriate period TCP will retransmit that segment because it will assume
  2287. that the segment was lost somewhere in the network.  Each time it  retransmits
  2288. a  segment  the  'Retry'  counter  is incremented.  TCP never gives up sending
  2289. data.  It does 'back off' and send segments less and less frequently in  order
  2290. to reduce network loading.
  2291.  
  2292. The next field is the 'Timer' field.  It displays the status of the timer  for
  2293. this  particular  socket.  If TCP is waiting for an acknowledgement to an out-
  2294. standing segment there will be a time displayed in this field.  If  there  are
  2295.  
  2296.  
  2297.  
  2298.  
  2299.  
  2300.  
  2301.  
  2302.  
  2303.  
  2304.                                     - 36 -
  2305.  
  2306.  
  2307. no outstanding segments the word "stopped" will indicate that the timer is not
  2308. running.
  2309.  
  2310. The last field, 'round trip time', is a very interesting piece of information.
  2311. It is the amount of time that TCP has determined that it takes for an outgoing
  2312. segment to arrive at its destination and for its  acknowledgement  to  return.
  2313. This  value  is  used to determine the proper setting for the retry timer thus
  2314. allowing TCP to adapt to the changing conditions of the underlying network and
  2315. to prevent the network from being flooded by unnecessary retransmissions.
  2316.  
  2317. The tcp status command is probably the most-used command in the  net  program.
  2318. Don't  be afraid of it, use it!  You may not understand all the fields but you
  2319. will quickly pick up what is important and what  you  can  ignore.  Experiment
  2320. with  it so that you understand it better.  It is a key to pinpointing network
  2321. performance problems.
  2322.  
  2323. 3.3.6.2.  udp status
  2324.  
  2325. The next status command of interest is 'udp status,' used for  getting  status
  2326. information  about  information  that  has been received for the User Datagram
  2327. Protocol (UDP) ULP.  This command may be abbreviated 'u.' When an  application
  2328. makes  use of the UDP transport service it opens a UDP socket.  The udp status
  2329. command will display the status of the transport service and of  each  of  the
  2330. open sockets.  Here is an example of the output of a udp status command:
  2331.  
  2332.         sent 51 rcvd 50 bdcsts 0 cksum err 0 Unknown Socket 9
  2333.         &UCB  Rcv-Q  Local Socket
  2334.  
  2335.         ff38    293  44.96.0.1:3
  2336.  
  2337.  
  2338. In this example the 'sent' and 'rcvd' fields indicate how many  UDP  datagrams
  2339. have  been  sent and received respectively.  The 'bdcsts' field identifies the
  2340. number of broadcast datagrams that have been received.  The 'cksum err'  field
  2341. indicates  how  many  datagrams  have been received with errors while the that
  2342. were addressed to unknown (unopened) sockets.
  2343.  
  2344. Following the general information is the specific information about all of the
  2345. currently  open sockets.  Each open socket is identified by the address of its
  2346. UDP Control Block (&UCB).  Following that is the number  of  bytes  that  have
  2347. been  received and placed on the receive queue (Rcv-Q).  Last comes the actual
  2348. socket identifier consisting of the IP  address  concatenated  with  the  port
  2349. number.
  2350.  
  2351. 3.3.7.  AX.25 connected mode operation:
  2352.  
  2353. In addition to the TCP/IP mode of operation this new version  of  NET.EXE  now
  2354. supports  fully  connected  AX.25 (TNC-to-TNC) operation for talking to BBS'es
  2355. and your buddies without TCP/IP.  When NET.EXE is  running  you  are  free  to
  2356. establish  both  TCP and AX.25 sessions.  When you make an AX.25 connection it
  2357. will be treated like a TELNET session.  You can use  the  session  command  to
  2358. switch between sessions at will.  This prevents the output from one AX.25 ses-
  2359. sion from interfering with other sessions.  To make a connection you  use  the
  2360. connect  command  which  is very similar to the TNC's connect command with the
  2361.  
  2362.  
  2363.  
  2364.  
  2365.  
  2366.  
  2367.  
  2368.  
  2369.  
  2370.                                     - 37 -
  2371.  
  2372.  
  2373. exception of the addition of a channel identifier.  Here are some examples:
  2374.  
  2375.         connect ax1 wa3pxx
  2376.         connect ax2 n4qq k3af-10
  2377.  
  2378.  
  2379. The first command starts a connection to  wa3pxx  directly  over  the  channel
  2380. labeled  ax1  (see the attach command).  The second example establishes a con-
  2381. nection to n4qq via the k3af-10 digipeater on channel ax2.   To disconnect you
  2382. use either the disconnect command or the close command.
  2383.  
  2384. The other commands for AX.25 are very familiar to a user of a TNC.  Here is  a
  2385. list of commands and a brief description of their meanings:
  2386.  
  2387.         ax25 digipeat [on|off]          turn digipeating on or off
  2388.  
  2389.         ax25 maxframe [n]               set the maximum number of outstanding
  2390.                                         frames (packets) to n where n is between
  2391.                                         1 and 7 inclusive.
  2392.  
  2393.         ax25 mycall [<call>]            Set the call sign for AX.25 frames
  2394.  
  2395.         ax25 paclen [n]                 Set the maximum size of an AX.25 I-field
  2396.  
  2397.         ax25 status                     Display a status much like tcp status.
  2398.                                         If you follow it with an ACB address it
  2399.                                         will display detailed info about a
  2400.                                         particular connection.
  2401.  
  2402.         ax25 t1 [n]                     Displays or sets the value of the
  2403.                                         retransmission timer (FRACK).  The value
  2404.                                         is in seconds.
  2405.  
  2406.         ax25 t2 [n]                     Displays or sets the value of the
  2407.                                         ack delay timer (RESPTIME) in seconds.
  2408.  
  2409.         ax25 t3 [n]                     Displays or sets the value of
  2410.                                         "keep alive" timer (CHECK) in seconds.
  2411.  
  2412.         ax25 window [n]                 Displays or sets the number of bytes
  2413.                                         that may be on the AX.25 receive queue
  2414.                                         before the host begins sending RNR
  2415.                                         frames.
  2416.  
  2417.  
  2418. 3.4.  Using connected mode AX.25 for moving IP datagrams:
  2419.  
  2420. Since connected mode AX.25 is now supported these connections may be used  for
  2421. both  host-to-TNC (chatting with your TNC-only equipped buddy or with the BBS)
  2422. and for connected mode IP channels.  With IP you have your choice  of  "uncon-
  2423. nected"  or  "connected"  packets.  The command that controls this is the mode
  2424. command.  The mode command allows you to select which style of connection will
  2425. be used on a particular interface.  Here are two examples:
  2426.  
  2427.  
  2428.  
  2429.  
  2430.  
  2431.  
  2432.  
  2433.  
  2434.  
  2435.  
  2436.                                     - 38 -
  2437.  
  2438.  
  2439.  
  2440.         mode ax0 vc
  2441.         mode ax1 datagram
  2442.  
  2443.  
  2444. In the first example the interface named ax0 will use "connected" mode  AX.25.
  2445. This  can  improve  the link reliability and hence throughput when the link is
  2446. somewhat marginal.  The second example causes your IP datagrams to be sent  in
  2447. UI frames (unproto or beacon packets).  This is the mode of choice on reliable
  2448. links where very few packets are lost. It  reduces  overhead  so  packets  are
  2449. transferred more rapidly.
  2450.  
  2451. 3.5.  Tracing and Monitoring:
  2452.  
  2453. NET.EXE has the most comprehensive and informative  tracing  features  I  have
  2454. seen  in any software package for packet radio.  The trace function understand
  2455. AX.25, IP, TCP, and NET/ROM.
  2456.  
  2457. Tracing is enabled for each interface individually.  You have  the  choice  of
  2458. tracing incoming packets, outgoing packets, or both.  The format for the trace
  2459. command is:
  2460.  
  2461.         trace <interface> TIO
  2462.  
  2463.  
  2464. where <interface> is the name of the interface to be traced, T  is  the  trace
  2465. mode,  I  is  for incoming packets, and O is for outgoing packets. T, I, and O
  2466. are digits.  The following table gives the values for T and their meanings:
  2467.  
  2468.         0       Trace headers only.  Do not display the data.
  2469.  
  2470.         1       Trace headers and data.  Display the data as ASCII, 64
  2471.                 characters to a line.
  2472.  
  2473.         2       Trace headers and data.  Display the entire packet as Hex and
  2474.                 ASCII with 16 bytes displayed per line.
  2475.  
  2476.  
  2477. The values for I and O are either 1 or 0 depending on whether or not you  want
  2478. the  respective  incoming  or  outgoing  packets traced or not.  Here are some
  2479. examples:
  2480.  
  2481.         trace ax0 010
  2482.         trace ax1 111
  2483.         trace ax0 201
  2484.  
  2485.  
  2486. In the first example incoming packets on interface ax0 will  be  traced.  Only
  2487. the headers will be displayed.  The second example show both incoming and out-
  2488. going packets on ax1 being traced.  Data in the packets will be  displayed  as
  2489. 64  ASCII  characters  on a line.  The last example will display a hex dump of
  2490. all packets being transmitted on ax0.
  2491.  
  2492. I recommend using trace liberally.  You will learn a lot  about  packet  radio
  2493.  
  2494.  
  2495.  
  2496.  
  2497.  
  2498.  
  2499.  
  2500.  
  2501.  
  2502.                                     - 39 -
  2503.  
  2504.  
  2505. when  you can see what is being sent and to whom.  The trace display separates
  2506. the different headers at the different layers.  Trace will display  the  link,
  2507. network, and transport layer headers separately so you can see their relation-
  2508. ship.
  2509.  
  2510. 3.6.  Running NET and BM Concurrently
  2511.  
  2512. In order to get the greatest use out of NET it is important to have it running
  2513. all the time.  The problem with that is that DOS is not a multitasking operat-
  2514. ing system.  It is very frustrating to have to start and stop NET  every  time
  2515. you want to do something else.  There are solutions: DoubleDos and DesqView.
  2516.  
  2517. The DoubleDos and DesqView packages from SoftLogic  Solutions  and  Microsoft,
  2518. respectively,  solve  this  problem. They permit you to split your memory into
  2519. two partitions (or more, for DesqView) and allow each program to operate as if
  2520. it  had its own PC.  Phil Karn wrote NET with these "multitaskers" in mind and
  2521. even included the necessary code in NET so that it can effectively reside with
  2522. other  programs  without performance penalties to either NET or the other pro-
  2523. grams.  This will also allow you to send and receive mail with BM while NET is
  2524. still  running.   That  way  you will not have to exit from NET every time you
  2525. want to prepare a mail message or read mail that has arrived.
  2526.  
  2527. The first step in using NET with DoubleDOS is to install  DoubleDOS  according
  2528. to  the  instructions.   Part  of  installing  DoubleDOS is to modify the file
  2529. /DDCONFIG.SYS  for  your  environment.   Many  things  can   be   changed   in
  2530. DDCONFIG.SYS  but  two  are  important to NET: size and program to load in the
  2531. bottom partition.  When you edit DDCONFIG.SYS you  will  find  a  field  named
  2532. 'bottom  size'  and  a  field  named  'bottom program.'  If you want NET to be
  2533. started  automatically  when  you  start  DoubleDOS  enter  the  following  in
  2534. DDCONFIG.SYS:
  2535.  
  2536.         bottom program = /NET.EXE
  2537.  
  2538.  
  2539. DoubleDOS will normally split the available memory in half.  This is  not  the
  2540. best  solution  because we know how much memory NET needs and we can then make
  2541. sure that all of the rest of the available memory is available for  the  other
  2542. partition.   NET  itself needs about 150 Kb of memory.  In addition, NET needs
  2543. COMMAND.COM also loaded in its partition.  For this reason you  will  probably
  2544. want to allocate about 175 Kb to the bottom partition where NET will run.
  2545.  
  2546. Let us assume that you want to have both DoubleDOS and  NET  start  when  your
  2547. system  boots (just what you want after a power hit).  Add the following entry
  2548. to your AUTOEXEC.BAT file:
  2549.  
  2550.         /doubledos
  2551.  
  2552.  
  2553. That will cause DoubleDOS to start and DoubleDOS will automatically start NET.
  2554.  
  2555. 3.7.  Installation on a Commodore Amiga
  2556.  
  2557. < not written yet >
  2558.  
  2559.  
  2560.  
  2561.  
  2562.  
  2563.  
  2564.  
  2565.  
  2566.  
  2567.  
  2568.                                     - 40 -
  2569.  
  2570.  
  2571. 3.8.  Installation on an Apple Macintosh
  2572.  
  2573. < not written yet >
  2574.  
  2575. 3.9.  Installation under Unix
  2576.  
  2577. < not written yet >
  2578.  
  2579. 4.  Operational Reference
  2580.  
  2581. 4.1.  The NET.EXE Program
  2582.  
  2583. The executable file "net.exe" provides both client and server Internet facili-
  2584. ties.   It  implements  the  various ARPA protocols as both a host and gateway
  2585. (i.e., it acts as an end-user node as well as an IP packet switch for  transit
  2586. traffic).   The  keyboard and display is used by the local operator to control
  2587. both host and gateway level functions, for which a number of commands are pro-
  2588. vided.
  2589.  
  2590. 4.1.1.  Startup
  2591.  
  2592. When net.exe is executed without arguments,  it  attempts  to  open  the  file
  2593. "autoexec.net"  in  the root directory of the current drive.  If it exists, it
  2594. is read and executed as though its contents were typed on the console as  com-
  2595. mands.  This feature is useful for setting the local IP address and host name,
  2596. initializing the IP routing table, and starting the various Internet services.
  2597. If  net.exe  is  invoked  with  an  argument, it is taken to be the name of an
  2598. alternate startup file; it is read instead of autoexec.net.
  2599.  
  2600. 4.1.2.  Console mode
  2601.  
  2602. The console may be in one of two modes: command mode  and  converse  mode.  In
  2603. command mode, the prompt "net>" is displayed and any of the commands described
  2604. in the next section may be entered.  In converse mode, keyboard input is  pro-
  2605. cessed  according  to the "current session", which may be either a Telnet, FTP
  2606. or AX.25 connection.  In a telnet or AX.25 session, keyboard input is sent  to
  2607. the  remote  system  and any output from the remote system is displayed on the
  2608. console.  In an FTP session, keyboard input is first examined to see if it  is
  2609. a  known  local  command; if so it is executed locally.  If not, it is "passed
  2610. through" to the remote FTP server.   (See  the  section  titled  "FTP  Subcom-
  2611. mands").
  2612.  
  2613. The keyboard also has "cooked" and "raw" states.  In cooked  state,  input  is
  2614. line-at-a-time;  the user may use the line editing characters ^U, ^R and back-
  2615. space to erase the line, redisplay the line  and  erase  the  last  character,
  2616. respectively.   Hitting either return or line feed passes the complete line up
  2617. to the application.  In raw mode, each character is immediately passed to  the
  2618. application as it is typed.  The keyboard is always in cooked state in command
  2619. mode. It is also cooked in converse mode on an AX25 or FTP session.  In a Tel-
  2620. net session it depends on whether the remote end has issued (and the local end
  2621. has accepted) the Telnet "WILL ECHO" option.  (See the "echo" command).
  2622.  
  2623. On the IBM-PC, the user may escape back to command mode  by  hitting  the  F10
  2624. key.   On  other systems, the user must enter the "escape" character, which is
  2625.  
  2626.  
  2627.  
  2628.  
  2629.  
  2630.  
  2631.  
  2632.  
  2633.  
  2634.                                     - 41 -
  2635.  
  2636.  
  2637. by default control-] (hex 1d, ASCII GS). (Note that this is distinct from  the
  2638. ASCII  character  of  the same name). The escape character can be changed (see
  2639. the "escape" command).
  2640.  
  2641. 4.1.3.  Commands
  2642.  
  2643. This section describes each of the commands recognized while in command  mode.
  2644. Note  that  certain  FTP subcommands, e.g., put, get, dir, etc, are recognized
  2645. only in converse mode with the appropriate FTP session; they  are  not  recog-
  2646. nized  while in command mode.  The notation "<hostid>" denotes a host or gate-
  2647. way, which may be specified in one of two ways: as a symbolic name  listed  in
  2648. the  file  "/hosts.net", or as a numeric IP address in dotted decimal notation
  2649. enclosed by brackets, e.g., [44.0.0.1]. When domain server support  is  added,
  2650. ARPA-style  domain  names  (e.g., ka9q.ampr) will also be accepted if a domain
  2651. server is available on the network to resolve them into IP addresses.
  2652.  
  2653. 4.1.3.1.  <cr>
  2654.  
  2655. Entering a carriage return (empty line) while in command mode puts you in con-
  2656. verse  mode  with  the  current  session.  If there is no current session, net
  2657. remains in command mode.
  2658.  
  2659. 4.1.3.2.  !
  2660.  
  2661. An alias for the "shell" command.
  2662.  
  2663. 4.1.3.3.  #
  2664.  
  2665. Commands starting with the hash mark (#) are ignored. This  is  mainly  useful
  2666. for comments in the autoexec.net file.
  2667.  
  2668. 4.1.3.4.  arp
  2669.  
  2670. Displays the Address Resolution Protocol table that maps IP addresses to their
  2671. subnet  (link)  addresses on subnetworks capable of broadcasting.  For each IP
  2672. address entry the subnet type (e.g., Ethernet, AX.25), subnet address and time
  2673. to  expiration  is shown. If the link address is currently unknown, the number
  2674. of IP datagrams awaiting resolution is also shown.
  2675.  
  2676. 4.1.3.5.  attach <hw type> <I/O address>  <vector>  <mode>  <label>  <bufsize>
  2677. <mtu> [<speed>]
  2678.  
  2679. Configure and attach a hardware interface to the system.
  2680.  
  2681. a.  <hw type> represents the kind of I/O device that is being  attached.   The
  2682. following types are supported:
  2683.  
  2684. 3c500   3Com 3C500 or 3C501 Ethernet interface
  2685. asy     Standard PC asynchronous interface using the National 8250
  2686. hapn    Hamilton Amateur Packet Network adapter board (Intel 8273)
  2687. eagle   Eagle Computer card (Zilog 8530)
  2688. pc100   PACCOMM PC-100 (Zilog 8530)
  2689.  
  2690.  
  2691.  
  2692.  
  2693.  
  2694.  
  2695.  
  2696.  
  2697.  
  2698.  
  2699.  
  2700.                                     - 42 -
  2701.  
  2702.  
  2703. These last two interfaces are still under development; driver code included in
  2704. this package may or may not work.
  2705.  
  2706. B. <I/O address> is the base address of the control registers for the device.
  2707.  
  2708. C. <vector> is the interrupt vector number.  Both the address and  the  vector
  2709. must  be in hexadecimal. (You may put "0x" in front of these two values if you
  2710. wish, but note that they will be interpreted in hex even if you don't use it).
  2711.  
  2712. D.  <mode> controls how IP datagrams are to be encapsulated  in  the  device's
  2713. link level protocol; i.e., it selects among several link protocols that may be
  2714. available.  The choices here depend on the interface; at  present,  the  3c500
  2715. interface only supports mode "arpa", which uses standard ARPA-style encapsula-
  2716. tion.  (In the future, "802" may mean "use 802.3-style  encapsulation").   Two
  2717. modes for the "asy" device are currently supported:
  2718.  
  2719. slip    Encapsulates IP datagrams directly in SLIP frames without a link
  2720.         header. This is for operation on point-to-point lines and is compatible
  2721.         with 4.2BSD UNIX SLIP).
  2722.  
  2723. ax25    Similar to slip, except that an AX.25 header and a KISS TNC
  2724.         control header are added to the front of the datagram before SLIP
  2725.         encoding.  Either UI (connectionless) or I (connection-oriented) AX.25
  2726.         frames can be used; see the "mode" command for details.
  2727.  
  2728.  
  2729. The Address Resolution Protocol (ARP) maps IP to Ethernet addresses on  Ether-
  2730. net  controllers  and  to  AX.25  addresses on "asy" lines operating in "ax25"
  2731. mode.
  2732.  
  2733. E. <label> gives the name by which the interface will be known to the  various
  2734. commands, such as "connect", "route" and "trace".
  2735.  
  2736. F. For asynchronous ports, <bufsize> specifies the size of the ring buffer  in
  2737. bytes  to be statically allocated to the receiver; incoming bursts larger than
  2738. this may (but not necessarily) cause data to be lost.  For Ethernet, <bufsize>
  2739. specifies  how many PACKETS may be queued on the receive queue at one time; if
  2740. this limit is exceeded, further received packets will be discarded.   This  is
  2741. useful  to  prevent  the system from running out of memory should another node
  2742. suddenly develop a case of diarrhea.
  2743.  
  2744. G.  <mtu> is the Maximum Transmission Unit size, in bytes.   Datagrams  larger
  2745. than  this  limit  will be fragmented at the IP layer into smaller pieces. For
  2746. AX.25 UI frames, this limits the size of the information field.  For  AX.25  I
  2747. frames,  however, the ax25 paclen parameter is also relevant.  If the datagram
  2748. or fragment is still larger than paclen, it is also fragmented  at  the  AX.25
  2749. level  (as  opposed  to  the  IP  level)  before transmission.  (See the "ax25
  2750. paclen" command for further information).
  2751.  
  2752. H. <speed> is needed only for an "asy" line; the controller will  be  initial-
  2753. ized to the given speed.
  2754.  
  2755.  
  2756.  
  2757.  
  2758.  
  2759.  
  2760.  
  2761.  
  2762.  
  2763.  
  2764.  
  2765.  
  2766.                                     - 43 -
  2767.  
  2768.  
  2769.  
  2770. Examples:
  2771.  
  2772. # Attach a 3Com Ethernet controller using the standard 3Com address and
  2773. # vector (i.e., as it comes out of the box) to use ARPA-standard encapsulation.
  2774. # The receive queue is limited to 5 packets, and outgoing packets larger
  2775. # than 1500 bytes will be fragmented
  2776. attach 3c500 0x300 3 arpa ec0 5 1500
  2777.  
  2778. # Attach the PC asynch card normally known as "com1" (the first controller)
  2779. # to operate in point-to-point slip mode at 9600 baud, calling it "sl0".
  2780. # A 1024 byte receiver ring buffer is allocated. Outgoing packets larger
  2781. # than 256 bytes are fragmented.
  2782. attach asy 0x3f8 4 slip sl0 1024 256 9600
  2783.  
  2784. # Attach the secondary PC asynch card ("com2") to operate in AX.25 mode
  2785. # with an MTU of 576 bytes at 9600 baud with a KISS TNC, calling it "ax0".
  2786. # By default, IP datagrams are sent in UI frames
  2787. attach asy 0x2f8 3 ax25 ax0 1024 576 9600
  2788.  
  2789.  
  2790.  
  2791. (Note that you cannot use the second asynch controller  ("com2")  and  a  3Com
  2792. Ethernet  card with standard addressing at the same time because they both use
  2793. interrupt vector 3).
  2794.  
  2795. ax25 digipeat [on|off] Controls whether AX.25 packets addressed to  this  sta-
  2796. tion as a digipeater will be repeated.
  2797.  
  2798. ax25 maxframe [<val]>] Establishes the maximum number of frames that  will  be
  2799. allowed  to  remain  unacknowledged at one time on new AX.25 connections. This
  2800. number cannot be greater than 7.
  2801.  
  2802. ax25 mycall [<call>] Display or set the local  AX.25  address.   The  standard
  2803. format  is  used,  e.g., KA9Q-0 or WB6RQN-5. This command must be given before
  2804. any attach command using AX.25 mode are given.
  2805.  
  2806. ax25 paclen [<val>] Limits the size of  I-fields  on  new  AX.25  connections.
  2807. Note  that if IP datagrams or fragments larger than this are transmitted, they
  2808. will be transparently fragmented at the AX.25 level, sent as  a  series  of  I
  2809. frames,  and  reassembled  back into a complete IP datagram or fragment at the
  2810. other end of the link. This parameter should be less than the MTU of the asso-
  2811. ciated interface.
  2812.  
  2813. ax25 reset <axcb> Deletes the AX.25 connection control block at the  specified
  2814. address.
  2815.  
  2816. ax25 retry [<val>] Limits the number of successive unsuccessful retransmission
  2817. attempts  on  new  AX.25  connections.  If  this  limit  is exceeded, link re-
  2818. establishment is attempted. If this fails "retry" times, then  the  connection
  2819. is abandoned and all queued data is deleted.
  2820.  
  2821. ax25 status [<axcb>] Without an argument, displays a one-line summary of  each
  2822. AX.25  control  block.   If  the  address  of  a  particular  control block is
  2823.  
  2824.  
  2825.  
  2826.  
  2827.  
  2828.  
  2829.  
  2830.  
  2831.  
  2832.                                     - 44 -
  2833.  
  2834.  
  2835. specified, the contents of that control block are dumped in more detail.  Note
  2836. that the send queue units are frames, while the receive queue units are bytes.
  2837.  
  2838. ax25 t1 [<val>] ax25 t2 [<val>] ax25 t3  [<val>]  Display  or  set  the  AX.25
  2839. timers  to  be used for new connections. T1 is the retransmission timer, T2 is
  2840. the acknowledgement delay timer and T3 is the idle "keep alive" timer.  Values
  2841. are in seconds.
  2842.  
  2843. ax25 window [<val>] Sets the number of bytes that can be pending on  an  AX.25
  2844. receive  queue  beyond  which I frames will be answered with RNR (Receiver Not
  2845. Ready) responses.  This presently applies only to suspended interactive  AX.25
  2846. sessions, since incoming IP datagrams are always processed immediately and not
  2847. allowed to remain on the receive queue.
  2848.  
  2849. cd [<dirname>] Change the current working directory, and display the new  set-
  2850. ting.   Without  an argument, cd simply displays the current directory without
  2851. change.  The "pwd" command is an alias for "cd"
  2852.  
  2853. close [<session #>] On an AX.25 session, this command initiates a  disconnect.
  2854. On a FTP or Telnet session, this command sends a FIN (i.e., initiates a close)
  2855. on the session's TCP connection.  This is an alternative to asking the  remote
  2856. server  to  initiate a close ("QUIT" to FTP, or the logout command appropriate
  2857. for the remote system in the case of Telnet).  When either FTP or Telnet  sees
  2858. the  incoming  half  of  a  TCP connection close, it automatically responds by
  2859. closing the outgoing half of the connection.  Close is more graceful than  the
  2860. "reset"  command,  in  that  it  is  less  likely to leave the remote TCP in a
  2861. "half-open" state.
  2862.  
  2863. connect <interface> <callsign> [<digipeater> ... ] Initiates a "vanilla" AX.25
  2864. session  to  the  specified  call  sign using the specified interface. Up to 7
  2865. optional digipeaters may be given; note that the word  "via"  is  NOT  needed.
  2866. Data sent on this session goes out in conventional AX.25 packets with no upper
  2867. layer protocol.  The de-facto presentation standard format is  used,  in  that
  2868. each packet holds one line of text, terminated by a carriage return.  A single
  2869. AX.25 connection may be used for both  terminal-to-terminal  and  IP  traffic,
  2870. with  the two types of data being automatically separated by their AX.25 Level
  2871. 3 Protocol IDs.
  2872.  
  2873. dir [<dirname>] List the contents of the specified directory on  the  console.
  2874. If no argument is given, the current directory is listed.
  2875.  
  2876. disconnect [<session #>] An alias for the "close" command (for the benefit  of
  2877. AX.25 users).
  2878.  
  2879. echo [accept|refuse] Displays or changes the flag controlling client  Telnet's
  2880. response to a remote WILL ECHO offer.
  2881.  
  2882. The Telnet presentation protocol specifies that in the absence of a negotiated
  2883. agreement  to  the  contrary, neither end echoes data received from the other.
  2884. In this mode, a Telnet client session echoes keyboard input locally and  noth-
  2885. ing  is  actually sent until a carriage return is typed. Local line editing is
  2886. also performed: backspace deletes the last character  typed,  while  control-U
  2887. deletes the entire line.
  2888.  
  2889.  
  2890.  
  2891.  
  2892.  
  2893.  
  2894.  
  2895.  
  2896.  
  2897.  
  2898.                                     - 45 -
  2899.  
  2900.  
  2901. When communicating from keyboard to keyboard the standard local echo  mode  is
  2902. used,  so the setting of this parameter has no effect. However, many timeshar-
  2903. ing systems (e.g., UNIX) prefer to do their own echoing of typed input.  (This
  2904. makes screen editors work right, among other things). Such systems send a Tel-
  2905. net WILL ECHO offer immediately upon receiving an incoming  Telnet  connection
  2906. request. If "echo accept" is in effect, a client Telnet session will automati-
  2907. cally return a DO ECHO response. In this mode, local echoing  and  editing  is
  2908. turned  off  and  each  key  stroke  is sent immediately (subject to the Nagle
  2909. tinygram algorithm in TCP).  While this mode is just fine across an  Ethernet,
  2910. it  is  clearly  inefficient  and  painful across slow paths like packet radio
  2911. channels. Specifying "echo refuse" causes an incoming WILL ECHO  offer  to  be
  2912. answered with a DONT ECHO; the client Telnet session remains in the local echo
  2913. mode.  Sessions already in the remote echo mode are unaffected. (Note:  Berke-
  2914. ley  Unix has a bug in that it will still echo input even after the client has
  2915. refused the WILL ECHO offer. To get  around  this  problem,  enter  the  "stty
  2916. -echo" command to the shell once you have logged in.)
  2917.  
  2918. 4.1.3.6.  eol [unix|standard]
  2919.  
  2920. Displays or changes Telnet's end-of-line behavior when in  remote  echo  mode.
  2921. In  standard  mode, each key is sent as-is. In unix mode, carriage returns are
  2922. translated to line feeds.  This command is not necessary with  all  UNIX  sys-
  2923. tems;  use  it only  when  you  find that a particular system responds to line
  2924. feeds but not carriage returns.  Only Sun UNIX release 3.2  seems  to  exhibit
  2925. this behavior; later releases are fixed.
  2926.  
  2927. 4.1.3.7.  escape <char>
  2928.  
  2929. Without arguments, displays the current command-mode escape character in  hex.
  2930. If  given  an  argument, the first character becomes the new escape character.
  2931. (This command is not provided on the IBM-PC; on the PC,  the  escape  char  is
  2932. always F10.)
  2933.  
  2934. 4.1.3.8.  etherstat
  2935.  
  2936. Display 3-Com Ethernet controller statistics (if configured).
  2937.  
  2938. 4.1.3.9.  exit
  2939.  
  2940. Exit the "net" program and return to MS-DOS (or CP/M).
  2941.  
  2942. 4.1.3.10.  ftp <hostid>
  2943.  
  2944. Open an FTP control channel to the specified remote host  and  enter  converse
  2945. mode  on  the  new  session.   Responses  from the remote server are displayed
  2946. directly on the screen.
  2947.  
  2948. 4.1.3.11.  help
  2949.  
  2950. Display a brief summary of top-level commands.
  2951.  
  2952. 4.1.3.12.  hostname [<name>]
  2953.  
  2954. Displays or sets the local host's name (an ASCII string such as "ka9q-pc", NOT
  2955.  
  2956.  
  2957.  
  2958.  
  2959.  
  2960.  
  2961.  
  2962.  
  2963.  
  2964.                                     - 46 -
  2965.  
  2966.  
  2967. an IP address).  Currently this is used only in the greeting messages from the
  2968. SMTP (mail) and FTP (file transfer) servers.
  2969.  
  2970. 4.1.3.13.  log [stop | <file>]
  2971.  
  2972. Without arguments, indicates whether server  sessions  are  being  logged.  If
  2973. "stop" is given as the argument, logging is terminated (the servers themselves
  2974. are unaffected). If a file name is given as an argument,  server  session  log
  2975. entries will be appended to it.
  2976.  
  2977. 4.1.3.14.  ip address [<hostid>]
  2978.  
  2979. Displays or sets the local IP address.
  2980.  
  2981. 4.1.3.15.  ip status
  2982.  
  2983. Displays Internet Protocol (IP) statistics, such as total  packet  counts  and
  2984. error  counters of various types.  Also displays statistics about the Internet
  2985. Control Message Protocol (ICMP), including the number of ICMP messages of each
  2986. type sent or received.
  2987.  
  2988. 4.1.3.16.  ip ttl [<val>]
  2989.  
  2990. Displays or sets the default time-to-live value placed  in  each  outgoing  IP
  2991. datagram.  This  limits the number of switch hops the datagram will be allowed
  2992. to take. The idea is to bound the lifetime of  the  packet  should  it  become
  2993. caught  in a routing loop, so make the value somewhat larger than the diameter
  2994. of the network.
  2995.  
  2996. 4.1.3.17.  memstat
  2997.  
  2998. Displays the internal free memory list in the storage allocator.
  2999.  
  3000. 4.1.3.18.  mode <interface> [vc|datagram]
  3001.  
  3002. Controls the default transmission mode on the specified  AX.25  interface.  In
  3003. "datagram"  mode, IP packets are encapsulated in AX.25 UI frames and transmit-
  3004. ted without any other link level  mechanisms,  such  as  connections  or  ack-
  3005. nowledgements.
  3006.  
  3007. In "vc" (virtual circuit) mode, IP packets are encapsulated in AX.25 I  frames
  3008. and  are acknowledged at the link level according to the AX.25 protocol.  Link
  3009. level connections are opened if necessary.  With the  proper  setting  of  the
  3010. AX.25  T2  (acknowledgement  delay)  timer, AX.25 acknowledgements can be pig-
  3011. gybacked on I frames carrying other IP datagrams (e.g., TCP level acknowledge-
  3012. ments),  thereby  eliminating  the  extra overhead ordinarily incurred by link
  3013. level acknowledgments.
  3014.  
  3015. In both modes, ARP is used to map IP to AX.25 addresses.  The defaults can  be
  3016. overridden  with  the  type-of-service (TOS) bits in the IP header. Turning on
  3017. the "reliability" bit causes I frames to be used, while turning  on  the  "low
  3018. delay"  bit  uses UI frames.  (The effect of turning on both bits is undefined
  3019. and subject to change).
  3020.  
  3021.  
  3022.  
  3023.  
  3024.  
  3025.  
  3026.  
  3027.  
  3028.  
  3029.  
  3030.                                     - 47 -
  3031.  
  3032.  
  3033. In both modes, IP-level fragmentation is done if the datagram is  larger  than
  3034. the  interface  MTU.  In virtual circuit mode, however, the resulting datagram
  3035. (or fragments) is further fragmented at the AX.25 layer if it  (or  they)  are
  3036. still  larger  than  the  AX.25  "paclen"  parameter.  In AX.25 fragmentation,
  3037. datagrams are broken into several I frames and reassembled  at  the  receiving
  3038. end before being passed to IP. This is preferable to IP fragmentation whenever
  3039. possible because of decreased overhead (the IP header isn't repeated  in  each
  3040. fragment) and increased robustness (a lost fragment is immediately retransmit-
  3041. ted by the link layer).
  3042.  
  3043. 4.1.3.19.  param <interface> [param ...]
  3044.  
  3045. Param invokes a device-specific control routine.  On  a  KISS  TNC  interface,
  3046. this  sends  control  packets  to the TNC.  Data bytes are treated as decimal.
  3047. For example, "param ax0 1 255" will set the keyup timer (type field  =  1)  on
  3048. the  KISS  TNC  configured  as ax0 to 2.55 seconds (255 x .01 sec).  On a SLIP
  3049. interface, the param command allows the baud rate to be  read  (without  argu-
  3050. ments)  or  set.  The implementation of this command for the various interface
  3051. drivers is incomplete and subject to change.
  3052.  
  3053. 4.1.3.20.  pwd [<dirname>]
  3054.  
  3055. An alias for the cd command.
  3056.  
  3057. 4.1.3.21.  record [<filename>|off]
  3058.  
  3059. Opens <filename> and appends to it all data received on the  current  session.
  3060. Data sent on the current session is also written into the file except for Tel-
  3061. net sessions in remote echo mode.  The command "record  off"  stops  recording
  3062. and closes the file. This command is not supported for FTP sessions.
  3063.  
  3064. 4.1.3.22.  reset [<session>]
  3065.  
  3066. If an argument is given, force a local reset (deletion) of the AX.25 (AXCB) or
  3067. TCP  Control  Block  (TCB) belonging to the specified session. The argument is
  3068. first checked for validity.  If no argument is given, the current session,  if
  3069. any,  is  used.   This  command  should be used with caution since it does not
  3070. inform the remote end that the connection no longer exists.  (In TCP  a  reset
  3071. (RST)  message will be automatically generated should the remote TCP send any-
  3072. thing after a local reset has been done.  In AX.25 the DM message  performs  a
  3073. similar  role.   Both  are used to get rid of a lingering half-open connection
  3074. after a remote system has crashed.)
  3075.  
  3076. 4.1.3.23.  route
  3077.  
  3078. route  add  <dest   hostid>[/bits]|default   <interface>   [<gateway   hostid>
  3079. [<metric>]] route drop <dest hostid>
  3080.  
  3081. With no arguments, "route" displays the IP routing table. "route add" adds  an
  3082. entry  to  the  routing  table,  while "route drop" deletes an existing entry.
  3083. "route add" requires at least two more arguments, the host id  of  the  target
  3084. destination and the local name of the interface to which its packets should be
  3085. sent.  If the destination is not local, the gateway's host id should  also  be
  3086. specified.  (If  the interface is a point-to-point link, then <gateway hostid>
  3087.  
  3088.  
  3089.  
  3090.  
  3091.  
  3092.  
  3093.  
  3094.  
  3095.  
  3096.                                     - 48 -
  3097.  
  3098.  
  3099. may be omitted even if the target is non-local because this field is only used
  3100. to  determine the gateway's link level address, if any.  If the destination is
  3101. directly reachable, <gateway hostid> is also unnecessary since the destination
  3102. address is used to determine the interface link address).
  3103.  
  3104. The optional "/bits" suffix to the destination  host  id  specifies  how  many
  3105. leading  bits  in  the host id are to be considered significant in the routing
  3106. comparisons.  If not specified, 32 bits (i.e., full significance) is  assumed.
  3107. With  this  option,  a  single routing table entry may refer to many hosts all
  3108. sharing a common bit string prefix in their IP addresses.  For  example,  ARPA
  3109. Class  A, B and C networks would use suffixes of /8, /16 and /24 respectively;
  3110. the command
  3111.  
  3112.         route add [44]/8 sl0 [44.64.0.2]
  3113.  
  3114.  
  3115. causes any IP addresses beginning with "44" in the first 8 bits to  be  routed
  3116. to [44.64.0.2]; the remaining 24 bits are "don't-cares".
  3117.  
  3118. When an IP address to be routed matches more than one  entry  in  the  routing
  3119. table,  the  entry  with  largest "bits" parameter (i.e., the "best" match) is
  3120. used. This allows individual hosts or blocks of hosts to be  exceptions  to  a
  3121. more general rule for a larger block of hosts.
  3122.  
  3123. The special destination "default" is used to route datagrams to addresses  not
  3124. in  the  routing table; it is equivalent to specifying a /bits suffix of /0 to
  3125. any destination hostid.  Care must be taken with  default  entries  since  two
  3126. nodes  with  default entries pointing at each other will route packets to unk-
  3127. nown addresses back and forth in a loop until their time-to-live (TTL)  fields
  3128. expire.   (Routing  loops for specific addresses can also be created, but this
  3129. is less likely to occur accidentally).
  3130.  
  3131. "route drop" deletes an entry from the table. If  a  packet  arrives  for  the
  3132. deleted address and a default route is in effect, it will be used.
  3133.  
  3134. Here are some examples of using the route command:
  3135.  
  3136.         # Route datagrams to IP address 44.0.0.3 to SLIP line #0.
  3137.         # No gateway is needed because SLIP is point-to point.
  3138.         route add [44.0.0.3] sl0
  3139.  
  3140.         # Route all default traffic to the gateway on the local Ethernet
  3141.         # with IP address [44.0.0.1]
  3142.         route add default ec0 [44.0.0.1]
  3143.  
  3144.         # The local Ethernet has an ARPA Class-C address assignment;
  3145.         # route all IP addresses beginning with 192.4.8 to it
  3146.         route add [192.4.8]/24 ec0
  3147.  
  3148.         # The station with IP address [44.0.0.10] is on the local AX.25 channel
  3149.         route add [44.0.0.10] ax0
  3150.  
  3151.  
  3152.  
  3153.  
  3154.  
  3155.  
  3156.  
  3157.  
  3158.  
  3159.  
  3160.  
  3161.  
  3162.                                     - 49 -
  3163.  
  3164.  
  3165. 4.1.3.24.  session [<session #>]
  3166.  
  3167. Without arguments, displays the list of current  sessions,  including  session
  3168. number,  remote  TCP or AX.25 address and the address of the TCP or AX.25 con-
  3169. trol block.  An asterisk (*) is shown next to the "current" session;  entering
  3170. <cr>  at this point will put you in converse mode with that session.  Entering
  3171. a session number as an argument to the session command will put  you  in  con-
  3172. verse  mode  with  that session.  If the telnet server is enabled, the user is
  3173. notified of  an  incoming  request  and  a  session  number  is  automatically
  3174. assigned.   The user may then select the session normally to converse with the
  3175. remote user as though the session had been locally initiated.
  3176.  
  3177. 4.1.3.25.  shell
  3178.  
  3179. Suspends "net" and executes a sub shell ("command  processor"  under  MS-DOS).
  3180. When  the  sub  shell  exits, net resumes (under MS-DOS, enter the "exit" com-
  3181. mand). Note that background activity (FTP  servers,  etc)  is  also  suspended
  3182. while the subshell executes.
  3183.  
  3184. 4.1.3.26.  smtp gateway [<hostid>]
  3185.  
  3186. Displays or sets the host to be used as a "smart" mail relay. Any mail sent to
  3187. a  hostid  not  in the host table will instead be sent to the gateway for for-
  3188. warding.
  3189.  
  3190. 4.1.3.27.  smtp kick
  3191.  
  3192. Run through the outgoing mail queue and attempt to deliver any  pending  mail.
  3193. This  command is periodically invoked by a timer whenever net is running; this
  3194. command allows the user to "kick" the mail system manually.
  3195.  
  3196. 4.1.3.28.  smtp maxclients [<val>]
  3197.  
  3198. Displays or sets the maximum number of  simultaneous  outgoing  SMTP  sessions
  3199. that  will be allowed. The default is 10; reduce it if network congestion is a
  3200. problem.
  3201.  
  3202. 4.1.3.29.  smtp timer [<val>]
  3203.  
  3204. Displays or sets the interval, in seconds, between scans of the outbound  mail
  3205. queue. For example, "smtp timer 600" will cause the system to check for outgo-
  3206. ing mail every 10 minutes and attempt to deliver anything it finds, subject of
  3207. course to the "maxclients" limit. Setting a value of zero disables queue scan-
  3208. ning altogether, note that this is the default!  This value is recommended for
  3209. stand  alone  IP gateways that never handle mail, since it saves wear and tear
  3210. on the floppy disk drive.
  3211.  
  3212. 4.1.3.30.  smtp trace [<val>]
  3213.  
  3214. Displays or sets the trace flag in the SMTP  client,  allowing  you  to  watch
  3215. SMTP's  conversations  as it delivers mail.  Zero (the default) disables trac-
  3216. ing.
  3217.  
  3218.  
  3219.  
  3220.  
  3221.  
  3222.  
  3223.  
  3224.  
  3225.  
  3226.  
  3227.  
  3228.                                     - 50 -
  3229.  
  3230.  
  3231. 4.1.3.31.  start ftp|smtp|telnet|discard|echo
  3232.  
  3233. Starts the specified Internet server, allowing remote connection requests.
  3234.  
  3235. 4.1.3.32.  stop ftp|smtp|telnet|discard|echo
  3236.  
  3237. Stops the specified Internet server,  rejecting  any  further  remote  connect
  3238. requests. Existing connections are allow to complete normally.
  3239.  
  3240. 4.1.3.33.  tcp irtt [<val>]
  3241.  
  3242. Display or set the intial round trip time estimate, in seconds, to be used for
  3243. new TCP connections until they can measure and adapt to the actual value.  The
  3244. default is 5 seconds.  Increasing this when operating over slow channels  will
  3245. avoid the flurry of retransmissions that would otherwise occur as the smoothed
  3246. estimate settles down at the correct value. Note that this command  should  be
  3247. given  before  servers  are started in order for it to have effect on incoming
  3248. connections.
  3249.  
  3250. 4.1.3.34.  tcp kick <tcb_addr>
  3251.  
  3252. If there is data on the send queue of the specified tcb, this  command  forces
  3253. an immediate retransmission.
  3254.  
  3255. 4.1.3.35.  tcp mss [<size>]
  3256.  
  3257. Display or set the TCP Maximum Segment Size in bytes that will be sent on  all
  3258. outgoing  TCP  connect  request (SYN segments).  This tells the remote end the
  3259. size of the largest segment (packet) it may send. Changing  MSS  affects  only
  3260. future connections; existing connections are unaffected.
  3261.  
  3262. 4.1.3.36.  tcp reset <tcb_addr>
  3263.  
  3264. Deletes the TCP control block at the specified address.
  3265.  
  3266. 4.1.3.37.  tcp rtt <tcb_addr> <rttval>
  3267.  
  3268. Replaces the automatically computed round trip time in the specified tcb  with
  3269. the  rttval in milliseconds.  This command is useful to speed up recovery from
  3270. a series of lost packets since it provides a manual bypass around  the  normal
  3271. backoff retransmission timing mechanisms.
  3272.  
  3273. 4.1.3.38.  tcp status [<tcb_addr>]
  3274.  
  3275. Without arguments, displays several TCP-level statistics, plus  a  summary  of
  3276. all  existing  TCP  connections, including TCB address, send and receive queue
  3277. sizes, local and remote sockets, and connection state. If <tcb_addr> is speci-
  3278. fied,  a  more detailed dump of the specified TCB is generated, including send
  3279. and receive sequence numbers and timer information.
  3280.  
  3281. 4.1.3.39.  tcp window [<val>]
  3282.  
  3283. Displays or sets the default receive window size in bytes to be  used  by  TCP
  3284. when creating new connections. Existing connections are unaffected.
  3285.  
  3286.  
  3287.  
  3288.  
  3289.  
  3290.  
  3291.  
  3292.  
  3293.  
  3294.                                     - 51 -
  3295.  
  3296.  
  3297. 4.1.3.40.  telnet <hostid>
  3298.  
  3299. Creates a Telnet session to the specified host and enters converse mode.
  3300.  
  3301. 4.1.3.41.  trace [<interface> [<flags>]]
  3302.  
  3303. Controls packet tracing by the interface drivers. Specific bits enable tracing
  3304. of  the various interfaces and the amount of information produced.  Tracing is
  3305. controlled on a per-interface basis; without arguments, trace gives a list  of
  3306. all  defined  interfaces and their tracing status.  Output can be limited to a
  3307. single interface by specifying it, and the control  flags  can  be  change  by
  3308. specifying  them as well. The flags are given as a hexadecimal number which is
  3309. interpreted as follows:
  3310.  
  3311.         TIO
  3312.         |||--- Enable tracing of output packets if 1, disable if 0
  3313.         ||---- Enable tracing of input packets if 1, disable if 0
  3314.         |----- Controls type of tracing:
  3315.                 0 - Protocol headers are decoded, but data is not displayed
  3316.                 1 - Protocol headers are decoded, and data (but not the
  3317.                     headers themselves) are displayed as ASCII characters,
  3318.                     64 characters/line. Unprintable characters are displayed
  3319.                     as periods.
  3320.                 2 - Protocol headers are decoded, and the entire packet
  3321.                     (headers AND data) is also displayed in hexadecimal
  3322.                     and ASCII, 16 characters per line.
  3323.  
  3324.  
  3325. 4.1.3.42.  udp status
  3326.  
  3327. Displays the status of all UDP receive queues.
  3328.  
  3329. 4.1.3.43.  upload [<filename>]
  3330.  
  3331. Opens <filename> and sends it on the current session as though it  were  typed
  3332. on the terminal. Valid only on AX.25 and Telnet sessions.
  3333.  
  3334. 4.1.3.44.  ?
  3335.  
  3336. Same as the "help" command.
  3337.  
  3338. 4.1.4.  FTP Subcommands
  3339.  
  3340. When in converse mode with an FTP server, everything typed on the  console  is
  3341. first  examined  to  see if it is a locally-known command. If not, the line is
  3342. passed intact to the remote server on the control channel. If it is one of the
  3343. following commands, however, it is executed locally. (Note that this generally
  3344. involves other commands being sent to the remote server on the  control  chan-
  3345. nel.)   When  actively  transferring  a  file,  the only acceptable command is
  3346. "abort"; all other commands will result in an error message.
  3347.  
  3348. 4.1.4.1.  abort
  3349.  
  3350. Aborts a get, put or dir operation in progress. When receiving a  file,  abort
  3351.  
  3352.  
  3353.  
  3354.  
  3355.  
  3356.  
  3357.  
  3358.  
  3359.  
  3360.                                     - 52 -
  3361.  
  3362.  
  3363. simply resets the data connection; the next incoming data packet will generate
  3364. a TCP RST (reset) in response which will clear the remote server.  When  send-
  3365. ing a file, abort sends a premature end-of-file. Note that in both cases abort
  3366. will leave a partial copy of the file on the destination machine,  which  must
  3367. be  removed manually if it is unwanted. Abort is valid only when a transfer is
  3368. in progress.
  3369.  
  3370. 4.1.4.2.  dir [<file>|<directory> [<local file>]]
  3371.  
  3372. Without arguments, "dir" requests that a full directory listing of the  remote
  3373. server's current directory be sent to the terminal.  If one argument is given,
  3374. this is passed along in the LIST command; this can be a specific file or  sub-
  3375. directory  that  is meaningful to the remote file system. If two arguments are
  3376. given, the second is taken as the local file into which the directory  listing
  3377. should  be  put  (instead  of being sent to the console).  The PORT command is
  3378. used before the LIST command is sent.
  3379.  
  3380. 4.1.4.3.  get <remote file> [<local file>]
  3381.  
  3382. Asks the remote server to send the file specified in the first argument.   The
  3383. second  argument, if given, will be the name of the file on the local machine;
  3384. otherwise it will have the same name as on the remote machine.  The  PORT  and
  3385. RETR commands are sent on the control channel.
  3386.  
  3387. 4.1.4.4.  ls [<file>|<directory> [<local file>]]
  3388.  
  3389. ls is identical to the "dir" command except that the "NLST" command is sent to
  3390. the  server  instead  of  the  "LIST"  command. This results in an abbreviated
  3391. directory listing, i.e., one showing only the file  names  themselves  without
  3392. any other information.
  3393.  
  3394. 4.1.4.5.  mkdir <remote directory>
  3395.  
  3396. Creates a directory on the remote machine.
  3397.  
  3398. 4.1.4.6.  put <local file> [<remote file>]
  3399.  
  3400. Asks the remote server to accept data, creating the file named  in  the  first
  3401. argument.  The  second argument, if given, will be the name of the file on the
  3402. remote machine; otherwise it will have the same name as on the local  machine.
  3403. The PORT and STOR commands are sent on the control channel.
  3404.  
  3405. 4.1.4.7.  rmdir <remote directory>
  3406.  
  3407. Deletes a directory on the remote machine.
  3408.  
  3409. 4.1.4.8.  type [a | i | l <bytesize>]
  3410.  
  3411. Tells both the local client and remote server the type of file that is  to  be
  3412. transferred.  The default is 'a', which means ASCII (i.e., a text file).  Type
  3413. 'i' means "image", i.e., binary.  In ASCII mode, files  are  sent  as  varying
  3414. length  lines  of  text  in ASCII separated by cr/lf sequences; in IMAGE mode,
  3415. files are sent exactly as they appear in the file system.  ASCII  mode  should
  3416. be  used whenever transferring text between dissimilar systems (e.g., UNIX and
  3417.  
  3418.  
  3419.  
  3420.  
  3421.  
  3422.  
  3423.  
  3424.  
  3425.  
  3426.                                     - 53 -
  3427.  
  3428.  
  3429. MS-DOS) because of their different end-of-line and/or end-of-file conventions.
  3430. When exchanging text files between machines of the same type, either mode will
  3431. work but IMAGE mode may be somewhat faster.  Naturally,  when  exchanging  raw
  3432. binary  files (executables, compressed archives, etc) IMAGE mode must be used.
  3433. Type 'l' (logical byte size) is used when exchanging binary files with  remote
  3434. servers  having  oddball  word sizes (e.g., DECSYSTEM-10s and 20s). Locally it
  3435. works exactly like IMAGE, except that it notifies the remote system how  large
  3436. the  byte size is. <bytesize> is typically 8.  The type command sets the local
  3437. transfer mode and generates the TYPE command on the control channel.
  3438.  
  3439. 4.1.5.  FTP server configuration
  3440.  
  3441. Since MS-DOS was designed as a single-user operating system,  it  provides  no
  3442. access  control;  all files can be read, written or deleted by the local user.
  3443. It is usually undesirable to give such open access to a system to remote  net-
  3444. work  users.  The FTP server therefore provides its own access control mechan-
  3445. ism.
  3446.  
  3447. The file "/ftpusers" is used to control remote FTP access.  The default is  NO
  3448. access;  if  this  file  does  not  exist, the FTP server will be unusable.  A
  3449. remote user must first "log in" to the system with the USER and PASS commands,
  3450. giving  a  valid  name  and password listed in /ftpusers, before he or she can
  3451. transfer files.
  3452.  
  3453. Each entry in /ftpusers consists of a single line of the form
  3454.  
  3455.         username password /path permissions
  3456.  
  3457.  
  3458. There must be exactly four fields, and there must be exactly one space between
  3459. each  field.   Comments  may  be added after the last field. Comment lines are
  3460. begun with "#" in column one.
  3461.  
  3462. a. "username" is the user's login name.
  3463.  
  3464. b.  "password" is the required password.  Note  that  this  is  in  plaintext;
  3465. therefore  it  is  not a good idea to give general read permission to the root
  3466. directory.  A password of "*" (a single asterisk) means that any  password  is
  3467. acceptable.
  3468.  
  3469. c.  "/path" is the allowable prefix on accessible files.  Before any  file  or
  3470. directory  operation,  the current directory and the user- specified file name
  3471. are joined to form an absolute path name in "canonical"  form  (i.e.,  a  full
  3472. path  name  starting  at  the root, with "./" and "../" references, as well as
  3473. redundant /'s, recognized and removed). The result MUST begin with the  allow-
  3474. able  path  prefix;  if  not, the operation is denied.  NB! Under MS-DOS, this
  3475. field must use backslashes ("/"), NOT forward slashes ("/").  This field  must
  3476. always begin with a "/", i.e., at the root directory.
  3477.  
  3478. d.  "permissions" is a decimal number granting permission for read, create and
  3479. write  operations.   If the low order bit (0x1) is set, the user is allowed to
  3480. read a file subject to the path name prefix  restriction.   If  the  next  bit
  3481. (0x2)  is  set,  the  user  is  allowed  to  create  a new file if it does not
  3482. overwrite an existing file.  If the third  bit  (0x4)  is  set,  the  user  is
  3483.  
  3484.  
  3485.  
  3486.  
  3487.  
  3488.  
  3489.  
  3490.  
  3491.  
  3492.                                     - 54 -
  3493.  
  3494.  
  3495. allowed  to  write a file even if it overwrites an existing file, and in addi-
  3496. tion he may delete files.  Again, all operations are allowed  subject  to  the
  3497. path name prefix restrictions. Permissions may be combined by adding bits, for
  3498. example, 0x3 (= 0x2 + 0x1) means that the user is given read and  create  per-
  3499. mission, but not overwrite/delete permission.
  3500.  
  3501. For example, suppose /ftpusers on machine "pc.ka9q.ampr" contains the line
  3502.  
  3503.         friendly test /testdir 7
  3504.  
  3505.  
  3506. A session using this account would look like this:
  3507.  
  3508.         net> ftp pc.ka9q.ampr
  3509.         SYN Sent
  3510.         Established
  3511.         250 pc.ka9q.ampr FTP version 871225.5 ready at Wed Jan 20 16:27:18 1988
  3512.         user friendly
  3513.         331 Enter PASS command
  3514.         pass test
  3515.         230 Logged in
  3516.  
  3517.  
  3518. The user now has read, write, overwrite and delete  privileges  for  any  file
  3519. under /testdir; he may not access any other files.
  3520.  
  3521. Here are some more sample entries in /ftpusers:
  3522.  
  3523.  
  3524.         karn foobar / 7         # User "karn" with password "foobar" may read,
  3525.                                 # write, overwrite and delete any file on the
  3526.                                 # system.
  3527.  
  3528.         guest bletch /g/bogus 3 # User "guest" with password "bletch" may read
  3529.                                 # any file under /g/bogus and its subdirectories,
  3530.                                 # and may create a new file as long as it does
  3531.                                 # not overwrite an existing file. He may NOT
  3532.                                 # delete any files.
  3533.  
  3534.         anonymous * /public 1   # User "anonymous" (any password) may read files
  3535.                                 # under /public and its subdirectories; he may
  3536.                                 # not create, overwrite or delete any files.
  3537.  
  3538.  
  3539. I recommend this last entry as a standard convention for keeping a  repository
  3540. of  downloadable  files;  in  particular, the username "anonymous" is an esta-
  3541. blished ARPA convention.
  3542.  
  3543. 4.2.  The BM.EXE Mail User Interface Program
  3544.  
  3545. Many thanks to Gerard PA0GRI who is primarily responsible for the addition  of
  3546. features  to  version  2,  and  to Dave Trulli NN2Z who is responsible for the
  3547. changes and additions making up version 3.
  3548.  
  3549.  
  3550.  
  3551.  
  3552.  
  3553.  
  3554.  
  3555.  
  3556.  
  3557.  
  3558.                                     - 55 -
  3559.  
  3560.  
  3561. 4.2.1.  Configuring the SMTP Environment
  3562.  
  3563. As supplied, the SMTP server and client make assumptions about the disk  space
  3564. available to them.  In particular, the file handling portion of the client and
  3565. server will need to be modified heavily if used on any operating system  other
  3566. than PC-Dos or MS-Dos.  Sorry.
  3567.  
  3568. To achieve minimum functionality, you should  create  directories  /spool/mail
  3569. and  /spool/mqueue  on  the default disk used when running net.exe... the mail
  3570. directory is used by the server for storing incoming mail, the  mqueue  direc-
  3571. tory  is  where  the  client  looks  to find outbound messages that need to be
  3572. delivered.
  3573.  
  3574. There is one command in net.exe that relates to the SMTP client operation.  It
  3575. is  'smtp'.   Issuing this command will cause the client to attempt to deliver
  3576. mail immediately.  Normally, the client will fire up 15mins after the  end  of
  3577. the previous invocation to try and process outbound mail.  The smtp command is
  3578. primarily a debugging tool, and should be used as such.
  3579.  
  3580. 4.2.1.1.  File Formats
  3581.  
  3582. Incoming mail for users on the current host gets placed in 'mailbox' files  in
  3583. the  /spool/mail  directory.   The  name of the file is based on the user name
  3584. given by the sending SMTP agent.  These are simple text files, with  new  mes-
  3585. sages  appended to the end.  If a mailbox file does not exist, the server will
  3586. create it automagically.  Messages in the files are in RFC822 format, with new
  3587. messages  appended  to  the  end.   The first line of each message will always
  3588. start with the token 'Received:', quotes not included.  This line is added  by
  3589. the  server  to  indicate  the date and time the message was received, and the
  3590. host it was received from.
  3591.  
  3592. Outgoing mail messages consist of two files each in the  /spool/mqueue  direc-
  3593. tory.   The  names  of  the  two  files  will be of the form <integer>.WRK and
  3594. <integer>.TXT, where integer is the sequence number of the message relative to
  3595. this  machine.   The  file  sequence.seq  in the mqueue directory contains the
  3596. current sequence number for reference by the mail user  interface.   The  .TXT
  3597. file contains the data portion of the SMTP transaction, in full RFC822 format.
  3598. The .WRK file consists of 3 lines, as follows:
  3599.  
  3600. o+    the hostname of the destination system
  3601.  
  3602. o+    the full sender address, in user@host format.
  3603.  
  3604. o+    the full destination address, in user@host format.
  3605.  
  3606. The mailer does not yet support multiple recipients; when it  does,  the  .wrk
  3607. file  format  will contain extra destination address lines, one for each addi-
  3608. tional recipient.
  3609.  
  3610. 4.2.1.2.  Bugs and Limitations:
  3611.  
  3612. The SMTP server does not allow forwarding.  In a perfect world, forwarding  is
  3613. a  crock.   Since  we do not live in a perfect world, some specialized forward
  3614. capability will probably be added eventually... though we'd like to avoid  it!
  3615.  
  3616.  
  3617.  
  3618.  
  3619.  
  3620.  
  3621.  
  3622.  
  3623.  
  3624.                                     - 56 -
  3625.  
  3626.  
  3627. Better  to  just  put  a  bsd4.X system on the air and let Sendmail handle the
  3628. grody work!  :-)
  3629.  
  3630. The SMTP client only understands a single destination address in the TO  line.
  3631. This  is  a  legal minimal implementation of the standard, but will eventually
  3632. change.  Note that the format of the .WRK file will change when this does,  of
  3633. necessity.
  3634.  
  3635. Error returns from the remote server are not properly handled. The mailer will
  3636. keep  trying  to  deliver  the  mail  each time the smtp command is issued (or
  3637. invoked automatically by the timer).  There is as yet no mechanism for "bounc-
  3638. ing" mail back to the sender when it cannot be sent.
  3639.  
  3640. The smtp client (mail sender) code in net.exe now tries to connect to all des-
  3641. tination  hosts  simultaneously.  If  there  is  a lot of mail in the outbound
  3642. queue, this may cause problems. In particular, try using the FILES=  parameter
  3643. in the MS-DOS config.sys file to allow net.exe to have more than the default 8
  3644. files open at once.
  3645.  
  3646. 4.2.1.3.  For More Information
  3647.  
  3648. The SMTP specification is RFC821.  The Format for text messages (including the
  3649. headers) is in RFC822.  RFC819 discusses hostname naming conventions, particu-
  3650. larly domain naming.
  3651.  
  3652. 4.2.2.  BM Setup
  3653.  
  3654. In order to make use of BM, you must first follow  the  installation  instruc-
  3655. tions in the file SMTP.DOC to provide minimal SMTP support.  Then, you should:
  3656.  
  3657. o+    copy the files BM.RC and HOSTS.NET to the root directory of  the  default
  3658.      drive used when NET.EXE is running.
  3659.  
  3660. o+    edit HOSTS.NET to reflect the hosts you will  exchange  mail  with.   the
  3661.      format of each line of this file is:
  3662.  
  3663.              IP_address <tab> hostname <newline>
  3664.  
  3665.      The IP address should be of the form 0.0.0.0, and the hostname can be any
  3666.      token you wish to use to represent that host.  In particular, it does NOT
  3667.      need to be the full legal name of the host.
  3668.  
  3669. o+    edit the file /BM.RC to correctly identify your hostname,  username,  and
  3670.      the IP address of the system you wish to punt mail to when you don't know
  3671.      the correct IP address.  The format lines in this file is:
  3672.  
  3673.              token <space> value <newline>
  3674.  
  3675.      where the currently defined tokens are 'host' for this system's hostname,
  3676.      'user'  for  your  username, and 'gate' for the ip address of the nearest
  3677.      'smart mailer'.  More on this below.  Additional tokens exist for setting
  3678.      your local timezone, and mailbox directory, and editor to be used in mes-
  3679.      sage creation.
  3680.  
  3681.  
  3682.  
  3683.  
  3684.  
  3685.  
  3686.  
  3687.  
  3688.  
  3689.  
  3690.                                     - 57 -
  3691.  
  3692.  
  3693. 4.2.3.  Operation
  3694.  
  3695. BM is designed to serve as the mail  user-interface  for  users  of  the  KA9Q
  3696. internetworking  software package.  The purpose of BM is to provide a full set
  3697. of electronic mail services to the  user.   These  include  sending  messages,
  3698. listing and reading received messages, and so forth.
  3699.  
  3700. BM reads mailbox files created by the SMTP server in NET.EXE, which are stored
  3701. in  a  directory  (usually  /spool/mail)  that is specified in the config file
  3702. /bm.rc.  Incoming mail is stored by the server in mailbox files, one per user-
  3703. name.   These  mailbox  files  may  also  be  referred to as "notefiles".  The
  3704. default mailbox to read is specified with the  'user'  option  in  the  /bm.rc
  3705. file.  This username is also used on all outgoing messages.
  3706.  
  3707. The /bm.rc file also defines a timezone stamp, which in conjunction  with  the
  3708. DOS date and time is used to provide the required RFC822 Date: header.
  3709.  
  3710. Commands are generally one character long and followed by a space, and parame-
  3711. ter if needed:
  3712.  
  3713. s  Send a message.  The user is prompted for a destination  address  and  sub-
  3714.    ject.   BM then creates appropriate RFC822 headers in a temporary file, and
  3715.    either invokes the user's favorite editor (specified with the 'edit' param-
  3716.    eter  in  /bm.rc)  to  enter the message text, or uses a simple/stupid text
  3717.    entry routine if no editor is defined.  Note that if you are using an  edi-
  3718.    tor,  you  should start by jumping to the end of the file.  RFC822 requires
  3719.    that the headers be first and be separated from the text of a message by at
  3720.    least one blank line.
  3721.  
  3722.    In this release, Phil KA9Q has modified BM slightly to  be  more  like  the
  3723.    Berkeley  Unix  mail program.  When the message entry routine first starts,
  3724.    you will be in the silly text editor.  If you want to use  your  editor  on
  3725.    the  message, type '~e<ret>'... not obvious to most folks, but very obvious
  3726.    to 4bsd fans... [sigh].
  3727.  
  3728. t  Transmits an already  created  file  as  a  message.   RFC822  headers  are
  3729.    prepended.   This is useful if you don't have an editor that will work with
  3730.    the 's' command.
  3731.  
  3732.    *** NOTE ***  RFC822 only allows 7bit data.  If you want to send a
  3733.                  binary file, use BSQ, or UUENCODE, or something similar
  3734.             to convert  it  to  a  text  file  first!   Better  yet,  use
  3735.    FTP...
  3736.  
  3737. r  Read all messages in the current notefile.
  3738.  
  3739. u  Updates you with new messages in  the  notefile,  shows  them  to  you  and
  3740.    updates  the  read  marker to the last one read.  If no new mes- sages came
  3741.    in, you will be notified.
  3742.  
  3743. f  Forward a message to someone else.  A temporary copy is made of the message
  3744.    specified and that is handed over to the send message routine, which treats
  3745.    it as a file ala the 't' command.
  3746.  
  3747.  
  3748.  
  3749.  
  3750.  
  3751.  
  3752.  
  3753.  
  3754.  
  3755.  
  3756.                                     - 58 -
  3757.  
  3758.  
  3759. d  Delete a message.  Parameter is the message number.  If the number  of  the
  3760.    to  be  deleted  message  is  higher than the last read message an "are you
  3761.    sure" message is printed. 'Y' or 'y' will delete it...
  3762.  
  3763. h  Displays message headers, a message number, received date,  from  whom  and
  3764.    the  subject fields on an single line.  An star is put in front of the last
  3765.    read message.
  3766.  
  3767. p   Sets the printer on or off so messages  to  the  screen  also  go  to  the
  3768.    printer.  ** This will be implemented in a future release. **
  3769.  
  3770. l  Lists the file names of messages waiting to be sent that are in  the  queue
  3771.    directory, usually /spool/mqueue.  Primarily useful for debugging.
  3772.  
  3773. n  Shows the notefiles in the mail directory, the location of which is  speci-
  3774.    fied  by  the 'smtp' parameter in the /bm.rc file.  If this command is fol-
  3775.    lowed with a parameter, the current notefile will be changed to the  speci-
  3776.    fied  notefile.  If it does not exist you will be notified if you try some-
  3777.    thing with it.
  3778.  
  3779. #  Substitute # with a number (1..whatever) and it will show you  the  message
  3780.    in  the current active notefile with that number. If the message is the one
  3781.    next to the last read one the * will be moved.
  3782.  
  3783. ?  Prints a short command summary to the screen.
  3784.  
  3785. q  Quit.
  3786.  
  3787. The program's prompt will always show the current notefile name.
  3788.  
  3789. 4.2.4.  Additional Information
  3790.  
  3791. BM will prompt you for a To: address.  This should be in the  form  user@host,
  3792. where  user  will be the name of the mailbox file on the destination KA9Q sys-
  3793. tem, or the username of the intended recipient on other SMTP-equipped systems.
  3794. The host field should exactly match a host token in the HOSTS.NET file.  If it
  3795. does not, the SMTP client in NET.EXE will insert the IP address of the nearest
  3796. "smart  mail  agent"  in  the  work file instead of the destination IP address
  3797. (since it is unknown).  The rationale behind this is that many  SMTP  equipped
  3798. systems include the ability to forward mail that is not addressed to them.  If
  3799. you have a system of this type nearby, you may be able to "punt" mail to  them
  3800. for handling.
  3801.  
  3802. Note that if there is such a smart mailer  on  a  system  near  you,  you  can
  3803. replace  the simple 'user' field with a full address that the smart mailer can
  3804. understand, since BM will scan from the  right  taking  everything  after  the
  3805. rightmost  '@'  to  be  the  host token, and will not mangle the address.  For
  3806. example, from my PC clone I can easily mail to:
  3807.  
  3808.         bellcore!karn@winfree            (to get to Phil, KA9Q)
  3809.  
  3810.  
  3811. where winfree is my Unix system, which talks to system bellcore via UUCP.   BM
  3812. really  doesn't  care what you put for an address as long as there is a system
  3813.  
  3814.  
  3815.  
  3816.  
  3817.  
  3818.  
  3819.  
  3820.  
  3821.  
  3822.                                     - 59 -
  3823.  
  3824.  
  3825. within range that it can punt to when it doesn't  understand  what  you  mean.
  3826. Note that this implies you should be extra careful when typing addresses!
  3827.  
  3828. Read the SMTP.DOC file for specification of the queue and mailbox  files,  and
  3829. limitations of the SMTP client that affect BM's capabilities.
  3830.  
  3831. 5.  Appendices
  3832.  
  3833. 5.1.  Technical Information for Client/Server Developers
  3834.  
  3835. This section describes the "guts" of the Internet package for the  benefit  of
  3836. programmers  who  wish  to  write their own applications, or adapt the code to
  3837. different hardware environments.
  3838.  
  3839. The code as distributed includes both the functions of an IP packet switch and
  3840. an  end-host  system,  including several servers. The implementation is highly
  3841. modular, however. For example, if one wants to build a dedicated packet switch
  3842. without  any  local applications, the various applications and the TCP and UDP
  3843. modules may easily be omitted to save space.
  3844.  
  3845. The package allows multiple simultaneous applications, each supporting  multi-
  3846. ple  simultaneous  users,  each using TCP and/or UDP. The only limit is memory
  3847. space, which is getting quite tight on the 820; the C compiler for the IBM  PC
  3848. seems  to  generate  much more compact code (typically 1/2 as large as for the
  3849. Z-80) so the PC seems more promising as a large-scale server.
  3850.  
  3851. 5.1.1.  Data Structures
  3852.  
  3853. To increase portability, the pseudo-types "int16" and "int32" are used to mean
  3854. an  unsigned  16-bit integer and a signed 32-bit integer, respectively.  Ordi-
  3855. narily these types are defined in machdep.h to be "unsigned int" and "long".
  3856.  
  3857. The various modules pass data in chained structures  called  mbufs,  with  the
  3858. following format:
  3859.  
  3860. struct mbuf {
  3861.         struct mbuf *next;      /* Links mbufs belonging to single packets */
  3862.         struct mbuf *anext;     /* Links packets on queues */
  3863.         char *data;             /* Pointer to start of actual data in buffer */
  3864.         int16 cnt;              /* Length of data in buffer */
  3865. };
  3866.  
  3867.  
  3868. Although somewhat cumbersome to work with, mbufs make  it  possible  to  avoid
  3869. memory-to-memory copies that limit performance. For example, when user data is
  3870. transmitted it must first traverse several protocol layers before reaching the
  3871. transmitter hardware. With mbufs, each layer adds its protocol header by allo-
  3872. cating an mbuf and linking it to the head of the mbuf "chain" given it by  the
  3873. higher layer, thus avoiding several copy operations.
  3874.  
  3875. A number of primitives operating on mbufs are available in mbuf.c.   The  user
  3876. may  create,  fill,  empty  and  free  mbufs  himself  with the alloc_mbuf and
  3877. free_mbuf primitives, or at the cost of a single memory-to-memory copy  he  he
  3878. may use the more convenient qdata() and dqdata() primitives.
  3879.  
  3880.  
  3881.  
  3882.  
  3883.  
  3884.  
  3885.  
  3886.  
  3887.  
  3888.                                     - 60 -
  3889.  
  3890.  
  3891. 5.1.2.  Timer Services
  3892.  
  3893. TCP and IP require timers. A timer package  is  included,  so  the  user  must
  3894. arrange to call the single entry point "tick" on a regular basis. The constant
  3895. MSPTICK in timer.h should be defined as the interval  between  ticks  in  mil-
  3896. liseconds. One second resolution is adequate. Since it can trigger a consider-
  3897. able amount of activity, including upcalls to user level, "tick" should not be
  3898. called  from  an  interrupt handler. A clock interrupt should set a flag which
  3899. will then cause "tick" to be called at user level.
  3900.  
  3901. 5.1.3.  Internet Type-of-Service
  3902.  
  3903. One of the features of the Internet  is  the  ability  to  specify  precedence
  3904. (i.e.,  priority)  on  a per-datagram basis. There are 8 levels of precedence,
  3905. with the bottom 6 defined by the DoD as Routine, Priority,  Immediate,  Flash,
  3906. Flash  Override  and  CRITICAL.  (Two  more are available for internal network
  3907. functions). For amateur use we can use the lower  four  as  Routine,  Welfare,
  3908. Priority  and  Emergency. Three more bits specify class of service, indicating
  3909. that especially high reliability, high throughput or low delay is  needed  for
  3910. this connection. Constants for this field are defined in internet.h.
  3911.  
  3912. 5.1.4.  The Internet Protocol Implementation
  3913.  
  3914. While the user does not ordinarily see this level directly,  it  is  described
  3915. here  for sake of completeness. Readers interested only in the interfaces seen
  3916. by the applications programmer should skip to the TCP and UDP sections.
  3917.  
  3918. The IP implementation consists of three major functions: ip_route, ip_send and
  3919. ip_recv.
  3920.  
  3921. 5.1.5.  IP Gateway (Packet Router) Support
  3922.  
  3923. The first, ip_route, is the IP packet switch. It takes a  single  argument,  a
  3924. pointer to the mbuf containing the IP datagram:
  3925.  
  3926.         void
  3927.         ip_route(bp,rxbroadcast)
  3928.         struct mbuf *bp;        /* Datagram pointer */
  3929.         int rxbroadcast;        /* Don't forward */
  3930.  
  3931.  
  3932. All IP datagrams, coming or going, pass through this  function.  After  option
  3933. processing,  if  any,  the  datagram's destination address is extracted. If it
  3934. corresponds to the local host, it is "kicked upstairs" to the upper half of IP
  3935. and  thence to the appropriate protocol module. Otherwise, an internal routing
  3936. table consulted to determine where the  datagram  should  be  forwarded.   The
  3937. routing  table  uses  hashing  keyed on IP destination addresses, called "tar-
  3938. gets". If the target address is not  found,  a  special  "default"  entry,  if
  3939. available,  is used. If a default entry is not available either, an ICMP "Des-
  3940. tination Unreachable" message containing the offending IP header  is  returned
  3941. to the sender.
  3942.  
  3943. The "rxbroadcast" flag is used to prevent forwarding of broadcast  packets,  a
  3944. practice which might otherwise result in spectacular routing loops. Any subnet
  3945.  
  3946.  
  3947.  
  3948.  
  3949.  
  3950.  
  3951.  
  3952.  
  3953.  
  3954.                                     - 61 -
  3955.  
  3956.  
  3957. interface driver receiving a packet addressed to the broadcast address  within
  3958. that  subnet  MUST  set  this flag.  All other packets (including locally ori-
  3959. ginated packets) should have "rxbroadcast" set to zero.
  3960.  
  3961. ip_route ignores the IP destination address in broadcast packets, passing them
  3962. up  to the appropriate higher level protocol which is also made aware of their
  3963. broadcast nature. (TCP and ICMP ignore them; only UDP can accept them).
  3964.  
  3965. Entries are added to the IP routing table with the rt_add function:
  3966.  
  3967. int
  3968. rt_add(target,gateway,metric,interface)
  3969. int32 target;                   /* IP address of target */
  3970. int32 gateway;                  /* IP addr of gateway to reach this target */
  3971. int metric;                     /* "cost" metric, for routing decisions */
  3972. struct interface *interface;    /* device interface structure */
  3973.  
  3974.  
  3975. "target" is the IP address of the destination; it becomes the hash  index  key
  3976. for subsequent packet destination address lookups. If target == 0, the default
  3977. entry is modified. "metric" is simply stored in the table; it is available for
  3978. routing  cost  calculations  when  an  automatic  routing protocol is written.
  3979. "interface" is the address of a control structure for the particular device to
  3980. which  the  datagram  should  be sent; it is defined in the section "IP Inter-
  3981. faces".
  3982.  
  3983. rt_add returns 0 on success, -1 on failure (e.g., out of memory).
  3984.  
  3985. To remove an entry from the routing table, only the  target  address  need  be
  3986. specified to the rt_drop call:
  3987.  
  3988.         int
  3989.         rt_drop(target)
  3990.         int32 target;
  3991.  
  3992.  
  3993. rt_drop returns 0 on success, -1 if the target could not be found.
  3994.  
  3995. 5.1.6.  IP Interfaces
  3996.  
  3997. Every lower level interface used to transmit IP datagrams must have an "inter-
  3998. face" structure, defined as follows:
  3999.  
  4000.  
  4001.  
  4002.  
  4003.  
  4004.  
  4005.  
  4006.  
  4007.  
  4008.  
  4009.  
  4010.  
  4011.  
  4012.  
  4013.  
  4014.  
  4015.  
  4016.  
  4017.  
  4018.  
  4019.  
  4020.                                     - 62 -
  4021.  
  4022.  
  4023.  
  4024. /* Interface control structure */
  4025. struct interface {
  4026.         struct interface *next; /* Linked list pointer */
  4027.         char *name;             /* Ascii string with interface name */
  4028.         int16 mtu;              /* Maximum transmission unit size */
  4029.         int (*send)();          /* Routine to call to send datagram */
  4030.         int (*output)();        /* Routine to call to send raw packet */
  4031.         int (*recv)();          /* Routine to kick to process input */
  4032.         int (*stop)();          /* Routine to call before detaching */
  4033.         int16 dev;              /* Subdevice number to pass to send */
  4034.         int16 flags;            /* State of interface */
  4035. #define IF_ACTIVE       0x01
  4036. #define IF_BROADCAST    0x04    /* Interface is capable of broadcasting */
  4037. };
  4038.  
  4039.  
  4040. Part of the interface structure is for the private use of the  device  driver.
  4041. "dev"  is  used to distinguish between one of several identical devices (e.g.,
  4042. serial links or radio channels) that might share the same send routine.
  4043.  
  4044. A pointer to this structure kept in the  routing  table.  Two  fields  in  the
  4045. interface  structure  are  examined by ip_route: "mtu" and "send". The maximum
  4046. transmission unit size represents the largest datagram that  this  device  can
  4047. handle; ip_route will do IP-level fragmentation as required to meet this limit
  4048. before calling "send", the function to  queue  datagrams  on  this  interface.
  4049. "send" is called as follows:
  4050.  
  4051. (*send)(bp,interface,gateway,precedence,delay,throughput,reliability)
  4052. struct mbuf *bp;                /* Pointer to datagram */
  4053. struct interface *interface;    /* Interface structure */
  4054. int32 gateway;                  /* IP address of gateway */
  4055. char precedence;                /* TOS bits from IP header */
  4056. char delay;
  4057. char throughput;
  4058. char reliability;
  4059.  
  4060.  
  4061. The "interface" and "gateway" arguments are kept  in  the  routing  table  and
  4062. passed on each call to the send routine. The interface pointer is passed again
  4063. because several interfaces might share the same output driver  (e.g.,  several
  4064. identical  physical channels).  "gateway" is the IP address of the neighboring
  4065. IP gateway on the other end of the link; if a link-level address is  required,
  4066. the  send  routine  must  map  this address either dynamically (e.g., with the
  4067. Address Resolution Protocol, ARP) or with a static lookup table.  If the  link
  4068. is  point-to-point, link-level addresses are unnecessary, and the send routine
  4069. can therefore ignore the gateway address.
  4070.  
  4071. The Internet Type-of-Service (TOS) bits are passed to the interface driver  as
  4072. separate arguments. If tradeoffs exist within the subnet between these various
  4073. classes of service, the driver may use these arguments to control them  (e.g.,
  4074. optional use of link level acknowledgments, priority queuing, etc.)
  4075.  
  4076. It is expected that the send routine will put a link level header on the front
  4077.  
  4078.  
  4079.  
  4080.  
  4081.  
  4082.  
  4083.  
  4084.  
  4085.  
  4086.                                     - 63 -
  4087.  
  4088.  
  4089. of  the  packet, add it an internal output queue, start output (if not already
  4090. active) and return. It must NOT busy-wait for completion (unless it is a  very
  4091. fast device, e.g., Ethernet) since that blocks the entire system.
  4092.  
  4093. Any interface that uses ARP must also provide an "output"  routine.  It  is  a
  4094. lower  level  entry  point that allows the caller to specify the fields in the
  4095. link header. ARP uses it to broadcast a request for a given IP address. It may
  4096. be  the  same  routine used internally by the driver to send IP datagrams once
  4097. the link level fields have been determined. It is called as follows:
  4098.  
  4099. (*output)(interface,dest,src,type,bp)
  4100. struct interface *interface;    /* Pointer to interface structure */
  4101. char dest[];                    /* Link level destination address */
  4102. char src[];                     /* Link level source address */
  4103. int16 type;                     /* Protocol type field for link level */
  4104. struct mbuf *bp;                /* Data field (IP datagram) */
  4105.  
  4106.  
  4107. 5.1.7.  IP Host Support
  4108.  
  4109. All of the modules described thus far are required in  all  systems.  However,
  4110. the  routines  that  follow  are  necessary  only  if the system is to support
  4111. higher-level applications. In a stand alone IP gateway (packet switch) without
  4112. servers  or clients, the following modules (IP user level, TCP and UDP) may be
  4113. omitted to allow additional space for buffering; define the flag  GWONLY  when
  4114. compiling iproute.c to avoid referencing the user level half of IP.
  4115.  
  4116. The following function is called by iproute() whenever a datagram arrives that
  4117. is addressed to the local system.
  4118.  
  4119. void
  4120. ip_recv(bp,rxbroadcast)
  4121. struct mbuf *bp;                /* Datagram */
  4122. char rxbroadcast;               /* Incoming broadcast */
  4123.  
  4124.  
  4125. ip_recv reassembles IP datagram fragments, if necessary, and calls  the  input
  4126. function  of  the  next  layer  protocol (e.g., tcp_input, udp_input) with the
  4127. appropriate arguments, as follows:
  4128.  
  4129. (*protrecv)(bp,protocol,source,dest,tos,length,rxbroadcast);
  4130. struct mbuf *bp;        /* Pointer to packet minus IP header */
  4131. char protocol;          /* IP protocol ID */
  4132. int32 source;           /* IP address of sender */
  4133. int32 dest;             /* IP address of destination (i.e,. us) */
  4134. char tos;               /* IP type-of-service field in datagram */
  4135. int16 length;           /* Length of datagram minus IP header */
  4136. char rxbroadcast;       /* Incoming broadcast */
  4137.  
  4138.  
  4139. The list of protocols is contained in a  switch()  statement  in  the  ip_recv
  4140. function. If the protocol is unsupported, an ICMP Protocol Unreachable message
  4141. is returned to the sender unless the packet came in as a broadcast.
  4142.  
  4143.  
  4144.  
  4145.  
  4146.  
  4147.  
  4148.  
  4149.  
  4150.  
  4151.  
  4152.                                     - 64 -
  4153.  
  4154.  
  4155. Higher level protocols such as TCP and UDP use the ip_send routine to generate
  4156. IP datagrams. The arguments to ip_send correspond directly to fields in the IP
  4157. header, which is generated and put in front of the user's  data  before  being
  4158. handed to ip_route:
  4159.  
  4160. ip_send(source,dest,protocol,tos,ttl,bp,length,id,df)
  4161. int32 source;           /* source address */
  4162. int32 dest;             /* Destination address */
  4163. char protocol;          /* Protocol */
  4164. char tos;               /* Type of service */
  4165. char ttl;               /* Time-to-live */
  4166. struct mbuf *bp;        /* Data portion of datagram */
  4167. int16 length;           /* Optional length of data portion */
  4168. int16 id;               /* Optional identification */
  4169. char df;                /* Don't-fragment flag */
  4170.  
  4171.  
  4172. This interface is modeled very closely after the example given on page  32  of
  4173. RFC-791.  Zeros  may be passed for id or ttl, and system defaults will be pro-
  4174. vided. If zero is passed for length, it will be calculated automatically.
  4175.  
  4176. 5.1.8.  The Transmission Control Protocol (TCP)
  4177.  
  4178. A TCP connection is uniquely identified by  the  concatenation  of  local  and
  4179. remote  "sockets".  In  turn,  a  socket  consists of a host address (a 32-bit
  4180. integer) and a TCP port (a 16-bit integer), defined by the C structure
  4181.  
  4182. struct socket {
  4183.         long address;   /* 32-bit IP address */
  4184.         short port;     /*16-bit TCP port */
  4185. };
  4186.  
  4187.  
  4188. It is therefore possible to have several simultaneous but distinct connections
  4189. to  the  same  port on a given machine, as long as the remote sockets are dis-
  4190. tinct. Port numbers are assigned either through mutual agreement, or more com-
  4191. monly  when  a  "standard" service is involved, as a "well known port" number.
  4192. For example,  to  obtain  standard  remote  login  service  using  the  TELNET
  4193. presentation-layer  protocol,  by  convention you initiate a connection to TCP
  4194. port 23; to send mail using the Simple Mail Transfer Protocol (SMTP) you  con-
  4195. nect  to  port 25. ARPA maintains port number lists and periodically publishes
  4196. them; the latest revision is RFC-960,  "Assigned  Numbers".   They  will  also
  4197. assign  port  numbers  to  a new application on request if it appears to be of
  4198. general interest.
  4199.  
  4200. TCP connections are best modeled as a pair  of  one-way  paths  (one  in  each
  4201. direction) rather than single full-duplex paths. A TCP "close" really means "I
  4202. have no more data to send". Station A may close its path to station B  leaving
  4203. the  reverse  path  from  B  to A unaffected; B may continue to send data to A
  4204. indefinitely until it too closes its half of the  connection.   Even  after  a
  4205. user initiates a close, TCP continues to retransmit any unacknowledged data if
  4206. necessary to ensure that it reaches the other end. This is known as  "graceful
  4207. close" and greatly simplifies certain applications such as FTP.
  4208.  
  4209.  
  4210.  
  4211.  
  4212.  
  4213.  
  4214.  
  4215.  
  4216.  
  4217.  
  4218.                                     - 65 -
  4219.  
  4220.  
  4221. This package is written as a "module" intended to be compiled and linked  with
  4222. the application(s) so that they can be run as one program on the same machine.
  4223. This greatly simplifies the user/TCP interface, which becomes just  a  set  of
  4224. internal  subroutine  calls on a single machine. The internal TCP state (e.g.,
  4225. the address  of  the  remote  station)  is  easily  accessed.  Reliability  is
  4226. improved,  since  any  hardware  failure  that  kills TCP will likely take its
  4227. applications with it anyway. Only IP datagrams flow out of the machine  across
  4228. hardware  interfaces  (such  as asynch RS-232 ports or whatever else is avail-
  4229. able) so hardware flow control or  complicated  host/front-end  protocols  are
  4230. unnecessary.
  4231.  
  4232. The TCP supports five basic operations on a  connection:  open_tcp,  send_tcp,
  4233. receive_tcp, close_tcp and del_tcp. A sixth, state_tcp, is provided mainly for
  4234. debugging. Since this TCP module cannot assume the presence of a  sleep/wakeup
  4235. facility from the underlying operating system, functions that would ordinarily
  4236. block (e.g., recv_tcp when no data is available) instead set net_error to  the
  4237. constant  EWOULDBLK  and  immediately return -1.  Asynchronous notification of
  4238. events such as data arrival  can  be  obtained  through  the  upcall  facility
  4239. described earlier.
  4240.  
  4241. Each TCP function is summarized in the following section  in  the  form  of  C
  4242. declarations and descriptions of each argument.
  4243.  
  4244. int net_error;
  4245.  
  4246.  
  4247. This global variable stores the specific cause of an error from one of the TCP
  4248. or UDP functions. All functions returning integers (i.e., all except open_tcp)
  4249. return -1 in the event of an error, and net_error should be examined to deter-
  4250. mine  the  cause.  The  possible errors are defined as constants in the header
  4251. file netuser.h.
  4252.  
  4253. /* Open a TCP connection */
  4254. struct tcb *
  4255. open_tcp(lsocket,fsocket,mode,window,r_upcall,t_upcall,s_upcall,tos,user)
  4256. struct socket *lsocket; /* Local socket */
  4257. struct socket *fsocket; /* Remote socket */
  4258. int mode;               /* Active/passive/server */
  4259. int16 window;           /* Receive window (and send buffer) sizes */
  4260. void (*r_upcall)();     /* Function to call when data arrives */
  4261. void (*t_upcall)();     /* Function to call when ok to send more data */
  4262. void (*s_upcall)();     /* Function to call when connection state changes */
  4263. char tos;               /* Internet Type-of-Service */
  4264. int *user;              /* Pointer for convenience of user */
  4265.  
  4266.  
  4267. "lsocket" and "fsocket" are pointers to the local and foreign sockets, respec-
  4268. tively.
  4269.  
  4270. "mode" may take on three  values,  all  defined  in  net.user.h.  If  mode  is
  4271. TCP_PASSIVE, no packets are sent, but a TCP control block is created that will
  4272. accept a subsequent active open from another TCP. If a specific foreign socket
  4273. is  passed  to  a  passive  open, then connect requests from any other foreign
  4274. socket will be rejected. If the foreign socket fields are set to zero,  or  if
  4275.  
  4276.  
  4277.  
  4278.  
  4279.  
  4280.  
  4281.  
  4282.  
  4283.  
  4284.                                     - 66 -
  4285.  
  4286.  
  4287. fsocket  is  NULLSOCK,  then  connect requests from any foreign socket will be
  4288. accepted.  If mode is TCP_ACTIVE, TCP will initiate a connection to  a  remote
  4289. socket  that must already have been created in the LISTEN state by its client.
  4290. The foreign socket must be completely specified in an active open.  When  mode
  4291. is TCP_SERVER, open_tcp behaves as though TCP_PASSIVE was given except that an
  4292. internal "clone" flag is set. When a connection request comes in, a fresh copy
  4293. of  the  TCP  control  block  is created and the original is left intact. This
  4294. allows multiple sessions to exist simultaneously;  if  TCP_PASSIVE  were  used
  4295. instead only the first connect request would be accepted.
  4296.  
  4297. "r_upcall", "t_upcall" and  "s_upcall"  provide  optional  upcall  or  pseudo-
  4298. interrupt  mechanisms  useful  when running in a non operating system environ-
  4299. ment.  Each of the three arguments, if non-NULL, is taken as the address of  a
  4300. user-supplied function to call when receive data arrives, transmit queue space
  4301. becomes available, or the connection state changes. The  three  functions  are
  4302. called with the following arguments:
  4303.  
  4304. (*r_upcall)(tcb,count); /* count == number of bytes in receive queue */
  4305. (*t_upcall)(tcb,avail); /* avail == space available in send queue */
  4306. (*s_upcall)(tcb,oldstate,newstate);
  4307.  
  4308.  
  4309.      Note: whenever a single event invokes more than one upcall the order
  4310.      in  which  the upcalls are made is not strictly defined. In general,
  4311.      though, the Principle of Least Astonishment is followed.  E.g., when
  4312.      entering  the  ESTABLISHED state, the state change upcall is invoked
  4313.      first, followed by the transmit upcall.  When  an  incoming  segment
  4314.      contains  both  data  and  FIN, the receive upcall is invoked first,
  4315.      followed by the state change to CLOSE_WAIT state.  In this case, the
  4316.      user may interpret this state change as a "end of file" indicator.
  4317.  
  4318. "tos" is the Internet type-of-service field. This parameter is passed along to
  4319. IP  and is included in every datagram. The actual precedence value used is the
  4320. higher of the two specified in the corresponding pair of open_tcp calls.
  4321.  
  4322. open_tcp returns a pointer to an internal Transmission  Control  Block  (tcb).
  4323. This "magic cookie" must be passed back as the first argument to all other TCP
  4324. calls. In event of error, the NULL pointer (0) is returned  and  net_error  is
  4325. set to the reason for the error.
  4326.  
  4327. The only limit on the number of TCBs that may exist at  any  time  (i.e.,  the
  4328. number  of  simultaneous  connections)  is  the  amount  of free memory on the
  4329. machine. Each TCB on a 16-bit processor currently takes up  111  bytes;  addi-
  4330. tional  memory  is consumed and freed dynamically as needed to buffer send and
  4331. receive data. Deleting a TCB (see the del_tcp() call) reclaims its space.
  4332.  
  4333. /* Send data on a TCP connection */
  4334. int
  4335. send_tcp(tcb,bp)
  4336. struct tcb *tcb;        /* TCB pointer */
  4337. struct mbuf *bp;        /* Pointer to user's data mbufs */
  4338.  
  4339.  
  4340. "tcb" is the pointer returned by the  open_tcp()  call.  "bp"  points  to  the
  4341.  
  4342.  
  4343.  
  4344.  
  4345.  
  4346.  
  4347.  
  4348.  
  4349.  
  4350.                                     - 67 -
  4351.  
  4352.  
  4353. user's  mbuf  with  data  to be sent. After being passed to send_tcp, the user
  4354. must no longer access the data buffer. TCP uses positive acknowledgments  with
  4355. retransmission  to  ensure in-order delivery, but this is largely invisible to
  4356. the user. Once the remote TCP has acknowledged the data, the  buffer  will  be
  4357. freed automatically.
  4358.  
  4359. TCP does not enforce a limit in the number of bytes that  may  be  queued  for
  4360. transmission,  but  it  is  recommended that the application not send any more
  4361. than the amount passed as "cnt" in the transmitter upcall.  The  package  uses
  4362. shared,  dynamically allocated buffers, and it is entirely possible for a mis-
  4363. behaving user task to run the system out of buffers.
  4364.  
  4365. /* Receive data on a TCP connection */
  4366. int
  4367. recv_tcp(tcb,bp,cnt)
  4368. struct tcb *tcb;
  4369. struct mbuf **bp;
  4370. int16 cnt;
  4371.  
  4372.  
  4373. recv_tcp() passes back through bp a pointer to an mbuf  chain  containing  any
  4374. available  receive  data, up to a maximum of "cnt" bytes. The actual number of
  4375. bytes received (the lesser of "cnt" and the  number  pending  on  the  receive
  4376. queue) is returned. If no data is available, net_error is set to EWOULDBLK and
  4377. -1 is returned; the r_upcall mechanism may be  used  to  determine  when  data
  4378. arrives.  (Technical  note: "r_upcall" is called whenever a PUSH or FIN bit is
  4379. seen in an incoming segment, or if the receive  window  fills.  It  is  called
  4380. before  an  ACK  is  sent back to the remote TCP, in order to give the user an
  4381. opportunity to piggyback any data in response.)
  4382.  
  4383. When the remote TCP closes its half of the connection and all  prior  incoming
  4384. data  has  been  read by the local user, subsequent calls to recv_tcp return 0
  4385. rather than -1 as an "end of transmission"  indicator.  Note  that  the  local
  4386. application  is  notified  of  a  remote close (i.e., end-of-file) by a state-
  4387. change upcall with the new state being CLOSE_WAIT; if  the  local  application
  4388. has  closed  first,  a  remote  close is indicated by a state-change upcall to
  4389. either CLOSING or TIME_WAIT state. (CLOSING state is used only  when  the  two
  4390. ends close simultaneously and their FINs cross in the mail).
  4391.  
  4392. /* Close a TCP connection */
  4393. close_tcp(tcb)
  4394. struct tcb *tcb;
  4395.  
  4396.  
  4397. This tells TCP that the local user has no more  data  to  send.  However,  the
  4398. remote TCP may continue to send data indefinitely to the local user, until the
  4399. remote user also does a close_tcp.  An attempt to send data after a  close_tcp
  4400. is an error.
  4401.  
  4402. /* Delete a TCP connection */
  4403. del_tcp(tcb)
  4404. struct tcb *tcb;
  4405.  
  4406.  
  4407.  
  4408.  
  4409.  
  4410.  
  4411.  
  4412.  
  4413.  
  4414.  
  4415.  
  4416.                                     - 68 -
  4417.  
  4418.  
  4419. When the connection has been closed in both connections and all incoming  data
  4420. has been read, this call is made to cause TCP to reclaim the space taken up by
  4421. the TCP control block. Any incoming data remaining unread is lost.
  4422.  
  4423. /* Dump a TCP connection state */
  4424. state_tcp(tcb)
  4425. struct tcb *tcb;
  4426.  
  4427.  
  4428. This debugging call prints an ASCII-format dump of the TCP connection state on
  4429. the  terminal.  You need a copy of the TCP specification (ARPA RFC 793 or MIL-
  4430. STD-1778) to interpret most of the numbers.
  4431.  
  4432. 5.1.9.  The User Datagram Protocol (UDP)
  4433.  
  4434. UDP is available for simple applications not needing the services of  a  reli-
  4435. able  protocol  like TCP.  A minimum of overhead is placed on top of the "raw"
  4436. IP datagram service, consisting only of port numbers and a  checksum  covering
  4437. the UDP header and user data. Four functions are available to the UDP user.
  4438.  
  4439. /* Create a UDP control block for lsocket, so that we can queue
  4440.  * incoming datagrams.
  4441.  */
  4442. int
  4443. open_udp(lsocket,r_upcall)
  4444. struct socket *lsocket;
  4445. void (*r_upcall)();
  4446.  
  4447.  
  4448. open_udp creates a queue to accept incoming datagrams (regardless  of  source)
  4449. addressed  to "lsocket". "r_upcall" is an optional upcall mechanism to provide
  4450. the address of a function to be called as follows whenever a datagram arrives:
  4451.  
  4452. (*r_upcall)(lsocket,rcvcnt);
  4453. struct socket *lsocket;         /* Pointer to local socket */
  4454. int rcvcnt;                     /* Count of datagrams pending on queue */
  4455.  
  4456. /* Send a UDP datagram */
  4457. int
  4458. send_udp(lsocket,fsocket,tos,ttl,bp,length,id,df)
  4459. struct socket *lsocket;         /* Source socket */
  4460. struct socket *fsocket;         /* Destination socket */
  4461. char tos;                       /* Type-of-service for IP */
  4462. char ttl;                       /* Time-to-live for IP */
  4463. struct mbuf *bp;                /* Data field, if any */
  4464. int16 length;                   /* Length of data field */
  4465. int16 id;                       /* Optional ID field for IP */
  4466. char df;                        /* Don't Fragment flag for IP */
  4467.  
  4468.  
  4469. The parameters passed to send_udp  are  simply  stuffed  in  the  UDP  and  IP
  4470. headers, and the datagram is sent on its way.
  4471.  
  4472.  
  4473.  
  4474.  
  4475.  
  4476.  
  4477.  
  4478.  
  4479.  
  4480.  
  4481.  
  4482.                                     - 69 -
  4483.  
  4484.  
  4485.  
  4486. /* Accept a waiting datagram, if available. Returns length of datagram */
  4487. int
  4488. recv_udp(lsocket,fsocket,bp)
  4489. struct socket *lsocket;         /* Local socket to receive on */
  4490. struct socket *fsocket;         /* Place to stash incoming socket */
  4491. struct mbuf **bp;               /* Place to stash data packet */
  4492.  
  4493.  
  4494. The "lsocket" pointer indicates the  socket  the  user  wishes  to  receive  a
  4495. datagram  on (a queue must have been created previously with the open_udp rou-
  4496. tine). "fsocket" is taken as the address of a socket structure to be overwrit-
  4497. ten  with  the  foreign  socket associated with the datagram being read; bp is
  4498. overwritten with a pointer to the data portion (if any) of the datagram  being
  4499. received.
  4500.  
  4501. /* Delete a UDP control block */
  4502. int
  4503. del_udp(lsocket)
  4504. struct socket *lsocket;
  4505.  
  4506.  
  4507. This function destroys any unread datagrams on a queue, and reclaims the space
  4508. taken by the queue descriptor.
  4509.  
  4510. 5.2.  The KISS Host to TNC Protocol
  4511.  
  4512. 5.2.1.  The Protocol Specification
  4513.  
  4514. 5.2.1.1.  Introduction
  4515.  
  4516. The purpose of the "Raw" (aka "KISS") TNC is to facilitate the use of  amateur
  4517. packet  radio  controllers  (TNCs)  with  host  computers, particularly in the
  4518. development of experimental protocols and multi-user servers (e.g.,  "bulletin
  4519. boards").
  4520.  
  4521. Current TNC software was written with human users in mind; unfortunately, com-
  4522. mands  and  responses  well suited for human use are ill-adapted for host com-
  4523. puter use, and vice versa. This is especially true for multi-user servers such
  4524. as  bulletin boards which must multiplex data from several network connections
  4525. across the single host/TNC link.  In addition, experimentation with  new  link
  4526. level  protocols  is greatly hampered because there may very well be no way at
  4527. all to generate or receive frames in the desired format without  reprogramming
  4528. the TNC.
  4529.  
  4530. The Raw TNC solves these problems by eliminating as much as possible from  the
  4531. TNC software, giving the attached host complete control over and access to the
  4532. contents of the HDLC frames transmitted and received over the air.  The  AX.25
  4533. protocol is removed entirely from the TNC, as are all command interpreters and
  4534. the like.  The TNC simply converts between synchronous  HDLC,  spoken  on  the
  4535. half  duplex radio channel, and a special asynchronous, full duplex frame for-
  4536. mat spoken on the host/TNC link.  Every frame received on  the  HDLC  link  is
  4537. passed intact to the host once it has been translated to the asynchronous for-
  4538. mat; likewise, asynchronous frames from the host are transmitted on the  radio
  4539.  
  4540.  
  4541.  
  4542.  
  4543.  
  4544.  
  4545.  
  4546.  
  4547.  
  4548.                                     - 70 -
  4549.  
  4550.  
  4551. channel once they have been converted to HDLC format.
  4552.  
  4553. Of course, this means that the bulk of AX.25 (or another protocol) must now be
  4554. implemented  on  the host system. This is acceptable, however, considering the
  4555. greatly increased flexibility and reduced overall complexity that  comes  from
  4556. allowing  the  protocol to reside on the same machine with the applications to
  4557. which it is closely coupled.
  4558.  
  4559. 5.2.1.2.  Asynchronous frame format
  4560.  
  4561. The "asynchronous packet protocol" spoken between the host  and  TNC  is  very
  4562. simple,  since its only function is delimiting frames. Each frame is both pre-
  4563. ceded and followed by a special FEND (frame end) character,  analogous  to  an
  4564. HDLC flag.  No CRC or checksum is provided.
  4565.  
  4566. The reason for both preceding and ending frames with FENDs is to improve  per-
  4567. formance  when there is noise on the asynch line. The FEND at the beginning of
  4568. a frame serves to "flush out" any accumulated garbage into  a  separate  frame
  4569. (which will be discarded by the upper layer protocol) instead of prepending it
  4570. to an otherwise good frame.  As with back-to-back  FLAGs  in  HDLC,  two  FEND
  4571. characters in a row should not be interpreted as delimiting an empty frame.
  4572.  
  4573. 5.2.1.2.1.  Transparency
  4574.  
  4575. Frames are sent in 8-bit binary; if an FEND ever appears in the  data,  it  is
  4576. translated  into  the  two  byte sequence FESC TFEND (frame escape, transposed
  4577. frame end).  Likewise, if the FESC character ever appears in the user data, it
  4578. is  replaced  with  the two character sequence FESC TFESC (frame escape, tran-
  4579. sposed frame escape).
  4580.  
  4581. As characters arrive at the receiver, they are appended to a buffer containing
  4582. the  current  frame.  Receiving  a  FEND  marks  the end of the current frame.
  4583. Receipt of a FESC puts the receiver into  "escaped  mode",  which  causes  the
  4584. receiver to translate a following TFESC or TFEND back to FESC or FEND, respec-
  4585. tively, before adding it to the  receive  buffer  and  leaving  escaped  mode.
  4586. (Receipt  of  any character other than TFESC or TFEND while in escaped mode is
  4587. an error; no action is taken and frame assembly continues.  A  TFEND  or  TESC
  4588. received while not in escaped mode is treated as an ordinary data character.)
  4589.  
  4590. This procedure may seem somewhat complicated, but it is easy to implement  and
  4591. recovers  quickly from errors. In particular, the FEND character is never sent
  4592. over the channel except as an actual  end-of-frame  indication.  This  ensures
  4593. that  any  intact frame (properly delimited by FEND characters) will always be
  4594. received properly regardless of the starting state of the receiver or  corrup-
  4595. tion of the preceding frame.
  4596.  
  4597. The special characters are:
  4598.  
  4599.         FEND    (frame end)                     300 (octal)
  4600.         FESC    (frame escape)                  333 (octal)
  4601.         TFEND   (transposed frame end)          334 (octal)
  4602.         TFESC   (transposed frame escape)       335 (octal)
  4603.  
  4604.  
  4605.  
  4606.  
  4607.  
  4608.  
  4609.  
  4610.  
  4611.  
  4612.  
  4613.  
  4614.                                     - 71 -
  4615.  
  4616.  
  4617. (ARPA Internet hackers will recognize this protocol as identical  to  SLIP,  a
  4618. popular method for sending IP datagrams across ordinary dialup modems).
  4619.  
  4620. 5.2.1.3.  Control of the Raw TNC
  4621.  
  4622. Each asynchronous data frame sent to the TNC is  converted  back  into  "pure"
  4623. form  and queued for transmission as a separate HDLC frame.  Although removing
  4624. the human interface and the AX.25 protocol from the TNC  makes  most  existing
  4625. TNC  commands unnecessary (i.e., they become host functions), the TNC is still
  4626. responsible for keying the transmitter's  PTT  line  and  deferring  to  other
  4627. activity  on the radio channel. It is therefore necessary to allow the host to
  4628. control a few TNC parameters, namely  the  transmitter  keyup  delay  and  the
  4629. transmitter persistence variables.
  4630.  
  4631. It is therefore necessary to distinguish between command and  data  frames  on
  4632. the  host/TNC  link. This is done by defining the first byte of each asynchro-
  4633. nous frame between host and TNC as a "type" indicator.   The  following  types
  4634. are defined in frames to the TNC:
  4635.  
  4636. Type    Function        Comments
  4637. 0       Data frame      Rest of frame is data to be sent on the HDLC channel
  4638. 1       TXDELAY         Second byte is transmitter keyup delay in 10 ms units
  4639. 2       P               Second byte of frame is persistence parameter, p:
  4640.                         0: p = (0+1)/256, 255: p = (255+1)/256 = 1.0
  4641. 3       SLOTTIME        Second byte of frame is slot interval in 10 ms units
  4642. 4       TXtail          Second byte of frame is time to hold up the TX after
  4643.                         the FCS has been sent (the time allowed to send the
  4644.                         HDLC flag character; should be at least 2 for 1200 bps
  4645.                         operation).  In 10 ms units.
  4646.  
  4647.  
  4648. The following types are defined in frames to the host:
  4649.  
  4650. Type    Function        Comments
  4651. 0       Data frame      Rest of frame is data from the HDLC channel
  4652.  
  4653.  
  4654. (No other types are defined; in particular, there is  no  provision  for  ack-
  4655. nowledging data or command frames sent to the TNC.)
  4656.  
  4657. 5.2.1.4.  Persistence
  4658.  
  4659. The P and SLOTTIME parameters are used to implement  true  p-persistent  CSMA.
  4660. This works as follows:
  4661.  
  4662. Whenever the host has queued data for transmission, the TNC begins  monitoring
  4663. the  carrier detect signal from the modem. It waits indefinitely for this sig-
  4664. nal to go inactive. Once the channel is clear,  the  TNC  generates  a  random
  4665. number  between  0 and 255. If this number is less than or equal to P, the TNC
  4666. asserts the transmitter PTT line, waits .01 * TXDELAY seconds,  and  transmits
  4667. all  frames  in its queue. The TNC then releases PTT and goes back to the idle
  4668. state.  If the random number is greater than  P, the  TNC  delays  signal  has
  4669. gone  active  in the meantime, the TNC again waits for it to clear before con-
  4670. tinuing).  Note  that  P=255  means  always  transmit  as  soon  as  possible,
  4671.  
  4672.  
  4673.  
  4674.  
  4675.  
  4676.  
  4677.  
  4678.  
  4679.  
  4680.                                     - 72 -
  4681.  
  4682.  
  4683. regardless of the random number.
  4684.  
  4685. The result is that the  TNC  waits  for  an  exponentially-distributed  random
  4686. interval  after  sensing  that the channel has gone clear before attempting to
  4687. transmit. The idea here is that with proper tuning of  the  parameters  P  and
  4688. SLOTTIME,  several  stations with traffic to send are much less likely to col-
  4689. lide with each other when they simultaneously see the channel go clear.
  4690.  
  4691. 5.2.2.  The TNC-2 Implementation
  4692.  
  4693. See the files included in the TNC-2 KISS Distribution.
  4694.  
  4695. 5.2.3.  The TNC-1 Implementation
  4696.  
  4697. See the files included in the TNC-1 KISS Distribution.
  4698.  
  4699. 5.2.4.  The VADCG/ASHBY Implementation
  4700.  
  4701. See the files included in the VADCG/ASHBY KISS Distribution.
  4702.  
  4703. 5.2.5.  The AEA Implementation
  4704.  
  4705. All PK-232 units with WEFAX, and PC-87 units of a similar vintage, are capable
  4706. of KISS operation.  See the installation instructions earlier in this document
  4707. for more information.
  4708.  
  4709. 5.2.6.  The Kantronics Implementation
  4710.  
  4711. See your Kantronics TNC Documentation.
  4712.  
  4713. 5.3.  The Experimental DES Package
  4714.  
  4715. Documentation is included in the DES package.
  4716.  
  4717.  
  4718.  
  4719.  
  4720.  
  4721.  
  4722.  
  4723.  
  4724.  
  4725.  
  4726.  
  4727.  
  4728.  
  4729.  
  4730.  
  4731.  
  4732.  
  4733.  
  4734.  
  4735.  
  4736.  
  4737.  
  4738.  
  4739.  
  4740.  
  4741.  
  4742.  
  4743.