Subject: Using PPP for a serial-only server.
To: None <current-users@NetBSD.ORG>
From: Dave Burgess <burgess@cynjut.neonramp.com>
List: current-users
Date: 12/31/1996 17:51:17
I have just finished (with the spark of understanding provided by Peter
Seebach, most recently) getting my PPP server box to work correctly.
Here is the summary of the problems and solutions:
For those of you joining in late in the game, here is the summary of
what I wanted to do:
For several reasons, we wanted to have a system set up where people
could call in and get routed to the Internet. The system itself lives
on a dial-up line as well. This turned out to be the hard part.
Static Routes - There is a static default route from the server to the
router and on to the Internet. This works; we can telnet to the machine
without a problem. Our Cisco is set up so that all of the traffic
destined for the machines hanging off the server gets routed through the
ppp0 connection.
Serial Ports - These all seem to work. I can dial in and connect using
/bin/tcsh as my primary shell. Customers have a shell script as their
primary shell. Each of the serial ports in the machine is
assigned an IP address through the use the shell script I wrote which
interrogates the current tty and assigns the address that way. As soon
as I get the pppd in the server upgraded, I'll switch to the tty.xx
option files. The shell script works; it assignes the client address
to the client machine correctly.
Data routing - Here is the spooky part. I can watch the client try and
log in. The logging in goes OK, the pppd starts up, and then nothing
happens. The ppp1 seems like it can't send data to ppp0 (which is the
connection to the rest of the Internet). There is an address example
below. [This turned out to be where the problem lay; see below for the
fix.]
pppd - This sets up the client correctly, and apparently works to set up
the server. When I use NetBSD to log in, my ppp0 interface gets set to
the "client side" address (x.18, for example). Folks using Windows have
to log in manually (for now) to get onto the server.
Here is that example:
x.x.21.17 (Jumpserver)
+----------------------------------------------------------------+
| [tty00] |
| |
| |
| [tty01] [tty02] [tty03] [tty04] etc. |
+----------------------------------------------------------------+
| | | |
| | | |
| | | |
v v v v
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+ etc.
/ \/ \/ \/ \
+---------++---------++---------++---------+
21.18 21.19 21.20 21.21
The defaultroute option in the /etc/ppp/options file is disabled: All
of the routes are added in the netstart.
The summary of the solution:
When I set everything up, I used the netmask 255.255.255.240 for the
server ppp link. This way (I thought) all traffic that was supposed
to stay on the server did. This was the first mistake. I did know
enough to change it from 255.255.255.0.
To get the system to work, all I've needed to do (since September 1st)
was change the ppp* netmasks. Since only the most recent versions of
pppd allow the netmask to be set in the options file, it needed to be
done using the ifconfig command before pppd was started. ALL of the
ppp ports (including the one that goes back to the Internet router)
must have their netmask set to 255.255.255.255. Once that is done,
the route established by the pppd instantiation is enough to get the
traffic to the right port.
Now for the question:
Should a ppp link ever have a netmask that ISN'T 255.255.255.255? My
guess would be 'yes, but only if you are using an ifconfig alias for
that port'.
--
Dave Burgess (The man of a thousand E-Mail addresses)
*bsd FAQ Maintainer / SysAdmin for the NetBSD system in my spare bedroom
"Just because something is stupid doesn't mean there isn't someone that
doesn't want to do it...."