Configuring PPP
Who throws the first stone?
The first step in negotiation is to decide which side starts. One of them starts the negotiation, and the other one responds. If you configure your end incorrectly, one of these things can happen:
- You both wait for the other end to start. Nothing happens. After a while, one of you times out and drops the connection.
- You both fire away and place your demands, and listen for the other one to reply. The software should recognize that the other end is talking, too, and recover, but often enough both ends give up and drop the connection.
- One side initiates negotiations before the other, and things work normally despite the misconfiguration. This is the most difficult kind to recognize: sometimes the connection will work, and sometimes it won't, apparently dependent on the phase of the moon.
In general, systems with login authentication also initiate the negotiation. ISPs with PAP or CHAP authentication tend to expect the end user to start first, because that’s the way Microsoft does it. It’s easier for debugging to assume that the other end will start. If it doesn't, and you have an external modem, you'll notice that there is no traffic on the line, and that the line has dropped. Then you can switch to active mode negotiation.
It makes more sense for the called system to start the negotiation: the calling system is ready to use the link immediately, but the called system often takes a certain amount of time execute its PPP server program. A common cause of problems is when the server machine is busy and it takes a while to invoke the PPP process. In this case the caller sends its initial configuration data and the called system's tty device may echo it back, resulting in a lot of confusion at the caller’s end. User PPP can typically survive about three reflections of this type before getting too confused to recover.
Typical features that require negotiation are:
-
What kind of authentication? Login authentication doesn’t count here, because it's not part of PPP. You may choose to offer CHAP or PAP negotiation. You may also require the other end to authenticate itself. You can accept both CHAP and PAP authentication—that way, you can accept whichever the other end asks for. If the other end is an ISP, you will probably not be able to authenticate him, but you should check with the ISP.
A common configuration problem is when a user enables some form of authentication without first agreeing this with the ISP. For example, very few ISPs perform authentication from their end (to prove to you that they're really the ISP you dialed). You can specify this type of authentication in your configuration file, but if the ISP refuses to authenticate, you will never establish a connection.
- LQR, Link Quality Requests, give you an over view of your line quality, if your modem doesn’t use error correction. If it does use error correction, it will hide any LQR problems. Occasionally LQR packets can confuse a PPP implementation, so don't enable it if you don’t intend to use it.
-
Data and header compression. You have a choice here: modern modems offer various kinds of data compression, and so do the PPP implementations. As we saw on page 331, modem compression increases the data throughput, but also increases the latency. If your ISP supports the same kind of data compression as your PPP software, you might find that it improves matters to disable modem data compression. Both implementations support Van Jacobson, deflate and Predictor 1 compression, and kernel PPP also supports BSD compression.
Which do you choose? Van Jacobson compression works at the TCP level. It compresses only the headers (see page 280 for more details), and the other compression schemes work at the frame level. You can always enable Van Jacobson compression. As far as the others are concerned, use what ever the other side offers. In case of doubt, enable all available compression types and allow PPP to negotiate the best combination.
Compression negotiation is handled by the Compression Control Protocol, usually known as CCP. It uses its own protocol number so that it can be distinguished from other protocols that the remote system might offer, such as IP, X.25, SNA and IPX.
- IP addresses. In many cases, the server machine allocates a dynamic IP address. We’ll look at the implications below.
- Proxy ARP. Some systems can’t understand being at the other end of a PPP link. You can fool them by telling the router to respond to ARP requests for machines at the other end of the link. You don’t need this subterfuge in FreeBSD.
Authentication
Nearly every PPP link requires some kind of identification to confirm that you are authorized to use the link. On UNIX systems, the authentication traditionally consisted of the UNIX login procedure, which also allows you to dialup either to a shell or to a PPP session, depending on what user ID you use. Login authentication is normally performed by the dial-up chat script.
Microsoft has changed many things in this area. Their platforms don’t normally support daemons, and in some cases not even multiple users, so the UNIX login method is difficult to implement. Instead, you connect directly to a PPP server and perform authentication directly with it. There are two different authentication methods currently available, PAP (Password Authentication Protocol)and CHAP (Challenge Handshake Authentication Protocol). Both perform similar functions. From the PPP point of view, you just need to know which one you are using. Your ISP should tell you this information, but a surprising number don’t seem to know. In case of doubt, accept either of them.
Just to confuse matters, Microsoft has implemented authentication protocols of its own, such as MS Lan MAN, MS CHAP Version 1 (also known as CHAP type 0x80)and MS CHAP Version 2, also known as CHAP type 0x81. User PPP supports both kinds.
If you're using PAP or CHAP, you need to specify a system name and an authentication key. These terms may sound complicated, but they're really just a fancy name for a user name and a password. We'll look at how to specify these values when we look at the individual software.
How do you decide whether you use PAP or CHAP? You don’t need to—accept both and let the other end decide which kind to use.
Which IP addresses on the link?
After passing authentication, you may need to negotiate the addresses on the link. At first sight, you’d think that the IP addresses on the link would be very important. In fact, you can often almost completely ignore them. To understand this, we need to consider what the purpose of the IP addresses is.
An IP address is an address placed in the source or the destination field in an IP packet to enable the software to route it to its destination. As we saw in "Chapter 17" , Configuring the local network it is not necessarily the address of the interface to which the packet is sent. If your packet goes through 15 nodes on the way through the Internet, quite a normal number, it will be sent to 14 nodes whose address is not specified in the packet.
The first node is the router at the other end of the PPP link. This is a point-to-point link, so it receives all packets that are sent down the line, so you don’t need to do anything special to ensure it gets them. This is in marked contrast to a router on a broadcast medium like an Ethernet: on an Ethernet you must specify the IP address of the router for it to receive the packets.
In either case, except for testing, it’s very unlikely that you will ever want to address a packet directly to the router, and it’s equally unlikely that the router would know what to do with most kinds of packets if they are addressed to itself. So we don’t really need to care about the address.
What if we set up the wrong address for the other end of the link? Look at the router gw.example.com in the reference network on page 294. Its PPP link has the local address 139.130.136.133, and the other end has the address 139.130.136.129. What happens if we get the address mixed up and specify the other end as 139.130.129.136? Consider the commands we might enter if we were configuring the interface manually (compare with page 300):
if config tunO 139.130.136.133 139.130.129.136 net mask 255.255.255.255 route add default 139.130.129.133
You need to specify the net mask, because otherwise ifconfig chooses one based on the network address. In this case, it’s class B address, so it would choose 255.255.0.0. This tells the system that the other end of the link is 139.130.129.136, which is incorrect. It then tells the system to route all packets that can't be routed elsewhere to this address (the default route). When such a packet arrives, the system checks the routing table, and find that 139.130.129.136 can be reached by sending the packet out from interface ton0. Its ends the packet down the line.
At this point any memory of the address 139.130.129.136 (or, for that matter, 139.130.136.129) is gone. The packet arrives at the other end, and the router examines it. It still contains only the original destination address, and the router routes it accordingly. In other words, the router never fi nds out that the packet has been sent to the incorrect " other end" address, and things work just fine.
What happens in the other direction? That depends on your configuration. For any packet to get to your system from the Internet, the routing throughout the Internet must point to your system. Now how many lP addresses do you have? If it's only a single IP address (the address of your end of the PPP link), it must be correct. Consider what would happen if you accidentally swapped the last two octets of your local IP address:
# if config tun0 139.130.133.136 139.130.129.136
If gw sends out a packet with this source address, it does not prevent it from getting to its destination, because the source address does not play any part in the routing. But when the destination system replies, it sends it to the address specified in the source field, so it will not get back.
So how can this still work? Remember that routers don’t change the addresses in the packets they pass. If system bumble sends out a packet, it has the address 223.147.37.3. It passes through the incorrectly configured system gw unchanged, so the reply packet gets back to its source with no problems.
In practice, of course, it doesn't make sense to use incorrect IP addresses. If you don't specify an address at either end of the link, PPP can negotiate one for you. What this does mean, though, is that you shouldn’t worry too much about what address you get. There is one exception, however: the issue of dynamic addressing. We'll look at that below.