On Wed, Dec 12, 2007 at 03:41:54PM -0500, Greg Troxel wrote:
> Manuel Bouyer <bouyer@antioche.eu.org> writes:
> 
> > On Tue, Dec 11, 2007 at 10:47:16PM -0600, Chris Brookes wrote:
> >> On 11/12/2007, Manuel Bouyer <bouyer@antioche.eu.org> wrote:
> >> 
> >> > Yes, it's the way to go
> >> 
> >> Sure enough it works  as planned. I'm very happy with the setup.
> >> 
> >> > From a quick look at current, it looks like the MTU is hardwired in
> >> > the vr(4) driver. But if you have a patch from openbsd, it shouldn't
> >> > be hard to get it working.
> >> 
> >> 
> >> I appeared to just need
> >> 
> >> sc->vr_ec.ec_capabilities = ETHERCAP_VLAN_MTU;
> >> tmp = ifp->if_mtu + ETHER_HDR_LEN + ETHER_CRC_LEN;
> >> tmp += ETHER_VLAN_ENCAP_LEN;
> >> ifp->if_mtu = tmp;
> >> 
> >> And it seems to work well. I hesitate to submit a patch because I have
> >> very little confidence in what I've done, particularly since I've only
> >> had it running for 10 minutes
> >
> > please send a PR with patch when you have tested it a bit more. Especially,
> > test (with e.g. ping -s) that you can send 1500-bytes packets.
> 
> Why is it correct to add ETHER_HDR_LEN and ETHER_CRC_LEN?  I would say
> that comments arguing that the logic is correct are needed too (but
> maybe I just don't get something).

Right, I think adding ETHER_VLAN_ENCAP_LEN would be enough.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--