PupGatewayManual.tioga
Wes Irish, March 18, 1989 11:58:23 am PST
PupGateway Manual FOR INTERNAL XEROX USE ONLY
copy [Indigo]<PupGateway>Doc>PupGatewayManual.tioga ← PupGatewayManual.tioga
PupGateway Manual
Wesley Irish
c Copyright 1987 Xerox Corporation. All rights reserved.
Abstract: PupGateway is a collection of network software that runs in the Mesa/Pilot/XDE environment. The name can be misleading because in addition to providing PUP routing it also provides a number of other services such as: NS routing, time Service, Name Lookup Service, Boot service, Boot request forwarding, and much more. PupGateway runs on DLions and Dicentras. (D0s are no longer supported.)
Documentation Created by: Wesley Irish <WIrish.pa>
Maintained by: Wesley Irish <WIrish.pa>
Keywords: PupGateway, PUP, NS, Gateway, Server, routing, time, Name Lookup, NLS, boot service
XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304
For Internal Xerox Use Only
Table of Contents
1. History
2. Overview
3. Building a new PupGateway
4. The Parameter file
5. Pup-Network.txt
6. Warnings and Cautions
7. Common Problems and Fixes
8. Routing and the [Gateway] section
9. Boot Service
10. Pup Name Service and Pup Dir Service
11. FTP Server
12. Host Watcher
13. Time Server and Time Checker
14. Other Servers and Services
15. Dicentra Commands
16. DLion (XDE) Tools
1. History
In the early days of networking at Xerox (PARC in particular), Data General Eclipses and Altos were used as gateways to connect Ethernets together either directly or through phone lines. Eclipses became obsolete early on. The Alto gateway code (written in Mesa) remained and was appropriately called AltoGateway. In the late 70's - early 80's, D0s and DLions came along and AltoGateway lead to PupGateway in the `D' machine world. As you might expect, PupGateway has grown, matured, and changed over the years. One of these changes was the addition of NS services, including NS routing. Somewhere around 1984-1985 the Dicentra was added to the list of machines that could run PupGateway.
2. Overview
"Wizard" in this manual means GatewaySupport↑.pa or one of the members thereof.
Any problems or questions about PupGateways (or related internet problems) should be addressed to a wizard. All individuals and groups that are involved with operating a PupGateway should be members of GatewayAdministrators↑.x. Dicentra users should also be members of DicentraUsers↑.pa.
The name "PupGateway" is somewhat misleading. PupGateway is a collection of software that provides a number of services and "features" that are related to internet activities. A number of these services support NS protocols in addition to PUP protocols. The main service (or at least the most obvious) provided is routing; both PUP and NS routing is supported. Other services include: BootService, NameLookupService, TimeService, etc.
In addition to documenting PupGateway, this manual is also intended to be a general reference for network and internet information. If you have any corrections, additions, or changes that you feel should be added to this manual please let the current maintainer know.
About this Manual
This manual attempts to "tell you everything you need to know" in order to run a PupGateway and an internet. Corrections, additions, comments, etc. are encouraged and should be sent to the current maintainer (see the front page).
Where to find things
This documentation is [Indigo]<PupGateway>Doc>PupGatewayManual.*, where * is a number of different extensions depending on what format you want the document in.
[Indigo]<PupGateway> holds all of the code and related files specific to PupGateway.
[Indigo]<Dicentra>Doc>DicentraManual.* is the Dicenta documentation.
[Indigo]<Dicentra> holds all of the code and related files specific to the Dicentra.
[Indigo]<Portola> holds Pup-Network.txt and all (some) of the parameter files from gateways around the internet.
[Dexter] is the "root" boot server at PARC and holds most if not all of the current boot files for everything from Altos to XDE.
Hardware
Altos and D0s
No longer supported and STRONGLY discouraged.
DayBreak (6085)
DO NOT USE DayBreaks as PupGateways. Among other things both the Ethernet and phoneline interfaces are junk. The Ethernet interface can go totally dead for periods of time (seconds/minutes) and the phoneline simply can't handle anthing faster than 9.6 Kbps (and even that is tricky to get right).
DLions
DLions only have the hardware to connect to a single Ethernet and therefore can't be used to (directly) connect two or more Ethernets together. DLions do have a single RS-232 port that can be used to connect to a phone line of a speed up to 56KB (really only ~50KB). DLions also have disks and therefore make good bootservers and nameservers.
Dicentras
Dicentras don't have disks (or displays for that matter) and therefore need a boot server to get going. They also can't (directly) provide bootservice. The big advantage of Dicentras are that they can drive a number of interface boards: multiple Ethernets (both 3Mb and 10Mb), T1 lines, and phone lines (a standard Dicentra has 8 phone line ports).
Pup-Network.txt
Pup-Network.txt is at the heart of the PUP Name Lookup Service (NLS). Any machines on the internet that communicate using PUP protocols should be registered in Pup-Network.txt. See the Pup-Network.txt section in this document for more information.
PupGateway.typescript, Chat, and the Log File
DLion PupGateways keep a log of events as the gateway runs. The size and layout of this file is described in the FTP Server chapter. The important thing to mention here is that the Dicentra does not keep a log file per se, remember, it doesn't have a disk. But, the Dicentra does "log" to the Chat connection, if one is open. This information is the same as what would go into the log file, if it had one.
Interesting Files and Access Control
The section of this manual on the FTP server mentions a number of interesting files that live on a DLion PupGateway. It also explains a GV group that is used to control FTP access.
Other Information
If you are running a Dicentra PupGateway then you should also read the Dicentra Manual. This manual has a lot of information particular to the Dicentra. You can get a copy from [Indigo]<Dicentra>Doc>DicentraManual.*, where * represents a number of different formats such as interpress, press, or tioga.
3. Building a new PupGateway
First you have to choose whether to use either a DLion or a Dicentra. The choice might already be made for you by available hardware. If you have a choice then it depends of what you are trying to do.
DLions are good for boot servers. They are also acceptable for driving a single phone line although they aren't great at 56KB lines.
Dicentras are the only choice for connecting multiple Ethernets together, driving 3Mb Ethernets or T1 lines, or for connecting more than one phone line to a single machine. Remember, though, that Dicentras need a boot server and an NS time server to get started. What works out really well at PARC is to use a few DLions as boot and time servers and then use Dicentras to actually connect everything together.
You'll need to create a parameter file for your new gateway. The best way to do this is to look at existing parameter files on machines that are used in a similar configuration, and to read this manual. All of the parameter file entries are document here but they are included in the particular sections of the manual which they directly pertain to.
New machines, networks, and phone lines all need to be properly registered in Pup-Network.txt. For DLions you should have the GV group GatewayName.internet created by a wizard for access control purposes.
Let a wizard know what you are doing.
DLion
Volumes
The machine should be configured with at least these three volumes: Othello, Copilot, and Tajo.
Boot Files
For boot files use: the Pup version of Othello, a standard version of Copilot, and there are a few ways to go for the Tajo boot file. You can use a standard version of Tajo but the gateway will not be able to translate NS names when there is not a valid NS user logged in. This means that you can't successfully use NS names as parameters for some of the utilities such as NetWatcher.
There is a modified version of the Tajo boot file that does not require a user to be logged in for the gateway to be able to translate names; this file is available from [Indigo]<PupGateway>.
There is also TajoBigBuffers.boot that does not require a user to be logged in and enables the gateway to deal with packets up to the full Ethernet size, about 1532 bytes. TajoBigBuffers.boot is available from [Indigo]<PupGateway>. A standard Tajo 12.0 bootfile limits the packet size to about 532 bytes. Warning: DO NOT USE TajoBigBuffers.boot on a DLion that drives a phone line. The problem is that the DLion IOP code cannot handle big buffers even if you use TajoBigBuffers.boot.
Phoneline Driver
If your DLion will be driving a phone line then you will need the RS-232 options cable and RS232CIOHeadsDLion.bcd. This cable brings the RS-232 port out of the box and to the back panel of the DLion. You should either modify the initial commands section of the User.cm or an appropriate .cm file to run RS232CIOHeadsDLion.bcd before running PupGateway.
PupGateway.bcd
PupGateway.bcd includes all of the servers and tools that make up the DLion version of the PupGateway system. This file is available from [Indigo]<PupGateway>. If started using the /i switch then all of the servers that are automatically started will be put on the inactive list rather than filling up the screen.
PupThings (or PupConfig)
You will also need to run PupThings.bcd or PupConfig.bcd. The only difference between PupThings and PupConfig is that PupThings knows how to plow ahead when booting even if it is the only gateway on a network, and its parameter file is sensible. PupConfig will get stuck complaining about 981 if it is the only gateway when booting.
Remote Control
It is also very handy sometimes to have a way to remotely control a DLion PupGateway, such as when a wizard is trying to find and/or fix some gateway related problem somewhere in the internet. With this in mind there is an additional convention that should be followed when building the User.cm and parameter files. By including two dummy .cm files on the gateway and also having one of them executed every time the server is rebooted remote control is clumsily achieved.
An example "InitialCommand"
An example "InitialCommand" that will achieve all of the above is shown below. Normally, both Rem.cm and Null.cm will be zero length (but existing) text files.
InitialCommand: @Rem.cm Copy Rem.cm ← Null.cm; Copy Old.typescript ← PupGateway.typescript; Run PupThings.bcd RS232CIOHeadsDLion PupGateway/i
Dicentra
As mentioned earlier, Dicentras Don't have disks and depend on a boot server to get started. The Germ (which is in PROM) loads the desired program over then net. The boot file number and which device to boot from can be stored in the EEPROM. The default is to boot NS boot file number 25200002000 from the first 10MB ethernet board. By convention this is OscarDicentra, the gateway program. You can also use the Alt-Boot button to manually select an alternative boot file or device.
MP codes in the 92x range will be shown while booting. If you make it to 990 then you have successfully loaded the boot file.
The Dicentra also needs an NS time server to get started. You'll get an MP of 1937 if it can't find one.
Dicentras can be booted with a blank parameter file. Once booted, you can use (Pup) Chat to load a new or modified parameter file. A Dicentra booted with a blank parameter file will know of any phonelines connected. NB: If the existing parameter file stored in the Dicentra has some sort of bug in it it will send you to 915 every time.
The way to deal with a bad parameter file is to boot BootMeAgainDicentra (Alt-boot 241, read the section on Alt-booting). BootMeAgainDicentra will smash (wiped clean) the "broken" parameter file. Let BootMeAgainDicentra run a while, it takes about 15 minutes. Once the file is smashed boot OscarDicentra again and start over by fetching a working version of the parameter file.
Current versions of both OscarDicentra.boot and BootMeAgainDicentra.boot can be gotten from [Dexter].
4. The Parameter file
All PupGateways should have a parameter file. This file is used to configure the gateway and to control various aspects of its operation. The parameter file is parsed by the same routines that parse the User.cm file. The general format is "entries" within "sections". Read the XDE documentation for the syntax details if you are unfamiliar with User.cm files. In general it's probably good enough just to look at an existing, working, parameter file on some other machine if you are unfamiliar with the format.
The various different parameters recognized by PupGateway are described throughout this manual in the appropriate places.
The parameter file on DLions is pointed to by the "ParameterFile" entry in the [Indirect] section of the User.cm. By convention this parameter file should be named GatewayName.txt where GatewayName is replaced by the actual name of the gateway.
The parameter file on Dicentras lives in the two EEPROM chips on the Misc board. Don't forget that if you swap out the Misc board the machine looses its parameter file. Also, remember that you can use BootMeAgainDicentra.boot to smash a bad parameter file. You can type the contents of the current parameter file or fetch a new parameter file using Chat.
5. Pup-Network.txt
General
Pup-Network.txt is the text file that is at the heart of the Pup Name database. Pup-Network.txt lives on [Indigo]<Portola> and is readable by virtually anyone. This text file provides the mapping between PUP names and addresses. There is an XDE tool called NetDirBuilder that is used to convert this text file into the two "machine format" files: Pup-Network.directory and Pup-Network.big. These two "machine format" files are the files that are actually passed around between the Pup Name servers.
NetDirBuilder
NetDirBuilder is a tool that comes with the XDE (DLion) version of PupGateway that is used to generate new versions of the Pup name database based on Pup-Network.txt. It provides a means of coordinating updates to the Pup-Network database by using the Librarian (Marion, presently located in Sunnyvale) to limit edits of Pup-Network.txt to one person at a time. NetDirBuilder also parses the new file for validity, creates the new versions of Pup-Network.directory and Pup-Network.big, and then becomes a Pup Directory server in order to start propagating the new version of Pup-Network throughout the network.
Pup-Network.txt has a syntax definition and some general guidelines spelled out in the begining of the file. In addition to all of things mentioned there be aware that you should not use 0# or 377# for any network or host number. These are special values and will result in chaos if used for a particular net or machine.
Updaters↑.internet
To be able to run NetDirBuilder you must be a member of Updaters↑.internet. Being a member of Updaters↑.internet is what is referred to as "being an Updater".
Being an Updater is not something to be taken lightly. Pup-Network.txt is the "heart" of the PUP world (and to some degree other worlds such as NS and TCP too) and mistakes can cause disasters if not just confusion and a lot of hassles. Updaters are held responsible for any and all changes that they make. Also, Updaters must follow "NetDirBuilder Etiquette". Failure to act responsibly or to follow NetDirBuilder Etiquette will result in lose of privilege -- and the wrath of GatewaySupport↑.pa.
"NetDirBuilder Etiquette" basically says that you are not the only one who needs to make updates and that you should be courteous to others:
Do not make changes to information in Pup-Network.txt that "isn't your" unless you have explicit permission from the "owner" to do so. This basically means to confine yourself to information pertaining to the networks that you directly support.
Do not keep Pup-Network.txt LOCKed any longer than necessary. This means only checking it out when you are fully ready to make updates, and checking it back as soon as you are done. The only excuse for keeping the file overnight is server failure.
To enforce this etiquette all Updaters should follow the following procedure:
If you have the Pup-Network.txt checked-out for more than three hours you should send a message to Updaters↑.internet with the reason why you still have it checked-out and ANOTHER message to Updaters↑.internet when you actually check it back in.
If you go to check out Pup-Network.txt and get a "Error, <Pup>Pup-Network.txt: Already checked out by ..." message and that person has had it for more than three hours (and they have not sent a reasonable explanation to Updaters↑.internet) then you should send a message to Updaters↑.internet with the complete error message and the time that you encountered this error.
This should exert pressure on possible offenders and/or point out problems with Marion or Indigo. Offenders stand a very good chance of losing Updater privileges.
Hints on using NetDirBuilder:
You can UNLOCK the file as soon as NetDirBuilder says that the file parses OK and that it is starting the directory server.
To become an "Updater"
There are three steps to becoming an Updater:
1) Updater membership is limited to only a few people per "site", where "site" is roughly analogous to network support groups around the internet. If your site already has its "quote" of Updaters then no more will be allowed. This determination is made by GatewaySupport↑.pa.
2) If GatewaySupport↑.pa has "approved" you to become an Updater then you should get an existing Updater to show you what updating is all about. Next have them lead you through one or two updates; both doing the whole process together.
3) Once #2 has been done the teacher should send a message to GatewaySupport↑.pa indicating so. At that time a wizard will add the "student" to the list that grants them Updater privlidges.
6. Warnings and Cautions
This section is just a catch-all for things that I haven't found a better place for, yet.
Don't "get fancy" with your gateway. Running various hacks and gimmick on a PupGateway can lead to some very strange problems. One in particular that comes to mind is running PupChat in server mode. When you do this the Chat tool steals the Pup Misc Server socket out from underneath a number of servers such as the Dir server that makes sure that the server stays up-to-date with the rest of the world as far as Pup-Network.directory and Pup-Network.big go. Problems such as this can be a royal pain to track down.
7. Common Problems and Fixes
Half-up Phone Lines
When two machines are connected via a phone line, you can really think of them being connected via two separate paths, one from machine A to machine B, and the other machine B to machine A. Usually, when something affects one path it affects the other at the same time. Examples of this might be the RS232 plug not being plugged into a machine or modem, or a phone company cable being severed by a work crew somewhere. The result is that machine A and machine B can either communicate with each other when everything is fine, or they can't if something is "broken".
Occasionally one path will be affected independently of the other. If machine A can hear machine B but machine B can't hear machine A, we have what we call the "Half-up" problem. Half-up can be caused by bad circuits in one side of a modem, bad connections in an otherwise good cable, etc. Since machine A can hear machine B it will think that it can send packets to any networks that machine B has in its routing tables, and it will include routes to these nets in its own routing table. However, every time A actually sends a packet to B, B never hears it because that path is down. The bottom line is that routing tables (in this case the tables in A) can be deceiving in the Half-up situation. You should try and echo packets off of the gateway on the far end. If you don't get any response then this might be the cause of the problem.
If you forget the "password" value and/or incorrectly use the values "NIL" or "DLion" in the "SDLC" entry in a Dicentra parameter the phoneline may exhibit a behavior very similar to "Half-up". Check the information for the proper use of the "SDLC" entry in the [Gateway] section of this manual (chapter 8).
CRC errors on phonelines
Virtually all Xerox equipment (DLions, Dicentras, the Multi-port board for the DLion, Daybreaks, etc.) has the same design flaw (some call it a feature) in the RS-232 circuit. The line receivers are biased to shift the 1/0 threshold to something unreasonable (-4 volts?, I don't remember off hand). What this means is that some modems don't work and/or work poorly with our equipment. Fortunately, the solution is very simple. Simply remove the DIP/SIP resistor pack(s) that bias the line receivers. With the bias resistors gone the chips now operate with their threshold at roughly 0 volts, exactly what you want!
Echo Problems (aka, Big Buffers strike again)
If you echo from a PupGateway to another machine, be it PupGateway or not, sometimes the echo will appear to "break" after a number of echos have succeeded. The problem has to do with bigbuffers vs non-bigbuffers. The source of the echo cycles through its concept of min to max size packets and then back again, in a continuous loop. If the sender is a bigbuffer machine and the receiver is a non-bigbuffer machine then the echo will appear to break after ~530 packets. If you let it run long enough it would actually start working again when the sender wraps around to min size packets again. If the sender is a non-bigbuffer machine and/or the receiver is a bigbuffer machine then everything will work fine over the full range of sender packet sizes.
Ethernet Connectivity Problems
Every gateway will always advertise, via routing tables, that it can reach the networks that it is directly connected to. Problems arise when some, but not all, of the interfaces are not actually connected. It doesn't matter if the reason is failed hardware or simply an unplugged cable. When this happens, the gateway will continue to broadcast what amounts to bogus routes to the unconnected networks on all of the connected networks. This is because the gateway has no way of knowing that it is no longer connect to the networks in question.
This isn't much of a problem with phone lines, because the phoneline itself isn't very interesting to machines other than the gateways. By interesting we mean that there are no end hosts connected to that particular network that any other end host on the internet would want to communicate with. Routing table traffic (or lack thereof) will maintain good routes to the interesting nets. Ethernets, on the other hand, are interesting to machines other than just the gateways and therefore are subject to this type of failure.
What to do when an Ethernet goes dead
Every once in a while an Ethernet stops working and affects (virtually) every machine connected to it (or at least to a given segment if repeaters are used). How do you deal with this type of problem?..
First of all you, should read and understand "The Blue Book" (the actual title is "The Ethernet, A Local Area Network"). This is the definitive standard for the physical and data link layers of the 10Mb Ethernet. All Ethernet terms (such as Section, Segment, Repeater, ...) are explained; limits are defined (such as cable lengths, repeater configurations, ...); timings are explained and tallied; pinouts are given; waveforms are shown; etc. If you are going to work on Ethernet problems you will need to understand this document.
Remember, "The Blue Book" and the discussion that follows below all pertains to 10Mb Ethernets. 3Mb Ethernets are similar but differ by more than just speed. 10Mb nets terminate in 50 ohms; 3Mb nets terminate in 75 ohms. 10Mb nets vary between 0 and -2.05 volts; 3Mb nets vary between 0 and +3 volts. 10Mb nets have "The Blue Book"; 3Mb nets have "The Ethernet Local Network: Three Reports" (Blue+White CSL-80-2).
Page 73 of The Blue Book shows what the waveform on a healthy cable should look like. When there are no packets on the cable there should be no signal on the cable (no AC and no DC). A good packet drives the cable between 0 and -2.05 volts (let's call it -2 volts for simplicity). The further you are from the source of the packet the lower it will read, but the general idea is that it is bounded by 0 on the plus side and -2 on the minus side.
To look at the signal with a scope you need to gain access to the center conductor of the coax without otherwise disturbing the cable. There are at least two ways to do this. If you are at a place in the cable where there are coax connectors, either at one of the ends or a section break, you can use a coaxial T connector to gain access. If you aren't at such a location or if you don't have the T connector, then you can tap in at a "tap, remove an existing transceiver is necessary. Don't forget to ground the scope probe to the shield of the cable and to use DC coupling. Also, make sure that the probe is set to high impedance.
Packets should be distinct bursts on the cable. Be careful, if you set the scope to too fast of a sweep time a single packet will be wider than the scope's screen and you can get easily fooled; too slow and you'll just see what look like spikes. A setting somewhere around 100uSec per division should be good. Also, don't forget that the amplitude of a signal will decrease with distance from the source of that signal. Therefore, even on a healthy cable, you will see packets with different amplitudes (but at least some should be near 2V P-P).
If you see a continuous signal on the cable then you probably have a bad transceiver or a sick machine "singing" on the net.
If you see distinct bursts but their amplitude is very small (no signals greater than 1 volt Peak-to-Peak), or if the bursts look as if they are going positive, then you probably have a short or open on your cable somewhere.
If you don't see anything on the cable then you probably have your scope set wrong or are right at the location of a short.
Check for missing terminators, open sections, shorted taps, etc. A tiny wire from the shield of the cable shorting to the center pin of a transceiver is not an uncommon problem. If you've installed or moved any taps recently this is a good place to check first. If you still haven't found the problem, then the best way to locate a problem like this is to break your cable at sections. Simply undo the barrel connector and to put a terminator on each piece. Now check each piece with the scope and see which is ok and which is still bad. Depending on how your cable is sectioned this can help narrow things down considerably.
In certain cases you can also use a TDR (Time Domain Reflectomometer) to help locate the problem. I won't go in to details here on how to use the TDR since few sites have them and even fewer have people who know how to use them correctly.
MP 981 and Pup Registration Problems
When a machine on a 10Mb net, such as a DLion, comes up (after power-on and/or being booted) all that it knows from its hardware is its 48 bit id. At this point, if it intends to speak PUPs, it uses an NS packet, and hence its 48 bit id, to request that someone tell it its 8 bit PUP host number. Servers that understand this protocol, PupGateways in particular, reply using information that they have from Pup-Network.txt. If the requesting machine doesn't get an answer after some number of retries, it dies with an MPC of 981 indicating that it can't figure out its PUP host number.
Problems arise when the machine is registered, but on the wrong net! Most systems (XDE, LISP, ...) simply ignore the returned network number and overwrite it with the number of the network that they are currently connected to, only using the returned host number. This is the problem that can lead to two registered machines conflicting on the same net; they each have the same host number but on different nets, but they ignore the net and clash! When two machines try to use the same PUP id they can get very confused.
Gateways keep a cache of 8<->48 translations to use when routing packets. Translations are needed for sending packets over networks where the physical and logical addresses differ. For example, if a gateway gets a packet destined for PUP host #45# on a 10 Mb network, it needs to know what 48bit physical id to put on the wire for the logical PUP host #45#. (The same thing is true for NS packets on 3 Mb nets.) On PupGateways these cached entries are updated/flushed every 3 minutes. This is why looking at a gateway's translation table is only useful if checked right away.
If you have a machine that occasionally (or not so occasionally) has problems when trying to use PUP protocols but is fine when using NS protocols then you might want to check this angle out. The next time the problem is actively happening, you need to check the translation cache of some gateway that the troubled machine is trying to use. Use PupChat to talk to a Dicentra PupGateway (from a working PUP machine) or select the proper menu item on a DLion PupGateway and "print translation Cache(s)". This will enumerate its current 8<->48 bit translation cache, by net.
Under the proper net, look for the host number of the PUP machine that isn't working (it's just a plain octal number without any # signs on the left hand side of each entry) and then look at the current Translation value (on the right hand side) -- this is its 48 bit address on the 10Mb net. Normally, this should be the id of the intended machine but in this case it will probably be the id of some other machine; this is the culprit machine's id!
Now, using NameLookupTool (or NameAndAddressTool) and/or a current copy of Pup-Network.txt, lookup the 48 bit address. If you find it then this will usually lead you to the offending machine somehow (via an owner comment or something),. Odds are that it is registered on some other net but with the same Pup host number as the machine that is having problems.
It may not be quite that easy...
Some systems (LISP in particular) have a "backdoor" where the user can specify the host id for that machine even though it's not registered in Pup-Network.txt at all. This is a definite NO-NO but some people do it anyway from time to time. (They usually just don't know any better.) In this case there may be no record in Pup-Network.txt at all for that particular 48 bit id. At that point you have to carry the 48 bit id around with you and start checking the id of every machine on the net, usually in areas that you don't know very well first. Look for LISP users first; they are often the worst offenders because LISP makes it so easy to plow ahead.
If the troubled machine is definitely using the gateway that you just checked (don't forget about the 3 minute timeout) but you can't find its PUP number or its 48 bit id, then it isn't using the 48 bit id that you think it is. In this case a good place to start would be to use Othello (or OthelloTool in XDE) and verify the machines host number (48 bit id). Odds are that somehow its host id PROM got changed or fell out (I've heard of it happening) and that it is no longer what you thought. Assuming that this is the problem then once you find out the correct number all you have to do is to properly re-register it and then you should be home free.
8. Routing and the [Gateway] section
"Gateway" vs "Router"
In the PupGateway world the terms Gateway and Router are interchangeable; they both refer to something that passes internet level packets between two or more networks or systems. Be warned, in the product world they "redefined" Gateway to mean a Mail Gateway. A Mail Gateway is something that connects two or more networks or systems together in such a way that only electronic mail is allowed to pass. In the PupGateway world if we ever mean a Mail Gateway then we say Mail Gateway.
"The Gray Book"
"Internet Transport Protocols" (Xerox Systems Integration Standard publication XSIS-028112) covers NS routing in addition to a number of other interesting low-level NS protocols. This is recommended reading for anyone working with gateways. The Chapter on routing (Chapter 4; "Level two: Routing information protocol") does a pretty good job of explaining routing and routing table maintenance. Read this chapter for the full details.
Pup routing and routing table maintenance is very similar (although not identical) to that described for NS.
Routing Tables and Routing Table Maintenance
Every machine on the internet maintains a routing table. This table is consulted every time a machine sends a packet to a destination machine with which it can not communicate directly. This consultation is necessary because it must send the packet to an intermediate host who is closer to the destination machine than itself. This intermediate host is called a gateway or router. If the router can not communicate directly with the destination machine then it too follows the exact same procedure as the previous machine. In this manner the packet travels from the source to the destination through as many routers as needed via the "best" path at every step along the way.
The routing table consists of a number of entries, one for each network in the internet. (NB: Some workstations don't maintain full routing tables all the time. The reasons are explained in the gray book. Consider this, for the most part, an implementation detail.) Each entry contains: the number for the network that it represents, the intermediate host that should be used to reach that network, the current "distance" to that network in "hops", and the "age" of the entry.
All gateways gratuitously broadcast their complete routing tables periodically (about once every 30 seconds). It is this gratuitous broadcasting (and the willingness to forward other machines packets) that makes a gateway a gateway. All machines, gateways and workstations alike, maintain their own routing tables by using this gratuitously broadcasted routing information to update the individual entries in their table.
Age and hop count are the keys to maintaining a routing table. When entries are first created or updated their age is set to zero. Entries are deemed "suspect" if their age is 90 seconds or greater. Entries are "discarded" when their age hits 180 seconds or greater. (Discarded may actually mean discarded or it may simply mean having their hop count set to logical infinity.)
Whenever you receive incoming routing information you update every entry in your table that is mentioned in the incoming information.
To "update" an entry:
1) Replace the hop count if the new hop count is lower.
2) Replace the hop count if the incoming hop count is equal to or greater than the existing hop count AND the age of the entry is "suspect".
3) Replace the intermediate host information if you've replaced the hop count in #1 or #2.
4) Set that entry's age back to zero.
Using this scheme you should notice a few interesting things:
1) After its initial creation your routing table should only change when the topology of the internet changes.
2) Unless an entry in it's table gets changed due to a change in topology a given machine will use one and only one particular router to reach any given net -- even if there are multiple equal-length paths.
3) If a gateway dies it will take at least 90 seconds before a machine will find alternate paths for the networks that it presently has the dead gateway as an intermediate host for. It may take 3 minutes or even longer to find the correct new path or to find out that one of the affected networks is now totally inaccessible.
4) A given machine only determines the next machine who should receive the packet. It does not determine the complete path for multiple-hop paths.
Real-world Limits and Picky Details
The current permissible range of hop counts is from 0 to 15. Any hop count of 16 or greater is considered to be infinity. This limits the "diameter" of our internet to 16 hops (0..15).
Every packet that is transmitted has a counter which is initially set to zero. Every time the packet passes through a gateway the gateway adds +1 to the counter. If this counter ever reaches 16 or greater then the gateway deletes the packet. This is to prevent packets from traveling around the internet for long periods of time due to topology transitions or routing bugs. This also limits the "diameter" of our internet to 16 hops.
There is actually a +1 that is done whenever you "Replace the hop count" as described in the To "update" an entry algorithm. This is what makes the distance to a network grow as you get further away. The NS and PUP protocols do the addition at slightly different places. In the NS world you add the +1 to each entry just before you transmit it. In the PUP world you add the +1 to each entry when you receive it.
PupGateways have a hack that allows them to add more than just +1 to each entry. This is called "Extra Hops". Extra Hops can be used to make certain routes less desirable than they would otherwise look. This can be very useful because the normal "hops" metric doesn't reflect the speeds of different routes such as a 9.6Kb path vs a 56Kb path. NB: Do not use "Extra Hops" on a gateway without first getting an explicit OK from a wizard. "Extra Hops" have to be carefully tweaked in order to be a help rather than a hindrance.
The [Gateway] Section in the parameter file
[Gateway] -- DLion
Ethernet: BoardNumber PupNetworkNumber NSNetworkNumber
Describes each 10Mb Ethernet interface. There should be as many EthernetOne entries as there are 10Mb boards.
BoardNumber -- The first board is 1, the second 2, etc
PupNetworkNumber -- in octal, with no #. For example: 131
NSNetworkNumber -- either octal or product format. For example: 131 or 0-089
EthernetOne: BoardNumber PupNetworkNumber NSNetworkNumber
Identical to "Ethernet" but describes 3Mb Ethernet interfaces. Note: although this parameter exists there is no 3Mb Ethernet board for the DLion and therefore this parameter should never get used.
Leased Line: LineNumber PupNetworkNumber NSNetworkNumber
Similar to "Ethernet" but describes Phone Lines.
NB: the first (and only) line is line 0.
Pup Host Number: PupHostNumber
PupHostNumber -- The machine's Pup host number in octal, no #'s.
Buffers: Buffers
Buffers -- Add this many buffer, in decimal, to the system pool. 50 is a good number.
Priority: Priority
Priority -- Set the priority of the router to this decimal value. Defaults to normal, which is fine.
Typescript: Pages
Pages -- Set Pupgateway.typescript to be this many pages long.
Deactivate Herald Window: Boolean
Deactivate the Herald Window if TRUE.
Disable NS Routing: Boolean
Disable NS Routing if TRUE. Pup Routing always runs.
Extra PUP Hops: ExtraHops
Add this many additional hops to all entries in the Pup Routing Table.
Extra NS Hops: ExtraHops
Add this many additional hops to all entries in the NS Routing Table.
Extra Hops: ExtraHops
Add this many additional hops to all entries in both the Pup and NS Routing Tables.
For backwards compatibility ExtraHops can be a boolean instead of a decimal value. In this case FALSE is the same as 0 and TRUE is the same as 1.
[Gateway] -- Dicentra
Ethernet: BoardNumber PupNetworkNumber NSNetworkNumber
Same as DLion.
EthernetOne: BoardNumber PupNetworkNumber NSNetworkNumber
Same as DLion.
SDLC: LineNumber PupNetworkNumber NSNetworkNumber PupHostNumber Password
Describes each phone line. There should be as many "SDLC" entries as there are phone lines.
LineNumber -- The first line is 0, the second 1, etc.
PupNetworkNumber -- in octal, with no #. For example: 131
NSNetworkNumber -- either octal or product format. For example: 131 or 0-089
PupHostNumber -- in octal, with no #. For example: 357
Password -- A string which will be used as the key to DES encrypt this line. The gateways on both ends of the line must use the same key. NB: there are two special cases. If the string is equal to "NIL" then no encryption will be done. If the string is equal to "DLion" then no encryption will be done AND the gateway will delay for approximately 7ms between sending packets. Without this delay a Dicentra will over-power a DLion on a 56Kb link.
Pup Host Number: PupHostNumber
Same as DLion.
Buffers: Buffers
Same as DLion.
Priority: Priority
Same as DLion.
Disable NS Routing: Boolean
Same as DLion.
Extra PUP Hops: ExtraHops
Same as DLion.
Extra NS Hops: ExtraHops
Same as DLion.
Extra Hops: ExtraHops
Same as DLion.
9. Boot Service
There are two general categories of boot service, NS and Pup. DLions can act as full fledged boot servers. They can hold a number of files on their disks and supply these files to boot service clients as requested. Dicentras have to fake it since they don't actually have a disk. What Dicentras do is to forward incoming boot request to some other boot server or net in hopes that some other machine will actually honor the request.
[BootServer] -- DLion
The BootServer section contains a number of entries, each representing a mapping from a boot file number to a particular file. There can be as many entries as appropriate. It is customary to keep a "full" list of files in this section and to simply comment out those entries which you don't want to supply. Look on [Dexter] to see exactly what I mean.
Alto: BootFileNumber BootFileName
Uses Pup boot protocol.
BootFileNumber -- The octal number for this boot file.
BootFileName -- The name of the file to supply when this number is requested.
DLion: BootFileType BootFileNumber BootFileName
Uses NS boot protocol.
BootFileType -- One of: Microcode | Germ | Boot | Pup | Other
BootFileNumber -- The octal number for this boot file.
BootFileName -- The name of the file to supply when this number is requested.
Dicentra: BootFileType BootFileNumber BootFileName
Same as for "DLion".
Dove: BootFileType BootFileNumber BootFileName
Same as for "DLion".
Other: BootFileType BootFileNumber BootFileName
Same as for "DLion".
DLionTrident: BootFileType BootFileNumber BootFileName
Same as for "DLion".
Dorado: BootFileType BootFileNumber BootFileName
Same as for "DLion".
D0: BootFileType BootFileNumber BootFileName
Same as for "DLion".
Pup D0: BootFileType BootFileNumber BootFileName
Same as for "DLion" but uses Pup boot protocol.
[BootServer] -- Dicentra
Remote: NetworkNumber Target
NetworkNumber -- The number of a network, in octal or product format, to forward boot requests from.
Target -- The Pup name or address (in the standard "#" notation) of a machine or network to forward these boot requests to.
[PupBootServer] -- Dicentra
Remote: NetworkNumber Target
NetworkNumber -- The number of a network, in octal, to forward boot requests from.
Target -- The Pup name or address (in the standard "#" notation) of a machine or network to forward these boot requests to.
10. Pup Name Service and Pup Dir Service
Pup Name Service, also known as the Name Lookup Server or NLS, enables clients to translate between Pup names and addresses, and vice-versa. Read the Pup-Network.txt section of this manual for information on how this information is maintained and used.
DLions provide full fledged NLS because they can store the entire database on the local disk.
Dicentras don't have a copy of the directory, but they keep a BIG cache of things they find on other servers so they can pass the service on to clients on adjacent nets.
PupDirServer is the server that allows one PupNameServer to probe another PupNameServer to check on what version of the Pup-Network database, known as the directory, each is using and to allow propagation of new databases between servers.
Dicentras also have a PupDirServer even though they don't have a directory to pass around. If and when they see a new version of the directory they flush their cache. At first this seems correct and adequate, but it isn't. The problem is that it may see a new directory on some server, flush its cache, and then proceed to fill it from a different server that still has the old information. This has not been fixed yet but it also doesn't seem to cause much of a problem. Just be warned that Dicentras are sometimes slow in noticing changes in the directory.
Dicentras are also willing to forward netDirVersion requests for Pup boot servers to keep IFSs happy. To do this they need a parameter file entry. Not that a Dicentra [PupDirServer] section is only needed for 3Mb nets.
[DirectoryServer] -- DLion
Remote: Target
The gateway will automatically check for new directories on machines that are on networks that are directly connected to this machine. The "Remote" entry is a way of peeking at some further away machine or machines. You may have a number or "Remote" entries.
Target -- The Pup name or address (in the standard "#" notation) of a machine to check for new versions of the directory on.
[PupDirServer] -- Dicentra
Remote: NetworkNumber Target
NetworkNumber -- The number of a network, in octal, to forward directory requests from.
Target -- The Pup name or address (in the standard "#" notation) of a machine or network to forward these requests to.
11. FTP Server
DLion versions of PupGateway run a Pup FTP server. In order to do some FTP operations you must be a member of an associated access control group for the particular server. The default group is machine.internet, where machine is actually the name of the given this machine. The FTP operations List and Retrieve are available to all users. Store, Delete and Rename are only available to those who are members of the access control group.
Since the Dicentra has no disk it also doesn't have an FTP server.
Some particular files are of special interest on gateways:
PupGateway.typescript is the gateway's log file. Many things that the gateway does generate a log entry in this file. Sometimes you have to look closely but often a problem can be found or solved simply by looking at this log. The first so many lines of the typescript are not over written so that you can always look at the information that the gateway logs when it first starts up. the rest of the typescript operates in wrap-around fashion so that you can always see what the gateway has been doing in recent history. The size of the typescript file can be controlled by the "Typescript" entry in the [Gateway] section of the parameter file.
User.cm is just like any other User.cm, it can affect the operation of the whole machine. On section of particular interest is the [Indirect] section. The "ParameterFile" entry contains the name of the parameter file. By convention, this parameter file should be Machine.txt, where machine is actually the name of the particular gateway.
Machine.txt, where machine is actually the name of the particular gateway. This is, by convention, the parameter file for the particular gateway. Check the User.cm to verify this.
Initial.log holds the log of the results of the "InitialCommand"s. This is a good place to check to see if a machine is getting started properly.
[FTPServer] -- DLion
My Group: GVGroup
GVGroup -- GV group for access control of this machine. This entry will default to machine.internet, where machine is actually the name of the given this machine, if this entry is omitted. There should at most be one "My Group" entry.
Password: User PasswordBlock
User -- The name of a GV user whose encrypted password follows.
PasswordBlock -- 8 octal numbers representing the encrypted password for the indicated user. There is a PasswordTool.bcd that comes with the DLion version of Pupgateway that can be used to generate these 8 octal numbers. There may be a number of "Password" entries all representing different users. "Password" entries override GV. In general, "Password" entries are not used anymore.
12. Host Watcher
Host Watcher is not a server but a way of keeping track of other servers. The basic idea is that every so often (about 15 minutes) the Host Watcher tries to contact some list of machines and keeps track of their status, such as being up or down, reachable or unreachable, etc. When the status changes in an interesting way the Host Watcher mails a message to some list of recipients indicating the previous and current status.
Host Watcher understands a number of different protocols such as Chat, FTP, etc. The full list is in the parameters specification.
The order of entries within the "HostWatcher" section is significant. Troubles, to, cc, and Full entries superceed previous ones and their current value is used for the following hosts. There may be a number of any type of entries.
Host Watcher does not run on Dicentras.
[HostWatcher] -- DLion
Troubles: GVNames
GVNames -- A list of GVNames to send messages to if troubles are encountered when sending the normal message.
to: GVNames
GVNames -- A list of GVNames to send messages to whenever the state of the indicated host changes.
cc: GVNames
GVNames -- A list of GVNames to copy in when sending messages.
Full: GVNames
GVNames -- A list of GVNames to send messages to when the given host is full.
Gateway: machineName
machineName -- The Pup name of a machine to poke using gateway protocols.
Chat: machineName
machineName -- The Pup name of a machine to poke using Chat protocols.
FTP: machineName
machineName -- The Pup name of a machine to poke using FTP protocols.
Mail: machineName
machineName -- The Pup name of a machine to poke using GV Mail protocols. This doesn't actually work, use Chat for GV servers.
Librarian: machineName
machineName -- The Pup name of a machine to poke using Librarian protocols.
Printer: machineName
machineName -- The Pup name of a machine to poke using Spruce protocols.
EFTP: machineName
machineName -- The Pup name of a machine to poke using EFTP protocols.
PopCorn: machineName
machineName -- The Pup name of a machine to poke using Chat and a "PupCorn" dialogue.
Debug: Boolean
Boolean -- used for debugging
13. Time Server and Time Checker
There are three main time protocols around these days: OldPup, NewPup, and NS. IFSs don't understand NS protocols. Product Services don't understand PUP protocols. PupGateways understand all three. The important thing to realize is that even though they are different protocols, they are still very interrelated. Some environments, such as Cedar (maybe LISP too), will get their time parameters from Pup or NS time servers -- their not picky. Also, even though Product Services only talk NS protocols they ultimately get the TRUE time from PupGateways who get it from PopCorn (using PUPs by the way).
In order for a PupGateway to run as a time server it must find the [TimeServer] section in the parameter file and it must be properly filled in. The Correction, Drift, Wobble, DST, and Zone must all be specified in order to activate the time server. If, when the TimeServer starts it enters into the log (PupGateway.typescript on a DLion) something to the effect "the time parameters on this disk are wrong" that means that it also will not start the time servers (although it never says that outright). See the Pilot Manual section on time to understand exactly what the numbers for DST mean. See the DST section below for information on how to change the DST if it ever becomes necessary.
Once the time server is running it will "track" the other time servers automatically.
The TimeChecker is independent of the time server and is optional. It compares its time against the other time servers specified and will mail periodic messages indicating the results. Additionally, if PopCorn and Threshold are both specified, then the TimeChecker will reset the TimeServer's clock when it differs from PopCorn by more than Threshold milliseconds (taking into account error bounds etc). DO NOT ADD PopCorn and Threshold to any gateway without first getting an explicit OK from a wizard. (PopCorn can get overloaded and the network can get confused.)
Times always maintained as GMT. ZONE is only used for the interpretation of the time, such as rendering in printed form, and does not affect the correctness of the time.
How the time is maintained on the Xerox internet
As mentioned above, the ultimate source of the TRUE time is PopCorn. PopCorn is a "magic" box that sits in the Clover printer room (2106) at PARC. It's a satellite receiver that listens to a time satellite(s) and also connects to the Ethernet via an RS232 line and the DLS. PopCorn has a very accurate internal clock. It also understands things like the speed of light, clock drift, transmission delays and rates, etc. The end result is that you can ask PopCorn the time over the network and you get back a very accurate answer, including error bounds.
This is exactly what some PupGateways do. Every so often a few hand-chosen PupGateways ask PopCorn the time. If PopCorn's answer is more accurate (read the code for the fine print) than their own concept of the current time (modulo some delta) then they adopt PopCorn's answer as their new concept of the current time and give it a new version number.
Independent of what is going on with PopCorn all NS time servers periodically (on the order of 15 minutes to an hour) compare their time to that of the other, usually nearby, time servers. They update their concept of the time from someone else if and only if the other machine has a newer version (this is how PopCorn becomes the ultimate authority) or if the other machine has a better concept of the current time (modulo some delta) when error bounds are taken into account. Again, read the code for the real fine print.
IFSs set their clock via the net when they boot but after that they don't track the other timeservers. This is why you should disable the time service on your IFS. The PupGateway will supply a more accurate time. If you have an IFS that deviates from the correct time to can help things by adjusting the "Clock correction" parameter on the IFS.
How did PopCorn get its name?
Here's a bit of folklore for you. From PARC the local telephone number to call for the current time is 767-2676, which can be dialed by spelling POPCORN on the telephone!
Changing the Daylight Savings Time
This year (1987) the U.S. changed the official start day for Daylight Savings Time. Since we may someday need to do something similar again (and because it has some other interesting information in it too) the information on how to do the conversion is reproduced below:
Product time servers and PupGateway time servers interact. Not updating both may cause the other to become "undone".
1) The parameter files of all PupGateways should be updated to reflect the change. To do this change the DST entry in the [TimeServer] section of the parameter file as indicated below. (These numbers are particular to the change made in 1987.)
DST: 121 305 ==> DST: 98 305
2) Reboot all PupGateways once the parameter files have been changed.
While rebooting, the gateway will ask the other time servers on the local net what they think the DST parameters are. If a time server providing the new time parameters answers then all is fine. If, on the other hand, a time server providing the old DST parameters responds then the booting gateway will use the old DST parameters. In this case, the gateway can either be rebooted (in hopes that it will get an updated time server this time) or, if the server you are trying to boot is a DLion, you can fetch and run the same ChangeDaylightSavingsTimeStartToDay98.bcd file as for product services. This bcd is available from [Indigo]<PupGateway>Sequoia>Temp> if you do not already have it.
To aid you in doing the upgrade, there is a tool called TestTimeServer.bcd available from [indigo]<PupGateway>Sequoia>Friends>. This tool runs under XDE 12.0 and can be run on a PupGateway or a workstation. It allows you to poke your time servers and ask them what DST parameters they are providing. There are six "command!" buttons but only use the "AskRemote!" and "LocalBroadcast!" buttons (unless you really know what the other buttons do). Keep in mind that the "RemoteAddress:" field takes an NS address and/or CHS name, not PUP addresses/names.
Keep in mind that many (most) clients of time service, such as workstations and other servers, only get time parameters upon booting. Because of this most machines should be rebooted after all of the time servers on the local net have been updated.
Parameters
TimeServer and TimeChecker both operate the same on the DLion and the Dicentra.
[TimeServer] -- DLion and Dicentra
Correction: millisecondsPerDay
millisecondsPerDay -- Positive or negative decimal number of milliseconds of correction to be added to the clock every 24 hours.
Drift: millisecondsPerDay
millisecondsPerDay -- Positive or negative decimal number of milliseconds of error that accumulates every 24 hours.
Wobble: millisecondsPerQuarterDay
millisecondsPerQuarterDay -- Quarter-day fluctuations.
DST: beginDST endDst
beginDST -- Indicates the first day of DST of the year. Read the Pilot manual for the fine print of how this number is calculated if you really must know. 98 is currently the correct number.
endDst -- Same as beginDST but indicates the last day of DST. 305 is currently the correct number.
Zone: sign hours:minutes
sign -- + or - to indicate west or east, + = west, - = east. California is +8.
hours:minutes -- Hours and minutes east or west. California is +8.
Flaky: Boolean
Boolean -- if TRUE then reset the clock via another time server every half hour and disable the Pup Time Server.
Disable NS Time Server: Boolean
Boolean -- default is FALSE (enabled)
[TimeChecker] -- DLion and Dicentra
Troubles: GVNames
GVNames -- A list of GVNames to send messages to if troubles are encountered when sending the normal message.
to: GVNames
GVNames -- A list of GVNames to send messages to whenever the clock is checked against another servers'.
cc: GVNames
GVNames -- A list of GVNames to copy in when sending messages.
Pup: machineName
There may be a number of these entries.
machineName -- The Pup name of a machine to periodically check the clock against using Pup Time Server protocols.
NS: machineName
There may be a number of these entries.
machineName -- The NS (ClearingHouse) name or address of a machine to periodically check the clock against using NS Time Server protocols.
PopCorn: machineName
There may be a number of these entries.
machineName --The Pup name of a machine to periodically check the clock against using Chat and a "PopCorn dialogue". Do not use this unless you get an explicit OK from a wizard. Too many and/or the incorrect machines "tied" to PopCorn can be harmful.
Threshold: milliseconds
milliseconds -- Clock fixup threshold in milliseconds. If you've specified a PopCorn machine and its clock differs from yours by more than threshold milliseconds then reset your clock to PopCorn's. The default fixup threshold is never. A reasonable value is 15 seconds which is 15000.
Example (from Dexter)
[TimeChecker]
Troubles: Sorenson.PA
To: Sorenson.PA, WIrish.PA
Cc: CPHarris.PA
PopCorn: PopCorn
Threshold: 15000
NS: Miragum:PARC:Xerox
NS: Donner:osbu north:Xerox
Pup: Ivy
Pup: Indigo
Pup: Cyan
Pup: Pixel
14. Other Servers and Services
Breather
Sends a RAW BreathOfLife Packet (it's not a PUP, it's not an XNS, it's a BreathOfLife) every 5 seconds or so on all directly connected 3Mb Ethernets. BreathOfLife packets are needed by Altos when booting from the net.
BSPSink
For testing and debugging purposes there is a BSPSink server in PupGateway. It accepts BSP connections and obediently dumps everything on the floor. This can be used for protocol and throughput testing.
There is no parameter section associated with the BSPSink server.
GateControlServer
GateControl is a Pup protocol for getting a "view" of a gateway in real-time. It also allows you to halt and restart a gateway remotely. As far as I know this protocol is totally undocumented, except by the code that implements it. Both DLion and Dicentra versions of PupGateway support this protocol.
There is a tool, GateWatcherTool, that comes with the DLion version of PupGateway that allows you to monitor and control a remote gateway via this protocol.
There is no parameter file for this server.
PupEchoServer
For testing and debugging purposes there is a PupEchoServer in PupGateway. Various statistic printouts include echo server information.
There is no parameter section associated with the Pup echo server.
PupMiscServer
A number of Pup servers actually use the same well know socket (WKS), the Miscellaneous services socket. The PupMiscServer is really just an umbrella server that dispatches to a particular server as a function of the Pup Type field. The servers that use the Misc socket are: boot, directory, name and time. The Misc server also supports the echo protocol (this is in addition to the echo server on the echo socket) and the whereIsUser/userIs protocol.
There is no parameter section associated with the Misc server.
TrapBadPups
If a PupGateway has a [TrapBadPups] section then it will detect and report, via GV mail, any Pup packets that it receives with good encapsulation but a bad internal packet. This usually points to sick software or a sick machine. These messages can be decoded to indicate the machine that was the source of the bad packet.
Sample Message:
Date: 11-Apr-88 18:49:41 PDT (Monday)
From: Hubbard.internet
Subject: Bad Pup Checksum info
To: BadPups↑.pa
cc: BadPups↑.pa
Reply-To: Sorenson.PA
11-Apr-88 18:49:28 ***** Bad software checksum on Pup from net 131
Bad pup number 3 has a checksum of 120717, but it should be 121017
Driver length: 32
Encap: 1140 106020 104445 0 125101 16011 1000
Header: 34 22 23107 101051 1721 41073 2027 54521 17102 116017
Body: 2706 4 13430
Decoding:
The Encap field is medium dependent. For 10Mb Ethernets the 4th, 5th and 6th words are the 48 bit host ID of the machine generating the packet. In the given example these words are 0, 125101, and 16011 respectively. These combine to give the 48 bit ID of 25220216011.
The Header field is the PUP header. The 8th word is the net and host of the machine generating the packet. In the given example the 8th word is 54521 and is equal to the PUP address of 131#121#. Note that, although often right, this word in the header might be corrupted -- remember, the checksum doesn't make sense.
Either way you decode the packet you should be able to lookup the machine in Pup-Network.txt either directly or via some sort of name lookup tool.
[TrapBadPups] -- DLion and Dicentra
Troubles: GVNames
GVNames -- A list of GVNames to send messages to if troubles are encountered when sending the normal message.
to: GVNames
GVNames -- A list of GVNames to send messages to whenever "Bad Pups" are detected.
cc: GVNames
GVNames -- A list of GVNames to copy in when sending messages.
Clump Size: Size
Size -- Clump size in decimal. Default is 3.
Seconds Per Packet: Seconds
Seconds -- Seconds per packet in decimal. NB: there seems to be a bug in the present implementation, this actually seems to set the "Clump Size" variable again. Default is 3600 -- one/hour.
Net Watcher
Net Watcher is not a server. It is a process on a PupGateway that watches the local machine's routing tables and prints a line to the log whenever it notices a change in the routing table. Since this is a separate process, and a very polite one at that (it does yields all over the place), it does not guarantee to log ALL changes of the routing table, but it does give a feel for the stability of the routing table.
There are two net watchers, one for PUP nets and one for NS nets.
[NetWatcher]
Disable: Boolean
Boolean -- Disable the Net Watcher. Default is FALSE (enabled).
[PupNetWatcher] parameters
[PupNetWatcher]
Disable: Boolean
Boolean -- Disable the Pup Net Watcher. Default is FALSE (enabled).
Translation Server
Gateways keep a cache of 8<->48 translations to use when routing packets. Translations are needed for sending packets over networks where the physical and logical addresses differ. For example, if a gateway gets a packet destined for PUP host #45# on a 10 Mb network, it needs to know what 48bit physical id to put on the wire for the logical PUP host #45#. The same thing is true for NS packets on 3 Mb nets. On PupGateways these cached entries are updated/flushed every 3 minutes.
See "MP 981 and Pup Registration Problems" under the "Common Problems and Fixes" section for more information on the Translation Cache.
15. Dicentra Commands
Boot Button -- Presses the Boot Button via software.
Boot From Ethernet -- Asks for the bootfile number, switches, and board [0..3] to use to do an NS boot from a 10Mb Ethernet.
Boot From Phone Line -- Asks for the bootfile number, switches, and line [0..3] to use to do an NS boot from a phone line.
Boot From Pup(3MB) -- Asks for the bootfile number, switches, and board [0..3] to use to do a PUP boot from a 3Mb Ethernet.
Cache Info -- Gives possibly interesting statistics of the Name Server Cache.
Cache Contents -- Enumerates the contents of the Name Server Cache.
Close -- Closes the connection established via open.
Debug -- Calls the TeleDebugger (dives into 915). Don't forget that the Watchdog timer is still running and will reboot the machine out from under you after so many minutes.
Directory -- Sets the default directory for remote file operations.
Echo User -- NS echo.
Fetch Parm File -- Fetch a new copy of the Parameter file over writing the old.
Gate Info -- Gives various interesting numbers regarding a number of servers and gateway functions. This information includes a traffic matrix in both packets and bytes between all directly connected nets.
Help -- Gives a brief one-line description of each command.
Info -- Gives some interesting info mostly regarding software versions and configurations.
List Remote Files -- Lists remote files matching a given pattern.
Login -- Login to the Dicentra with your GV name and password. This is not necessary for most operations.
Open -- Open a PUP FTP connection to the given server.
Power Off -- Execute System.PowerOff. This doesn't actually do anything because the Dicentra lacks the hardware to turn off its own power.
Print Device Statistics -- Enumerates all of the active network interfaces and gives interesting statistics for each. Ethernet means 10Mb Ethernet. EthernetOne means 3Mb Ethernet. PhoneNet means a phoneline, the current speed will be given on the right-hand side of the line.
One of the more interesting numbers (actually a set of numbers) given is the "Lds" line given for 10Mb Ethernets. "Lds" is actually printed for 3Mb Ethernets (EthernetOne) too but it is non-interesting, the last 15 numbers will always be zero because of a lack of information returned from the 3Mb boards.
"Lds" stands for Load Distribution and represents the number of packets that were transmitted by this machine on the Nth attempt. For example, the first number (left-most) represents the number of packets sent on the first attempt (no collisions). The second number is the number of packets sent on the second attempt (1 collision). And so on. Any numbers that would have fallen off the right hand end (more than 16 collisions) are counted as "too many collisions" and will show up on the previous line ("too many collisions" will also be given for 3Mb boards).
On a healthy Ethernet every number should be larger than the number on its right and the last few numbers should die out to zero. You should never have "too many collisions". If this isn't the case then there have been some problems on that particular Ethernet between the time that the gateway was last booted and the present. Sometimes these "problems" are just network people adding transceivers or moving cables. If you don't know of any transceiver or cable work to account for the problems then you should investigate.
Print Translation Cache(s) -- Enumerates the 8<->48 bit translation caches for each connected Ethernet. Refer to "MP 981 and Pup Registration Problems" under the "Common Problems and Fixes" section for more of an insight on 8<->48 bit translation.
Pup Blaster -- An extremely aggressive Pup Echoer (no waiting between packets).
Pup Echo User -- Pup Echo to the given remote machine (one packet at a time).
Pup PhoneLine Sender -- Pup Echo on all phone lines simultaneously.
Pup Sender -- An aggressive Pup Echoer (3 packets in flight at once).
Pup Routing Tables -- Enumerate the current Pup Routing table.
Quit -- Terminate the chat connection.
Routing Tables -- Enumerate the current NS routing table.
Set Boot Location -- Set the default boot file number, device, and board/line.
Stats Recent -- Give a bunch of possibly interesting statistics on various aspects of the gateway's operation since the last time you invoked this command.
Stats Totals -- Give a bunch of possibly interesting statistics on various aspects of the gateway's operation since it was last booted.
Time -- Gives the current time, how long the machine has been up, and the current CPU load.
Type Parm File -- Shows the current boot location information and parameter file contents. (Both of these are stored in the EEPROM on the the Misc board. NB: If you swap Misc boards you end up swapping parameter files.
-- The following commands are mostly only used for testing hardware problems.
Activate 4 phone lines -- ?.
DES RandomKey -- ?.
DES RandomSeed -- ?.
DES Fixed Pattern Tests -- Another DES test. If it doesn't work, but Burdock's DESTest worked ok, the chip is probably broken. DESTest uses only a single pattern. This test uses many patterns and also test the software and emulator microcode.
DES ECB1 -- ?.
DES ECB4 -- ?.
DES CBC1 -- ?.
DES CBC4 -- ?.
DES Loop ECB -- Another DES test. If it doesn't work, but Burdock's DESTest worked ok, the chip is probably broken. DESTest uses only a single pattern. This test uses many patterns and also test the software and emulator microcode.
DES Loop CBC -- Another DES test. If it doesn't work, but Burdock's DESTest worked ok, the chip is probably broken. DESTest uses only a single pattern. This test uses many patterns and also test the software and emulator microcode.
DES Flap -- ?.
Random Biased Bits -- ?.
Random Collect -- ?.
Random Info -- ?.
PhoneLine Double Buffered LoopBack -- ?.
PhoneLine DTR Flapper -- ?.
PhoneLine LoopBack -- ?.
PhoneLine PushPull -- ?.
PhoneLine Recv -- ?.
PhoneLine Send -- ?.
PhoneLine Statistics -- ?.
PhoneLine Timing -- ?.
PhoneLine Thrash -- Runs all 8 phone lines in SDLC mode. You need 8 echo plugs. The first 2 lines run at 56KB. Use either the RS232 echo plugs, or the V35 echo plugs. The other 6 lines run at 9600 baud. All 8 lines should receive as many messages as they send (less 1 or 2). On the printout chart, G is Good, B is Bad. If lines 2 through 7 don't work, either the clock is sick, or the SCC doesn't work in Sync mode. (TTYTest tested the data paths.) It normally prints out a cryptic line of junk when starting. Each clump of 3 or 4 characters is a bad packet. I've forgotten what it means. Look in the code if you really need to know. I think it is an initialization bug in the software/microcode. That's why the first packet on each line gets mashed.
Test Bank Hopping -- ?.
Test Dialers Noisy -- Flaps all 24 RS366 lines. (You need an echo plug.) Test Dialers Quietly is the same, but it doesn't print anything. It's intended for use with a scope.
Test Dialers Quietly -- Same as Test Dialers Noisy but it doesn't print anything. It's intended for use with a scope.
Test Mesa Clocks -- This is a good test of all the hardware, microcode, and software used to implement the clocks. (It's leftover from chasing some nasty problems.) The first 3 sections sample the clock and printout the numbers and the differences. If the differences in each clump are not very close, something is fishy. The next section (scanning for Hiccups) is looking for cases where the clock goes backwards. The last section compares the time of day clock with a WAIT for one second as determined by the process ticker. The first column is the number of microseconds in each "second" of waiting. Things should be quite close. The other columns are the fine print - look at the code. Typing STOP (while the mouse is in your Chat window) to terminate the current section of the test sooner in case you are getting impatient.
16. DLion (XDE) Tools
There are a number of XDE tools that are packaged with the DLion version of PupGateway. They are automatically started when PupGateway is run so either look on the inactive menu or the screen for what is available. These tools cover a number of things such as echoing, name and address translation, the ability to check routing tables, etc. A description of what these tools are and how to operate them should be included in this chapter, but it hasn't been written yet... Some of these tools are presently mentioned in the other chapters.