| PPPOE(4) |
AerieBSD 1.0 Refernce Manual |
PPPOE(4) |
NAME
pppoe
PPP Over Ethernet protocol network interface
SYNOPSIS
.Cd "pseudo-device pppoe"
DESCRIPTION
The
pppoe
interface encapsulates
Point-to-Point Protocol (PPP)
packets inside Ethernet frames as defined by RFC 2516.
This is often used to connect a router via a DSL modem to
an access concentrator.
The
pppoe
interface does not by itself transmit or receive frames,
but needs an Ethernet interface to do so.
This Ethernet interface is connected to the
pppoe
interface via
ifconfig(8).
The Ethernet interface needs to be marked UP, but does not need to have an
IP address.
There are two basic modes of operation, controlled via the
link1
switch.
The default mode,
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
dial on demand
mode, selected by setting
link1,
only establishes a connection when data is being sent to the interface.
Before a
pppoe
interface is usable, it needs to be configured.
The following steps are necessary:
-
Create the interface.
-
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.
-
Configure authentication.
The PPP session needs to identify the client to the peer.
For more details on the available options see
ifconfig(8).
This all is typically accomplished using an
/etc/hostname.pppoe0
file.
EXAMPLES
A typical
/etc/hostname.pppoe0
file looks like this:
inet 0.0.0.0 255.255.255.255 NONE \e
pppoedev ne0 authproto pap \e
authname 'testcaller' authkey 'donttell' up
dest 0.0.0.1
!/sbin/route add default -ifp pppoe0 0.0.0.1
The physical interface must also be marked
"up":
# echo "up" \*(Gt /etc/hostname.ne0
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.
To wildcard the local address set it to 0.0.0.0; to wildcard the remote
address set it to 0.0.0.1.
KERNEL OPTIONS
A
pppoe
enabled kernel will not interfere with other PPPoE implementations
running on the same machine.
Under special circumstances
(details below) this is not desirable, so the
pppoe
driver can be told to kill all unknown PPPoE sessions
received by the Ethernet interface used for a configured
pppoe
interface.
To do this,
add the following to your kernel config file:
option PPPOE_TERM_UNKNOWN_SESSIONS
Note that this will break all userland PPPoE
implementations using the same Ethernet interface!
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
pppoe
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.
If the kernel is compiled with option
PPPOE_SERVER,
there are two modes of connection, controlled via the
link0
switch.
The default mode,
link0
not being set, is client mode.
The
PPPoE server
mode, selected by setting
link0,
is to wait for incoming PPPoE sessions.
MTU/MSS ISSUES
Problems can arise on machines with private IPs connecting to the Internet
via a machine running both
Network Address Translation (NAT)
and
pppoe.
Standard Ethernet uses a
Maximum Transmission Unit (MTU)
of 1500 bytes,
whereas PPPoE mechanisms need a further 8 bytes of overhead.
This leaves a maximum MTU of 1492.
pppoe
sets the MTU on its interface to 1492 as a matter of course.
However,
machines connecting on a private LAN will still have their MTUs set to 1500,
causing conflict.
While
pppoe(8)
has an internal option,
mssfixup,
which is enabled by default and takes care of this,
pppoe
users have to rely on other methods.
Using a packet filter,
the
Maximum Segment Size (MSS)
can be set (clamped) to the required value.
The following rule in
pf.conf(5)
would set the MSS to 1440:
scrub out on pppoe0 max-mss 1440
Although in theory the maximum MSS over a PPPoE interface
is 1452 bytes,
1440 appears to be a safer bet.
Note that setting the MSS this way can have undesirable effects,
such as interfering with the OS detection features of
pf(4).
See
pf.conf(5)
for more information on MTU, MSS, and NAT.
SEE ALSO
sppp(4),
hostname.if(5),
pf.conf(5),
ifconfig(8),
ppp(8),
pppoe(8)
.Rs
.%R RFC 2516
.%T A Method for Transmitting PPP Over Ethernet (PPPoE)
.%D February 1999
.Re
HISTORY
The
pppoe
device first appeared in
OpenBSD 3.7.
BUGS
This implementation is client side only.
It is important to specify
netmask 255.255.255.255
to
ifconfig(8).
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.
The presence of a
mygate(5)
file will interfere with the routing table.
Make sure this file is either empty or does not exist.
| AerieBSD 1.0 Reference Manual |
December 26 2008 |
PPPOE(4) |