Copyright 1995, 1996 David F. Mischler


			IPRoute PC-based Router V0.91

	IPRoute is a software package that routes Internet Protocol
	(IP) packets between network interfaces on PC hardware.  It
	requires a 286 or better CPU. It is intended to be useful
	for connecting a LAN to an Internet Service Provider, or for
	routing between LANs.  It provides the following features:

	* Multiple ethernet interfaces.

	* SLIP, CSLIP and asynchronous PPP serial links.

	* Demand-dial and answer scripting.

	* IP packet filtering.

	* Network Address Translation (NAT).

	* Packet and event logging to a syslog daemon.

	* Routing Information Protocol (RIP).

	* Multiple transmit queue management strategies.

	* Administrative preference on routes.

	* IP tunnelling over ESP using DES-CBC (for US citizens and
	  permanent residents only; not exportable at this time).



   THIS SOFTWARE IS PROVIDED "AS-IS".  THE AUTHOR IS NOT RESPONSIBLE
   FOR ANY DAMAGES CAUSED BY THE USE OR MISUSE OF THE SOFTWARE, EVEN
   IF INFORMED OF THE POSSIBILITY OF THESE DAMAGES IN WRITING.  THE
   AUTHOR MAKES NO COMMITMENT REGARDING THE USABILITY OF THE SOFTWARE
   OR ITS FITNESS FOR A PARTICULAR PURPOSE.



			SUPPORTED INTERFACES

	An ethernet interface may be configured by attaching to a
	packet driver loaded before IPRoute was started with the
	"packet" command.  There is no hard-coded limit on the number
	of packet drivers allowed, but I have never tested more than
	two.  Packet drivers from the Crynwr Packet Driver Release 11
	or later are recommended.  At present, only class 1 (ethernet)
	packet drivers are supported.  Only ethernet packet headers are
	supported (i.e. IEEE 802.3 headers are not supported).

	Asynchronous serial ports using the standard PC UARTS (i.e.
	8250/16450/16550) are supported.  These interfaces may be
	configured with the "async", "slip", "ppp" and "command"
	commands.  The 16550 FIFOs are used to provide far better
	performance than with the other UARTS.



			MODEM CONFIGURATION

	IPRoute can be configured to work with almost any modem, but
	certain modem settings are expected.  Unfortunately, modem
	configuration commands are not standard enough for me to tell
	you exactly what commands are needed to configure your modem.
	IPRoute will generally work best when your modem is set for
	8-bit data with no parity and hardware flow control.  The
	data terminal ready (DTR) and carrier detect (CD) control
	signals should work as "normal" (i.e. a DTR transition from
	on to off will hang up the phone line, and CD will be on
	if and only if there is a connection to a remote modem).
	You may set your modem to return extended result codes if
	you wish to receive more information on each connection.



				COMMAND ENTRY

	All router commands must be entered in lower case.  There
	are several special purpose characters.  The backspace or
	delete characters will erase the last character typed, and
	the Ctrl-U character will erase the entire line.  The enter
	key must be typed before a command will be executed.  When
	a question mark is entered as a command component the
	command syntax or options available for the partial command
	will be displayed (try "route ?" for an example).



				SCRIPTING

	IPRoute is normally provided a script file at startup.  The
	script file contains commands to be executed in a particular
	order under specified conditions.  It is possible to specify
	packet, modem control signal, and timing events.  A script
	processing task is normally run at startup, and additional
	script processors may be started for each asynchronous
	interface.  This makes it possible for different interfaces
	to execute scripted commands independently.

	When a script command requires a string it should be enclosed
	in double quotes.  The backslash character may be used as an
	escape for various control characters.  In particular, \r is
	used to represent a carriage return, \n represents a line
	feed, \" represents an embedded double quote, and \\ represents
	a backslash.

	It is possible to define symbols for use in scripts with the
	"define" and "read" commands.  The symbols must be preceded by
	a dollar sign to be expanded.  Dollar signs in quoted strings
	must be preceded by a backslash unless symbol substitution is
	desired.

	Whenever a script process transfers control due to an enabled
	"on" event, all "on" events are disabled.

	The command reference includes many details about scripting.



			PACKET FILTERING

	Packet filtering can be a useful security tool.  It is
	imperative that the network administrator understand how
	filtering improves security, and that it be used wisely.
	Most experts on packet filtering recommend that you only
	allow the packets through your filters that are required
	to provide the services you need, and drop all others.
	The best introduction to packet filtering that I know of
	is Brent Chapman's "Network (In)Security Through IP
	Packet Filtering", available in PostScript by anonymous
	FTP from ftp.GreatCircle.COM.  The directory path has
	changed a few times, but the file is still called
	pkt_filtering.ps.Z.

	A filtered interface has two separate lists of filtering
	rules: one for inbound packets, and one for outbound
	packets.  As packets enter or leave the router on a
	filtered interface they are checked against each filter
	rule in the order the rules were specified until a match
	occurs, or the end of the filter list is reached.  When
	a match occurs the actions specified in the filter rule
	are performed on that packet.  Packets that do not match
	any filter rules will be silently dropped if a filter list
	exists on the interface for the packet's direction.

	IP fragments, except for the initial fragment, are not
	completely filtered because they do not contain port
	numbers.  It is possible for some data to "leak" or be
	tunnelled past the filter.  In general, this is not a
	serious problem because normal TCP/IP implementations
	will drop the data if the initial fragments are not
	received.  If you are concerned about packet sniffing or
	deliberate fragment tunneling then I recommend that you
	couple NAT with filtering because NAT drops IP fragments
	whose datagram IDs do not match recently forwarded
	initial fragments.  Please note that a determined user
	of your internal network might still find a way to
	tunnel past your filtering scheme.  I can not think of
	any way to make this absolutely impossible.

	The present implementation drops any initial or only
	fragment that is too short to contain all of its protocol
	headers (including the TCP, UDP, or ICMP header), and TCP
	packets with an IP fragment offset of 1.  This prevents
	certain types of attempts to bypass filtering.

	Filtering has some performance impact.  This impact can
	be minimized by constructing your filter lists so that,
	on average, the fewest possible filter rules are checked
	for each packet.  For example, placing a rule that
	matches all TCP packets that are not connection open
	attempts (i.e. filter protocol "tcp-xsyn") at the start
	of the list should improve things a lot.




		    NETWORK ADDRESS TRANSLATION

	Network Address Translation (NAT) allows a network with
	non-global addresses to connect to the Internet.  This
	is done by assigning one or more globally valid addresses
	to the external interface of the router and specifying
	how addresses and port numbers are to be translated.

	NAT can be a good security tool for situations where a
	(potentially) large number of external services are
	desired by the internal users, but only a few services
	should be provided to the outside world.  In particular,
	NAT can solve the problem of handling inbound FTP data
	connections without making all high-numbered TCP ports
	vulnerable from the outside.  This problem has plagued
	most packet filtering schemes.

	Two separate tables are maintained for each interface
	running NAT.  One table, the NAT configuration list, is
	entered as part of the router configuration.  It provides
	a set of rules for setting up new NAT connections.  It is
	always scanned in the order in which the rules were given.
	The other table is constructed dynamically by the router
	with one entry for each active translated connection.

	When a packet representing a new connection comes in on a
	translated interface it is compared to each entry in the
	NAT configuration list.  A protocol of "*" will match any
	incoming protocol, but the internal and external IP
	addresses must be specified.  The port numbers must be
	provided unless neither is given (this indicates that the
	same port numbers should be used internally as externally).
	These rules provide enough flexibility for an external
	address and port to be translated to an internal address
	and port, or for an external address to be translated to
	an internal address without port translation.  Note that
	if port numbers are not specified then no service filtering
	can be performed by NAT.

	The rules are somewhat different for outgoing connections.
	When a packet representing a new connection goes out on a
	translated interface it is compared to each entry in the
	NAT configuration list.  A protocol of "*" will match any
	outgoing protocol, and an internal address of "*" will
	match any internal address.  Neither port number is
	usually specified, but it is sometimes necessary to set
	the external port number to be assigned for use with an
	internal port number (e.g. outgoing FTP data connections
	so that the remote system will see the connection
	originate from port 20 rather than a "random" port).  It
	is also legal (but maybe a little weird) to use "*" for
	both the internal and external IP addresses, in which case
	neither the addresses nor port numbers will be translated,
	but the connection establishment and tracking rules will be
	enforced.

	It should be noted that packets that enter the router on
	a translated interface will have only their destination
	address and port number translated.  Packets that leave
	the router on a translated interface will have only their
	source address and port number translated.  It is possible
	to perform "double-blind" translation by enabling NAT on
	two interfaces, but it is not possible to connect two
	networks with the same address using this technique.

	An interface that runs NAT must always have an IP
	address that is valid on the external network to which
	it is connected.  This is because ICMP error messages
	may be generated and sent out this interface using the
	interface's assigned address.

	If an interface has both filtering and NAT enabled then
	filtering is always performed first, then translation,
	except in a few cases where ICMP error messages or TCP
	resets are generated on the "wrong side" of NAT.  This
	has implications on exactly what can be filtered, logged,
	and translated.

	The present implementation drops any initial or only
	fragment that is too short to contain all of its protocol
	headers (including the TCP, UDP, or ICMP header), and TCP
	packets with an IP fragment offset of 1.  This prevents
	certain types of attempts to fool NAT.

	When NAT is used with PPP with dynamic IP addresses and
	the NAT external address must correspond to the IP address
	negotiated by PPP the PPP option "dynamic-nat" should be
	used.  This causes the external IP address of each NAT
	list entry to be set to the negotiated IP address, all
	packets with the wrong IP source address to be dropped
	from the outgoing interface queue, and all dynamic NAT
	table entries with the wrong external IP address to be
	deleted.  Note that if you are using a dynamically
	addressed PPP link to route to a fixed IP network then
	this option must not be used.



		PORT NUMBERS, SERVICES, AND PROTOCOLS

	This information is provided as reference material to
	assist network administrators.  Various network services
	are discussed with regard to protocol and port numbers.
	Most of this information comes from the "Assigned Numbers"
	RFC, which at the time of this writing was RFC 1700.

	DNS is implemented as both a TCP and UDP service to port
	53 on the destination machine.  Zone transfers and lists
	are performed using TCP, so many security experts
	recommend that machines other than your authoritative
	secondary DNS servers should be prevented from connecting
	to TCP port 53 (this could be a job for packet filtering),
	unless you are controlling zone transfers and listings by
	some other technique.  Client to server communication is
	generally from arbitrary client ports greater than 1023,
	but server to server communication generally uses UDP port
	53 for both the source and destination.

	FINGER is implemented as a TCP service to port 79 on the
	destination machine.  In practice, the TCP port on the
	client machine is 1024 or greater, although this is not
	a protocol requirement.

	FTP is the most complicated service in common use.  It
	uses a TCP service to port 21 on the destination machine
	to provide a control channel, and connects back from the
	server's TCP port 20 to a port specified by the client
	machine to provide the data channel.  This means that FTP
	control streams must be monitored by NAT to allow the
	data connections to succeed.  There is also a less common
	technique ("PASV" mode) that allows the client to connect
	outward to the server for data connections.  NAT does not
	presently support this approach on inbound FTP, but it
	presents no problems for outbound FTP.

	NNTP is implemented as a TCP (or UDP?) service to port
	119 on the destination machine.  In practice, the TCP port
	on the client machine is 1024 or greater, although this is
	not a protocol requirement.

	NTP is implemented as a UDP (or TCP?) service to port 123
	on the destination machine.  Some client functions use
	arbitrary ports greater than 1023, but server to server
	UDP communication uses port 123 on both ends.

	SMTP (mail) is implemented as a TCP service to port 25 on
	the destination machine.  In practice, the TCP port on
	the machine sending the mail is 1024 or greater, although
	this is not a protocol requirement.

	TELNET is implemented as a TCP service to port 23 on the
	destination machine.  In practice, the TCP port on the
	client machine is 1024 or greater, although this is not
	a protocol requirement.

	WWW is implemented as a TCP (or UDP?) service to port 80
	on the destination machine.  The client machine's port is
	almost always 1024 or greater.



			LOGGING

	Events can be logged to a file or a UDP server.  Filter
	entries, as well as various flags, control what is logged.
	See the "set log" commands for more information.



				RIP

	The present RIP implementation is based mostly on RFC 1058.
	Split horizon is always enabled.  RIP requests are not
	generated or responded to, and no triggered updates are sent.
	Routes learned by RIP are poisoned for approximately 2 minutes
	when lost.  An administrative preference value may be assigned
        to routes learned on each interface.  See the "rip" command
	description for more info.



			TRANSMIT QUEUING

	All transmit queues are limited.  This means that packets
	will be dropped if the limit is exceeded.  In addition,
	all transmit queues are aged every few seconds if packets
	are not being transmitted on the interface.  During queue
	aging, the time each packet was queued for output is
	examined, and any packet whose remaining IP time-to-live
	(TTL) is less than the time that it has been on the queue
	is dropped.  The TTL of packets that are not dropped is
	not affected by this process.  This behavior is intended
	to prevent router constipation caused by an interface
	that fails, or whose modem dropped, etc.

	If transmit queuing is set to "fifo" then packets are
	always sent in the order they were queued.  In addition,
	if packets must be dropped due to queue limiting then
	the first packet on the queue will be dropped.  This
	queuing strategy is especially good for fast interfaces,
	like ethernet, where the computational overhead of
	priority queuing would hurt performance, and provide
	little or no benefit.  The optimal tradeoff between link
	speed and queuing strategy is dependent on the hardware
	and network characteristics.

	If transmit queuing is set to "priority" then packets are
	sent in priority order.  The present algorithm uses the
	IP precedence and type of service to determine a send
	priority and a save priority.  Precedence has a greater
	effect on these priorities than the type of service.
	Packets are sent in the order of highest send priority
	first, and are dropped in the order of lowest save
	priority first.  This queuing strategy is especially
	good for low-speed SLIP lines, where interactive users
	will benefit from the improved response time, and high
	reliability services will benefit from fewer packet drops
	under congested conditions.  Perhaps the biggest weakness
	of this strategy is that there are still some  TCP/IP
	implementations that do not set the type of service as
	required by RFC 1122.

	If transmit queuing is set to "fair" then packets are
	sent in priority order, but the priority of any packet
	directly preceded by a newer packet is increased by one.
	This has the effect of providing better response time
	than FIFO queuing, but fairer service distribution than
	strict priority queuing.  This queuing strategy is most
	useful when FIFO queuing provides decent throughput but
	inadequate response, and priority queuing provides OK
	response but lousy throughput.  It is also less subject
	to abuse than strict priority routing (e.g. smart users
	might start doing high-priority file transfers).  It has,
	however, a slightly higher computational overhead than
	the priority queuing strategy.

	By default, all async lines use priority queuing, and
	all ethernet interfaces use FIFO queuing.



			ADMINISTRATIVE PREFERENCE

	Each routing table entry includes an administrative preference
	value.  Lower preference values indicate that a route should be
	preferred over another route with a higher preference value.
	This can be used to control backup routes, etc.  By default, the
	preference value for all routes is 1.  This may be overridden
	when a static route is created, or by interface for RIP.



			ENCRYPTED IP TUNNELLING

	An encrypted IP tunnel can be created with the US-only
	version of IPRoute using the "tunnel" and "esp" commands.
	Under current US regulations these functions cannot be
	exported or provided to persons that are not citizens or
	permanent residents of the United States.

	An encrypted security payload (ESP) tunnel allows secure
	operation of a virtual private network over insecure networks,
	including the Internet.  At the present time only DES-CBC with
	manual key distribution is supported.  Due to the short (56
	bit effective) key this encryption technology is not suitable
	for protecting military secrets or information worth millions
	of dollars.  The security is sufficient, however, to make
	spoofing very difficult.

	An ESP tunnel is created by routing packets to the
	destination network(s) through a tunnel driver, and
	specifying encryption and decryption keys.  Each key has
	an associated security parameters index (SPI).  Outgoing
	TCP/IP packets routed through the tunnel driver will be
	encrypted and encapsulated in an ESP/IP packet.  Incoming
	ESP packets will be matched by source IP address and SPI
	so that the appropriate key can be used to decrypt the
	encapsulated packet so it may be forwarded.  Only true
	point to point tunnels are supported.

	Users should be aware that ESP tunnelling has a negative
	effect on throughput because the resulting packets are
	larger than the original packets, and are not compressible
	using any common compression algorithms.



			COMMAND REFERENCE

Warning: all router commands must be in lower case.



async <iface> <I/O addr> <IRQ> <speed> [<label>]

	Configures a standard 8250/16450/16550 serial port for
	use by the router.  Many other commands can make use of
	the interface after it is configured.  Of particular
	interest are the "command" and "slip" commands, as well
	as the "send" and "wait" commands for scripting.  If a
	script label is provided then a new script processor will
	be created that will begin execution at the specified
	label, and will assume the interface created by this
	command is meant whenever an interface name is required,
	but missing.

	The example below configures the standard PC COM1 port
	with the name "sl0" and a speed of 9600 bits per second.
	The interface will be configured in "raw" mode unless a
	command, such as "slip" changes the encapsulation.

	async sl0 0x3f8 4 9600


backoff <symbol> <max value>

	Doubles the numeric value stored in the named symbol, and
	limits the result to the maximum value specified.  This is
	useful for adjusting redial delays when failures occur.
	This command will be eliminated if/when general expression
	evaluation is implemented.



command <iface>

	Starts an interactive command interpreter on the specified
	interface.  At present, only async interfaces are suitable.

	The example below starts a command interpreter on sl0.

	command sl0



define <symbol> <string>

	Only usable in scripts.  Defines a script symbol with the
	supplied double-quoted string as its value.  The symbol
	may then be expanded later in the script by immediately
	preceding it with a dollar sign.



delay <interval>

	Delays the specified number of seconds before returning.
	Internal times are maintained in milliseconds, with a
	resolution of 25 mS.

	The following example delays for 1.125 seconds.

	delay 1.125



detach <iface>

	Intended to disconnects from the hardware and eliminate
	everything created for an interface.  Probably buggy as hell
	at this time.  For now, I recommend you shut down the router
	and restart it to eliminate an interface.



drop filter <iface>

	Drops all of the packet filter entries previously set up
	for an interface with the "filter" command.  Essentially
	turns off filtering on an interface.



drop nat <iface>

	Drops all of the network address translation information
	previously set up for an interface with the "nat" command.
	Also drops all connection state information.  Essentially
	turns off address translation on an interface.



drop packets <iface>

	Drops all of the outgoing packets queued on an interface.
	This might be useful for dynamic addressing.



drop route <addr/bits> <iface> [<router addr>] [metric <metric>]
		[preference <pref>] [perm]

	Drops the route from the routing table that matches the
	supplied information.



esp <iface> {in,out} <spi> des-cbc <key>

	Associates an SPI and key with a tunnel driver for incoming
	or outgoing ESP-tunnelled traffic.  The <spi> parameter
	is a 32-bit number.  The key is a 64-bit number that must
	be entered in hexadecimal.



exit

	Logs off an interactive command interpreter.  If you use
	this command on the console you will probably be hitting
	Ctrl-Alt-Del soon after.



filter <iface> [log] [nodial] {deny,drop,permit} {in,out} <proto> <src> <dest>

	Appends a packet filter rule to the incoming or outgoing
	list for the specified interface.

	If the optional "log" qualifier is present, then packets
	that match the rule will be passed to the logger.  The
	logging commands control exactly what is logged and where
	it goes.

	If the optional "nodial" qualifier is present, then
	packets that match the rule will be silently dropped if
	the interface is in "raw" mode.  This is useful for
	preventing "noise" packets from establishing a link,
	but allowing them to be transported if the link is up.

	One of the action keywords "deny", "drop", or "permit"
	must be specified.  The "deny" action is to drop the
	matching packet and send an ICMP destination unreachable
	message back to the packet's originator; the "drop"
	action is to silently drop the packet, and the "permit"
	action is to route the packet normally.

	A direction, "in" or "out", must be specified.  These
	directions are from the router's viewpoint, i.e. "in"
	refers to packets entering the router from the outside,
	and "out" refers to packets leaving the router over the
	filtered interface.

	The <proto> item is a protocol name or number.  The
	following options are available:

    *		Matches any valid IP packet.
    icmp	Matches any ICMP packet.
    icmp-du	Matches an ICMP destination unreachable.
    icmp-eq	Matches an ICMP echo request (ping).
    icmp-er	Matches an ICMP echo reply (ping response).
    icmp-pp	Matches an ICMP parameter problem message.
    icmp-rd	Matches an ICMP redirect.
    icmp-sq	Matches an ICMP source quench.
    icmp-tx	Matches an ICMP time exceeded.
    tcp		Matches any TCP packet.
    tcp-syn	Matches TCP with SYN set and ACK clear.  This
		indicates an attempt to open a new connection.
    tcp-xsyn	Matches TCP with SYN clear or ACK set.  This
		indicates a packet for an existing connection.
    udp		Matches any UDP packet.
    udp-zcs	Matches UDP packets with a zero checksum.

	The <src> and <dest> parameters specify the source and
	destination IP addresses, masks, and TCP/UDP port numbers.
	The syntax is [!]a[/w][:{p,p+,pl-ph}], which is just
	about as confusing as it really is.  OK, here goes.  The
	"a" represents an IP address in dotted decimal format, or
	* to match all addresses.  The "/w" is the width of the
	network mask in bits (e.g. 192.168.0.0/24 would match all
	addresses whose first 24 bits are 192.168.0).  The "!"
	negates the match on the address and mask only (not on
	the ports).  If a port or port range is specified then it
	is separated from the address part by a colon.  A single
	port number may be specified, or a port number followed
	by a plus sign (this represents ports p-65535), or a port
	range may be specified with two port numbers separated by
	a hyphen.

	The following example logs and silently drops attempts to
	open a telnet connection to any hosts on network
	192.168.0.0 that enter the router through interface sl0.

	filter sl0 log drop in tcp-syn * 192.168.0.0/24:23



goto <label>

	Only useful in scripts.  Causes an immediate and
	unconditional transfer of control to the specified
	label.  This command disables all "on" events.



log <string>

	Writes the supplied quoted string to the log.  This is
	most useful when there are script symbols in the string.



nat <iface> <proto> <int addr:port> <ext addr:port>

	Appends a network address translation rule to the list
	for the specified interface.  This list is only checked
	when a packet that does not match an existing connection
	enters or leaves the router on a translated interface.
	It is used to control connection establishment.  It is
	scanned linearly when a new connection is required.

	The <proto> item specifies the protocols that should be
	allowed to open a new connection.  The following values
	are recognized: "tcp", "udp", "icmp" or "*" to match any
	recognized protocol.

	The <int addr:port> item specifies the internal machine
	and/or port numbers that should be allowed access.  On
	outgoing connections, both the address and port can be
	"*" to indicate any internal machine and/or port.  On
	incoming connections the address can only be "*" if the
	external address is also "*" (this implies that the same
	addresses must be used inside and out).  The port number
	on incoming connections can likewise only be "*" if the
	external port number is the same (and this disables port
	number translation).

	The <ext addr:port> item specifies the address and/or
	port numbers that should be used on the externally
	visible network.  The address and port must always be
	fully specified unless they are the same internally and
	externally.  This is only useful for filtering traffic
	based on established and approved connection information.
	This can be useful because it provides a kind of dynamic
	filtering that classic packet filtering can't do.

	The following example commands allow for a single external
	address, 192.0.2.1, and an internal network 192.168.0.0.
	All outgoing connections from the internal network are
	permitted, plus SMTP mail from the outside is delivered
	to 192.168.0.5, and FTP connections from the outside are
	delivered to 192.168.0.9.  All other incoming connections
	will be dropped.  Note that the third line isn't strictly
	needed.  It establishes that outgoing FTP data connections
	from the internal FTP host will use port 20 externally.
	This helps keep all sorts of filtering and translating
	schemes that depend on this behavior happy.

	nat sl0 tcp 192.168.0.5:25 192.0.2.1:25
	nat sl0 tcp 192.168.0.9:21 192.0.2.1:21
	nat sl0 tcp 192.168.0.9:20 192.0.2.1:20
	nat sl0 *   *              192.0.2.1



on cd [<label>]

	Only useful in scripts.  Specifies that when CD becomes
	active on an interface during a "wait" command the script
	should resume execution at the specified label.  Leaving
	off the label cancels any established label.



on cdloss [<label>]

	Only useful in scripts.  Specifies that when CD becomes
	inactive on an interface during a "wait" command the script
	should resume execution at the specified label.  Leaving
	off the label cancels any established label.



on packet [<label>]

	Only useful in scripts.  Specifies that when a packet is
	queued on an interface during a "wait" command the script
	should resume execution at the specified label.  Leaving
	off the label cancels any established label.



on ring [<label>]

	Only useful in scripts.  Specifies that when RI becomes
	active on an interface during a "wait" command the script
	should resume execution at the specified label.  Leaving
	off the label cancels any established label.



on timeout [<label>]

	Only useful in scripts.  Specifies that when a timeout
	occurs during a "wait" or "slip" command the script should
	resume execution at the specified label.  Leaving off the
	label cancels any established label.



packet <iface> <int #> <addr/bits> [broadcast <brdcst addr>] [mtu <mtu>]

	Configures a device interfaced by a packet driver for
	use by the router.  At present, only ethernet (class 1)
	packet drivers are supported.

	The example below configures a packet driver using the
	standard software interrupt 0x60, and indicates that the
	interface IP address is 192.168.1.254, and the network
	mask is 255.255.255.0.  By default the MTU is set to 1500
	and 255.255.255.255 is used as the broadcast address.

	packet en0 0x60 192.168.1.254/24



ping <addr>

	Sends 5 ICMP echo requests to the specified address and
	displays any replies received.



ppp <iface> <timeout> <addr/bits> [broadcast <brdcst addr>] [mtu <mtu>]
		[dynamic-nat]

	Starts PPP on the specified interface.  The interface
	will revert to "raw" mode if no packets are received for
	<timeout> seconds, or if a carrier drop is detected, or if
	the peer requests LCP link termination.  The IP address
	and mask are treated like the ones in the "packet"
	command, except that a "*" is used to indicate dynamic IP
	address assignment.  If the "dynamic-nat" option is used
	then when the local IP address is negotiated all entries
	in the NAT list will be modified to use the negotiated
	address externally, any active NAT connections with a
	different external address will be removed, and any
	outgoing queued packets with the wrong source IP address
	will be dropped.

	If this command is typed in to a command interpreter then
	a new process will be started to execute the command.  If
	this command is part of a script then script execution
	will pause until the interface reverts to raw mode.  If
	this was due to a timeout or carrier drop then any enabled
	"on" event for these conditions will be taken.



read <iface> <timeout> <terminator string> <symbol>

	Only usable in a script.  Reads a string ending with one
	of the specified terminator characters into the specified
	symbol.  The symbol may then be expanded later in the
	script by immediately preceding it with a dollar sign.
	This is intended for purposes like reading an IP address
	from a SLIP server.



rip <iface> [default] [preference <pref>] [quiet] [{v1,v2,off}]

	Turns on/off RIP broadcasts on the specified interface.  By
	default, the entire routing table will be sent in version
	1 responses.  The "v2" qualifier causes RIP version 2
	responses to be sent, but still broadcasts rather than
	multicasts.  The "default" qualifier causes only a default
	route to be broadcast rather than the real routing table.
	The "preference" option specifies the administrative
	preference to be assigned to routes learned via RIP on this
	interface.  The "quiet" qualifier causes routes to be
	learned but not distributed on this interface.



route <addr/bits> <iface> [<router addr>] [metric <metric>]
		[preference <pref>] [perm]

	Adds a static route to the routing table.  The "perm"
	qualifier is required if packets are to be routed to
	an interface that is not encapsulating IP (e.g. an
	async interface running a script that will dial and
	establish a SLIP link when packets are queued to the
	interface).



send <iface> <string>

	Sends the quoted string out the specified interface.



set echo {off,on}

	Controls character echo while matching strings in a
	"wait" command.



set filter deny-code <ICMP DU code>

	Sets the code carried in the ICMP destination unreachable
	messages sent by the router when a packet matches a filter
	rule whose action is "deny".  By default, the code is set
	to 1 (host unreachable).  RFC 1812 says the value should
	really be 13, but many hosts seem to ignore this code.

	The default will probably change in a future release.



set interface <iface> cd {ignore,normal}

	Controls the use of CD on an interface.  By default, CD
	is used to detect modem disconnects.  The state of CD can
	be ignored with the "ignore" qualifier.



set interface <iface> dtr {off,on}

	Controls the state of DTR on an interface.  By default,
	DTR is low at the EIA interface.  This signal is used
	to control modem answer and hangup.



set interface <iface> mtu <mtu>

	Sets the MTU on the specified interface.



set interface <iface> queue fair

	Sets the transmit queue for the specified interface
	to queue (and drop) packets using a modified priority
	algorithm with improved fairness.



set interface <iface> queue fifo

	Sets the transmit queue for the specified interface
	to queue (and drop) packets in a FIFO manner.



set interface <iface> queue limit <limit>

	Sets the outgoing queue packet limit for the specified
	interface.


set interface <iface> queue priority

	Sets the transmit queue for the specified interface
	to queue (and drop) packets in a prioritized manner.



set interface <iface> rts {flow,off,on}

	Controls the interface RTS line.  The "flow" qualifier
	establishes RTS/CTS flow control.



set interface <iface> speed <bps>

	Controls the interface speed.



set log brief

	Reduces the data logged for each packet to 1 or 2 lines.
	This is the default.



set log data

	Expands the data logged for each packet to the
	entire packet contents.



set log errors {off,on}

	Controls whether the router logs various errors.
	The default is "on".



set log file <filename>

	Specifies a file for the log data to be written to.
	"CON" specifies logging should be to the console display.



set log headers

	Expands the data logged for each packet to the
	IP and TCP/UDP/ICMP headers.



set log memory <lines>

	Specifies how many lines of the log are queued in memory.
	The default is 240.  Values over 2000 are not recommended.



set log monitor {off,on}

	Enables console display of all messages written to the log.



set log none

	Disables logging to a file or UDP server.



set log raw {off,on}

	Controls logging of raw device input received while
	executing "wait" commands.  This is especially useful
	for debugging dial/login scripts.  The default is off.
	This command only works in a script interpreter that
	is attached to the interface you want to log.



set log timestamp {off,on}

	Controls time stamping of log entries.  This should
	not be used if you are logging over the network and
	timestamping can be performed by the logging host
	because no attempt is made to synchronize the DOS
	clock with an outside source.  This feature is off
	by default.



set log udp <ip addr[:port]>

	Specifies that log entries should be sent to the UDP
	server at the specified IP address and port.  The format
	is suitable for use with the BSD syslog daemon.  If no
	port is specified then port 514 (syslog) is assumed.



set nat pass-icmp-errors {off,on}

	Specifies whether NAT will translate ICMP errors for
	open connections.  The default is on.



set nat ports <lowest port> <highest port>

	Specifies the range of port numbers used externally by NAT.
	The default is 1024 through 4999.



set nat send-icmp {off,on}

	Specifies whether NAT will attempt to cause bad/old
	connections to drop by sending ICMP messages.  This
	feature causes the router to spoof the IP address of the
	intended destination of the original packet.  The network
	administrator must beware, because things are not quite
	as they seem.  This feature is off by default.



set nat send-reset {off,on}

	Specifies whether NAT will attempt to cause bad/old
	connections to drop by sending TCP reset messages.  This
	feature causes the router to spoof the IP address of the
	intended destination of the original packet.  The network
	administrator must beware, because things are not quite
	as they seem.  This feature is off by default.



set ppp <iface> login <name> <password>

	Specifies the name and password to use for authentication as
	a client.



set ppp <iface> trace {off,on}

	Controls the logging of PPP trace information for the
	specified interface.  When enabled, the PPP negotiation
	information will be logged.  This is helpful when
	analyzing PPP problems.



set ppp <iface> vjtcp {off,on}

	Controls the negotiation of Van Jacobson TCP/IP header
	compression.  When turned off, this feature disables
	VJTCP in both directions.  This feature is on by default.



set trace {off,on}

	Controls logging of script commands.  This is very
	useful for debugging all sorts of scripts.  The
	default is off.



show arp

	Displays the ARP table.



show filter <iface>

	Shows the filter list and match counts for an interface.



show interface [<iface>]

	Shows various interface parameters and counters.



show nat <iface> [status] [debug]

	Shows the static NAT list, or the dynamic connection
	table with the "status" parameter.



show options

	Displays various compile-time options, and the values of
	some settable features that cannot be viewed elsewhere.



show route

	Displays the routing table.



show task

	Displays the active task list.



show version

	Displays the version identification message.



shutdown

	Shuts down the router software.



slip <iface> <timeout> <addr/bits> [broadcast <brdcst addr>] [mtu <mtu>]
		[compress] [allow-compress]

	Starts SLIP on the specified interface.  The interface
	will revert to "raw" mode if no packets are received for
	<timeout> seconds, or if a carrier drop is detected.  The
        IP address and mask are treated like the ones in the
	"packet" command.  The default SLIP MTU is 1006 bytes (as
	per RFC 1055).  If the optional "compress" keyword is
	specified then Van Jacobson TCP header compression will
	be performed.  If "allow-compress" is specified then Van
	Jacobson TCP header compression will be enabled only if
	it is detected from the remote end of the link.

	If this command is typed in to a command interpreter then
	a new process will be started to execute the command.  If
	this command is part of a script then script execution
	will pause until the interface reverts to raw mode.  If
	this was due to a timeout or carrier drop then any enabled
	"on" event for these conditions will be taken.



tip <iface>

	Connects to a "raw" interface.  Sometimes useful for
	configuring modems and stuff.  Type ^] to exit.  This
	will not work as expected if a script is running.



tunnel <iface> <addr/bits> esp <remote addr> [mtu <mtu>]

	Creates a tunnel driver that uses the specified address
	and prefix width as its tunnel endpoint, and that
	tunnels to the specified remote IP address.  At this time
	only ESP tunnelling is supported.



wait <iface> <timeout> [exact] [<string>]

	Waits for the timeout to expire, or the string to be
	matched, or an enabled "on" event to occur.






	EXAMPLE ROUTER CONFIGURATION USING SLIP

;
;   IPR script for example configuration.
;
;   Configure ethernet interface on network 192.168.0.0/24
	packet en0 0x60 192.168.0.254/24
;   Configure my modem port and make it the default route
	async sl0 0x3f8 4 57600 do_sl0
	route * sl0 perm
;   Broadcast RIP routes on the ethernet
	rip en0
;   Start a command interpreter on the console
	command
	exit

;
;   Script for filter and NAT configuration on sl0,
;   with demand dial out, etc.
;
do_sl0:
	set trace on
;
;   Set up packet filtering.
;
;   Allow established TCP
	filter permit in tcp-xsyn !192.168.0.0/22 38.145.214.209
;   Drop and log attempts to spoof internal addresses, or our external address
	filter log drop in * 192.168.0.0/22 *
	filter log drop in * 38.145.214.209 *
;   Allow UDP responses.  NAT will keep out unsolicited packets.
	filter permit in udp * 38.145.214.209
;   Allow incoming mail and FTP connections
	filter permit in tcp-syn * 38.145.214.209:25
	filter permit in tcp-syn * 38.145.214.209:21
	filter permit in tcp-syn *:20 38.145.214.209
;   Allow DNS zone transfers from 192.33.4.10
	filter permit in tcp-syn 192.33.4.10 38.145.214.209:53
;   Drop and log everything else.
	filter log drop in * * *

;
;   Set up NAT
;
;   Allow SMTP mail to come in.
	nat tcp 192.168.0.69:25 38.145.214.209:25
;   Allow FTP requests to be serviced.
	nat tcp 192.168.0.69:21 38.145.214.209:21
	nat tcp 192.168.0.69:20 38.145.214.209:20
;   Allow DNS zone transfers (packet filtering controls with whom).
	nat tcp 192.168.0.69:53 38.145.214.209:53
;   Allow all outgoing service requests and their responses.
	nat * * 38.145.214.209

;
;   Configure modem control and set up for demand dial.
;
	set interface rts flow
hangup:
	set interface dtr off
	delay .5
	set interface dtr on
	on packet dialout
	wait 0

;
;   Dial the phone, log in, and run SLIP.
;   Hang up if no packets are received for 10 minutes.
;
dialout:
	send "ATDT 555-1212\r"
	wait 1
	on timeout hangup
	wait 45 "CONNECT"
;   Read the rest of the CONNECT message into symbol "speed".
	on cd lineup
	read 5 "\r" speed
	wait 60
lineup:	on cdloss hangup
	on timeout hangup
	send "\r\r"
	wait 5 "Username: "
	send "IWantToBeA\r"
	wait 5 "Password: "
	send "Schutzhund3\r"
	wait 5 "Local> "
	send "CONNECT SLIP\r"
	log "Connected at $speed"
	slip 600 38.145.214.209/24 mtu 1006





	EXAMPLE ROUTER CONFIGURATION USING PPP (STATIC)

;
;   IPR script for example configuration with PPP
;   using a static IP address.
;
;   Configure ethernet interface on network 192.168.0.0/24
	packet en0 0x60 192.168.0.254/24
;   Configure my modem port and make it the default route
	async sl0 0x3f8 4 57600 do_sl0
	route * sl0 perm
;   Broadcast RIP routes on the ethernet
	rip en0
;   Start a command interpreter on the console
	command
	exit

;
;   Script for filter and NAT configuration on sl0,
;   with demand dial out, etc.
;
do_sl0:
	set trace on
;
;   Set up packet filtering.
;
;   Allow established TCP
	filter permit in tcp-xsyn !192.168.0.0/22 38.145.214.209
;   Drop and log attempts to spoof internal addresses, or our external address
	filter log drop in * 192.168.0.0/22 *
	filter log drop in * 38.145.214.209 *
;   Allow UDP responses.  NAT will keep out unsolicited packets.
	filter permit in udp * 38.145.214.209
;   Allow incoming mail and FTP connections
	filter permit in tcp-syn * 38.145.214.209:25
	filter permit in tcp-syn * 38.145.214.209:21
	filter permit in tcp-syn *:20 38.145.214.209
;   Allow DNS zone transfers from 192.33.4.10
	filter permit in tcp-syn 192.33.4.10 38.145.214.209:53
;   Drop and log everything else.
	filter log drop in * * *

;
;   Set up NAT
;
;   Allow SMTP mail to come in.
	nat tcp 192.168.0.69:25 38.145.214.209:25
;   Allow FTP requests to be serviced.
	nat tcp 192.168.0.69:21 38.145.214.209:21
	nat tcp 192.168.0.69:20 38.145.214.209:20
;   Allow DNS zone transfers (packet filtering controls with whom).
	nat tcp 192.168.0.69:53 38.145.214.209:53
;   Allow all outgoing service requests and their responses.
	nat * * 38.145.214.209

;
;   Configure modem control and set up for demand dial.
;
	set interface rts flow
hangup:
	set interface dtr off
	delay .5
	set interface dtr on
	on packet dialout
	wait 0

;
;   Dial the phone, log in, and run PPP.
;   Hang up if no packets are received for 10 minutes.
;
dialout:
	send "ATDT 555-1212\r"
	wait 1
	on timeout hangup
	wait 45 "CONNECT"
;   Read the rest of the CONNECT message into symbol "speed".
	on cd lineup
	read 5 "\r" speed
	wait 60
lineup:	on cdloss hangup
	on timeout hangup
	log "Connected at $speed"
	set ppp login mischler xerxes
	ppp 600 38.145.214.209/24
	goto hangup





	EXAMPLE ROUTER CONFIGURATION USING PPP (DYNAMIC)

;
;   IPR script for example configuration with PPP
;   using a dynamically negotiated IP address.
;
;   Configure ethernet interface on network 192.168.0.0/24
	packet en0 0x60 192.168.0.254/24
;   Configure my modem port and make it the default route
	async sl0 0x3f8 4 57600 do_sl0
	route * sl0 perm
;   Broadcast RIP routes on the ethernet
	rip en0
;   Start a command interpreter on the console
	command
	exit

;
;   Script for filter and NAT configuration on sl0,
;   with demand dial out, etc.
;
do_sl0:
	set trace on
;
;   Set up NAT
;
;   Allow all outgoing service requests and their responses.
;   The IP address is not critical, but should be the most
;   likely address (or at least a possible address).
	nat * * 38.145.214.209

;
;   Configure modem control and set up for demand dial.
;
	set interface rts flow
hangup:
	set interface dtr off
	delay .5
	set interface dtr on
	on packet dialout
	wait 0

;
;   Dial the phone, log in, and run PPP.
;   Hang up if no packets are received for 10 minutes.
;
dialout:
	send "ATDT 555-1212\r"
	wait 1
	on timeout hangup
	wait 45 "CONNECT"
;   Read the rest of the CONNECT message into symbol "speed".
	on cd lineup
	read 5 "\r" speed
	wait 60
lineup:	on cdloss hangup
	on timeout hangup
	log "Connected at $speed"
	set ppp login mischler xerxes
	ppp 600 * dynamic-nat
	goto hangup



	EXAMPLE AUTOEXEC.BAT

rem  Load packet driver and start IPR.
smc_wd 0x60 10 0x280 0xd000
ipr script.ipr

