| The final layer is PPP. This is the part that runs IP over the serial line, establishing the network connection across it. When this has been created it will have all the standard network parameters, such as an IP address at each end, a netmask, and so on. Once it is up and running we can view its statistics using ifconfig and netmask just as we would any other network. Again, we need to check that we have the correct packages installed before we can do anything. Running pkginfo should show us something similar to that shown below: cesium# pkginfo | grep -i ppp system SUNWapppr PPP/IP Asynchronous PPP daemon configuration files system SUNWapppu PPP/IP Asynchronous PPP daemon and PPP login service system SUNWpppk PPP/IP and IPdialup Device Drivers cesium# Which Configuration? PPP can be set up in a number of different configurations, depending on the type of connection that is required. These connections are known as "point-to-point" and "multipoint" and will use one of two device drivers to establish links. For point-to-point links the driver is ipdptp, whereas for multipoint links it is the ipd driver. Point-to-point links have a machine at either end of the connection (for example, a dial-out system connecting into an ISP), whereas multipoint links use one machine that acts as an end point for a number of different systems (for example, as a dial-in system that provides users with a method of accessing the machines). Here, we will use PPP to dial out of our system and into the ISP, so it will be configured in dial-out mode and therefore use the ipdptp driver. Link Manager A powerful feature that PPP provides is automatic connection and disconnection of the link. When you need to connect to the remote system, a program known as the "link manager" will detect whether traffic is being directed there and will establish the connection. After the link has been inactive for a predetermined amount of time, the connection will be dropped. This is very useful and ensures that both costly communications links and possible security breaches are kept to a minimumalthough some users prefer to be able to control when the link is made or torn down. We'll show how this can be accomplished a little later when we have everything working correctly. The link manager is named /usr/sbin/aspppd and is started at boot-time by the /etc/init.d/asppp start-up script. When aspppd starts, it reads a configuration file named /etc/asppp.cf. Let's have a look at ours now to see what it contains before we start everything: cesium# cat /etc/asppp.cf ifconfig ipdptp0 plumb local-ppp remote-ppp up path interface ipdptp0 peer_system_name theISP negotiate_address on inactivity_timeout 300 default_route debug_level 9 cesium# Again, we'll take each line one at a time and determine what each one does. We've already seen in Chapter 11, "Connecting to the Local Area Network," how to use ifconfig to plumb the interface in. This command performs a similar task using the PPP point-to-point driver, which is ipdptp0 in this case. On a point-to-point link, we would expect to provide two addresses to PPP: one for the local end and another for the remote end. Often they may not be known in advance, such as when the ISP uses dynamic addressing for its customers (most do, nowadays!). To get around this, we can add the keyword "negotiate_address" to the configuration file and also provide dummy addresses to the ifconfig commandwe've used the host names local-ppp and remote-ppp for this in our configuration file above. When the connection is made, PPP will negotiate with the remote system to obtain the correct addresses, which will be exchanged for the dummy ones previously specified (we'll see this when we check the connection later). We could just use IP addresses rather than host names in /etc/asppp.cf, if we prefer. However, we've used this standard across the rest of the machines, and it allows us to quickly scan the hosts file and see what has been allocated, rather than have IP addresses hidden away in files. Let's update the hosts file now to add the dummy addresses to it. The entries we'll use are shown below: cesium# cat /etc/inet/hosts <lines removed for clarity> # # Dialout PPP system dummy addresses # Uses dynamic local address # 1.1.1.1 local-ppp 9.9.9.9 remote-ppp <lines removed for clarity> cesium# The "path" keyword simply marks the start of a definition, which continues to the next "path" or "defaults" statement. Multiple path entries can be used to define multiple PPP connections (for example, to different ISPs). As we explained earlier, "negotiate_address" indicates that we are using dynamic addresses, which PPP needs to exchange when the network is configured. The keyword "peer_system_name" is where PPP ties into UUCP. It will pass the system name onto UUCP and let it establish the dialup link for us. The name should exactly match the entry we defined earlier in the Systems file. The default timeout for PPP is set to 120 seconds. We will increase this to 300 seconds using the keyword "inactivity_timeout." When the connection is made, we need to use this route as our default; "default_route" will add this entry into the routing table for us. Lastly, "debug_level" allows us to control the amount of debug information that will be loggedwe've set the highest value for now so we can check that everything works. We can also do this from the aspppd command line if we wish, but we've included it here so we don't have to alter the standard start-up script. Log Files PPP writes to a log file named /var/adm/log/asppp.log. It's worth noting that this file can grow quite rapidly, especially at the higher levels of debug. It isn't automatically cleaned out by the system, either. How often you use PPP and the level of debug you have set will determine how fast this file grows and how often you will need to preen it. While we're looking at the log file, let's run PPP and check to confirm that it starts OK: cesium# /etc/init.d/aspppd start cesium# tail f /var/adm/log/asppp.log 16:51:01 Link manager (264) started 03/25/01 16:51:01 parse_config_file: Successful configuration cesium# At this point, the link manager has started, read the configuration file, and checked the syntax, and is now ready to establish the connection should we need it. If we take a look at ifconfig, we can see that aspppd has already plumbed the interface in, although it still has the dummy addresses in place since we have not yet connected in to get our dynamic ones: cesium# ifconfig ipdptp0 ipdptp0: flags=8d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500 inet 1.1.1.1 --> 9.9.9.9 netmask ff000000 ether 0:0:0:0:0:0 cesium# Testing the Link Now we are ready to test the link to make sure everything is working. As we said earlier, the link manager is monitoring the connection, so we only need to direct traffic to the remote systemsomething simple like a ping will do this for us. The link manager "knows" that it needs to connect to "theISP" using the modem connected on /dev/cua/b. OK, let's ping the remote system and see what happens. We've already increased the debug level, so we can determine what is happening by tailing the log file while we're testing everything. We'll use a high time-out for ping so that it doesn't exit before the connection has had time to establish: cesium# ping remote-ppp 300 <lines removed for clarity> While the ping is working, we can monitor PPP's progress by checking the log file. We won't reproduce the whole of it here, but you will see the various stages that are being passed through, as we saw before when we checked the connection with cu. For example, we'll see UUCP opening the relevant files and executing the chat script. When the login is successful, we'll then see PPP starting to run over both ends of the link: cesium# tail f /var/adm/log/asppp.log 16:51:44 process_ipd_msg: ipdptp0 needs connection conn(theISP) Trying entry from '/etc/uucp/Systems' - device type ACU. Device Type ACU wanted Trying device entry 'cua/b' from '/etc/uucp/Devices'. processdev: calling setdevcfg(ppp, ACU) cesium# Now the connection has been made, so we should have a network between the two systems, which ifconfig will confirm. The dummy IP addresses have also been replaced with the correct ones: cesium# ifconfig ipdptp0 ipdptp0: flags=8d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500 inet 195.2.137.61 --> 194.88.88.72 netmask ff000000 ether 0:0:0:0:0:0 cesium# Checking netstat will also show that the default route has being correctly added because we included the "default_route" keyword in the configuration file: cesium# netstat rn Routing Table: Destination Gateway Flags Ref Use Interface --------------- ----------------- ----- ----- ------ ---------- 194.88.88.72 195.2.137.61 UH 4 1 ipdptp0 224.0.0.0 127.0.0.1 U 0 0 lo0 default 194.88.88.72 UG 0 1 127.0.0.1 127.0.0.1 UH 0 67 lo0 cesium# The only odd thing is that ping will timeout after 300 seconds and return an error that shows it cannot see the system "remote-ppp." The reason for this is that we initiate the connection by pinging the dummy IP address. This is enough to direct traffic to the dialup interface and start the whole process off, but when the connection is actually made the IP addresses are replaced, which means the dummy machine will never be seen. This isn't a problem since we're only using ping to initiate the process and we aren't really interested in it after that. | 
