Date: Wed, 30 Sep 1998 18:05:10 -0700 From: Mike Smith <mike@smith.net.au> To: hart@dotat.com Cc: freebsd-net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: 802.1Q VLAN support Message-ID: <199810010105.SAA04638@dingo.cdrom.com> In-Reply-To: Your message of "Thu, 01 Oct 1998 00:29:32 %2B0930." <199809301459.AAA15771@at.dotat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I'm developing some single board computer applications that require > 802.1Q vlan support (of the simplest kind) and in trawling through > these list archives I found mention of if_vlan.c ...: > > /* > * ... > * ... > * ... > * > * $Id: if_vlan.c,v 1.3 1998/08/23 03:07:10 wollman Exp $ > */ > > /* > * if_vlan.c - pseudo-device driver for IEEE 802.1Q virtual LANs. > * Might be extended some day to also handle IEEE 802.1p priority > * tagging. This is sort of sneaky in the implementation, since > * we need to pretend to be enough of an Ethernet implementation > * to make arp work. The way we do this is by telling everyone > * that we are an Ethernet, and then catch the packets that > * ether_output() left on our output queue queue when it calls > * if_start(), rewrite them for use by the real outgoing interface, > * and ask it to send them. > */ > > This is about all I can find in the kernel-current source tree that > relates to 802.1Q - there's little or no documentation I can find > that tells me how to start using this code...(god help me if it's > there and I havn't looked hard enough :[) 'pseudo-device vlan X' will get it into the kernel. However it seems that there's a missing userland application required for the 'SIOC[GS]ETVLAN' ioctls. You ought to ask Garrett about this. > PS - my work with 802.1Q has found that, despite the current draft > spec suggesting that each vendor should decide on their own what > to do about the problem of having a larger frame size due to the > extra 4 byte VLAN header, most vendors have opted to support an > increas by four bytes in the frame size... > > It should be noted that if FreeBSD is going to support this in > any sensible manner, it should start including an option for > changing ETHER_MAX_LEN in the kernel, either real time or at > compile time... Ick. How does this impact hardware with frame size limitations? You'll need to differentiate between "how big a frame is allowed to be" and "how big we will normally make a frame". Diffs would be good. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810010105.SAA04638>