PPP Networking

Basics

The /iss/etc/init.d/asppp module starts, stops, and configures PPP networking. On startup, the network script calls the asppp script if the ppp networking option has been enabled (see Choosing the Networking Option). The ISS asppp script runs the system ppp startup script, /etc/init.d/asppp start, which starts the aspppd daemon on all the interfaces specified in /etc/asppp.cf. The /etc/asppp.cf is generated by the ISS asppp script during PPP configuration.

For example, this is the aspppd configuration for ISP connections:

# Automatically generated asppp.cf
# To change, run /iss/etc/init.d/asppp config

ifconfig ipdptp0 plumb isp-local isp up netmask 255.255.255.0
path
	interface ipdptp0
	inactivity_timeout 120
	peer_system_name isp
	default_route
	negotiate_address on
	debug_level 1
	

The ifconfig line assigns dummy IP addresses for the local and remote ends of the link, plumbs the interface, and sets a netmask. The dummy endpoint addresses are added to the routing table when the ipdptp0 interface is configured:

83 iss1:/iss/doc/html> netstat -r
Routing Table:
  Destination           Gateway           Flags  Ref   Use   Interface
-------------------- -------------------- ----- ----- ------ ---------
1.1.1.2              1.1.1.1               UH       3      0  ipdptp0

The /iss/etc/init.d/asppp script then adds a route for atd through the interface attached to 1.1.1.2:

/usr/sbin/route -q -f add -host atd 1.1.1.2 0 -static

The 0 metric argument to route (equivalent to -interface) effectively, if a little indirectly, sets up a static route to the destination host atd through the ppp interface. So the relevant parts of the routing table look like this while aspppd is running:

  Destination           Gateway           Flags  Ref   Use   Interface
-------------------- -------------------- ----- ----- ------ ---------
1.1.1.2              1.1.1.1               UH       3      0  ipdptp0
atd                  1.1.1.1               UH       3      0  ipdptp0

Note

Note that this static route is necessary because the ATD exposed host resides on the 128.117.80 subnet, the same subnet as the ISS and field computers. Without the static route all traffic to the host atd would be routed to the local ethernet instead of through the ppp link.

Note

Without the dummy remote IP address for the ipdptp0 interface, I was unable to set up a static route for atd which would work both before and after a ppp connection had been established. Adding routes from atd to 1.1.1.1 (i.e., the local endpoint of the ppp interface) did not work. A previous approach of explicitly specifying a non-.80 gateway host as the remote ppp endpoint is similar to this approach, in that a static route was added from atd to the gateway host (named isp) which effectively directed atd traffic across the ppp interface. However, the determination of the gateway host was problematic, and explicitly setting the endpoint of a dynamic ppp link was at best inaccurate. In this configuration approach, 1.1.1.2 is a placeholder for the remote gateway, which allows for the addition of a static route to atd through the ppp interface, and aspppd sets the endpoint IP address when the ppp link comes up and adjusts the routing table accordingly, and automatically.

The key here seems to be that the atd route flags are UH and not UGH: the route has metric 0 through the ipdptp0 interface, which when the ppp link is up will be the router at the end of the link. This also means that pinging atd will bring up the link. If the flags are UGH, pings to atd result in ICMP network unreachable errors because the 1.1.1.1 gateway has no route in the table (or so I surmise). Once aspppd brings the link up, dynamically assigns the real IP addresses at either end of the link, and then adds the default route (default_route option in asppp.cf interface listing above), the routing table reflects the real IP addresses with which the dummy 1.1.1.1 and 1.1.1.2 endpoints were replaced. Anyway, it works, and the routing table looks something like this while the ppp connection is up:

Routing Table:
  Destination           Gateway           Flags  Ref   Use   Interface
-------------------- -------------------- ----- ----- ------ ---------
atd                  4.19.162.213          UH       4      1  ipdptp0
4.19.162.8           4.19.162.213          UH       4      0  ipdptp0
128.117.80.0         iss1                  U        3     76  le0
224.0.0.0            iss1                  U        3      0  le0
default              4.19.162.8            UG       0      0  
localhost            localhost             UH       0    574  lo0

Following is the ppp interface configuration reported by ifconfig while the ppp link is up:

ipdptp0: flags=8d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
        inet 4.19.162.213 --> 4.19.162.8 netmask ffffff00 
        ether 0:0:0:0:0:0 

The peer system name for the interface configuration in /etc/asppp.cf (see asppp.cf interface listing) is set to the generic name isp, which refers to the entry in the /etc/uucp/Systems file created by the asppp script when it configures an ISP connection.

Since both ends of the ppp interface are now configured with dummy IP addresses, there is no longer a need for a special isp entry in the /iss/etc/hosts file, and likewise no longer a need to edit /iss/etc/asppp.cf.

In past ISS distributions, data transfers would also run the pppreset script to reset the PPP network interface. This is no longer the responsibility of data transfers so that data transfer can be more independent of the particular networking setup. Instead, the /iss/etc/init.d/asppp script would register a crontab entry to reset the PPP daemon daily, but only if a PPP connection has been configured and enabled.

#   iss-asppp: periodic ppp reset installed `date`
0 6 * * * $initdir/asppp reset iss-asppp

Now even the reset has been abandoned since it seems stopping and starting the ppp daemon occasionally hangs the serial port, to the point of requiring a system reboot.

ISP Setup

The mechanics of configuring PPP with an ISP are built into the interactive configuration provided by the asppp module, as explained in the chapter on Configuration. This section documents how the configuration works behind the scenes.

The only difference between ISP configurations should be the phone number of the ISP, and the username and password for the PPP account. Each of these three pieces of information are put in the /etc/uucp/Systems file when asppp creates it. There should be single entry in the Systems file for a system named isp, similar to the following:

# Generated automatically by: /iss/etc/init.d/asppp config
#
isp Any Sportster 38400 ppp_phone "" P_ZERO ogin:--ser:--name: ppp_user  word: ppp_word 

All of the lines which begin with a # character are comments, so they are ignored. The actual system configuration line is the line which begins with isp. On this line, the ppp_phone, ppp_user, and ppp_word will be replaced with the actual phone number, username, and password for the ISP.

The cryptic field ogin:--ser:--name: indicates patterns of login prompts to expect from the ppp server. Any prompt ending in ogin:, ser:, or name: will trigger the transmission of the username (Pucar123 in this example). This should allow most ppp server login prompts to be recognized.

Login as the root user, either with su - or from the console, and edit the file /iss/etc/uucp/Systems. Change the phone number, username, and password fields for the isp system as noted above, and save the file.

The following sequence of commands should bring up the ppp connection and start a login to the atd host. Note that it should be run as user iss, and the ppp networking option needs to have been enabled in the system configuration. (See Choosing the Networking Option.) If there are the problems, the following section, PPP Troubleshooting, might help.

iss1> pppreset
add host atd: gateway 1.1.1.2
iss1> ping atd 300
atd.ucar.edu is alive
iss1> ssh atd