Describe what happens when RFC 4638 is not supported.

With help from sthen@.  OK sthen@ jmc@

diff --git a/share/man/man4/pppoe.4 b/share/man/man4/pppoe.4
index a6af9e0..9766245 100644 (file)
--- a/share/man/man4/pppoe.4
+++ b/share/man/man4/pppoe.4
@@ -1,4 +1,4 @@
-.\"    $OpenBSD: pppoe.4,v 1.34 2017/06/16 10:58:43 stsp Exp $
+.\"    $OpenBSD: pppoe.4,v 1.35 2021/03/16 13:53:39 millert Exp $
 .\"    $NetBSD: pppoe.4,v 1.26 2003/10/02 07:06:36 wiz Exp $
 .\"
 .\" Copyright (c) 2002 The NetBSD Foundation, Inc.
@@ -28,7 +28,7 @@
 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 .\" POSSIBILITY OF SUCH DAMAGE.
 .\"
-.Dd $Mdocdate: June 16 2017 $
+.Dd $Mdocdate: March 16 2021 $
 .Dt PPPOE 4
 .Os
 .Sh NAME
@@ -201,6 +201,20 @@ With this, the previously mentioned MSS clamping rules in
 .Xr pf.conf 5
 are no longer necessary.
 .Pp
+If the MTU is set to a value larger than 1492 and the remote endpoint does
+.Em not
+support RFC 4638,
+.Nm
+will write
+.Dq \&No valid PPP-Max-Payload tag received in PADO
+to the kernel message buffer and the MTU will remain at the default value.
+However, RFC 4638 negotiation only takes into account the MTU configured
+on the endpoints, not the maximum MTU supported on the path between them.
+If the path cannot pass the larger Ethernet frames, negotiation will succeed
+but the larger frames will be dropped.
+For this reason it is important to test the connection with large packets
+when enabling a higher MTU.
+.Pp
 See
 .Xr pf.conf 5
 for more information on MTU, MSS, and NAT.
@@ -237,11 +251,6 @@ The
 .Nm
 device first appeared in
 .Ox 3.7 .
-.Sh CAVEATS
-RFC 4638 negotiation is only aware of the MTU configured on the endpoints,
-but not the maximum MTU supported on the path between them.
-If the path cannot pass the larger Ethernet frames, negotiation will succeed
-but the connection will not function correctly.
 .Sh BUGS
 This implementation is client side only.
 .Pp