Hi Patrik

I have the source for network driver (devn-ixp2351) and know it reasonably
well. I checked today and it does not receive any devctl checking for the
MTU size...hmm..maybe I should check again.

However, leaving that aside, do you think it is correct for maximum MTU to
be 1496 if 802.1Q is enabled and this is valid for most systems?

In that case we need to consider updating requirements for our system.

VG

On Wed, Sep 29, 2010 at 6:56 PM, Patrik Lahti <community-noreply@qnx.com>wrote:

> Then the driver or the medium itself don't allow frames larger than 1514
> bytes. With the regular Ethernet header there's only 1500 bytes of
> payload left, with the and Q-header there is simply not more than 1496
> bytes left...
>
> I've never seen the devn-ixp2351 driver. It might be hard coded to 1500
> bytes MTU. You'd have to ask whoever wrote it, maybe in the driver forum?
>
> PS. The article isn't QNX product documentation, it's on a website which
> isn't controlled nor endorsed by QNX.
>
> /P
>
> On 10-09-28 11:46 PM, Vineet Garg wrote:
> > hi patrik
> >
> > in my case system is not allowing to set mtu of parent interface to more
> > than 1500 bytes thus leading to problems as even in article pointed to by
> > you.
> >
> > To be compatible with other IEEE 802.1Q devices, the *vlan* interface
> sup-
> > ports a 1500 byte MTU, which means that the parent interface will have to
> > handle packets that are 4 bytes larger than the original Ethernet stan-
> > dard
> >
> >
> > Is this behavior dependent on underlying network driver or is a
> > property of operating system? I have devn-ixp2351 as network driver in
> > my case.
> >
> > Since article provides a list of network drivers that support
> > increased mtu size, does it mean that ifconfig sends a devctl to
> > network driver to check if given mtu value is supported or not? In
> > that case I can modify my network driver to accept even higher mtu.
> >
> >
> >
> >
> > On Wed, Sep 29, 2010 at 1:18 AM, Patrik Lahti
> > <community-noreply@qnx.com>wrote:
> >
> >  > This is expected and not unique to QNX.
> >  >
> >  > The 802.1Q encapsulation requires four more bytes which are then not
> >  > available for payload (IP or whatever).
> >  >
> >  > To change the MTU of the VLAN interface I believe you'll have to set
> the
> >  > parent interface's MTU to be bigger.
> >  >
> >  > See e.g. http://netbsd.gw.com/cgi-bin/man-cgi?vlan+4
> >  >
> >  > /P
> >  >
> >  > On 10-09-28 02:17 PM, Vineet Garg wrote:
> >  > > Hi
> >  > >
> >  > > I noticed that VLAN interface derives its mtu attribute from the
> parent
> >  > > interface (say en0) but uses a value that is 4 less than that of
> parent
> >  > > interface.
> >  > > So, if mtu for en0 is 1500
> >  > > vlanX on en0 will have mtu 1496.
> >  > >
> >  > > Also, stack does not allow user to set the mtu value at vlanX to be
> > more
> >  > > than 1496 so that difference of 4 byte always stays. Neither does
> stack
> >  > > allow mtu of en0 to be more than 1500.
> >  > >
> >  > > This causes issues when an IP peer with MTU set to 1500 sends
> > fragmented
> >  > > packets to this interface vlanX.
> >  > >
> >  > > Theoratically, I do not understand the reasoning for having this
> >  > > difference of 4 bytes. MTU at IP layer (1500 for ethernet) is IP
> header
> >  > > + IP payload....