diff options
Diffstat (limited to 'static/netbsd/man4/pppoe.4 3.html')
| -rw-r--r-- | static/netbsd/man4/pppoe.4 3.html | 249 |
1 files changed, 0 insertions, 249 deletions
diff --git a/static/netbsd/man4/pppoe.4 3.html b/static/netbsd/man4/pppoe.4 3.html deleted file mode 100644 index 9601ddc3..00000000 --- a/static/netbsd/man4/pppoe.4 3.html +++ /dev/null @@ -1,249 +0,0 @@ -<table class="head"> - <tr> - <td class="head-ltitle">PPPOE(4)</td> - <td class="head-vol">Device Drivers Manual</td> - <td class="head-rtitle">PPPOE(4)</td> - </tr> -</table> -<div class="manual-text"> -<section class="Sh"> -<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1> -<p class="Pp"><code class="Nm">pppoe</code> — <span class="Nd">PPP over - Ethernet protocol network interface</span></p> -</section> -<section class="Sh"> -<h1 class="Sh" id="SYNOPSIS"><a class="permalink" href="#SYNOPSIS">SYNOPSIS</a></h1> -<p class="Pp"><code class="Cd">pseudo-device pppoe</code></p> -</section> -<section class="Sh"> -<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1> -<p class="Pp">The <code class="Nm">pppoe</code> interface encapsulates - <a class="permalink" href="#Point-to-Point"><i class="Em" id="Point-to-Point">Point-to-Point - Protocol (PPP)</i></a> packets inside Ethernet frames as defined by - <code class="Li">RFC2516</code>.</p> -<p class="Pp">This is often used to connect a router via a DSL modem to an - access concentrator. The <code class="Nm">pppoe</code> interface does not by - itself transmit or receive frames, but needs an Ethernet interface to do so. - This Ethernet interface is connected to the <code class="Nm">pppoe</code> - interface via <a class="Xr">pppoectl(8)</a>. The Ethernet interface needs to - be marked UP, but does not need to have an IP address.</p> -<p class="Pp">There are two basic modes of operation, controlled via the - <i class="Em">link1</i> switch. The default mode, <i class="Em">link1</i> - not being set, tries to keep the configured session open all the time. If - the session is disconnected, a new connection attempt is started - immediately. The “dial on demand” mode, selected by setting - <i class="Em">link1</i>, only establishes a connection when data is being - sent to the interface.</p> -<p class="Pp">If the kernel is compiled with options - <code class="Dv">PPPOE_SERVER</code>, there are two modes of connection, - controlled via the <i class="Em">link0</i> switch. The default mode, - <i class="Em">link0</i> not being set, is client mode. The “PPPoE - server” mode, selected by setting <i class="Em">link0</i>, is to wait - for incoming PPPoE session.</p> -<p class="Pp">Before a <code class="Nm">pppoe</code> interface is usable, it - needs to be configured. The following steps are necessary:</p> -<ul class="Bl-bullet"> - <li>Create the interface.</li> - <li>Connect an Ethernet interface. This interface is used for the physical - communication. As noted above it must be marked UP, but need not have an - IP address.</li> - <li>Configure authentication. The PPP session needs to identify the client to - the peer. For more details on the available options see - <a class="Xr">pppoectl(8)</a>.</li> -</ul> -<p class="Pp">This all is typically accomplished using an - <span class="Pa">/etc/ifconfig.pppoe0</span> file.</p> -<section class="Ss"> -<h2 class="Ss" id="MSS/MTU_problems"><a class="permalink" href="#MSS/MTU_problems">MSS/MTU - problems</a></h2> -<p class="Pp">If you are using a <code class="Nm">pppoe</code> interface, you - will have an unusually low MTU for today's Internet. Combined with a lot of - misconfigured sites (host using path MTU discovery behind a router blocking - all ICMP traffic) this will often cause problems. Connections to these - servers will only work if your system advertises the right MSS in the TCP - three way handshake. To get the right MSS, you need to set</p> -<div class="Bd Pp Bd-indent Li"> -<pre># Obey interface MTUs when calculating MSS -net.inet.tcp.mss_ifmtu=1</pre> -</div> -<p class="Pp">in your <span class="Pa">/etc/sysctl.conf</span> file. This causes - the calculated MSS to be based on the MTU of the interface via which the - packet is sent. This is always the right value if you are sure the answer to - this packet will be received on the same interface (i.e., you only have one - interface connected to the Internet.)</p> -<p class="Pp" id="MSS-clamping">Unfortunately this sysctl does not fix the MSS - advertised by hosts in the network behind a <code class="Nm">pppoe</code> - connected router. To fix this you need - <a class="permalink" href="#MSS-clamping"><i class="Em">MSS-clamping</i></a>, - explained below.</p> -</section> -<section class="Ss"> -<h2 class="Ss" id="Setting_up_NAT_with_MSS-clamping"><a class="permalink" href="#Setting_up_NAT_with_MSS-clamping">Setting - up NAT with MSS-clamping</a></h2> -<p class="Pp">Some systems behind misconfigured firewalls try to use - Path-MTU-Discovery, while their firewall blocks all ICMP messages. This is - an illegal, but not uncommon, setup. Typically you will have no chance to - fix this (remote, outside of your control) setup. And sometimes you will - have to use such remote systems (to download data from them, or to do your - online banking).</p> -<p class="Pp">Without special care systems as described above will not be able - to send larger chunks of data to a system connected via - <code class="Nm">pppoe</code>. But there is a workaround (some may call it - cheating): pretend to not be able to handle large packets, by sending a - small MSS (maximum segment size) option during initial TCP handshake.</p> -<p class="Pp">For connections originating from your - <code class="Nm">pppoe</code> connected machines, this is accomplished by - setting the sysctl variable <code class="Dv">net.inet.tcp.mss_ifmtu</code> - to 1 (see above). For connections originating from systems behind your - <code class="Nm">pppoe</code> router, you need to set the - <code class="Dv">mssclamp</code> options in your NAT rules, like in this - example of <span class="Pa">/etc/ipnat.conf</span>:</p> -<div class="Bd Pp Bd-indent Li"> -<pre>map pppoe0 192.168.1.0/24 -> 0/32 portmap tcp/udp 44000:49999 mssclamp 1440 -map pppoe0 192.168.1.0/24 -> 0/32 mssclamp 1440</pre> -</div> -<p class="Pp">If you do not use NAT, you need to set up a 1:1 NAT rule, just to - get the clamping:</p> -<div class="Bd Pp Bd-indent Li"> -<pre>map pppoe0 x.x.x.x/24 -> 0/0 mssclamp 1440</pre> -</div> -<p class="Pp" id="Note">The above examples assume a MTU of 1492 bytes. If the - MTU on your PPPoE connection is smaller use the MTU - 52 bytes for clamping - e.g. 1408 bytes for a MTU of 1460 bytes. - <a class="permalink" href="#Note"><i class="Em">Note</i></a>: The - theoretically correct value for the above example would be 1452 bytes (it - accounts for the smaller PPPoE MTU, the TCP header and the maximum of 0x40 - bytes of TCP options) but it seems to not be sufficient in some cases. - Experiments conducted by various people have shown that clamping to the MSS - values suggested above works best.</p> -</section> -</section> -<section class="Sh"> -<h1 class="Sh" id="EXAMPLES"><a class="permalink" href="#EXAMPLES">EXAMPLES</a></h1> -<p class="Pp">A typical <span class="Pa">/etc/ifconfig.pppoe0</span> file looks - like this:</p> -<div class="Bd Pp Bd-indent Li"> -<pre>create -! /sbin/ifconfig ne0 up -! /sbin/pppoectl -e ne0 $int -! /sbin/pppoectl $int myauthproto=pap myauthname=testcaller myauthsecret=donttell -inet 0.0.0.0 0.0.0.1 netmask 0xffffffff -#! /sbin/route add default -iface 0.0.0.1 -up</pre> -</div> -The commented out call to <a class="Xr">route(8)</a> may be omitted and the - route added in the ip-up script called by <a class="Xr">ifwatchd(8)</a> when - the real IP address is known. This is easy in the “connect - always” mode (link1 not set), but hard to accomplish in the - “dial on demand” mode (link1 set). In the latter case adding an - iface route is an easy workaround. -<p class="Pp">The <code class="Nm">pppoe</code> interfaces operate completely - inside the kernel, without any userland support. Because of this, a special - daemon is used to fire ip-up or down scripts to execute arbitrary code when - the PPP session is established and addresses of the interface become - available. To enable the usage of <span class="Pa">/etc/ppp/ip-up</span> and - <span class="Pa">/etc/ppp/ip-down</span> for this purpose, simply add</p> -<div class="Bd Pp Bd-indent Li"> -<pre>ifwatchd=YES</pre> -</div> -<p class="Pp">to <span class="Pa">/etc/rc.conf</span>. See - <a class="Xr">ifwatchd(8)</a> for details and parameters passed to these - scripts.</p> -<p class="Pp">Since this is a PPP interface, the addresses assigned to the - interface may change during PPP negotiation. There is no fine grained - control available for deciding which addresses are acceptable and which are - not. For the local side and the remote address there is exactly one choice: - hard coded address or wildcard. If a real address is assigned to one side of - the connection, PPP negotiation will only agree to exactly this address. If - one side is wildcarded, every address suggested by the peer will be - accepted.</p> -<p class="Pp">To wildcard the local address set it to 0.0.0.0, to wildcard the - remote address set it to 0.0.0.1. Wildcarding is not available (nor - necessary) for IPv6 operation.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="OPTIONS"><a class="permalink" href="#OPTIONS">OPTIONS</a></h1> -<p class="Pp">A <code class="Nm">pppoe</code> enabled kernel will not interfere - with other <code class="Nm">PPPoE</code> implementations running on the same - machine. Under special circumstances (details below) this is not desirable, - so the <code class="Nm">pppoe</code> driver can be told to kill all unknown - <code class="Nm">PPPoE</code> sessions received by the Ethernet interface - used for a configured <code class="Nm">pppoe</code> interface. To do this, - add the following to your kernel config file:</p> -<p class="Pp"></p> -<div class="Bd Bd-indent"><code class="Li">options - PPPOE_TERM_UNKNOWN_SESSIONS</code></div> -<p class="Pp">and set the value of <a class="Xr">sysctl(7)</a> variable - <code class="Dv">net.pppoe.term_unknown</code> to true.</p> -<p class="Pp">Note that this will break all userland - <code class="Nm">PPPoE</code> implementations using the same Ethernet - interface!</p> -<p class="Pp">This option is only useful if you have a static IP address - assigned and your ISP does not use LCP echo requests to monitor the link - status. After a crash or power failure the peer device still tries to send - data to the no longer active session on your computer, and might refuse to - reestablish a new connection, because there already is an open session. On - receipt of such packets, the <code class="Nm">pppoe</code> driver with this - option set will send a PADT packet (request to terminate the session). The - peer will immediately disconnect the orphaned session and allow a new one to - be established.</p> -<p class="Pp">To enable <code class="Nm">pppoe</code> server support in the - kernel, use</p> -<p class="Pp"></p> -<div class="Bd Bd-indent"><code class="Li">options PPPOE_SERVER</code></div> -<p class="Pp">As described above, this allows <code class="Nm">pppoe</code> - interfaces to be created and configured for incoming connections by setting - the “<code class="Li">link0</code>” flag with - <a class="Xr">ifconfig(8)</a>.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE - ALSO</a></h1> -<p class="Pp"><a class="Xr">ifwatchd(8)</a>, <a class="Xr">pppoectl(8)</a></p> -<p class="Pp"><cite class="Rs"><span class="RsT">A Method for Transmitting PPP - Over Ethernet (PPPoE)</span>, <span class="RsR">RFC</span>, - <span class="RsN">2516</span>, <span class="RsD">February - 1999</span>.</cite></p> -<p class="Pp"><cite class="Rs"><span class="RsT">Accommodating a Maximum Transit - Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point - Protocol over Ethernet (PPPoE)</span>, <span class="RsR">RFC</span>, - <span class="RsN">4638</span>, <span class="RsD">September - 2006</span>.</cite></p> -</section> -<section class="Sh"> -<h1 class="Sh" id="HISTORY"><a class="permalink" href="#HISTORY">HISTORY</a></h1> -<p class="Pp">The <code class="Nm">pppoe</code> device appeared in - <span class="Ux">NetBSD 1.6</span>.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="DEVIATIONS_FROM_STANDARD"><a class="permalink" href="#DEVIATIONS_FROM_STANDARD">DEVIATIONS - FROM STANDARD</a></h1> -<p class="Pp">The original PPPoE standard, <code class="Li">RFC2516</code>, - requires a maximal MTU of 1492 octets. This value is the maximum - conservative value possible, based on the PPPoE header size and the minimum - frame size Ethernet interfaces are required to support.</p> -<p class="Pp">In practice most modern Ethernet interfaces support bigger frames, - and many PPPoE services allow the use of (slightly) larger MTUs, to avoid - the problems described above.</p> -<p class="Pp">This implementation allows MTU values as large as possible with - the actual MTU of the used Ethernet interface and conforms to the - enhancement to the PPPoE standard, <code class="Li">RFC4638</code>, to - request the use of this larger MTU value with the PPPoE server.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="BUGS"><a class="permalink" href="#BUGS">BUGS</a></h1> -<p class="Pp">When using the wildcard address 0.0.0.0 (as described above) it is - important to specify the proper - “<code class="Li">netmask</code>” to - <a class="Xr">ifconfig(8)</a>, in most setups - “<code class="Li">0xffffffff</code>”. If the netmask is - unspecified, it will be set to 8 when 0.0.0.0 is configured to the - interface, and it will persist after negotiation.</p> -</section> -</div> -<table class="foot"> - <tr> - <td class="foot-date">August 7, 2016</td> - <td class="foot-os">NetBSD 10.1</td> - </tr> -</table> |