Keywords: IPRoute, ISPA, ISDN, proxy server, sharing a connection
to the Internet, modem sharing, IP Masquerading, Network Address
Translation, software router, DOS
This page contains some background information on how you can
connect a LAN (running Ethernet, for instance) to the Internet, using a
standard (personal) account. The connection to the Internet can be an
analog modem, ISDN or even a cable or ADSL modem.
Most of this information is severely outdated.
Nowadays it's more cost effective to buy an inexpensive
hardware based firewall/router such as those from Linksys or Draytek.
This webpage mainly covers IPRoute, a DOS software router. This program
does not seem to be sold anymore. Alternatives are mentioned below. Linux based solutions such as Astaro are probably a much better
solution nowadays. Plus, they are free! People also use the Internet
Connection Sharing option included with recent versions of Windows.
IPRoute is a DOS software router for TCP/IP. ISPA
is
an emulator which lets an ISDN card appear like an Ethernet card to
DOS.
The focus of this webpage will be mainly on using IPRoute with ISDN
plug-in cards through the ISPA driver. The software also works with
analog modems, ISDN modems and cable modems (in that case, just skip
the parts where ISPA is mentioned because ISPA is only needed when you
use an ISDN plug-in card).
The latest version for registered users of IPRoute is now V1.10.
A (personal) Internet account isn't that expensive anymore. Let's say
you have a whole (Ethernet) network of computers at home. One for
yourself, one for the kids, one on the toilet, you get the idea...
Preferably, you want to access the Internet from each of those
machines.
One machine, which has the modem, will be the "middle-man" for the
other machines. You want all connected machines to share the link to
the Internet. If you have a couple of "workstations", a 28K8 modem will
probably not be enough. ISDN
may be a good option in that case. If you use a "proxy" or a feature
called "IP Masquerading", you will be able use a standard (read:
inexpensive) personal account to connect the LAN to your Internet
Service Provider (ISP). All this is explained in the following.
Here are some examples of connecting a LAN to the Internet. I already
mentioned the "homebrew" LAN. In most cases people use a coax Ethernet
cable so they can do without a "hub" (central interconnection device).
Another application is a school which has a couple of computers and
wants to connect to the Internet at low cost. Or you can think of a
small office. I myself used IPRoute in combination with ISPA (described
later on) to connect the LAN of a user group to the Internet during
meetings (HCC Amsterdam).
But first, a little bit of theory. Every computer connected to the
Internet must have a unique "licence plate", called an IP address.
Unfortunately there is only a limited number of IP addresses available.
As with any scarce goods, if you need more IP addresses you will have
to pay!
Internet developers have devised workarounds which help to limit the
number of needed IP addresses. For instance, an ISP has a certain
number
of customers but they can't possibly be all logged in at exactly the
same moment. So the ISP buys a smaller block of IP addresses. When you
call in to your ISP, you receive one of the IP addresses out of this
block from your ISP during the connection setup negotiation process. So
you don't know your IP address in advance. This is called a dynamic
IP address.
However, some ISPs also offer fixed addresses, i.e. every time you
dial-in you get the same IP address. This is of course advantageous if
you are connected to the net for long periods (e.g. if you have an ADSL
or cable modem) or if you want to run servers. The problem is that most
ISPs charge extra for static IP address if they are used for
dial-up connections.
So you want to connect your LAN to the Internet. This means that there
is one machine which has the link to the Internet (modem, ISDN card).
Let's call that one the gateway computer, for simplicity. The
gateway computer receives packets from the other machines
(let's
call those the workstation computers) and then passes
them to your ISP. And vice versa.
There are several options that can be used to connect a LAN to the
Internet. Invariably, they all work with one machine forwarding the
packets it receives from the other machines to the Internet.
Serial port sharing
Routing
Proxy servers
IP Masquerading
I will discuss each of them in the next paragraphs. Tony Rall of IBM
Almaden has also written an excellent article
on this, with special attention to OS/2.
As you probably know, you can share disk drives and printers with
several operating systems such as Windows for Workgroups, Windows
95/98/ME/NT/2K and Warp Connect / Warp 4. But in some cases you can
even
share a serial port. A modem can then be attached to this shared serial
port. However, only Warp Connect and Warp 4 support serial port sharing
out of the box. OS/2 2.x and Warp non-Connect support it if you install
the free OS/2
LAN Manager client by Microsoft. A special version of Windows,
called Small Business
Server (SBS), also contains a modem server. Special Windows client
software is included with SBS. IBM now also has a Small
Business Suite for Windows, competing with Microsoft's SBS. As you
can see from the specifications, IBM's SBS also has a modem pool
server,
which probably means that it too comes with its own proprietary modem
clients.
Client software which is readily available for your Windows
machine(s) is offered by (in alphabetical order):
I am not sure if SBS (from either Microsoft or IBM) is compatible with
these clients. Serial port sharing over NetBIOS/SMB/CIFS has not been
standardised nor documented, as far as I know.
In most business setups, a special modem server is used.
This is a hardware device which has multiple serial ports equipped with
modems. Workstation computers which connect to this server then get a
virtual serial port, say COM6. The disadvantage is that only
one user can gain access to a modem at the same time, if he uses it or
not. He has to release the remote modem out of the goodness of his
heart, once he's finished. The advantage is that the user has the full
bandwidth of the modem at his disposal. Plus, it is not limited to IP
or
IPX traffic but you can also use it with fax software, connect to BBSes
etc.
This is what most businesses use. They get a block of static IP
addresses from their ISP and give each of their machines an IP address.
In most cases, what I call the "gateway computer" is in fact a router,
a special hardware device which forwards the packets. Many operatings
systems (e.g. Unix, Windows NT/2K, OS/2 etc.) can route IP packets too.
*) The disadvantage of routing that it is more expensive because you
will have to 'buy' static IP addresses from your ISP. Not only that,
the
ISP will have to define a "route" to your own little subnet on their
systems. That means they'll have to do some work and thus they want to
be paid for it. It also means that intervention by your ISP is required,
i.e. you can't do it all on your own. This is in contrast with the next
two strategies.
*) Nathan Goyette
pointed out to me that Windows 9x can be tweaked to support routing
through some registry editting, although this is an undocumented
feature.
Routing works great for businesses which are connected to the Internet
24 hours a day. But what if you're not, and you still want to hook up a
whole LAN to the Internet once in a while? One solution would be if
somehow a workstation computer could ask the gateway computer to send
and receive data on it's behalf. The software which does the trick is
called a proxy server. A well known example is WinGate. As far as the operating
system is concerned, the proxy server is a normal TCP/IP application. A
workstation computer sends a request to the gateway asking it to send
data to the Internet. The data is sent using the gateway's IP address,
and any response comes back the same way. Any number of computers on
your LAN can use the connection in this way at the same time, as long
as
the data for separate requests is kept separate. The gateway computer
can be a 'normal' PC with a standard Internet connection. There are
several different way to do proxying: using the SOCKS protocol, socket
relays and application proxies.
The SOCKS protocol is defined by an official standard.
TCP/IP applications have got to support SOCKS (in other words: must be SOCKSified)
in order to connect to a SOCKS proxy server. Some do, but many of them
do not. Some operatings systems, such as Warp 4, have special support
in
their TCP/IP stack so that non-SOCKS aware programs can be used with
SOCKS servers.
With socket relay (also known as "port mapping"), the
proxy
server mirrors ports from the remote machine on the Internet and makes
them available as though it was providing the services. In this
case, when a workstation on the internal network connects to for
instance the SMTP port on the proxy server, the proxy server opens a
matching socket on the connection to the Internet and then just ferries
data between the two connections. Unlike SOCKS, a socket relay does not
require any special support on behalf of the client program, so it can
be used with most applications. The disadvantage of socket relays is
that not all protocols can be handled. For instance, using the FTP
protocol in non-passive mode is very problematical, and is not normally
possible with a socket relay system.
An application proxy is a special TCP/IP program that
knows
about a particular application protocol, and will accept requests using
this protocol. A common example of this is the HTTP proxy provided by
many internet server providers. This program accepts HTTP requests from
clients using the HTTP protocol and converts them to requests to other
HTTP servers. The resultant data is then copied back to the client
computer. This approach has the advantage of allowing the proxy server
to make use of its special knowledge about the application protocol in
order to make the request more efficient. For example, most HTTP
proxies
will cache requests and can respond without requiring any further
network access if the requested page is already in the cache.
Some operating systems, most notably Linux, have the capability to
perform IP routing with the addition of changing the IP address
in the packets on the fly, i.e. as the data is passed through from the
LAN to the Internet. When there is a mapping of multiple addresses on
an
internal LAN to one particular IP address of the gateway, this is
called IP Masquerading. When the mapping is a bit broader (any IP
address to any other IP address) the feature is called Network
Address Translation (NAT). NAT is a superset of IP Masquerading and is
often used in firewalls for security reasons. Note that ISPA also has a
feature called NAT (used for a different purpose).
NAT is normally a feature of the TCP/IP stack. Many older TCP/IP
stacks (Warp, Windows 95 etc.) don't support NAT, whereas newer
operating systems (Linux, Windows 98SE and higher) do support it. The
shareware DOS application IPRoute
is another example. It comes with its own custom TCP/IP stack
supporting
NAT.
Let's say in the following example that you use IPRoute for NAT.
IPRoute changes the addresses in the packets it receives from the
workstation machines into the address it is using itself. For example,
2
workstation machines can each run a webbrowser. IPRoute changes the
addresses so the ISP thinks both webbrowsers are running on one and the
same machine! There's nothing strange with that, it has always been
possible to run multiple webbrowsers on one machine.
Running servers (say, webservers) on multiple workstation machines
is a bit less transparent. Most servers listen to a "well-known" port
number. For a webserver this is port 80. But only 1 server can listen
to
a port at the same time. That means that the gateway machine can remap
a port to only one workstation machine. So, if you want to run more
than one webserver on your internal network which must all be reachable
from the outside, there is a problem. Fortunately, there is also a
solution. Let's say you have webservers on each port 80 of the
workstation machines 192.168.0.2, 192.168.0.3 and 192.168.0.4. You can
remap port 80 on the gateway machine to port 80 on 192.168.0.2, port 81
to port 80 on 192.168.0.3 and port 82 to port 80 on 192.168.0.4. People
on the outside will have to specify URLs with "non-standard" ports for
the last two workstation machines, say http://www.example.com:81/
and http://www.example.com:82/
It works but it isn't very elegant...
One of the major problems with using the SOCKS protocol is that it
requires that clients be able to perform name lookups for external
addresses, usually via DNS. This means that as well as implementing a
SOCKs server, the proxy server must also provide a full DNS service to
it's clients. Additionally, some protocols do not lend themselves to
transport via SOCKs. The FTP protocol, in non-passive mode, can be
particularly difficult. It is also possible to use a socket relay
server
without access to a DNS server, but this is not always the case.
If you have several workstation machines who all hit the same
webpage at the same time, a caching proxy server may be provide better
performance than a system with IP Masquerading. That is because the
webpages can be served from the cache (local harddisk) instead of
getting each of them over the modem/ ISDN link. On the other hand, a
caching proxy may require a more powerful machine with a big harddisk,
i.e. you will probably not get away with a lowly 286, as you can with
IPRoute...
IPRoute:
DOS software which sports a TCP/IP stack with routing and IP
Masquerading.
Due to licencing restrictions, the shareware version of IPRoute
cannot be distributed from www.mischler.com
anymore. You can still download it from this
location though.
Windows 98 SE and higher come with
"Internet Connection Sharing". In fact, Microsoft has bought Nevod and
merged its NAT1000 product into Windows.
Commercial version of IPRoute/Secure,
extended with firewall, accounting and Dynamic DNS support etc. etc.
FreeSco: a 1-floppy
based version of Linux supporting IP Masquerading, dial-up server,
print
server etc.
Linux Router: a
(discontinued) micro-distribution of Linux.
Share The Net:
(also discontinued) a 1-floppy based version of Linux supporting IP
Masquerading.
NAT32:
Windows9x/NT/2K
software with NAT. Excellent software, and the
price
is right. I use it myself. Configuration is partly through text files
(Unix/Linux style) so it's certainly not something for everyone.
ISDNPM:
OS/2 Dialer (replacement for IBM's "Dial Other Internet Providers") for
internal ISDN cards (CAPI driver needed), which also supports IP
Masquerading.
InJoy: OS/2 Dialer
(replacement for IBM's "Dial Other Internet Providers") which also
supports IP Masquerading.
Vicom: has
software routers with and without IP Masquerading for the Mac.
IPNetRouter by
Sustainable Networks is a configuration program for Open Transport
(Mac)
which you can use to configure network routing. Also supports NAT / IP
Masqueradiing.
Very small, but easy to use proxy server for OS/2: Tproxy.
IGATE, proxy
server for OS/2, Windows 95 and Windows NT.
Freeware SOCKS5 (powerful) proxy server for OS/2, made by
Philippe Gillain of IBM Belgium: SOCKD.
You need to use SOCKS enabled software to be able to use it. But also
your TCP/IP stack can be SOCKSified. For instance, Warp 4 (and Warp
Connect, with an update) can be SOCKS4 clients. You need to specify the
SOCKS server in the TCP/IP configuration settings. For Windows clients
you need to download a SOCKS client. Ethan Hall-Beyer has
written an excellent article
in OS/2 E-Zine on how you can set up a Socks client.
Winroute: IP
Router, Network Address Translator, Packet Layer Firewall, Cache-Proxy
Server (http, ftp, gopher), Mail Server, Scheduler for events such as
dial-up connection and disconnection, internet mail processing etc. For
Windows95/NT.
Sygate: Network
Address Translator for Windows 95.
Nevod NAT1000: Network Address Translator for
Windows 95/NT. (Nevod has been bought by Microsoft, NAT1000
product withdrawn from market. Incorporated into Windows 98SE and
higher).
Both IPRoute and ISPA use the word 'NAT' (Network Address Translation)
for more or less different purposes. I will try to explain the
differences.
In ISPA, NAT is used for handling the dynamic IP address you get
from your ISP. And it works like this. When ISPA gets the dynamic IP
address from the ISP, there is no mechanism which allows the
application
running on top of ISPA (IPRoute, NCSA Telnet, etc.) to get that IP
address! So ISPA uses a trick. In both the application and ISPA you
specify the same dummy IP address (I use 145.220.128.13, but anything
is allowed). You need to specify these in advance! This allows both to
communicate with each other. Now, when ISPA dials out and receives the
real dynamic IP address, it changes the address in that packet on
the fly to the dummy IP address. This way, ISPA uses a dynamic IP
address it gets from the ISP, while the application (IPRoute) thinks it
has a static IP address!
IPRoute also has a NAT, but it's used for a different purpose. It
allows multiple machines connected to a LAN access the Internet through
only 1 IP address. This is what I earlier called IP
Masquerading.
Here is a typical setup for IPRoute and ISPA, acting as an Internet
router for the workstations.
your gateway your workstations +----------------------------+ | IPRoute (192.168.0.1) | | $50 shareware | | running DOS, 286+, 1 Mb+ | +----------------------------+ | | +-------------+ +-----------------+ +-------------+ | ISPA shim | | packet driver | | OS/2 Warp | | shareware | | e.g. for NE2000 | |(192.168.0.3)| | $30 | | (freeware) | +-------------+ +-------------+ +-----------------+ || | | || and others +----------------+ +-----------------+ +-------------+ || running Linux, | CAPI driver | | network card | | Windows 9x | || NT, Mac, etc.: | (supplied with | | (e.g. NE2000) | |(192.168.0.2)| || 192.168.0.4, | ISDN card) | +-----------------+ +-------------+ || 192.168.0.5, +----------------+ || || || etc. | #===============================================# +-------------+ Ethernet cable (coax or UTP with hub/switch) | ISDN card | +-------------+ | NT1 connector | | | The workstations think they *********************************** | are connected directly to * The Internet (through your ISP) * <---+ the Internet... ***********************************
As you can see, I use the "dummy" Class C subnet 192.168.0.x
for the local network with the workstations. This is a "private" block
of addresses, especially reserved for exactly these kind of setups.
These addresses are not intended to be used on the Internet (the IP
Masquerading of IPRoute makes sure of that). See also RFC1918.
Here are the configuration scripts I am using for such a setup.
Hopefully they are a good enough example. Of course you have to remove
the comments at the right hand side of ISP.BAT. By the way, ISP stands
for Internet Service Provider in the following.
ISP.BAT (located in root directory)
@echo off \network\ne2000 0x61 10 0x300 <- Load packet driver for Ethernet card (in cd \online-i this case an NE2000 on IRQ 10, port 300) call starts0.bat <- Load the CAPI driver for your ISDN card cd \network\ispa (in this case a Teles S0/16.3) ispap ? 0x60 isp.ini <- If/when you have registered ISPA, cd \network\iproute replace '?' with your registration key! ipr isp.ipr (with '?' it will only work for 15 minutes).
ISP.INI (located in \NETWORK\ISPA)
# call with ISPAP.EXE # # global options: #-u # Uncomment if you want only one active channel -w # DOS activity display: on -d # Disconnect on release: on -m 145.220.128.13 # Dummy IP address for comm. with IPRoute # # because no IP-address is specified all packets (unicast and # broadcast) are forwarded to the peer. # # for all other options the defaults are used # # REPLACE isphonenumber, myloginid, mypassword WITH YOUR INTERNET ACCOUNT INFO! # Add -c for CHAP authorization, otherwise PAP is used. # -p means: synchronous PPP over HDLC (which seems to be the # most used protocol) 0.0.0.0 ispphonenumber -p -n myloginid,mypassword -o -r -t 240
ISP.IPR (located in \NETWORK\IPROUTE)
set log file out.txt set log raw on set log monitor on
; ISPA packet driver on 0x60. Use the dummy IP address for comm. with ISPA. packet isdn0 0x60 145.220.128.13/24 ; Route all packets to remote side of ISDN line (your ISP). The IP address ; used here doesn't seem to matter. You might just as well leave it this way. route * isdn0 145.220.128.1
; Allow all outgoing connections nat isdn0 * * 145.220.128.13 ; Configure ethernet interface on network 192.168.0.0/2 packet en0 0x61 192.168.0.1/24 ; Broadcast RIP routes on the ethernet ; Start a command interpreter on the console command exit
You can get packet drivers for Ethernet cards from this site. If your
Ethernet card does not have a DOS packet driver, but only an ODI
driver,
you can download a shim ("interface") from Dan Lanciani's site.
Don't be alarmed if the software router stops running after about 15
minutes. That's ISPA's shareware limitation if you haven't registered
it
yet.
In ISP.IPR, you find several nat isdn0 lines. With this I tell
IPRoute to route incoming sessions of port types 80 (WWW), 1376 (OS/2
Person-2-Person), 2213 (Kali games), and 20/21 (FTP) etc. to one
particular machine (mine :-). However, Dave Mischler told me that you
can route all incoming sessions (any port) to one machine (in
my
case 192.168.0.2) if you use the following line instead of the 5
tcp/udp
NAT lines: nat isdn0 * 192.168.0.2 145.220.128.13
So what I am doing is a bit of a hassle.
When you start the ISP.BAT batch file, make sure that both IPRoute
and ISPA start with no warning messages. The first test is to ping a
workstation machine on the Ethernet network using the PING command at
the console prompt of IPRoute, for instance: PING 192.168.0.2
If the ping test fails, verify that the packet driver is installed
correctly (IRQ, DMA, I/O port) and that IPRoute is able to see the
packet driver for your Ethernet card.
Now ping a machine which is not located on your Ethernet LAN, a
machine on the Internet, for instance PING 165.113.58.253 or
use the IP address of the Domain Name Server your ISP told you to use.
The modem/ISDN card will dial and establish a connection with your ISP.
On every workstation machine, you will have to specify the IP number
of the Domain Name Server (DNS) of your ISP. If you have multiple IPSs,
you can specify more DNSes. I'd love to have IPRoute perform some kind
of DNS proxy service (so you can specify 192.168.0.1 as the
DNS, which makes the workstation machines almost completely independent
of the ISP used) but Dave says it's difficult to do (NAT32 supports it
though). There might be a way to get around this and that is by
installing your own DNS or DHCP server.
I haven't quite figured out how to use both ISDN B-channels at the
same time, to get a bandwidth of 128 Kbps. However, I found the ADC Kentrox
Pacesetter FAQ to be very informative on this subject.
IPRoute does not seem to be sold anymore. The information below
may be outdated.
I live in Europe and paid the $50 using an International Money
Order (the Postbank, to be exact). Worked liked a charm. The advantage
for Dave is that he didn't have to pay his bank any fees. For more
information on this, download IPRoute and
check the README.1ST. This is what Dave had to say about this:
To register, send a check or money order for $50 US by postal mail to:
David F. Mischler 245 McNair Road Buffalo, NY 14221 USA
For electronic fund transfers please use the following information:
Bank Name: Marine Midland Bank Branch: Williamsville Office Address: 5556 Main Street Williamsville, NY 14221 USA
ABA Number: 021 001 088
Account Name: David F. Mischler Account Number: 716-69843-9
Please ask that all fees associated with the transfer are paid in advance. I have received several partial payments due to deducted fees.
Do not use addresses which end with .0 or .255 for either the
gateway machine or the workstation machines (example: 192.168.0.255)
because these are reserved for administrative use. I use an address
which ends in .1 for my IPRouter machine (192.168.0.1).
A user reported that when Windows 95 starts up it does some
broadcasts which force IPRoute to dial out, possibly due to DNS or SMB
traffic.
If you have an ISDN adapter which connects to your serial port
(an ISDN TA) then you can do without ISPA. That's because as
far
as IPRoute is concerned it is hooked up to a normal modem which is
controlled using AT command. In that case IPRoute's PPP implementation
is used and not ISPA's. ISDN TA's such as the Motorola BitSurfr Pro and
the ZyXel Omni TA128 are easier to use and operating system independent
because they don't use any special drivers. However, they are also more
expensive than ISDN plug-in cards for the ISA bus. TA's are more
popular
in the US than in Europe. The disadvantage is that you also need a high
speed serial port such as the 16550 (not always available in old PCs)
or even a Hayes ESP.
Another advantage is that all the administrative stuff, such as
the PPP packetizing, the serial port handling (which costs
interrupts!),
the ISDN protocol handling (most people use a inexpensive passive ISDN
card where the PC processor does all the work) etc. are done on the
dedicated IPRoute machine. This means that this machine "offloads" lots
of work from your main machine(s), so more processor speed remains for
those machine(s) (games!). You could say that with a dedicated IPRoute
machine you have a multiprocessor system :-). Daryl Banttari claims
that the speed of Kali has gone up!
I get many NAT translation error messages on the console.
Perhaps
the ISP's router is screwing up. They don't seem to have any effect
though so I just ignore them. I don't even think this is a problem.
IPRoute completely takes over the DOS machine. You can't do much
else with it, except use IPRoute's command interpreter. You can for
instance use the command PING to test if a system can be
reachable. You must use the numerical IP address, for instance 198.105.232.1
and not the symbolical name, e.g ftp.microsoft.com. Another interesting
command is SHOW INT ISDN0 and SHOW INT EN0 (ISDN0
and EN0 are the defined interfaces, if you used my
configuration files). These will give some statistics on these
interfaces. ISPA also has an option -l x which shows statistics
in intervals of x seconds.
You might not like the idea that a machine with IPRoute is not
available for any other tasks, especially if that machine is fairly
powerful (more than say a 486). If it's a 286, I'm sure you wouldn't
give a fuzz. It is possible to run IPRoute in a DOS
box under Windows 9x. Several people are running such a setup. I am
not quite sure how it affects performance but I assume it's OK. I have
also run ISPA and IPRoute on an OS/2 machine, it works, but I can't
tell
if it's slower. The network card is accessed through a packet driver so
it isn't available to OS/2 for other applications at the same time.
Another advantage of using NAT (even for big companies) is that
if you use dummy addresses such as 192.168.0.x you don't have to change
all the addresses of the workstation machines when you switch to
another
ISP. Of course other settings (such as the DNS/mail/news/web/ftp
servers) still have to be changed.
My user group happens to have more than one ISP. So if there is a
problem with one ISP (bad connection, no more B-channels free,
completely down, or thinks we forgot to pay the bill (happened one time
and it was completely their fault)), we can switch to the other ISP.
The
"trick" is to specify both Domain Name Servers when you configure your
Windows 95, OS/2, Linux etc. workstation machines. So if you switch
ISP, there will be almost no disruption.
Once you get IPRoute up and running, you can even strip the
system of "unneeded" hardware. Eric Johansson writes
about this on his homepage:
The video and keyboard are really only required to get the
router working. Once the system is running cleanly, if your bios
permits, you can remove the keyboard and video to run the system in an
embedded system mode. Shopping in the used/surplus equipment
market should give you one of these systems for well under $300.
Most companies using computers probably have one of these machines
lying
in a closet somewhere. A hard drive is actually a detriment to a router
system because it increases the chances of the router failing because
of heat or a hardware problem. The only time to use a hard drive in a
router is when logging data locally is important and you expect a lot
of data.
One thing you don't want is that IPRoute opens the connection
for
no apparent reason. Especially with ISDN this is very dangerous because
the connection is made within a couple of seconds and generally you
don't hear the modem (or whatever) dialling. You wouldn't be the first
with a huge phone bill! For starters, Windows has a bad habit of
querying the DNS when the TCP/IP entry has been added to the Network
configuration setup. A solution would be to disable the binding of
"Microsoft Client" to TCP/IP on each and every Windows 95 machine. But
this is error prone, once you forget just a single machine, you're in
trouble. An easier solution would be to block these particular DNS
requests in IPRoute:
filter sl0 drop out udp *:137 *:53 filter sl0 permit out * * * filter en0 permit in * * *
See also the IPRoute script I use with
modems. This has the disadvantage that you cannot do name lookups of
SMB/CIFS servers located on the Internet. There are actually very few
of
these (they are considered a security risk), so that may not be much of
a problem. Probably the best solution would be to run your own
(caching) DNS on your LAN. Only genuine DNS requests will cause IPRoute
to dial out then.
A problem with Warp Connect and Warp 4 is that Sendmail also
causes IPRoute to dial out once in a while. You can fix this by killing
the Sendmail process and use another mailer (Netscape Mail, Postroad
etc.), or remove Sendmail completely from the startup .CMD file. I
don't
know if installing your own DNS helps in this case.
IPRoute can be run in a DOS box under Windows 95. In this case a
dedicated DOS machine for running IPRoute is not needed. The trick is
to
use the NDIS3PKT "shim". This is a
driver which makes the Windows 95 driver for your network card also
available as a packet driver interface. IPRoute can only deal with
packet drivers. You could run a DOS packet driver in a Win95 DOS box,
but then it completely takes over the network card. With NDIS3PKT the
network card is available for other tasks as well. Tom Hayes invented this trick. He
writes:
The only pitfall we've come across so far is that the dos
box must have focus in order to dial out again after the
connection has been dropped due to idleness. I wrote a small Visual C++ program to periodically give
the IPRoute dos box focus. This avoids the dial out problem altogether.
At the same time, you could install a DNS and/or DHCP server on that
Windows 95 machine running IPRoute.
Another trick by Tom: if the
IPRoute machine is located on a site, and you are elsewhere, you can
remotely access the IPRoute machine using FTP and/or Telnet. Quite
handy
if you need to tinker with the IPRoute scripts or configuration.
145.220.128.13 is the "dummy" IP address mentioned above. If
your ISP has given you a static IP address, use that one instead. The
ports 2021 and 2023 are the "secret" ports you FTP
and
Telnet into. You may alter these of course. Most telnet and ftp clients
allow you to specify these non-standard (custom) ports. But be warned,
use logon scripts with usernames and passwords or else anyone can have
access. Also note that FTP and Telnet transmit passwords in clear text.
That does not mean that any bozo can read them, but sysadmins of your
ISP and Internet long distance carriers might...
It might be an
idea to download PLIP
(not successfully tested by me). This is a DOS packet driver for a
network connection using the parallel port. You use a "LapLink" style
cable to connect another machine to it, for instance, one which does
not have a regular network card. But you could also use it as an
"administrator port", which you use to configure the IPRoute machine
should you have stripped it of non-essential parts such as a keyboard,
a monitor etc. (Of course, you could FTP and Telnet to the IPRoute
machine over the network, but these protocols transmit their passwords
in clear text so anyone with a network sniffer could grab your
passwords. With a machine connected to the IPRouter's parallel port,
there's no such chance).
Other (faster) cables can also be used but these require faster
parallel ports, EPP or ECP. Download PARA14.ZIP for an
excellent tool which allows you to determine what parallel port you
have
(believe me, this one is better than CheckIt or MSD). The docs also
discuss the standards which exist for parallel ports.
The
below does not seem to work! It hangs Windows 95 after a while!
It should be possible to hook up a DOS machine via the parallel port to
a Windows 95 machine which has a connection to the Internet or
whatever.
Run PLIP.COM and WINPKT.COM from the AUTOEXEC.BAT, use NDIS3PKT so that
IPRoute has access to the network card, run IPRoute in a Windows 95 DOS
box. Create config file for IPRoute with entries for both packet
drivers and let it route from the parallel port to the network card.
PLIP + PDETHER + ODIHLP does not seem to work! PIPX + ODIHLP might
work, but it has a time limit and a nag screen and you'll have to pay
to
get rid of these.
Back to top
Notes on ISPA
I live in Europe and paid the DEM 70 (EUR 35) using a bank
transfer from the the Dutch Postbank to Herbert's account at the
Postbank München (not related to the Dutch one!). Worked liked a
charm. The advantage was that for both of us we didn't have to pay
provisions to our banks.
In most cases, you will want the IPRoute machine to dial out
when
there is traffic from one of the connected workstation machines (demand
dialing), and that it disconnects if there hasn't been traffic for a
specified amount of time. The dialing out is standard in ISPA but the
automatic hanging up has to specifically configured with the "max-idle"
option -m xxx where xxx is a time in seconds. With
ISDN
it costs money to set up a connection so you don't want to specify
"max-idle" too low because it will keep disconnecting and reconnecting
(which costs money). But you also don't want to specify "max-idle" too
high because then it will keep the connection open (which costs money)
while there is in fact no traffic. For the Netherlands I'd recommend a
"max-idle" time in the range of 180 and 240 seconds.
You don't hear a dial tone with ISDN, and there are no status
lights. So, especially if you don't specify a "max-idle" setting, watch
out that the line ISDN doesn't open all time! Otherwise you'll be
confronted with an unpleasant surprise next time the phone bill comes
in...
If your ISP uses a Cisco router, it may occur that it sends RIP
packets in intervals of 10 seconds. The ISP wants to 'help' you by
sending these "keep alive packets" and keep the connection up if you
are
sending no traffic. Nice if you live in the US where local calls are
free, not nice if you live in Europe where many ISPs are in hands of
the old national phone companies... ISPA's option -r makes sure
that these keep alive packets are ignored. That is, they do not count
as "real" traffic so they won't keep open the connection if there is no
traffic.
With the -m xxx option ISPA can fire up the second 64
Kbps
B-channel if the workload generated by the workstation machines is
higher than 6000 bytes per seconds for more than xxx seconds in a row.
The problem (at least in the Netherlands; in the US it's not much of a
problem) is that not every ISP don't supports it. And if they support
it, but they want to be paid extra.
ISPA supports many ISDN protocols. I found the documentation a
bit confusing though. Let's say your ISP says they support PPP. You
need
to get more information than that because ISPA supports several
variants. It has the following options to choose from (odd protocols
have not been included):
-p sync PPP over HDLC (the normal case, used by
Windows
as well).
-l2 async PPP over X.75
-e2 async PPP over X.75/T.70NL
-b async PPP over V.110
You can choose only one option of these, they are mutually exclusive.
For each of the options you can/must use -n to specify the PPP
options such as login ID and password, and also -c if you need
CHAP instead of PAP (the default) for PPP authorization. Sync PPP
over HDLC is by far the most popular protocol. It's also the
default
for most Windows systems, so try -p first.
Always use the
latest versions of the ISDN CAPI drivers, ISPA and IPRoute. I have tested
ISPA sucessfully with the following ISDN cards:
AVM B1: tested with
both the CAPI 1.1 driver and the CAPI 2.0 driver (using CIPA, the CAPI
2.0 counterpart of ISPA)
Teles S0/16.3: comes
only with a CAPI 1.1 driver, so only ISPA will work and not CIPA.
Cisco 200: I had many problems with this card and the
CAPI 2.0 driver that came with it. A machine with the Cisco + the CAPI
2.0 driver + CIPA + IPRoute crashes unpredictably, sometimes after 2
hours, sometimes after 2 minutes. After a lot of experimentation and
scrupulously ruling out other causes I came to the conclusion that the
CAPI 2.0 driver must have been buggy. The Cisco 200 is in fact an ITK ix1-micro . New drivers can be
found on their website. The DOS CAPI 2.0 driver still seems to crash
but
I have one report from Wolfgang
Bröker who writes that he had no problem with the card. He has
a newer version of the card though, perhaps that's the difference.
There aren't that many (freeware) TCP/IP applications for DOS
because there isn't really a standard for a DOS TCP/IP interface. Most
DOS applications more or less come with their own built-in TCP/IP stack
and access the network card driver directly. So, what if you can't get
IPRoute and ISPA working and you don't know which one of the two needs
some tweaking? You might want to try another DOS app than IPRoute, just
for the sake of testing. I used NCSA
Telnet for that purpose. You can configure a static IP address in
NCSA Telnet, or let it use ISPA's BOOTP support.
CAPI 2.0 is a newer standard than CAPI 1.1. DOS and OS/2
applications (mostly communications software) generally require CAPI
1.1
while Windows drivers are often CAPI 2.0. I don't think it matters
which one you have because both seem to work fine (for developers it
may
be a different question). However, as you can see from my buggy ITK driver story, you might probably want to
register ISPA (for CAPI 1.1) instead of CIPA (for CAPI 2.0) if you want
to use IPRoute.
There's a special version of ISPA which allows you to use 8 ISDN
B-channels. Too bad that most ISPs only allow dialling in with 1
B-channel.
ISPA/CIPA support the standard in bundling B-channels: Multi-link
PPP. Previously it didn't work.
(Old: I received a report from Herman Bos that it is possible to
use both B-channels with the Teles card if your ISP allows you to login
twice under the same accountname. I am unsure if you have to run the
Teles BUNDLE command before you load ISPA. But you will have to specify
-m
8,180 (2nd channel open after 8 seconds of maximum load, down after
180 seconds of low load; or change this to your likings). So far, I
receive one report that this works with the Dutch provider XS4ALL. But there are some drawbacks:
you'll need a static IP address (which
normally
costs you extra), plus you must be so lucky that the second B-channel
also connects at your ISP to exactly the same ISDN router as the first
B-channel! There might also be alternative ways to get ISPA/IPRoute
working with both B-channels, but these may require using of
proprietary bundling protocols (e.g. Teles' BUNDLE), which may or may
not be supported by your ISP).
One of the peculiar things of ISDN is that it's difficult to
figure out what's going on on the ISDN line. If you use one of Herbert
Hanewinkel's Windows drivers you can use the included ISDNMON Windows
program. But with IPRoute + ISPA you're dealing with DOS and DOS is
essentially single-tasking. Fortunately, the Graz University of
Technology, Austria, has developed a freeware ISDN monitor, but
unfortunately I cannot find it anymore on their
site. You load it in between ISPA and IPRoute. It shows the
internals of the packets sent over the B-channel(s). I haven't tried it
yet so I can't tell how much the performance impact on the system will
be. The software is in German.
If you specify the option -w, ISPA monitors the status
of
the ISDN line in the top right hand corner, including the average load
in Kbps received and sent in the last 8 seconds. This feature does not
interfere with the IPRoute console screen.
There is a freeware "CAPI-to-packet driver" available, called PAPI.
But this one has much less functionality. And it has not been updated
for a couple of years), for instance it doesn't support PPP so it will
probably not be much use to you if you want to dial up to an ISP. It
may
work if you want to hook up two LANs of your own through ISDN, because
what I understand from it PAPI's main use is to send whole Ethernet
packets. I haven't quite figured out how they implement security (you
don't want everyone to dial in to your Ethernet, do you? :-), perhaps
with ISDN's Caller Identification...
cFos (older verions
also here)
is a piece of software that emulates a serial modem (with AT commands
and all) using the CAPI driver of your ISDN card. It might be possible
to use cFos and IPRoute together, but I have no idea if it works. In
that case, you will be using IPRoute's PPP implementation. With the
ISPA
+ IPRoute combination I described earlier, ISPA's PPP implementation is
used. A disadvantage of cFos might be that it is less efficient than
ISPA (cFos emulates a modem, and modems work with one character at a
time, while ISPA emulates a network card, and network cards work with
packets), but I'm not sure. The advantage of cFos over ISPA is that
cFos can be used for other communication programs too.
It is difficult to say how many users can be handled by a
machine
running IPRoute + ISPA. At one time I had 15 users hooked up in an
Ethernet, with 10 users connected to the Internet (at least, that's
what SHOW
ARP on the IPRoute console told me). At that time people started
to
complain about the speed. When people start complaining I ask them to
connect to the website of the service provider because when those
webpages load in quickly, the lack of speed was probably caused by the
Internet and not the ISDN line. I think 1 B-channel should be enough to
support about 5 moderately active users, who surf the web, sometimes
FTP stuff etc. The machine which is IPRoute + ISPA should not be the
bottleneck, because I asked Dave Mischler the following:
> - What's the minimum machine needed for routing from 5-10 machines > to an ISDN line?
I don't know. A 16 MHz 286 might be enough. A 33 MHz 386 is almost certainly enough (unless the card and driver combincation is very bad).
When I had the 15 users connected to the Ethernet, a couple of
machines running Windows95 could NOT ping the gateway machine
(192.168.0.1). But they did show up in IPRoute's ARP table.
ISPA's PPP implementation is used and not IPRoute's. As far as
IPRoute is concerned, it routes packets from one Ethernet driver (a
real
Ethernet, namely your LAN) to another (a fake Ethernet, namely the ISDN
card).
If you want to force IPRoute + ISPA to dial out (normally they
start up without making a connection), just PING a machine on
the Internet using the IPRoute console. But although ISDN connections
are set up very quickly (4 seconds or so), the ping times out before
the
connection is up. No worries, just repeat the PING command.
Security was not a concern to me so far, because my user group
only wants to make use of the Internet connection 2 times per months
for
about 8 hours in total. Besides, we're not running any servers. I have
not used any filters so I probably can't help you with that...
Most apps will work fine with IPRoute, without having to configure
proxies. However, the workstation machines will have to have private
("dummy") addresses (e.g. 192.168.0.x). The problem is that if an
application asks the machine it is running on what its IP address is,
it
gets the dummy address. When this address is sent to a remote side
(say, for Internet telephony), that machine gets confused because the
packets it sends may not get back to you because of the fake address.
Certain applications transfer IP addresses or port numbers as part of
their data. This requires special treatment for address translation
(packets must be examined and addresses changed on the fly). So, if an
apps doesn't work, this could be the problem.
Most of the applications and their settings mentioned on the Linux Masq Apps page will
work for IPRoute as well. You'll need to "translate" the ipfwadm/ipchains/iptables
lines into corresponding IPRoute NAT lines, of course.
If you switch over from WinGate to IPRoute, make sure that you turn
off the proxy settings in your apps.
Here's a list of TCP/IP applications which are known to work with
IPRoute or WinGate, or not, or I just don't know because I haven't
tried. More recent information on which apps are supported by WinGate
can be found on the WinGate homepage.
If you have any additions/updates to this list, please mail me!
Netscape/Internet Explorer (or any other Webbrowser):
Works with both. For WinGate you will have to specify WinGate as the
proxy server. If you use IPRoute no additional configuration is
required.
FTP clients: work with both. For WinGate you will have
to
specify the host in a complicated way, with the WinGate machine as a
proxy. If you use IPRoute no such hassle is required.
FTP servers (such as Trumpet, Penguin, NeoLogic FTPD
etc.): work with IPRoute but incoming ports 20 and 21 have to be
configured with NAT.
HTTP servers (such as GoServe and NCSA HTTPD): work with
IPRoute but incoming port 80 has to be configured with NAT.
Telnet: works with both. For WinGate you will have to
Telnet first to the WinGate machine, then you get a new Telnet prompt
from which you login to your actual destination. If you use IPRoute no
such hassle is required.
SSH client: you might need to specify -P to
force the client to use a "non-privileged" port. For scp, the SSH
secure
copy, the equivalent switch is -L.
News/mail clients (such as Free Agent, UltiMail/2,
Netscape Mail etc.): all these should work without problems.
Gopher clients: haven't tried / unknown, but should work
without problems since they are the predecessors of web clients.
IRC: Will probably work with IPRoute, but DCC send might
be problematic (haven't tried yet). IPRoute docs say that it has
support
for IDENTD. PMIRC (OS/2) works fine on one machine, haven't tried with
more machines on the same network. mIRC is also reported to work fine.
Haven't tried / unknown with WinGate.
PING: works with IPRoute. Doesn't work with WinGate.
SMB/CIFS/NBT ("Windows networking"): transfers IP
address
or port number in data. Makes it difficult for NAT. Unknown whether it
is supported by WinGate or IPRoute.
Traceroute (TRACERTE.EXE): at least the Windows
versions (which work differently than Unix and OS/2 versions) work with
IPRoute, though I noticed it may take a couple of seconds before it can
get through the IPRoute machine. I also often see some duplicate lines
with '192.168.0.1 * *' or so. Traceroute doesn't work with WinGate,
last
time I checked. Traceroute does work with NAT32, but if you use the
Linux traceroute you need to specify -I in order to use ICMP
ECHO instead of UDP datagrams.
VDOLive: haven't tried / unknown.
IPhone: I haven't
tried it myself with IPRoute but one user on my LAN got it to work.
He's
certainly not a 'power user' so I guess it was quite easy to do :-).
Status with WinGate: unknown.
InterCom
by ixWorld (OS/2). Audio (voice), video (QuickCam) and Talk (text) all
work with IPRoute. You can call somebody else, but if you want to be
called you must enter a NAT command in IPRoute for the port InterCom is
using (haven't determined which one). I route all incoming
connections to one machine which always works. Unknown with WinGate.
WinChat: works with IPRoute, but incoming port 2048 has
to be configured with NAT. Other chat programs such as iChat and
Microsoft Comic Chat: haven't tried / unknown.
Alphaworld (is this the same as Worlds Chat?): a guy at my users
group used it while IPRoute was running, so I guess it works. With
WinGate: haven't tried / unknown.
Shockwave: haven't tried / unknown.
VRML: haven't tried / unknown.
StreamWorks: haven't tried / unknown.
RealAudio: will
work with WinGate 2.0+. Reported to work fine with IPRoute too. Blair Hicks wrote to me that he
got Real Player V 4.01 to work by opening its Preferences, clicking on
Transport and then enable the "use specific UDP Port" checkbox. On the
IProute gateway he then added a TCP and UDP mapping, i.e. a NAT line,
to
the workstation running the RealAudio player. You should be able to get
more players running on multiple workstations by incrementing the port
numbers. For instance: port 7070 is mapped to and used by workstation
#1, port 7071 is mapped to and used by workstation #2 etc. RealAudio
5.0 confirmed to work in a similar way by Richard
Spooner.
Shockwave: haven't tried / unknown.
Talk: there seems to be no "standard" for talk so it may
depend. But: haven't tried / unknown.
CUSeeme: haven't tried / unknown.
CoolTalk: haven't tried / unknown.
Microsoft NetMeeting / H.323: transfers IP address or
port number in data. People have tried very, very hard to get this
working with any proxy server or NAT product on the market. Not even
Microsoft's own Proxy Server 2.0 will allow you to hook up multiple
NetMeeting users through one shared TCP/IP connection! With most
Internet sharing products, NetMeeting's whiteboard and the text based
conversation window will work fine, but audio and video will NOT work.Open H.323 can be used as a proxy.
Person-2-Person (whiteboard sharing application included
with OS/2 Warp BonusPak): it has been a couple of months back since I
tried but I think it works with IPRoute.
Kali (converter which
allows you to play IPX-based network games such as Duke3D, Quake and
Descent over the Internet): with IPRoute only tested Kali for OS/2 so
far. Seems to work but you will have to specify my_ip in
KALI.CFG with the real IP address that gateway machine gets from your
ISP. Kali does most of its communication on UDP ports 2213 and 6666 so
you will have to NAT these on the IPRoute machine to the machine you're
playing Kali on. Kali proxy (kproxy.exe, see Kali homepage) may be
useful.
Vxtreme: transfers IP address or port number in data.
Makes it difficult for NAT. Unknown whether it is supported by WinGate
or IPRoute.
Quake (running under DOS B&W TCP/IP stack or
Windows95
TCP/IP, not Kali) and other games over TCP/IP: haven't tried / unknown.
Set up a PPP connection with IPRoute to Unix account with SLiRP, a PPP emulator:
haven't tried / unknown.
I have a setup that I just put together for evaluation that seems to work pretty well for me, here is the recipe: - old 486/66 w/8MB & 130MB (overkill) ($0 personal surplus) - a TC200-S6 460K serial card ($29 from www.byterunner.com) - an NE2000 LAN card ($30 from datacomm warehouse) - a Zyxel 2864iu external TA ($?) - IPRoute router software ($50 from this site) This system does "dial on demand" and call dropping after a configuable amount of time for my 3 PC network. The Zyxel TA does utilization sensitive adding/dropping of the 2nd B channel. Total time to bring up the link (call establishment & ppp negotiation) is ~2.5 sec. FTP downloads run at 15200+ KBytes/sec. Ping times are about 40ms. I've only been running it for a few days but it already compares very favorably to my ~$1000 Ascend P75. The P75 connects in ~2.0 sec and is configuable over the LAN, but doesn't do NAT.
The advantages of special hardware over IPRoute + ISPA are:
They can do more protocols, such as IPX (ISPA should be able to
handle more protocols, but IPRoute, as the name implies, only does IP).
Some can do compression, e.g. using Stac or V.42bis or whatever.
Some can do Multi-link
PPP, BACP, or "bonding" of the two ISDN B-channels, i.e. on a
bit-level which is better for applications such as video and audio.
Some can be configured from a remote location (using Telnet,
SNMP, a terminal hooked up to a serial port etc.)
If you are running OS/2, there's also InJoy.
It is a replacement for the "Dial Other Internet Providers" program
supplied with Warp. InJoy supports
IP
Masquerading, at the moment for 4 users but more than 4 are also
possible (at a higher price). In combination with cFos (see paragraph above), you can also run InJoy over an
ISDN line. Click here
for information on that, including examples. InJoy also does Dial on
Demand.
The advantage of InJoy + cFos over IPRoute + ISPA is that you don't
need to sacrifice a dedicated machine. It is probably easier to
configure too. The disadvantage is that it is higher in price. Also
don't forget that the unregistered cFos doesn't support sync
PPP
over HDLC, which makes it impossible to test InJoy + cFos with most
Internet providers.
(This is all horribly old information. I'm keeping it here for old
time's sake :-)
First read the part on how to set up IPRoute + ISPA and use
the sample configuration files included there. Now, let's say your
login
ID is aladdin and your password is sesame.
And you're calling your ISP's Point Of Presence (inbelpunt) in
Amsterdam. (If you live in another part of the country, just click on
the name of the provider below, and you'll jump to that provider's list
op POPs). Change this according to your own account info and location.
I
assume you want autodial and automatic disconnect after 240 idle
seconds. Change ISP.BAT so that the correct settings for the Ethernet
card and the ISDN card (CAPI drivers) are used. You should then only
have to change one line in ISP.INI:
NLnet / UUNET: use
synchronous PPP over HDLC with PAP. NLnet also wants the login ID to be
specified in a rather strange way. Configure your workstation machines
to use the Domain Name Server (DNS) 193.67.237.6 0.0.0.0 0206638251 -p -naladdin@inter.nl.net,sesame -o -r -t 240
World
Access: use synchronous PPP over HDLC with PAP/CHAP?. In most
cases I could not reach servers running on my local network from the
outside (Internet), perhaps this inbound traffic is blocked because of
security reasons. Configure your workstation machines to use the Domain
Name Server (DNS) 145.220.1.7 0.0.0.0 0206933004 -c -p -naladdin,sesame -o -r -t 240
XS4ALL:
use synchronous PPP over HDLC with PAP. Seems to support B-channel bundling so you get 128Kbps? Configure your
workstation machines to use the Domain Name Server (DNS) 194.109.6.66 0.0.0.0 0204229700 -p -naladdin,sesame -o -r -t 240
Euronet:
use synchronous PPP over HDLC with PAP. Configure your workstation
machines to use the Domain Name Server (DNS) 194.134.5.5 0.0.0.0 0204274330 -p -naladdin,sesame -o -r -t 240
Added reference to a NetMeeting proxy called Phonepatch.
Mentioned that the last couple of ISPA versions now support Multi-link
PPP. 2-apr-1999.
Added reference to a new Small Business suite
by IBM which contains a modem pool server and clients (i.e. serial
port sharing). 1-nov-1998.
Here's the IPRoute script I am using
with modems. Updated 22-aug-1997. Some modems handle carrier detect
differently. Needs investigation. This script might work with ISDN
modems as well but then you need to add AT init strings. E.g. for some
ISDN model (Elsa?) you need to use AT&FB40 for initialisation and
ATDI (instead of ATDT) for the dial command. Jae Kim uses these settings
for his Motorola Bitsurfr Pro at 128 Kbps:
send "AT&F1&C1&D2@B0=2\r" ; for initialisation send "ATDxxxxxxx&yyyyyyy\r" ; for dialing out (2 B-channels, ; 2 phone numbers xxxxxxx and yyyyyy)
Author and credits
Most of the information in this document comes from discussions with
Dave Mischler and Herbert Hanewinkel. Some parts on routing and proxy
servers were shamelessly stolen from the FireDoor FAQ.
I would like to thank Herbert Hanewinkel for generously providing me
an ISPA registration key when the CIPA key turned out to be almost
useless because of a buggy driver. In return, this
document was written...
