KA9Q Router

by Michael Ratcliffe, Cable & Wireless ECRC GmbH

Introduction

This solution for an Internet access router is based on using standard IBM PC hardware. An old '286 or '386 based machine running DOS is perfectly adequate. Although it is possible to squeeze all the software on a single floppy, its more convenient to split it between two or use a small hard disk. The machine needs no more than 640kB of main memory.

Additional hardware required is an ethernet card and an ISDN card. A passive ISDN card is adequate; the most economical just now being the Creatix S0/16 or the Teles S0/16. Both can be obtained for about DM170.

The machine configuration has the following structure/layers:

Each of these software and hardware components need to be configured properly for the system to work. For the hardware components, this simply involves the allocation of IRQs and memory space which does not conflict with other components. Using IRQ 5 for the ethernet card and IRQ15 for the ISDN card usually works fine.

Another useful information source for this router solution is

http://www.ix.de/ix/artikel/9504/ka9q.html.

CAPI Driver

The ISDN card is usually supplied with a suitable CAPI driver. At the time of writing, there are two CAPI standards in use, CAPI v1.1 and CAPI v2. Many suppliers are moving towards supplying CAPI v2 but both the Teles and Creatix cards are still shipping with CAPI v1.1.

The cards usually come with a collection of application software too (e.g.Fax, file transfer ...) which for the pure routing application are not needed. The software must usually be installed under Windows, although windows is also not needed for the final application. The software can be installed on another system and then copied to the target machine. In this case, it is best to ensure that the location of the software on the target machine has the same path definition as when it is installed on the Windows machine.

Teles also produce a CAPI-only version of their software which can be installed entirely under DOS. Note also that the Teles software is also used by the Creatix cards. This version can be downloaded from the Teles ISDN Mailbox. This version is recommended since it does not require the

Teles activation key to function. See the software documentation for more details.

Teles/Creatix Software Configuration

The software is configured during the installation process by filling in the parameters in the menu screens. Once the software has been installed, the "setup" programme, part of the installed package, can be used to change the IRQ and memory area. On the card itself is one jumper which determines the address of the on-board hardware I/O register; this must agree with the software setting in order that the software and card can communicate properly.

Be sure to choose the correct ISDN protocol:

1TR6 national German standard, no longer used on new installations

DSS1 European standard, now used on all new ISDN connection installations

The most important difference in these two is the handling of subscriber telephone numbers. The old German standard used so-called EAZs while the newer DSS1 standard uses MSNs (Multiple Subscriber Numbers). All ISDN equipment has to be programmed with its own telephone number, since the basic system configuration is a bus, indeed, the S0 bus. The CAPI 1.1 standard was designed for the older German standard and so uses a table to map between pseudo-EAZs and MSNs.

The table can be stored in a text file and has the format:

<EAZ>:<MSN>*<Subaddress>

The <Subaddress> field is, along with the "*" can be omitted if subaddresses have not been implemented by the user (usually the case). The <MSN> is the number assigned by the Telecom which the ISDN card should respond to; only the local part of the number is required here. The <EAZ> is the pseudo EAZ number, a single digit. This number is also used to identify the calling station on outgoing calls. This table is then loaded into the CAPI driver with the command:

mapcfg <file>

Omitting the <file> name will display the currently active table. The standard software delivered with these cards is only installable under windose; a DOS only version is downloadable from the Teles support server, but that requires a working ISDN card to get it, so .... The software can be installed on a different machine that the final target and simply copied over, for example, via floppy, or else by installing the router's hard disk, if it has one, temporarily in a windose machine, or via ftp using a LAN and KA9Q on the target router machine.

When installing on a machine other than the final router, it will be necessary to hand-edit the startS0.bat file to:

• ensure all paths are specified correctly
• remove references to unused functions

The test functions will also not function properly on the final target router. The best solution, and in the end the simplest, is to use the initial windose implementation to download the Teles DOS CAPI only package using the supplied Teles Support application. The installation can then be done exclusively on the DOS router machine.

ISPA Driver

ISPA maps CAPI 1.1 to Packet Driver interface standards. Several instances of ISPA may run concurrently, for example, when multiple cards are installed or to define different parameters for different connections through the same card, for example, one defining the Internet up-link and the other a set of possible dial-in accesses. ISPA is shareware and is downloadable from http://home.t-online.de/home/hanewin/homee.htm Note that CIPA, a similar driver but for CAPI 2.0, is also available from the same address. There is one configuration file per ISPA instance, normally called ìISPA.INIî. The most important parameters are shown in the sample file. This configuration file is used to map ip addresses onto telephone numbers. That is, for incoming calls it validates the caller's telephone number and for outgoing calls, it uses the ip address to know which number it should call to build up a connection.

Ethernet Packet Driver

This software comes on a floppy with the ethernet card. This floppy will also contain a setup utility to configure the boardís IRQ and memory address. Thereís also usually a utility to test the card, often integrated into the setup utility.

KA9Q

This software is extremely flexible. It is a network operating system built on top of DOS but looking like UNIX. It has been written by Phil Karn of Qualcomm Inc, a specialist communications company in the US. Many versions of KA9Q exist, with different functionality and alternative modules added by other authors. There are two versions that particularly recommend themselves, the one used by Demon Internet, a UK ISP, as end-user Internet access software for DOS customers, or the version by Thomas Hommes. Both are compact but the latter is more optimised for routing; it also supports selective logging via syslog for ip filter rules. These

versions are obtainable from:

IP filtering is supported for firewalling.

The KA9Q software, as well as supporting ip routing, can also function as an SMTP, HTTP, NNTP, DNS, FTP and TELNET server. The sample configuration file explains the most important options for implementing an ip router. Once KA9Q is installed, it has several useful commands for checking that things are working properly.

Here are a few basics:

ifconfig check that the isdn and ethernet interfaces exist

route check the routing table

ping <ip address> ping an ip address

exit terminate execution of KA9Q

Several configuration files are also used. All the commands they contain can also be entered by hand. These files, are:

autoexec.net basic KA9Q configuration file

domain.txt DNS host/ip mapping file

ftpusers user/password definitions for ftp and telnet access

Its also good practice to define a seperate file(s) for the IP filtering rules. These can be defined for each interface. Putting it all Together The software is usually started using the standard DOS autoexec.bat mechanism. It may be that the ethernet card driver is started in the config.sys file. When installing a KA9Q router solution, the best strategy is to install the ethernet card, ethernet packet driver and KA9Q first. The major advantage is that it is then possible to use ftp for copying over further software; this is particularly useful if the ISDN software has been first installed on a windose machine connected via a LAN to the router.

Here is a sample autoexec.bat file:

The CAPI software has been installed in the subdirectory "online"; alternatively it is often stored in a subdirectory by the name of "telescom". The ethernet packet driver call contains three parameters:

0x60 the software interupt number

5 assigned IRQ

0x300 system memory base address

The call to start ISPA also has several parameters:

? he ISPA registration key. With "?" it will only work for 20min.

0x61 software interrupt number

c:\ispa\isdn0.ini location of the ISPA configuration file

When installing and testing this software, its probably best to first ensure that all the drivers start properly when issuing the commands by hand. This is easily achieved by typing the F8 key at the first startup message from DOS when booting; this will allow you to confirm each command executed from the config.sys file individually and ensure each functions. In case of problems, remember also that the autoexec.bat and config.sys files can be bypassed during booting by either holding down the shift key or pressing F5 at the DOS startup message. Once this is the case, an automated autoexec.bat can be used. Its also worth disabling the loop at the end in order to allow easily returning to the DOS level when working on the configuration.

The command starting the KA9Q software itself also specifies the default working directory, in this case, c:\ka9q, which is also the location for all the configuration files.

Sample Configuration Files

CAPI

The only configuration file here is the definition of the pseudo-EAZ mappings. From the autoexec.bat file above, this file is named c:\online\map.

Here is a sample file:

The format is discussed above. Here we are mapping EAZ 0 and 1 onto the MSN number 61771 and EAZ 2 onto the MSN 61772. If a KA9Q router is not responding in any way to an incoming call, this table and the ISDN card setup is the problem. There is some test software delivered with the CAPI software. For the Teles/Creatix cards, this is started by the "tests0" command. Note that if the software was installed by copying from Windows, the subdirectory paths must be identically named and even then, it may complain that some software components are missing.

Nevertheless, the hardware test may be run on its own using the command "hwtest".

ISPA

Normally there is only one ISPA configuration file. If several instances of ISPA are being used, thenthere will be one per instance. From the autoexec.bat file above, in this case there is one ISPA configuration file named c:\ispa\isdn0.ini:

Note that the space character between an option and value is optional, hence "-e 1" is equivalent to "-e1".

The file is divided into two parts:

Global Options

These options apply to all connections controlled by this instance of ISPA. A few comments are necesary to the comments given in the file itself:

-z It is recommendable to reboot the router every few days; this can also be done remotely from a UNIX host with cron if desired.

-m this is a static definition used with PPP negotiation and/or with BOOTP, RARP, NAT.

-r 194.112.91.13,194.59.187.9 this allows logging of connections to a syslog host. The first ip address is that of the syslog host, the second is the ip address of the isdn interface. Syslog messages have the characteristics "local0.info".

-u restricts a connection to use one B channel; this is overridden by the "-m" option in the translation entries sections

-w displays a useful activity indicator in the upper right corder of the router monitor screen. Two rotating lines indicate incoming and outgoing packets respectively. Note that if more than one ISPA instance is loaded,only one of them should use this option.

Several of these options have sensible defaults if they are not explicitely specified:

-c 0

-e 2

Translation Entries

Each line in the translation entries correspond to a possible connection. If it is required to define an entry to accept all incoming calls, regardless of the phone number of the caller, this should be entered first with a "*" for the caller phone number. This is useful for testing but should not be used for production use. In the example above it is commented out.

The general format of translation entries is:

<ip_address> <phone_number> <options>

where:

<ip_address> the ip address of the remote machine ISDN interface

<phone_number> the phone number to reach teh remote machine

<options> specify the protocol to be used and other options. See below

The ip address for the remote station used here is only used to look up the phone number for the remote machine. It doesn't have to be the ip address of the ISDN interface itself on the far end but must just appear in the router's routing table. This makes it possible to avoid using a transfer network if desired.

The phone number is used both by the dialer to know how to reach the remote machine but also on incoming calls to authenticate the incoming caller id. This means that a specific format is needed; a few examples will illustrate this:

German SPV connections, officially no longer supplied by Telekom, are supported by appending an "s" to the phone number. Digital 64S leased lines are also supported when using the Teles CAPI implementation, although this is not part of the CAPI standard. This is done by using a pseudo telephone number of "1tap" or "2tap", depending on the desired B channel.

Of the many possible options, the following are probably the most important:

-f <dlci> frame relay

<dlci>
data link connection identifier appending "i" to the <dlci> switches encapsulation from "early" style to IETF format as defined by RFC 1294, with an assumed data size of 1500.

-h <n> HDLC encapsulations. <n> specifies the substandard according to:

0 ip data in HDLC frames with no header

1 ip data with X.75 unnumbered information frame (UI) header

2 ip data with Cisco style encapsulation

3 ethernet bridging with the whole ethernet packet in an HDLC frame

-l <type> LAPB (X.75) based encapsulation (caller=DCE, window=7, mod 8)

<type> is defined by:

0 ip data in X.75 packets, no header

1 multi-X.75 (called LAPB on ACC routers, multi-LAPB on Ciscos)

2,<file> Asynchronous PPP with byte stuffing

3 ethernet bridging

4 undefined

5,<file> SLIP

6,<file> ethernet bridging using SLIP emcapsulation (SLX) where <file> is an optional login script

-e <type> X.75/T.70NL based encapsulation (caller=DCE, window=7, mod 8)

<type> is defined analagously to -l above

-p <opt> PPP encapsulation using <opt> optional parameters. The following options are accepted from the remote peer: LCP MRU requests for values > 1500, protocol field compression, address and control field compression.IPCP ip addres requests

<opt> is defined as

-n <user>,<pass>
user and password for the remote site should it request PAP or CHAP authentication. <user> can be <user>@<host> for Cisco CHAP challenges.

-g <user>,<pass>
user and password for incoming call authentication. <user> can be <user>@<host> for Cisco CHAP challenges.

-i operate as an ip address provider. Uses a non-zero ip address field to tell the peer which ip address it should use.

-d <mode> specifies mode of operation. <mode> has the following values:

0 outgoing calls are disabled

1 (default) incoming and outgoing calls are enabled

2 outgoing calls are dropped after sending the connect request. This allows callback at the ISDN level (i.e. over the D-channel) without needing to make a data connection.

3 incoming calls are rejected but trigger a call back

4 incoming calls are disabled

-t <max-idle> an idle connection will be disconnected after <max-idle> seconds. 0 => maintain connection. default is 300 seconds Optionally, ",<min-idle> may be included. On outgoing calls, a connection will be held at least <min-idle> seconds but closed down shortly before the next charge unit or <max-idle> expires.

-m <high>,<low> static or dynamic load sharing across both S0 channels. A second phone number can be specified for loadsharing to two different phone numbers. <high> is defined as:

0 static loadsharing; as a caller will try to activate both channels

<n> (n <> 0) A second connection will be built up when a transfer rate of 6kB/s has occurred for longer than n seconds. The second channel is losed down once the transfer rate has dropped below 6kB/s for either <max-idle> seconds (see -t above) or for <low> seconds, where ",<low>" is an optional parameter

KA9Q: Autoexec.net

This file is the main configuration file for KA9Q. All the commands it

contains may be entered by hand at the KA9Q prompt. Here is a sample file:

All the commands given in "autoexec.net", the KA9Q configuration file, can be entered by hand at the KA9Q prompt. A help facility is also available by typing a "?" This also works within a command line to discover the parameters.

This configuration file is mostly straightforward. It begins by defining the host it is running on in terms of its name and ip address. The following section sets up a DNS service and defines "dns.crystal.de" as another DNS server to request information from. During development of the configuration, its best to leave this line commented out since it tries contacting the other machine when executing the "addserver" command; if the machine isnít available, it will only continue after an inconveniently long timeout.

The next section deals with the local ethernet interface. The packet driver is declared with software interrupt "0x60", given an interface name of "eth0", a transmit queue packet length of 10 packets and an MTU of 1500 Bytes. The "attach" command can be used to declare several types of devices:

"asy" asynchronous devices connected to the PC COM ports

"packet" packet drivers in the classes: ethernet, ARCNET, SLIP, SLFP or KISS/AX25

"pc100" PACOMM PC-100 (Zilog 8530) card

"drsi" N6TTO driver for the Digital Radio Systems PCPA 8530 card

"eagld" WA3CVG/NG6Q driver for Eagle Computer card

"3c500" 3Com C501 ethernet card

The "ifconfig" command is used to configure an attached interface. If the command is typed without arguments at the KA9Q prompt, it will list all known interfaces.

In order to route packets between the various interfaces known and declared to KA9Q, a routing table has to be set up. Although RIP is available in KA9Q, a static table is usual. The "route" command is used for this purpose; several similar forms are possible:

• adding an entry to the routing table

route add <dest_host>[/<mask_bits>] <iface>

route add <dest_host>[/<mask_bits>] <iface> <gateway_hostid> [<metric>]

route add default <iface>

• removing an entry from the routing table

route drop <dest_host>/<mask_bits>

• displaying the routing table

route

These forms are illustrated in the configuration file above. The <mask_bits> parameter defines the number of most significant bits of the address are relevant for this entry. The ARPA class A, B, and C internet network addresses therefore correspond to <mask_bits> of 8, 16 and 24 respectively. However, KA9Q supports full classless routing and so the size of networks or subnets are not restricted to these boundaries. This is illustrated in the above configuration file by the network 194.112.91.0 which has a <mask_bits> of 28 and is therefore a subnet with 16 addresses (i.e. the 4 least significant address bits). Note also that two addresses of any network are not generally available for use; the first address corresponds to the total subnet address (i.e. the subnet 194.112.91.0) and the last is used for broadcast (i.e. 194.112.91.15).

KA9Q automatically adds a static routing table entry corresponding to the "ifconfig <iface> netmask" command. Hence a routing table entry for the network 194.112.91.0 has been added and does not need adding again. For this reason, the isdn interface declatation includes a ìroute dropî command since this interface is really only a point-to-point connection and not a conventional network connection.

KA9Q also automatically adds a routing table entry corresponding to the "ifconfig <iface> broadcast command. In the routing table, this appears as a single host routing entry and should be removed, hence the "route drop" command in the interface definition.

The ethernet and isdn interfaces are configured in exactly the same way. To KA9Q they both look like ethernets.

The next section sets up additional entries in the static routing table. Note that alternatively, RIP can be used but its hardly necessary for a simple access router. A default route, over the ISDN link is added here. Other subnets routed through internal routers or gateway machines could of course also be added. Here is an example of a more complex routing table as displayed on the KA9Q console with the "route" command:

This finishes the most important part, without which, nothing will work. The rest of the configuration file deals with some niceties which may be desireable but are not essential. Only some points will be discussed here. Most of the following is best commented out during initial setup, until the basic configuration is working.

The "ip log" command is only valid with the "Hommes" version of KA9Q and defines the syslog host for logging data from the packet filtering rules. These syslog report packets are sent from the ip address of the isdn interface. The packet filtering rules must let them through! These rules are defined in the seperate file ìc:\ka9q\isdn0.filî but could be included in "autoexec.net" if desired. The general form of the rules is:

ip filter <interface> log <deny;permit> <in;out> <type> <source> <destination>

where:

<interface> symbolic interface identifier

log this applies only to the "Hommes" KA9Q version. If present, this will cause logging of each application of the rule to the syslog host defined by the "ip log" command.

<deny;permit> refuse ("deny") or allow ("permit") packets to pass

<in;out> direction of transfer with regard to the router machine

<type> packet type:

* any ip packet

icmp any icmp packet

icmprd any icmp redirect packet

icmpxrd any icmp packet except a redirect

tcp any tcp packet

tcpsyn tcp packet with the SYN bit set and the ACK bit clear. This implies an attempt to set up a connection.

tcpxsyn tcp packet with either the SYN or the ACK bit lear. This implies an existing connection.

udp any udp packet

<source> packet source address of the form:

[!]<address>[/<mask_bits>][:<port>[+][-<hiport>]] where

! any address but .... (negation)

<address> ip address in dotted quad form or a resolvable domain name or ì*î

<mask_bits> number of significant address bits in the address

<port> ip port identifier

+ indicates all ports including and above <port>

- <hiport> indicates ports up to port <hiport>

e.g. ip filter isdn0 deny in * 194.112.91.0/24 * prevents any packets pretending to come from an internal network address from entering.

Two commands are also provided for interactive use:

ip filter <interface> list list filter rules for <interface>

ip filter <interface> delete delete all filter rules for <interface>

Several services are also started:

ftp normal ftp server, permitting the downloading of the configuration files to a remote machine, for example. This is extremely useful to have available when setting up a new router.

remote remote control to exit or reboot the router. A password is required as defined in the next line "remote -s password" This is possible from a DOS machine or, using the "ka9q-remote" package, from a UNIX host.

ttylink remote console accessible via telnet using the ftp user/password combinations. This only works with the "Hommes" distribution of KA9Q.

Finally, this configuration file ends by setting the local time of day clock from a remote server, in this caes, the machine "time.crystal.de". This is probably best commented out during development

KA9Q: domain.txt

The DNS configuration file is similar to a named configuration file. If all references to hosts in the autoexec.net file are given by ip addresses, then this file can be empty, otherwise it should define the symbolic host names used. It can contain A, CNAME, MX, NS and SOA records. This file is updated by the system and acts as a cache for further translations. TTL vales are respected if the command "domain cache clean on" has been used

KA9Q: ftpusers

This file defines users and passwords for ftp access to the router. Here is an example with a single entry

Each entry is on a spererate line and consists of four entries sperated by exactly on space:

<user> <password> <start> / <permission>

where:

<user> user name

<password> user's password in plain text

<start> the top level directoy in UNIX style

<permission> UNIX style permission for user:

1 - read files

2 - create new files

3 - read access plus create new files

4 - overwrite/delete an exiting file

5 - read and overwrite/delete existing files

6 - overwrite/delete existing files plus create new files

7 - read, create new and overwrite/delete files

Changing the ISDN Access

it happens from time to time rthat an Internet service provider moves an user access to a different router. What needs to be changed in a running KA9Q router configuration? This section rounds off the description and configuration discussion above by illustrating the steps needed to do this change. If you have understood the material above, this will be straightforward.

STEP 1: ISPA Configuration

Change the line appropriate for the link to the provider:

a) ip address of the provider's ISDN interface

b) phone number of the provider's ISDN router

c) communications protokol

STEP 2: KA9Q Configuration

Change the interface definition commands for the ISDN provider link only. This is all in the file autoexec.net

a) change the ip address of the ISDN interface to the new one provided by the provider

b) change the corresponding "route drop" command

c) change the ISDN network mask ("ifconfig isdn0 netmask" command)

d) change the corresponding "route drop" command

It will also be neccasary to change any ip filtering rules applying to the ISDN interface.