Annotation of embedaddon/mpd/doc/mpd20.html, revision 1.1.1.4

1.1       misho       1: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
                      2: <HTML>
                      3: <HEAD>
                      4: <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
                      5: <TITLE>Link layer</TITLE>
                      6: </HEAD>
                      7: <BODY text="#000000" bgcolor="#ffffff">
                      8: 
1.1.1.4 ! misho       9: <A HREF="mpd.html"><EM>Mpd 5.9 User Manual</EM></A>
1.1       misho      10:  <b>:</b> <A HREF="mpd17.html"><EM>Configuring Mpd</EM></A>
                     11:  <b>:</b> <EM>Link layer</EM><BR>
                     12: <b>Previous:</b> <A HREF="mpd19.html"><EM>Mpd Layers</EM></A><BR>
                     13: <b>Next:</b> <A HREF="mpd21.html"><EM>EAP</EM></A>
                     14: 
                     15: 
                     16: <HR NOSHADE>
                     17:   <H2><A NAME="20"></A>4.3. Link layer<A NAME="links"></A></H2>
                     18: <p>This chapter describes commands that configure the link layer.
                     19: All of these commands apply to the currently active link, i.e.,
                     20: the link shown at the command line prompt.</p>
                     21: <p>
                     22: <dl>
                     23: 
                     24: <dt><b><code>set link action (bundle|forward) <em>name</em> [ <em>regexp</em> ]</code></b><dd>
                     25: <dt><b><code>set link action drop [ <em>regexp</em> ]</code></b><dd>
                     26: <p>List of such command describes how incoming calls should be processed.
                     27: "bundle" means that connection should be processed locally with
                     28: specified bundle. "forward" means that connection should be forwarded
                     29: using repeater to the specified link. "drop" means that connection
1.1.1.4 ! misho      30: should be dropped. Optional "regexp" parameter defines regular
1.1       misho      31: expression which will be checked against peer auth name.</p>
                     32: <p>Actions from list are checked in order of definition until regexp
                     33: match will be found. Actions processed at three points. First time
                     34: they are checked just after connection acception, second time just 
                     35: after receiving peer's auth during LCP negotiation and third time
                     36: when link is authenticated. As during first check there is no peer
                     37: auth name known yet, check will be skipped if there are more then 
                     38: one action specified for link or if action has regexp specified.</p>
                     39: 
                     40: <dt><b><code>set link action clear</code></b><dd>
                     41: <p>Clears link actions list.</p>
                     42: 
                     43: <dt><b><code>set link latency <em>microseconds</em></code></b><dd>
                     44: <dt><b><code>set link bandwidth <em>bits-per-second</em></code></b><dd>
                     45: <p>These commands are relevant when multi-link PPP is active.  They
                     46: affect the way in which packets are chopped up into fragments
                     47: before being sent over the various links that make up the bundle.</p>
                     48: <p>To motivate the idea, imagine a bundle that had a modem link and
                     49: a 1.5Mbps T1 link. If mpd sent each packet in two equal sized
                     50: fragments over these links, then by the time the modem got around
                     51: to transmitting the first byte of its fragment, the T1 link would
                     52: have probably already sent the whole other fragment. Clearly this
                     53: is not very good. By factoring in the latency and bandwidth parameters
                     54: for each link, mpd can distribute the fragments in a more intelligent
                     55: way.</p>
                     56: <p>Mpd attempts to distribute bytes over the links so that (if the
                     57: configured parameters are accurate) the last byte of each fragment
                     58: arrives at the peer at the same time on each link. This minimizes
                     59: latency. However, if you only care about maximizing throughput,
                     60: simply set all of the latency values to zero.</p>
                     61: <p>If all of your links are of the same type and speed (which is often
                     62: the case), then they should be configured with the same values (or
                     63: just not configured at all, since all links default to the same
                     64: values anyway). Then mpd will distribute packets in equal sized
                     65: fragments over the links.</p>
                     66: 
                     67: <dt><b><code>set link mtu <em>numbytes</em></code></b><dd>
                     68: <dt><b><code>set link mru <em>numbytes</em></code></b><dd>
                     69: <dt><b><code>set link mrru <em>numbytes</em></code></b><dd>
                     70: <p>The <code>set link mtu</code> command sets the maximum transmit unit
                     71: (MTU) value for the link.  This is the size of the largest single
                     72: PPP frame (minus PPP header) that this link will transmit, unless
                     73: the peer requests an even lower value. The default value is 1500 bytes.</p>
                     74: <p>The <code>set link mru</code> command sets maximum receive unit (MRU)
                     75: value for the link, which is the size of the largest single PPP frame
                     76: (minus PPP header) that this link is capable of receiving. The default
                     77: value is 1500 bytes.</p>
                     78: <p>If PPP multilink is negotiated on a link, then these values are
                     79: less important, because multilink allows PPP frames themselves to
                     80: be fragmented, so a PPP frame up to MRRU bytes can always pass
                     81: through no matter how small the MTU is in a particular direction.</p>
                     82: <p>Otherwise, mpd is responsible for making sure that the MTU configured
                     83: on the system networking interface is low enough so that the largest
                     84: transmitted IP packet does not exceed the peer's negotiated MRU after
                     85: it becomes a PPP frame. This includes e.g. PPP encryption and/or
                     86: compression overhead.</p>
                     87: <p>However, mpd does not account for overhead that occurs ``outside''
                     88: of the PPP frame. For example, when using link types such as PPTP
                     89: that encapsulate PPP frames within IP packets, a large outgoing
                     90: ``inner'' IP packet can result in a fragmented ``outer'' IP packet,
                     91: resulting in suboptimal performance. In this situation it may be
                     92: useful to set the link MTU to a lower value to avoid fragmentation.</p>
                     93: 
                     94: <dt><b><code>set link accmap <em>value</em></code></b><dd><p>This sets the desired asynchronous control-character map for the
                     95: link at the local end.  This option is only relevant for the
                     96: asynchronous link types (i.e., <b>modem</b> and <b>tcp</b>).
                     97: It determines which control characters need to be escaped.</p>
                     98: <p>The <code><em>value</em></code> is expressed as a 32-bit hex
                     99: value; the default is <code>0x000a0000</code>, which escapes the
                    100: Control-S and Control-Q characters.</p>
                    101: 
                    102: <dt><b><code>set link ident <em>string</em></code></b><dd><p>This enables the sending of an identification string to the peer
                    103: via the LCP Ident code. The Ident string is sent when the link is
                    104: brought up. This is useful for debugging, etc. and is meant to be
                    105: human-readable. However, it confuses some broken PPP implementations.</p>
                    106: <p>Setting an empty string disables this feature; this is the default.</p>
                    107: 
                    108: <dt><b><code>set link fsm-timeout <em>seconds</em></code></b><dd><p>This command is analogous to the same command at the bundle layer,
                    109: but it applies to link-layer FSM's such as Link Control Protocol (LCP).
1.1.1.4 ! misho     110: The default is two seconds; normally this value should not be changed.</p>
1.1       misho     111: 
                    112: <dt><b><code>set link keep-alive <em>seconds</em> <em>max</em></code></b><dd><p>This command enables the sending of LCP echo packets on the link.
                    113: The first echo packet is sent after <code><em>seconds</em></code>
                    114: seconds of quiet time (i.e., no frames received from the peer on
                    115: that link).  After <code><em>seconds</em></code> more seconds, another
                    116: echo request is sent.  If after <code><em>max</em></code> seconds of
                    117: doing this no echo reply has been received yet, the link is brought
                    118: down.</p>
                    119: <p>If <code><em>seconds</em></code> is zero, echo packets are disabled.
                    120: The default values are five second intervals with a maximum no-reply
                    121: time of forty.</p>
                    122: <p>This feature is especially useful with modems when the carrier
                    123: detect signal is unreliable. However, in situations where lines are
                    124: noisy and modems spend a lot of time retraining, the <code><em>max</em></code>
                    125: value may need to be bumped up to a more generous value.</p>
                    126: 
                    127: <dt><b><code>set link max-redial <em>num</em></code></b><dd><p>When a link fails to connect, mpd automatically retries the connection.
                    128: This command limits the number of consecutive retries.
                    129: After <code><em>num</em></code> attempts, mpd will give up.</p>
                    130: <p>When there is another open event, new dial-on-demand traffic, etc.
                    131: mpd will try again, starting over at zero.</p>
                    132: <p>If <code>max-redial</code> is set to -1, then mpd will never redial.
                    133: This setting should be used with links that are dedicated for dial-in.</p>
                    134: <p>If <code>max-redial</code> is set to 0, then mpd will redial infinitely.</p>
                    135: <p>The default value is -1.</p>
                    136: 
                    137: <dt><b><code>set link redial-delay <em>seconds</em></code></b><dd><p>This command defines time between connection retries.</p>
                    138: <p>The default value is 1.</p>
                    139: 
                    140: <dt><b><code>set link max-children <em>num</em></code></b><dd><p>This template option specifies maximum number of links, created using
                    141: this template, that could exist at the same time. Value 0 disables template.</p>
                    142: <p>The default value is 10000.</p>
                    143: 
                    144: <dt><b><code>set link accept <em>option ...</em> </code></b><dd>
                    145: <dt><b><code>set link deny <em>option ...</em> </code></b><dd>
                    146: <dt><b><code>set link enable <em>option ...</em> </code></b><dd>
                    147: <dt><b><code>set link disable <em>option ...</em> </code></b><dd>
                    148: <dt><b><code>set link yes <em>option ...</em> </code></b><dd>
                    149: <dt><b><code>set link no <em>option ...</em> </code></b><dd>
                    150: <p>These commands configure various link options. Most options 
                    151: are <em>bi-directional</em> in that they can be independently
                    152: enabled and disabled in each direction.</p>
                    153: <p>The <code><b>enable</b></code> and <code><b>disable</b></code> commands determine
                    154: whether we want the corresponding option.
                    155: The <code><b>accept</b></code> and <code><b>deny</b></code> commands determine
                    156: whether we will allow the peer to request the corresponding option.</p>
                    157: <p>Note that when talking about the authentication options PAP and CHAP,
                    158: when you <code><b>enable</b></code> an option you're saying you are going
                    159: to require a login and password from the peer.
                    160: When you <code><b>accept</b></code> an option you're saying you will
                    161: allow the peer to require a login and password from us.</p>
                    162: 
                    163: <p>The <b><code>yes</code></b> command is the same as
                    164: <code><b>enable</b></code> and <code><b>accept</b></code>.
                    165: The <b><code>no</code></b> command is the same as
                    166: <code><b>disable</b></code> and <code><b>deny</b></code>.</p>
                    167: 
                    168: </dl>
                    169: </p>
                    170: 
                    171: <p>The options available at the link layer are:</p>
                    172: <p>
                    173: <dl>
                    174: 
                    175: <dt><b><code>pap</code></b><dd><p>PAP style authentication. Note that this style of authentication
                    176: is insecure, since the password crosses the link in plaintext.</p>
                    177: <p>Default <code><b>disable</b></code> and <code><b>accept</b></code>.</p>
                    178: 
                    179: <dt><b><code>chap</code></b><dd><p>CHAP style authentication. This style of authentication is safer
                    180: than PAP, because only a hash of the password is passed over the
                    181: link.  Mpd supports MD5 style CHAP and Microsoft style CHAP versions
                    182: 1 and 2.  Mpd will prefer Microsoft CHAP over MD5 CHAP to get
                    183: encryption keys.</p>
                    184: <p>This option is an alias for <code>chap-md5</code> <code>chap-msv1</code> <code>chap-msv2</code></p>
                    185: 
                    186: <dt><b><code>chap-md5</code></b><dd><p>Traditional CHAP MD5 style authentication.</p>
                    187: <p>Default <code><b>disable</b></code> and <code><b>accept</b></code>.</p>
                    188: 
                    189: <dt><b><code>chap-msv1</code></b><dd><p>Microsoft CHAP style authentication.</p>
                    190: <p>Default <code><b>disable</b></code> and <code><b>deny</b></code>.</p>
                    191: 
                    192: <dt><b><code>chap-msv2</code></b><dd><p>Microsoft CHAP style authentication Version 2.</p>
                    193: <p>Default <code><b>disable</b></code> and <code><b>accept</b></code>.</p>
                    194: 
                    195: <dt><b><code>eap</code></b><dd><p>Extensible Authentication Protocol. For details see
1.1.1.4 ! misho     196: <A HREF="mpd21.html#eap">the EAP chapter</A>.</p>
1.1       misho     197: <p>Default <code><b>disable</b></code> and <code><b>accept</b></code>.</p>
                    198: 
                    199: <dt><b><code>incoming</code></b><dd><p>This option enables the acceptance of incoming connections.
                    200: If this option is disabled, mpd will not accept incoming connections
                    201: using this link. To avoid races it is advised to enable it after
                    202: all other link options are configured.</p>
                    203: <p>The default is <code><b>disable</b></code>.</p>
                    204: 
                    205: <dt><b><code>multilink</code></b><dd><p>This command enables multi-link PPP on the link. This option is required
                    206: in both directions if there is more than one link in the bundle. However,
                    207: multi-link PPP is sometimes useful on single links when the link MTU is
                    208: low; multi-link PPP allows arbitrarily long packets to go over a link
                    209: in fragments.</p>
                    210: <p>The default is <code><b>disable</b></code> (i.e., normal non-multilink PPP).</p>
                    211: 
                    212: <dt><b><code>shortseq</code></b><dd><p>This option is only meaningful if multi-link PPP is negotiated.
                    213: It proscribes shorter multi-link fragment headers,
                    214: saving two bytes on every frame.</p>
                    215: <p>The default is <code><b>enable</b></code> and <code><b>accept</b></code>.</p>
                    216: 
                    217: <dt><b><code>acfcomp</code></b><dd><p>Address and control field compression. This option only applies
                    218: to asynchronous link types. It saves two bytes per frame.</p>
                    219: <p>The default is <code><b>enable</b></code> and <code><b>accept</b></code>.</p>
                    220: 
                    221: <dt><b><code>protocomp</code></b><dd><p>Protocol field compression. This option saves one byte per frame
                    222: for most frames.</p>
                    223: <p>The default is <code><b>enable</b></code> and <code><b>accept</b></code>.</p>
                    224: 
                    225: <dt><b><code>magicnum</code></b><dd>
                    226: <dt><b><code>check-magic</code></b><dd><p>The <code>magicnum</code> option enables using a magic number for the
                    227: local end of the PPP link.  This causes a unique number to be
                    228: included in each LCP packet we send, which helps detect loopback
                    229: conditions.</p>
                    230: <p>The <code>check-magic</code> option causes mpd to verify that the peer's
                    231: magic number is correct in all received LCP frames.</p>
1.1.1.4 ! misho     232: <p>Some old broken PPP implementations do not handle magic numbers correctly,
1.1       misho     233: so these options need to be disabled in these cases.</p>
                    234: <p>Default for both options is <code><b>enable</b></code>.</p>
                    235: <p>Note that the two most common reasons for seeing ``loopback condition
                    236: detected'' on a modem link are:
                    237: <ul>
                    238: <li> The modem is in command mode and is echoing back all of our frames.</li>
                    239: <li> The PPP server is not in PPP mode, but is giving a shell prompt
                    240: or somesuch and echoing back all of our frames.</li>
                    241: </ul>
                    242: </p>
                    243: 
                    244: <dt><b><code>passive</code></b><dd><p>Enables passive mode for this link. This is useful on some full time
                    245: connections. See RFC 1661 for more information about this option.</p>
                    246: <p>Default <code><b>disable</b></code>.</p>
                    247: 
                    248: <dt><b><code>callback</code></b><dd><p>Enables PPP callback request. If the remote peer can/wants to, it will 
                    249: hangup immediately after connecting and call us back.</p>
                    250: <p>Default <code><b>disable</b></code>.</p>
                    251: 
                    252: <dt><b><code>no-orig-auth</code></b><dd><p>Normally, if PAP or CHAP is enabled, we require the peer to
                    253: authenticate to us at the beginning of each connection. This option
                    254: temporarily disables this requirement if we are the one who originated
                    255: the connection and the peer rejects our request for a login.</p>
                    256: <p>This is useful when the same link is used for both dial-in and dial-out.</p>
                    257: <p>Default <code><b>disable</b></code>.</p>
                    258: 
                    259: <dt><b><code>keep-ms-domain</code></b><dd><p>Normally, if using MS-CHAP, the MS-Domain is stripped and only the plain
                    260: username is used. Under certain circumstances the MS-Domain should be kept,
                    261: for instance if IAS is used as RADIUS server.</p>
                    262: <p>Default <code><b>disable</b></code>.</p>
                    263: 
                    264: <dt><b><code>time-remain</code></b><dd><p>Send Time-Remaining LCP packet to the peer if AAA returned session timeout.</p>
                    265: <p>Default <code><b>disable</b></code>.</p>
                    266: 
                    267: <dt><b><code>peer-as-calling</code></b><dd><p>Forces mpd to send remote tunnel address in Calling-Station-Id 
1.1.1.4 ! misho     268: instead of address supplied by remote peer via tunnel (for PPTP and L2TP).
1.1       misho     269: Can be enabled for untrusted peers.</p>
                    270: <p>Default is <code><b>disable</b></code>.</p>
                    271: 
                    272: <dt><b><code>report-mac</code></b><dd><p>Forces mpd to send peer MAC address and interface in Calling-Station-Id.</p>
                    273: <p>Default <code><b>disable</b></code>.</p>
                    274: 
                    275: </dl>
                    276: </p>
                    277: 
                    278: <H3>4.3.1. <A HREF="mpd21.html#21">EAP</A></H3>
                    279:  <HR NOSHADE>
1.1.1.4 ! misho     280: <A HREF="mpd.html"><EM>Mpd 5.9 User Manual</EM></A>
1.1       misho     281:  <b>:</b> <A HREF="mpd17.html"><EM>Configuring Mpd</EM></A>
                    282:  <b>:</b> <EM>Link layer</EM><BR>
                    283: <b>Previous:</b> <A HREF="mpd19.html"><EM>Mpd Layers</EM></A><BR>
                    284: <b>Next:</b> <A HREF="mpd21.html"><EM>EAP</EM></A>
                    285: 
                    286: 
                    287: 
                    288: </BODY>
                    289: </HTML>

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>