This is a multi-part message in MIME format.

--Multipart_Sun__3_Aug_2003_15:07:30_+0200_08222a00
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Le Sun, 3 Aug 2003 13:51:38 +0200
Martin Husemann a ecrit :
> On Sat, Aug 02, 2003 at 11:27:55PM +0200, Quentin Garnier wrote:
> > I've repeatedly ask for that change. The only answer I got was
> > 'it's a flaw in the design of PPPoE'.
> 
> Well, the PPPoE standard (RFC 2516) is pretty explicit in this point.
> Section 7 (LCP Considerations) says:
> 
>    The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a
>    larger size than 1492.  Since Ethernet has a maximum payload size of
>    1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is
>    2 octets, the PPP MTU MUST NOT be greater than 1492.
> 
> So it's a flaw in their PPPoE implementation to actually allow this
> large frames, and it's a configuration flaw at their router to not
> return need-frag ICMPs.

Well, it's a bit more complicated than that. The telephony operator
manages the BAS which is the equipment that implement PPPoE. The ISP
manages the LNS, which is linked to the BAS through a L2TP tunnel (over
ATM). At least that's how things work here.

The MRU is negociated with the BAS, and is indeed at 1492. The ISP is
mostly used for authentication (it is not clear how much of the PPP
session is handled by the BAS or by the LNS).

Since the MRU isn't negociated with the LNS, at this side the MTU stays at
1500. Then, when a packet with 1500 bytes of data enters the L2TP tunnel,
the BAS has no other option but to silently drop it or pass it, since it
can't send an ICMP packet on the behalf of the LNS and/or the client.

> I have no problem for us accepting such broken input when a special
> option is present, as long as this option is pretty clear documented to
> be depreciated and in violation of relevant standards.

Ok, updated the patch then. It's not really clear to me how it would be
violating a standard accepting a frame that found its way to us. We're not
the one breaking the standard.

> I know how hard it is to find even semi-competent ISPs, it's a big
> problem here in  germany too.

I wouldn't say my ISP is semi-competent, quite the contrary actually. Lazy
on that issue at most. After all, the ISP only gets sessions from the L2TP
tunnel, with no distcintion if the client is using PPPoE, PPTP or PPPoA as
a transport to the BAS.

IMO, it's not really the ISP's fault, nor it is the telephony opertor's.
The flaw here is that PPPoE is not the only protocol used, and that the
ISP doesn't see the PPPoE sessions. So yes, it is a flaw in the design of
PPPoE in the sense that it cannot work peacefully with other PPP
transports.

How about the attached patch?

-- 
Quentin Garnier - cube@cubidou.net
"Feels like I'm fiddling while Rome is burning down.
Should I lay my fiddle down and take a rifle from the ground ?"
Leigh Nash/Sixpence None The Richer, Paralyzed, Divine Discontents, 2002.

--Multipart_Sun__3_Aug_2003_15:07:30_+0200_08222a00
Content-Type: text/plain;
 name="diff"
Content-Disposition: attachment;
 filename="diff"
Content-Transfer-Encoding: 7bit

Index: share/man/man4/pppoe.4
===================================================================
RCS file: /cvsroot/src/share/man/man4/pppoe.4,v
retrieving revision 1.24
diff -u -r1.24 pppoe.4
--- share/man/man4/pppoe.4	2003/07/04 12:54:14	1.24
+++ share/man/man4/pppoe.4	2003/08/03 12:53:08
@@ -288,6 +288,36 @@
 packet (request to terminate the session).
 The peer will immediately disconnect
 the orphaned session and allow a new one to be established.
+.Pp
+Under certain circumstances, depending on the
+.Nm PPPoE
+modem, the ISP and the telephony operator, the MTU of the link on the ISP
+side will be of 1500.
+If the telephony operator relays the packet, your modem transmits it and
+you network card is able to receive the frame, you can have an effective
+MRU of 1500 bytes, thus avoiding all MTU-related issues of
+.Nm PPPoE .
+The MSS clamping option, which is effective only for TCP connection, is
+then not needed anymore.
+.Pp
+However, this is a
+.Em violation
+of the standard and must only be seen as a convenience, not as a solution
+to the issue.
+.Pp
+Adding
+.Pp
+.Nm options
+.Ar PPPOE_ACCEPT_LARGE_FRAMES
+.Pp
+to your kernel config file will make NetBSD accept and process unusually
+large
+.Nm PPPoE
+frames, but beware that the network card also has to able to actually
+receive such frames, which is not always the case.
+For example, by default, the DP83815 chip
+.Xr (sip 4 )
+cuts frames that are longer than 1518 bytes.
 .Sh SEE ALSO
 .Xr ifwatchd 8 ,
 .Xr pppoectl 8
Index: sys/conf/files
===================================================================
RCS file: /cvsroot/src/sys/conf/files,v
retrieving revision 1.624
diff -u -r1.624 files
--- sys/conf/files	2003/07/28 21:28:24	1.624
+++ sys/conf/files	2003/08/03 12:53:10
@@ -964,6 +964,7 @@
 defpseudo sl:		ifnet
 defpseudo ppp:		ifnet, bpf_filter
 defpseudo pppoe:	ifnet, ether, sppp
+defflag	opt_pppoe.h	PPPOE_ACCEPT_LARGE_FRAMES
 defpseudo sppp:		ifnet
 defpseudo tun:		ifnet
 defpseudo vlan:		ifnet, ether
Index: sys/net/if_ether.h
===================================================================
RCS file: /cvsroot/src/sys/net/if_ether.h,v
retrieving revision 1.33
diff -u -r1.33 if_ether.h
--- sys/net/if_ether.h	2003/06/26 08:22:06	1.33
+++ sys/net/if_ether.h	2003/08/03 12:53:11
@@ -41,6 +41,7 @@
 #ifdef _KERNEL
 #ifdef _KERNEL_OPT
 #include "opt_mbuftrace.h"
+#include "opt_pppoe.h"
 #endif
 #include <sys/mbuf.h>
 #endif
@@ -60,6 +61,9 @@
  * Some Ethernet extensions.
  */
 #define	ETHER_VLAN_ENCAP_LEN 4	/* length of 802.1Q VLAN encapsulation */
+#ifdef PPPOE_ACCEPT_LARGE_FRAMES
+#define	ETHER_PPPOE_ENCAP_LEN 8
+#endif
 
 /*
  * Ethernet address - 6 octets
@@ -90,10 +94,18 @@
  * Compute the maximum frame size based on ethertype (i.e. possible
  * encapsulation) and whether or not an FCS is present.
  */
+#ifdef PPPOE_ACCEPT_LARGE_FRAMES
 #define	ETHER_MAX_FRAME(ifp, etype, hasfcs)				\
 	((ifp)->if_mtu + ETHER_HDR_LEN +				\
 	 ((hasfcs) ? ETHER_CRC_LEN : 0) +				\
+	 (((etype) == ETHERTYPE_VLAN) ? ETHER_VLAN_ENCAP_LEN : 0) +	\
+	 (((etype) == ETHERTYPE_PPPOE) ? ETHER_PPPOE_ENCAP_LEN : 0))
+#else
+#define ETHER_MAX_FRAME(ifp, etype, hasfcs)				\
+	((ifp)->if_mtu + ETHER_HDR_LEN +				\
+	 ((hasfcs) ? ETHER_CRC_LEN : 0) +				\
 	 (((etype) == ETHERTYPE_VLAN) ? ETHER_VLAN_ENCAP_LEN : 0))
+#endif
 
 /*
  * Ethernet CRC32 polynomials (big- and little-endian verions).

--Multipart_Sun__3_Aug_2003_15:07:30_+0200_08222a00--