On Fri, Jul 25, 2008 at 05:35:03PM +0200, Martin Husemann wrote: > On Fri, Jul 25, 2008 at 03:15:03PM +0000, Christos Zoulas wrote: > > Modified Files: > > src/sys/net: if_ether.h > > > > Log Message: > > PR/39203: Paul Ripke: PPPoE issues with broken MTU/MRU implementations > > Allow larger frames for systems that don't negotiate MTU/MRU properly. > > I don't object this change, but it does look kinda wrong. > > I wondered if the whole ETHER_MAX_FRAME() check in ether_input is not a bogus > workaround for some old (maybe even long fixed) bugs in chipset drivers. > Shouldn't we leave the decision "I did receive this frame OK" to the driver > (modulo fcs if not checked in hardware)? > > If we did receive the frame ok, why should we drop it? The NIC might have simply truncated it. I'm pretty sure I've seen it happen in that context, without specific notification to the driver. It might not be worse to let a truncated frame through the upper layers, but the point is that you shouldn't have received such a frame in the first place. My initial implementation was smarter because it let the NIC driver confirm it is able and willing to receive such frames. -- Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling" KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Attachment:
pgpjcBq1GB3G3.pgp
Description: PGP signature