Le Mon, 4 Aug 2003 22:41:52 +0200
Manuel Bouyer a ecrit :
> On Mon, Aug 04, 2003 at 10:30:09PM +0200, Quentin Garnier wrote:
> > Le Mon, 4 Aug 2003 12:51:42 +0200
> > Manuel Bouyer a ecrit :
> > > > > > But anyway, we don't have to check if the NIC can receive the
> > > > > > frame at that time, because obviously it could.
> > > > > 
> > > > > ec_capenable ETHERCAP_VLAN_MTU is there to have the driver allow
> > > > > the nic to receive such frames. 
> > > > 
> > > > I'll do that then.
> > > 
> > > Thanks.
> > 
> > I tested this with sip(4). I added the necessary bit to tlp(4), but I
> > didn't have the time to test it yet. I'll have a closer look at all
> > the other cards I have here (ne, rtk, ep, iy). None of them declare
> > the ETHERCAP_VLAN_MTU. My guess is that there is no documentation
> > and/or no way to disallow or permit reception of large frames.
> 
> ne use the dp8390.c code, which declares it.

Ah, right.

> For rtk, I guess nobody looked at it yet.

I haven't seen anything about large frames and erroneous frames in the
rtk8139 documentation, but I admit I've read it quite quickly.

[...]
> If you enable ETHERCAP_PPPOE_MTU, then you probably want to change the
> MTU of pppoe from 1492 to 1500.

No, I don't. What ETHERCAP_PPPOE_MTU provides is an effective *MRU* of
1500. I won't change the MTU of the PPPoE interface since the MRU that is
advertised by the peer (the BAS) is 1492 (thus following the standard).

It is not guaranteed that the BAS will do what it does for large frames in
the other way, and I would have to make the sppp code blatantly break the
standard.

As I said before, the goal of this hack is not to provide a MTU of 1500,
but to take advantage of an otherwise desperate situation.

-- 
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.