1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
|
<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>
|
