embedaddon/mpd/doc/mpd26.html - view

File: [ELWIX - Embedded LightWeight unIX -] / embedaddon / mpd / doc / mpd26.html
Revision 1.1.1.4 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Wed Mar 17 00:39:23 2021 UTC (3 years, 9 months ago) by misho
Branches: mpd, MAIN
CVS tags: v5_9p16, v5_9, HEAD

mpd 5.9

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <TITLE>IPCP layer</TITLE> </HEAD> <BODY text="#000000" bgcolor="#ffffff"> <A HREF="mpd.html">Mpd 5.9 User Manual</A> : <A HREF="mpd17.html">Configuring Mpd</A> : IPCP layer  Previous: <A HREF="mpd25.html">MPPC protocol</A>  Next: <A HREF="mpd27.html">IPv6CP layer</A> <HR NOSHADE> <H2><A NAME="26"></A>4.7. IPCP layer<A NAME="ipcp"></A></H2> This chapter describes commands that configure the IP Control Protocol (IPCP) layer. To enable IPCP, <code>ipcp</code> option should be enabled at the bundle layer. All of these commands apply to the currently active bundle.  <dl> <dt><code>set ipcp ranges (local/width|ippool pool) (remote/width|ippool pool)</code><dd>This command determines what IP addresses mpd will allow to be negotiated at the local and remote ends of the link. For each endpoint, we have a target address and a netmask width. The <code>width</code> determines how flexible we are, i.e., how close the actual negotiated address must be to the target address. A <code>width</code> of 32 means they must match exactly; a <code>width</code> of zero means any address is suitable. For example, <code>192.168.1.17/25</code> means that IP address <code>192.168.1.17</code> is desired, but any IP address in the range <code>192.168.1.0</code> through <code>192.168.1.128</code> is acceptable. By convention, the <code>local</code> address may be <code>0.0.0.0</code> to request that the remote server assign us an IP address. Of course, for this to work the remote side must know a priori what our local IP address should be. The <code>remote</code> address should not be <code>0.0.0.0</code>. This is so if the peer requests <code>0.0.0.0</code>, we have some address to give him. The <code>width</code> may of course be zero. It is also possible to specify ippool name to use for assigning remote ip. In such case width 32 is assumed. If the two sides cannot agree on the IP address assignments after repeated negotiation attempts, then the connection will fail. This is manifested with the error message ``IPCP: not converging.'' <dt><code>set ipcp dns primary [ secondary ]</code><dd>Some PPP clients request DNS server information from their remote peer. This commands enables mpd to have an answer for any such clients. This command is especially useful for supplying information to PPTP clients. One or two DNS server IP addresses may be given. An address of <code>0.0.0.0</code> erases that entry. <dt><code>set ipcp nbns primary [ secondary ]</code><dd>Some Microsoft PPP clients request NetBIOS name server (NBNS) information from their remote peer. This commands enables mpd to have an answer for any such clients. This command is especially useful for supplying information to PPTP clients. One or two NBNS server IP addresses may be given. An address of <code>0.0.0.0</code> erases that entry. <dt><code>set ipcp accept option ... </code><dd> <dt><code>set ipcp deny option ... </code><dd> <dt><code>set ipcp enable option ... </code><dd> <dt><code>set ipcp disable option ... </code><dd> <dt><code>set ipcp yes option ... </code><dd> <dt><code>set ipcp no option ... </code><dd> These commands configure various IPCP options. The <code>vjcomp</code> option is bi-directional in that it can be independently enabled and disabled in each direction. The <code>enable</code> and <code>disable</code> commands determine whether we want the corresponding option. The <code>accept</code> and <code>deny</code> commands determine whether we will allow the peer to request the corresponding option. The <code>yes</code> command is the same as <code>enable</code> and <code>accept</code>. The <code>no</code> command is the same as <code>disable</code> and <code>deny</code>. </dl>  The options available at the IPCP layer are:  <dl> <dt><code>vjcomp</code><dd>This option enables Van Jacobson TCP header compression, which saves several bytes per TCP data packet. You almost always want this option. This compression ineffective for TCP connections with enabled modern extensions like time stamping or SACK, which modify TCP options between sequential packets. Default <code>enable</code> and <code>accept</code>. <dt><code>req-pri-dns </code><dd> <dt><code>req-sec-dns </code><dd> <dt><code>req-pri-nbns </code><dd> <dt><code>req-sec-nbns </code><dd> Enabling these options causes mpd to request primary and/or secondary DNS and/or NBNS servers from the remote peer during negotiation. If any DNS servers are supplied by the peer, they will appear as parameters to the script specified by the <code>set iface up-script</code> command, if any. Currently, mpd does not use the NBNS values for anything; they just appear in the log. A future revision may actually do something with them. </dl>  <HR NOSHADE> <A HREF="mpd.html">Mpd 5.9 User Manual</A> : <A HREF="mpd17.html">Configuring Mpd</A> : IPCP layer  Previous: <A HREF="mpd25.html">MPPC protocol</A>  Next: <A HREF="mpd27.html">IPv6CP layer</A> </BODY> </HTML>