Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Apr 1996 14:46:31 +0100 (BST)
From:      Nik Clayton <nik@blueberry.co.uk>
To:        questions@freebsd.org
Subject:   Server PPP: Opinions before handbook submission
Message-ID:  <199604261346.OAA01205@plum.blueberry.co.uk>

next in thread | raw e-mail | index | archive | help
Hi,

After my previous message, and thanks to some enlightenment from Nate 
Williams, I now have server ppp working quite nicely.

As promised, I've written it up for the handbook. I'd appreciate anyone
who's knowledgable in these areas to take a quick look over the included
text in case I've made any glaring errors. 

Also, if anyone's about to try and setup server ppp, perhaps they could
look through this and suggest improvements about anything that's not clear?

I'll give it until Wednesday next week, then submit it to doc.

N

Configuring FreeBSD to act as a PPP server.

By Nik Clayton (nik@blueberry.co.uk), based on additional information supplied
by Nate Williams (nate@sri.mt.net)

The Theory

    Consider two machines, 'A' and 'B'. 'A' is the server. It has it's own
    connection to the Internet (or an intranet), runs FreeBSD, and has at
    least one modem attached. 'B' is the client, running some form of PPP
    client software.

    'B' will dial into 'A'. At which point it is presented with some form of
    login and password prompt. After succesfully authenticating 'B', the ppp
    server is started on 'A'. A route is added on 'A' to allow packets to flow
    from 'A' to 'B' and back again and (optionally) 'A' proxies ARP (address
    resolution protocol) requests for 'B' so that 'B' can get off the local
    network and on to the wider Internet.

The Implementation

    1. Configure 'A' to allow dial-up access. See section 10.4 in this
       handbook for information on how to do this. You must be able to
       successfully dial in to 'A', type in the username and password of
       someone on the system and be allowed in before you can proceed any
       further.

       Don't forget to configure the modem to autoanswer.

    2. Include the 'ppp' device on A.

       While it is possible to use the 'user-mode' PPP program (iijppp) to act
       as a server, received wisdom does not recommend this, particularly if
       'A' will be spending a large portion of it's time as a server. This
       document does not address using 'iijppp' as the server.

       pppd requires a kernel interface, 'ppp0' to work. At the very least,
       add the line

           pseudo-device  ppp	  1

       to your kernel config file (something similar to this, but commented
       out, may already be there). This will create one ppp interface (called
       ppp0) if you plan on allowing more than one connection then replace '1'
       with the number of active connections you want.

       Rebuild and re-install the kernel. Section 5 has more information on
       the steps necessary. Note that on rebooting the pppn devices are not
       shown at boot time. To confirm the device has been installed, login,
       and as root type

           ifconfig ppp0

       which should return text similar to

           ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500

    3. Configure the pppd software.

       The interface is only half the story. The PPP daemon 'pppd' must be run
       on each succesfull connection to provide PPP services.

       pppd's configuration file is /etc/ppp/options. Create this file if it
       doesn't already exist. It should look like this:

           proxyarp
           crtscts
           w.x.y.z:
           auth
           +pap
	   login
           modem
           netmask 255.255.255.0
           domain foo.bar
           passive

       You can alter some of these options depending on your local
       requirements. In order, these options mean:

       proxyarp - pppd will add an entry in the system ARP table for the host
       that has connected (B). This is essential to allow traffic from 'B' to
       get off the local network.

       crtscts - Use hardware flow control

       w.x.y.z: - replace this with the IP address of 'A'

       auth - 'B' *must* authenticate itself before network packets will be
       sent or received.

       +pap - 'B' *must* use PAP (Password Authentication Protocol) to do the
       authentication. This is a fairly common method of authentication. You
       can also +chap, to use CHAP authentication. Or you can turn these
       options off. 'man pppd' has more information.

       login - Use the passwd file as the 'secrets' file for PAP or CHAP
       authentication. This allows users to authenticate themselves using
       their existing user IDs and passwords. If you do not do this then you
       can create a file (called a 'secrets' file) which contains equivalent
       information. Again, 'man pppd' goes into more detail on this topic.

       modem - Use the modem control lines. I'm unsure of the effect this has,
       but it doesn't seem to hurt. Perhaps someone could provide more
       information for this.

       netmask 255.255.255.0 - This is the netmask for the connection. Use
       whatever netmask you already use for the local network.

       domain foo.bar - Replace 'foo.bar' with your domain name

       passive - pppd will try and initiate the conversation with 'B'. If no
       reply is received then pppd will wait, rather than immediately
       quitting. This useful for noisy lines, or where 'B' is slow in
       responding.

    4. Test the above

       Pick a modem line on which you are not running a getty. If you don't
       have any free then turn off one of the gettys in /etc/ttys, send a HUP
       signal to init to do so.

       Assume this is the first modem line on the system. Then run

           pppd speed /dev/ttyd0 -detach

       replace 'speed' in the above with the port speed you use. Use whatever
       speed you have in the getty line in /etc/ttys. For example, if you
       normally start a getty on /dev/ttyd0 with the std.115200 profile then
       run

           pppd 115200 /dev/ttyd0 -detach

       This will run pppd, and it won't detach from the terminal. This is
       good.
       
       Now configure your client software on 'B'. Things to watch for with
       this configuration involve how much information the client program is
       expecting to receive.

       Specifically, the client should be configured with it's own IP
       address. It should not rely on the server to send it down. The client
       should be told 'A's IP address (w.x.y.z in the config file above).
           
       'B' should now attempt to dial into 'A'. When the line is answered pppd
       should notice this. If you are watching this on 'B' you'll see data
       that looks like random garbage (with lots of '}' characters in it)
       coming down the line. This is 'A' asking 'B' to authenticate itself.

       The software on 'B' will probably prompt for a username and password
       pair. Recall that we are using PAP to authenticate the connection, and
       that the /etc/passwd file is being used, so you must enter the username
       and password of someone on your system.

       If it is accepted then the PPP connection should come fully up. You
       should be able to telnet from 'B' to 'A'. In fact, you should be able
       to do anything on 'B' that you could do on 'A'. If you could telnet to
       other hosts on your network from 'A' then try doing that from 'B'. If
       you could browse the Web from 'A' then get some browser software onto
       'B' and try that as well. This should all work.

       If it's working correctly, then hang up the line from 'B'.

       You should notice back on 'A' that pppd has returned to the shell
       prompt. pppd exits once the connection is finished. This is normal.

    5. Final configuration

       All that remains now is to setup things up so that pppd runs on
       connection, and is restarted when a connection is dropped.

       To do this, you need to create a ppp user. The username is unimportant,
       but the shell is very important.

       Edit the password file on 'A', and create a line something like this:

           ppp::1020:1000::0:0:PPP login:/etc/ppp:/etc/ppp/ppp-login

       Obviously set the UID and GID to whatever is appropriate on your
       system. Also, give it a password if that's what you want.

       Notice that this accounts home directory is set to /etc/ppp
       (which doesn't really matter, the home directory is never used) and the
       login shell for this account is /etc/ppp/ppp-login.

       You need to create this program. Create the file /etc/ppp/ppp-login,
       and place the following commands into it

           #!/bin/sh
	   #
	   # PPP login script

	   PATH=:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin
	   export PATH

	   mesg n
	   stty -tostop
	   exec pppd 115200 debug

       Don't forget to make this shell script executable.

       Essentially, whenever anyone logs in with the 'ppp' username, messaging
       is turned off, SIGTTOU is turned off for background output (see
       stty(1)) and then the pppd program is executed over the top of it. We
       specify the speed of the connection (make sure this matches the other
       speeds you've set earlier on) and debugging is turned on, allowing
       connection information to be logged.

       Don't forget to turn the getty on /dev/ttyd? back on (if you turned it
       off for testing earlier).

    6. Final configuration and testing

       Go back to 'B'. Edit the client software configuration so that on
       connection it waits for the string 'ogin:', and sends the string
       'ppp'. It should then wait for the string 'assword:', and send back
       whatever password you set for the 'ppp' account.

       Make the connection to 'A'. If all goes well then the client software
       will dial up 'A'. The 'getty' running on 'A' will then send the
       'login:' and 'Password:' prompts. In response to these the client will
       then send the username 'ppp' and the password you've set.

       If this validates then /etc/ppp/ppp-login will then be run. This runs
       the pppd daemon, completing the connection.

       Congratulations, you should now have a working PPP connection.

       When 'B' drops the connection, pppd on 'A' will die. 'init' will notice
       this, and another getty will be spawned to watch for incoming
       connections. At which point another client can log in.

       And so on.

Common problems

    I get "pppd [pid]: ioctl(TIOCSCTTY): Operation not permitted" errors when
    pppd starts up.

      pppd and getty have different ideas about the options on the
      communications port, probably the speed is different. Double check that
      the speed assigned to the port is the same in /etc/rc.serial, /etc/ttys
      and /etc/ppp/ppp-login.

    When testing pppd (without getty, i.e., step 4 above) I can connect OK,
    but pppd just sends down repeated '`' (backtick) characters.

      Again, a speed problem. Double check that they match.
	 
Things you might want to experiment with

    The setup outlined above assumes that you have IP addresses permanently
    assigned to machines. It's possible to have pppd assign IP addresses on
    demand. Or you might want an IP address to be assigned depending on which
    user authenticates themself. All sorts of clever bits and pieces can be
    done.

    Unfortunately, I don't know how, since it's fairly simple environment in
    which I use pppd. However, if you've got some examples that you want to
    share then send them on and I'll include (with appropriate credit of
    course).
-- 
--+=[ Blueberry Hill                   Blueberry Design                   ]=+--
--+=[ http://www.blueberry.co.uk/      1/9 Chelsea Harbour Design Centre, ]=+--
--+=[ WebMaster@blueberry.co.uk        London, England, SW10 0XE          ]=+--
--+=[       Don't anthropomorphize computers.  They don't like it.        ]ENTP



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604261346.OAA01205>