Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ginosko!usc!rutgers!bellcore!ka9q.bellcore.com!karn
From: karn@ka9q.bellcore.com (Phil Karn)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: KA9Q, forwarding between ethernets
Message-ID: <18010@bellcore.bellcore.com>
Date: 23 Oct 89 12:29:02 GMT
References: <8910181933.AA14935@ti.com>
Sender: news@bellcore.bellcore.com
Reply-To: karn@ka9q.bellcore.com (Phil Karn)
Organization: Secular Humanists for No-Code
Lines: 28

In article <8910181933.AA14935@ti.com> rjberke@skvax1.csc.ti.com (RICHARD BERKE -- COMMUNICATIONS ENGINEERING) writes:
>I've been exploring KA9Q (Sept 29, 1989) for PC, and have noticed a curious 
>command listed: forward.  
>
>Does anyone have information on its use/syntax?

The "forward" command is a hack that I added to support receive-only
interfaces. I added it a year ago to support an experimental packet radio
store-and-forward repeater that listened on a set of frequencies and
transmitted on a common output channel, distinct from the inputs. It wasn't
a pretty solution, but I couldn't think of a better way to do what I wanted
to do. (IP datagram routing wasn't the problem; just setting up the routing
table took care of this. The problem was with link level packets, such as
ARP requests and AX.25 link level control frames.  I needed a way to deflect
responses to such packets out a different physical interface than the one
they arrived on. Hence the forward command.)

This command is of little use in regular Internet-style operation. The code
will already work as an IP router, although until just yesterday it took
some playing with proxy ARP to make it all work right. I just added
IP-address-per-interface support, so all this will become much easier,
and more like a regular router.

BTW, the code has supported RIP for about a month, so you can indeed use the
package as an IP router. It will definitely not outperform a Cisco, though.
The code is written for flexibility and portability, not speed.

Phil