This is a multi-part message in MIME format.

--Multipart_Sat__2_Aug_2003_23:27:55_+0200_0847b400
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

With certain hardware chains (like mine), you can receive PPPoE frames
containing 1500 bytes of actual data.

Unfortunately, those frames (up to 1522 bytes on wire) are (not silently)
dropped by NetBSD, although it can be useful to receive them in order to
avoid MTU-related issues that happen whenever the ISP side of the PPP
connection has a MTU of 1500.

Thus, for this patch to be welcomed, there are three conditions to meet:

 o Your ISP is lazy and leaves the default MTU of 1500 on the
   L2TP interface,

 o your modem allows transmission of large frames,

 o your NIC transmits complete large frames to the upper layer.

Note that this not always the case: I had to add a line in the attach code
to allow this on the sip interfaces of my Soekris box, the default
behaviour of the DP83815 being to cut frames bigger than 1518 bytes.

On my current gateway, running netbsd-1-5, large frames are of course
dropped by NetBSD, but rp-pppoe gets them through bpf, and with a little
hack, can actually use them. Thus I've been happily receiving 1522 bytes
frames for about a year (with a cheap NIC that doesn't seem to care much
about frame size apparently).

First I thought of also adding an option to *send* large frames (thus
breaking the RFC), but the BAS follows the standard and correctly
advertise a MRU of 1492, so it would have been really dirty.

The fundamental issue here, I guess, is that the BAS doesn't really know
what to do with a large frame coming from the LNS, and prefers
transmitting it since it has no practical way of reporting the error to
the upper layer. The following patch just lets the system take advantage
of this situation.

The patch is very small and is just meant to be comfortable with PPPoE.
The real fix is in the ISP's hands. And before I get some remarks on that
issue, yes, I've repeatedly ask for that change. The only answer I got was
'it's a flaw in the design of PPPoE'.

Of course, I don't know how PPPoE is handled anywhere but in France, maybe
telephony operators and ISPs work differently out there...

Comments?

-- 
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_Sat__2_Aug_2003_23:27:55_+0200_0847b400
Content-Type: text/plain;
 name="diff"
Content-Disposition: attachment;
 filename="diff"
Content-Transfer-Encoding: quoted-printable

Index: if_ether.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/src/sys/net/if_ether.h,v
retrieving revision 1.33
diff -u -r1.33 if_ether.h
--- if_ether.h	2003/06/26 08:22:06	1.33
+++ if_ether.h	2003/08/02 21:18:57
@@ -60,6 +60,7 @@
  * Some Ethernet extensions.
  */
 #define	ETHER_VLAN_ENCAP_LEN 4	/* length of 802.1Q VLAN encapsulation */
+#define	ETHER_PPPOE_ENCAP_LEN 8
=20
 /*
  * Ethernet address - 6 octets
@@ -93,7 +94,8 @@
 #define	ETHER_MAX_FRAME(ifp, etype, hasfcs)				\
 	((ifp)->if_mtu + ETHER_HDR_LEN +				\
 	 ((hasfcs) ? ETHER_CRC_LEN : 0) +				\
-	 (((etype) =3D=3D ETHERTYPE_VLAN) ? ETHER_VLAN_ENCAP_LEN : 0))
+	 (((etype) =3D=3D ETHERTYPE_VLAN) ? ETHER_VLAN_ENCAP_LEN : 0) +	\
+	 (((etype) =3D=3D ETHERTYPE_PPPOE) ? ETHER_PPPOE_ENCAP_LEN : 0))
=20
 /*
  * Ethernet CRC32 polynomials (big- and little-endian verions).

--Multipart_Sat__2_Aug_2003_23:27:55_+0200_0847b400--