283 lines
9.5 KiB
Groff
283 lines
9.5 KiB
Groff
.\" $NetBSD: pppoe.4,v 1.14 2002/09/01 20:16:47 wiz Exp $
|
|
.\"
|
|
.\" Copyright (c) 2002 The NetBSD Foundation, Inc.
|
|
.\" All rights reserved.
|
|
.\"
|
|
.\" This code is derived from software contributed to The NetBSD Foundation
|
|
.\" by Martin Husemann <martin@netbsd.org>.
|
|
.\"
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
.\" modification, are permitted provided that the following conditions
|
|
.\" are met:
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
|
.\" notice, this list of conditions and the following disclaimer.
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
.\" 3. All advertising materials mentioning features or use of this software
|
|
.\" must display the following acknowledgement:
|
|
.\" This product includes software developed by the NetBSD
|
|
.\" Foundation, Inc. and its contributors.
|
|
.\" 4. Neither the name of The NetBSD Foundation nor the names of its
|
|
.\" contributors may be used to endorse or promote products derived
|
|
.\" from this software without specific prior written permission.
|
|
.\"
|
|
.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
|
|
.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
|
|
.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
|
.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
|
|
.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
|
|
.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
|
.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
|
.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
|
|
.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
|
.\" POSSIBILITY OF SUCH DAMAGE.
|
|
.\"
|
|
.Dd September 1, 2002
|
|
.Dt PPPOE 4
|
|
.Os
|
|
.Sh NAME
|
|
.Nm pppoe
|
|
.Nd PPP over Ethernet protocol network interface
|
|
.Sh SYNOPSIS
|
|
.Nm pseudo-device pppoe
|
|
.Sh DESCRIPTION
|
|
The
|
|
.Nm
|
|
interface encapsulates
|
|
.Em Point-to-Point Protocol (PPP)
|
|
packets inside Ethernet frames as defined by
|
|
.Li RFC2516 .
|
|
.Pp
|
|
This is often used to connect a router via a DSL modem to
|
|
an access concentrator. The
|
|
.Nm
|
|
interface does not by itself transmit or receive frames,
|
|
but needs an Ethernet interface to do so. This Ethernet interface
|
|
is connected to the
|
|
.Nm
|
|
interface via
|
|
.Xr pppoectl 8 .
|
|
The Ethernet interface needs to be marked UP, but does not need to have an
|
|
IP address.
|
|
.Pp
|
|
There are two basic modes of operation, controlled via the
|
|
.Em link1
|
|
switch. The default mode,
|
|
.Em link1
|
|
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
|
|
.Dq dial on demand
|
|
mode, selected by setting
|
|
.Em link1 ,
|
|
only establishes a connection when data is being sent to the interface.
|
|
.Pp
|
|
Before a
|
|
.Nm
|
|
interface is usable, it needs to be configured. The following steps
|
|
are necessary:
|
|
.Bl -bullet
|
|
.It
|
|
Create the interface.
|
|
.It
|
|
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.
|
|
.It
|
|
Configure authentication.
|
|
The PPP session needs to identify the client to the peer. For more details
|
|
on the available options see
|
|
.Xr pppoectl 8 .
|
|
.El
|
|
.Pp
|
|
This all is typically accomplished using an
|
|
.Pa /etc/ifconfig.pppoe0
|
|
file.
|
|
.Ss MSS/MTU problems
|
|
If you are using a
|
|
.Nm
|
|
interface, you will have an unusual low MTU for todays 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 this 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
|
|
.Bd -literal -offset indent
|
|
# Obey interface MTUs when calculating MSS
|
|
net.inet.tcp.mss_ifmtu=1
|
|
.Ed
|
|
.Pp
|
|
in your
|
|
.Pa /etc/sysctl.conf
|
|
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.)
|
|
.Pp
|
|
Unfortunately this sysctl does not fix the MSS advertised by hosts in
|
|
the network behind a
|
|
.Nm
|
|
connected router.
|
|
.Ss Setting up NAT with MSS-clamping
|
|
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).
|
|
.Pp
|
|
Without special care systems as described above will not be able
|
|
to send larger chunks of data to a system connected via
|
|
.Nm "" .
|
|
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.
|
|
.Pp
|
|
For connections originating from your
|
|
.Nm
|
|
connected machines, this is accomplished by setting the sysctl
|
|
variable
|
|
.Dv net.inet.tcp.mss_ifmtu
|
|
to 1 (see above).
|
|
For connections originating from systems behind your
|
|
.Nm
|
|
router, you need to set the
|
|
.Dv mssclamp
|
|
options in your NAT rules, like in this example of
|
|
.Pa /etc/ipnat.conf :
|
|
.Bd -literal -offset indent
|
|
map pppoe0 192.168.1.0/24 -> 0/32 portmap tcp/udp 44000:49999 mssclamp 1452
|
|
map pppoe0 192.168.1.0/24 -> 0/32 mssclamp 1452
|
|
.Ed
|
|
.Pp
|
|
If you do not use NAT, you need to setup a 1:1 NAT rule, just to
|
|
get the clamping:
|
|
.Bd -literal -offset indent
|
|
map pppoe0 x.x.x.x/24 -> 0/0 mssclamp 1452
|
|
.Ed
|
|
.Pp
|
|
.Em Note :
|
|
While the MSS of 1452 byte (as shown in the examples above) is the
|
|
theoretically correct value (it accounts for the smaller
|
|
.Nm
|
|
MTU, the TCP header and the maximum of 0x40 bytes of TCP options), it
|
|
seems to not be sufficient in some cases.
|
|
Other
|
|
.Nm
|
|
implementations recommend clamping to 1412 byte MSS, and we have
|
|
received reports that this actually helps in some situations.
|
|
So if you have weird problems (like sessions to certain sites
|
|
stalling), you might try using this even smaller value and see if it
|
|
helps.
|
|
.Sh EXAMPLES
|
|
A typical
|
|
.Pa /etc/ifconfig.pppoe0
|
|
file looks like this:
|
|
.Bd -literal -offset indent
|
|
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
|
|
#! /sbin/route add default -iface 0.0.0.1
|
|
up
|
|
.Ed
|
|
The commented out call to
|
|
.Xr route 8
|
|
may be omitted and the route added in the ip-up script called by
|
|
.Xr ifwatchd 8
|
|
when the real IP address is known. This is easy in the
|
|
.Dq connect always
|
|
mode (link1 not set), but hard to accomplish in the
|
|
.Dq dial on demand
|
|
mode (link1 set). In the latter case adding an iface route is an easy
|
|
workaround.
|
|
.Pp
|
|
The
|
|
.Nm
|
|
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
|
|
.Pa /etc/ppp/ip-up
|
|
and
|
|
.Pa /etc/ppp/ip-down
|
|
for this purpose, simply add
|
|
.Bd -literal -offset indent
|
|
ifwatchd=YES
|
|
.Ed
|
|
.Pp
|
|
to
|
|
.Pa /etc/rc.conf .
|
|
See
|
|
.Xr ifwatchd 8
|
|
for details and parameters passed to these scripts.
|
|
.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.
|
|
.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.
|
|
.Sh OPTIONS
|
|
A
|
|
.Nm
|
|
enabled kernel will not interfere with other
|
|
.Nm PPPoE
|
|
implementations running on the same machine. Under special circumstances
|
|
(details below) this is not desirable, so the
|
|
.Nm
|
|
driver can be told to kill all unknown
|
|
.Nm PPPoE
|
|
sessions received by the ethernet interface used for a configured
|
|
.Nm
|
|
interface. To do this, add
|
|
.Pp
|
|
.Nm options
|
|
.Ar PPPOE_TERM_UNKNOWN_SESSIONS
|
|
.Pp
|
|
to your kernel config file.
|
|
.Pp
|
|
Note that this will break all userland
|
|
.Nm PPPoE
|
|
implementations using the same ethernet interface!
|
|
.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
|
|
.Nm
|
|
driver with this option set will send a
|
|
.Nm PADT
|
|
packet (request to terminate the session). The peer will immediately disconnect
|
|
the orphaned session and allow a new one to be established.
|
|
.Sh SEE ALSO
|
|
.Xr ifwatchd 8 ,
|
|
.Xr pppoectl 8
|
|
.Rs
|
|
.%R RFC
|
|
.%N 2516
|
|
.%D February 1999
|
|
.%T "A Method for Transmitting PPP Over Ethernet (PPPoE)"
|
|
.Re
|
|
.Sh HISTORY
|
|
The
|
|
.Nm
|
|
device appeared in
|
|
.Nx 1.6 .
|
|
.Sh BUGS
|
|
This implementation is client side only.
|