The two most important options that may be negotiated by LCP are the maximum receive unit, and the Asynchronous Control Character Map. There are a number of other LCP configuration options, but they are far too specialized to discuss here. Please refer to RFC-1548 for a description of those.
The Asynchronous Control Character Map, colloquially called the async map, is used on asynchronous links such as telephone lines to identify control characters that must be escaped (replaced by a specific two-character sequence). For instance, you may want to avoid the XON and XOFF characters used for software handshake, because some misconfigured modem might choke upon receipt of an XOFF. Other candidates include Ctrl-] (the telnet escape character). PPP allows you to escape any of the characters with ASCII codes 0 through 31 by specifying them in the async map.
The async map is a bitmap 32-bits wide, with the least significant bit corresponding to the ASCII NUL character, and the most significant bit corresponding to ASCII 31. If a bit is set, it signals that the corresponding character must be escaped before sending it across the link. Initially, the async map is set to 0xffffffff, that is, all control characters will be esaped.
To tell your peer that it doesn't have to escape all control characters
but only a few of them, you can specify a new asyncmap to pppd
using the asyncmap option. For instance, if only ^S and
^Q (ASCII 17 and 19, commonly used for XON and XOFF) must be
escaped, use the following option:
asyncmap 0x000A0000
The Maximum Receive Unit, or MRU, signals to the peer the maximum size
of HDLC frames we want to receive. Although this may remind you of the
MTU value (Maximum Transfer Unit), these two have little in common. The
MTU is a parameter of the kernel networking device, and describes the
maximum frame size the interface is able to handle. The MRU is more of
an advice to the remote end not to generate any frames larger than the
MRU; the interface must nevertheless be able to receive frames of up to
1500-bytes.
Choosing an MRU is therefore not so much a question of what the link is capable of transferring, but of what gives you the best throughput. If you intend to run interactive applications over the link, setting the MRU to values as low as 296 is a good idea, so that an occasional larger packet (say, from an FTP session) doesn't make your cursor ``jump''. To tell pppd to request an MRU of 296, you would give it the option mru 296. Small MRUs, however, only make sense if you don't have VJ header compression disabled (it is enabled by default).
pppd understands also a couple of LCP options that configure the overall behavior of the negotiation process, such as the maximum number of configuration requests that may be exchanged before the link is terminated. Unless you know exactly what you are doing, you should leave these alone.
Finally, there are two options that apply to LCP echo messages. PPP defines two messages, Echo Request and Echo Response. pppd uses this feature to check if a link is still operating. You can enable this by using the lcp-echo-interval option together with a time in seconds. If no frames are received from the remote host within this interval, pppd generates an Echo Request, and expects the peer to return an Echo Response. If the peer does not produce a response, the link is terminated after a certain number of requests sent. This number can be set using the lcp-echo-failure option. By default, this feature is disabled altogether.