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:
KA9Q Network Operating System
Passive ISDN Card
Standard PC Hardware & Software (ISA
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
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
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
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
The table can be stored in a text file and has the format:
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:
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 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
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.
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:
demon internet ftp://ftp.demon.co.uk/pub/demon/ibmpc/dos/files/
Thomas Hommes http://www.bg.bib.de/~tshm/isdnrouter/
Source code is also available.
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
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:
echo ISDN-Router with KA9Q
rem Start S0 API 1.1 driver, i.e. the CAPI 1.1.
COMMAND /C c:\online\starts0.bat /t
rem Setup our ISDN number to answer calls on
echo Load the ethernet packet driver
c:\ethernet\nwpd 0x60 5 0x300
echo Load ISPA packet driver
rem The configuration file is often just called
rem stored directly on the hard disk
c:\ispa\ispa ? 0x61 c:\ispa\isdn0.ini
rem Now get the KA9Q stuff going
rem Put it in a loop so we keep right on goin'
rem when developing the configuration, its best
to rem the
rem loop out temporarily. The KA9Q software is
rem "net" rather than "router"
router -d \ka9q
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
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
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
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
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:
######### ISPA Packet Driver Configuration File
# Global Options
-b # Disable BOOTP responses
-c 0 # Controller (card) i.d.
-e 1 # EAZ -> MSN table index number
-z 5 # Force a reboot every 5 days
-m 188.8.131.52 # ISDN interface ip address
-r 184.108.40.206,220.127.116.11 # syslog logging
-u # Restrict to one B channel
-w # Display activity on upper-right
# Translation Entries: Unspecified Incoming Calls
# ECRC's ISDN Gateway
#18.104.22.168 * -p -d 2 -t 180,60
# Translation Entries: Incoming/outgoing Calls
# ECRC's ISDN Gateway
22.214.171.124 0,8992401060 -p -d 2 -t 180,60
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:
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 126.96.36.199,188.8.131.52 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
-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
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
The general format of translation entries is:
<ip_address> the ip address of the remote machine
<phone_number> the phone number to reach teh remote
<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:
||number for incoming callers checks
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
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
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)
-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
user and password for the remote site should it request PAP or CHAP authentication.
<user> can be <user>@<host> for Cisco CHAP challenges.
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
This file is the main configuration file for KA9Q. All the commands
contains may be entered by hand at the KA9Q prompt. Here is a sample
###### KA9Q Configuration File ########
ip address 184.108.40.206
# Let's assume an AT type clock chip so we can
# measure times in ms
# DNS Setup
domain addserver dns.crystal.de
domain suffix crystal.de
domain cache clean on
domain trace on
# ETH0 interface configuration
# remember to delete the erroneous route KA9Q
# automatically sets up for the broadcast address
attach packet 0x60 eth0 10 1500
ifconfig eth0 ipaddress 220.127.116.11
ifconfig eth0 broadcast 18.104.22.168
ifconfig eth0 netmask 0xfffffff0
route drop 22.214.171.124/32
#ISDN0 interface configuration
attach packet 0x61 isdn0 10 1500
ifconfig isdn0 ipaddress 126.96.36.199
ifconfig isdn0 netmask 0xffffffe0
route drop 188.8.131.52/27
# Now let's set up a static routing table.
# The "route drop" stuff above will have
# that by this point the table is empty.
# Routes over eth0 (automatically added but
# left commented out here as a reminder)
#route add 184.108.40.206/28 eth0
# Routes over isdn0
route add default isdn0 220.127.116.11
# Logging and tracing .... I only use for
#trace isdn0 0001 \ka9q\isdn0.log
# Load some packet filtering rules for the
# interfaces and set up logging
ip log dns.crystal.de
# Start any internet servers or services we want
remote -s password
time server time.crystal.de
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
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
"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>
route add default <iface>
- removing an entry from the routing table
route drop <dest_host>/<mask_bits>
- displaying the routing table
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 18.104.22.168 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 22.214.171.124) and the last
is used for broadcast (i.e. 126.96.36.199).
KA9Q automatically adds a static routing table entry corresponding to
the "ifconfig <iface> netmask" command. Hence a routing
table entry for the network 188.8.131.52 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:
Dest Len Interface Gateway Metric P Timer Use
184.108.40.206 28 isdn1 220.127.116.11 1 0 0
18.104.22.168 28 eth0 0 0 94
22.214.171.124 28 eth0 126.96.36.199 1 0 0
188.8.131.52 28 eth0 184.108.40.206 1 0 0
default 0 isdn0 220.127.116.11 1 0 31
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>
<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
<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:
! 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 * 18.104.22.168/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
ip filter <interface> delete delete all filter rules
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
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
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>
<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"
d) change the corresponding "route drop" command
It will also be neccasary to change any ip filtering rules applying
to the ISDN interface.