We already encountered the Link Control Protocol (LCP), which is
used to negotiate link characteristics and test the link.
The two most important options negotiated by LCP are the
Asynchronous Control Character Map and the
Maximum Receive Unit. There are a number of other
LCP configuration options, but they are far too specialized to discuss
here.
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) to avoid them being interpreted by equipment
used to establish the link. For instance, you may want to avoid the XON and
XOFF characters used for software handshake because a misconfigured modem
might choke upon receipt of an XOFF. Other candidates include Ctrl-l (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 32-bit-wide bitmap expressed in hexadecimal. The least
significant bit corresponds to the ASCII NULL character, and the most
significant bit corresponds to ASCII 31 decimal. These 32 ASCII characters are
the control characters. If a bit is set in the bitmap, it signals that the
corresponding character must be escaped before it is transmitted across the
link.
To tell your peer that it doesn't have to escape all control characters,
but only a few of them, you can specify an async map to pppd
using the asyncmap option. For example, if only
^S and ^Q (ASCII 17 and 19, commonly
used for XON and XOFF) must be escaped, use the following option:
The conversion is simple as long as you can convert binary to hex.
Lay out 32 bits in front of you. The right-most bit corresponds to ASCII 00
(NULL), and the left-most bit corresponds to ASCII 32 decimal. Set the bits
corresponding to the characters you want escaped to one, and all others to zero.
To convert that into the hexadecimal number pppd expects,
simply take each set of 4 bits and convert them into hex. You should end up
with eight hexadecimal figures. String them all together and preprend
“0x” to signify it is a hexadecimal number, and you are done.
Initially, the async map is set to 0xffffffff—that
is, all control characters will be escaped. This is a safe default,
but is usually much more than you need. Each character that appears in
the async map results in two characters being transmitted across the
link, so escaping comes at the cost of increased link utilization
and a corresponding performance reduction.
In most circumstances, an async map of 0x0 works
fine. No escaping is performed.
The Maximum Receive Unit (MRU), signals to the peer the maximum size
of HDLC frames we want to receive. Although this may remind you of the
Maximum Transfer Unit (MTU) value, 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 transmit. The MRU is more of
an advice to the remote end not to generate frames larger than the
MRU; the interface must nevertheless be able to receive frames of up to
1,500 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 give it the option mru
296. Small MRUs, however, make sense only if you have VJ
header compression (it is enabled by default), because otherwise you'd
waste a large amount of your bandwidth just carrying the IP header for
each datagram.
pppd also understands 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 options 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 are sent. This number can be set using the
lcp-echo-failure option. By default, this feature is
disabled altogether.
