Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Mar 1999 11:33:06 -0500 (EST)
From:      Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To:        Bill Paul <wpaul@skynet.ctr.columbia.edu>
Cc:        current@FreeBSD.ORG
Subject:   Request for review: changes to if_vlan.c
Message-ID:  <199903011633.LAA16808@khavrinen.lcs.mit.edu>
In-Reply-To: <199902280437.XAA26179@skynet.ctr.columbia.edu>
References:  <199902280437.XAA26179@skynet.ctr.columbia.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
<<On Sat, 27 Feb 1999 23:37:10 -0500 (EST), Bill Paul <wpaul@skynet.ctr.columbia.edu> said:

> Interested persons should review the diffs and pipe up if they have
> some passionate argument argument against them.

Patches look mostly fine.

> Also, I should point out that while if_vlan provides the necessary
> kernel hackery to implement VLANs, there isn't any user space utility
> for configuring vlan interfaces (ifconfig doesn't seem to have any
> vlan-specific code that I could see, and is no vlanconfig). 

I stopped development on vlan(4) when the switch we had that spoke
802.1Q was returned to the vendor at the end of our demo period.  I
have 28 on order right now, and should resume work on the driver after
I get those switches deployed.  For interfaces like yours, I would
have preferred a subinterface mechanism, but I never had the time to
implement that.  Care to implement GVRP while you're at it?

> There also is no vlan(4) man page.

See above.

> otherwise I'm going to take it upon myself to hack up ifconfig and
> write the man pages myself.

I believe ifconfig is the wrong program for the task.  There should be
a separate vlanconfig program.  (I wrote one, but it's on my
laptop where I can't conveniently get to it right now.)

There are a couple of areas where vlan(4) needs to get some help from
the underlying driver:

- Promiscuous mode doesn't work at all.  It ought to be possible to
put just a specific VLAN into promiscuous mode, without affecting all
the others.  This probably involves repeating all of the BPF
does-this-packet-look-like-mine? gluck from the physical interface
drivers.

- Multicast is similarly broken (and a more serious weakness).  There
needs to be a mechanism to pass multicast group membership down to the
underlying driver.  It may also be necessary to do duplicate
suppression, which is a real challenge.

> +  * XXX It's incorrect to assume that we must always kludge up
> +  * headers on the physical device's behalf: some devices support
> +  * VLAN tag insersion and extraction in firmware.

My theory, as explained above, was that such devices would implement
subinterfaces.

> ! 		 * If the LINK1 flag is set, it means the underlying interface
> ! 		 * can do VLAN tag insertion itself and doesn't require us to
> ! 	 	 * create a special header for it. In this case, we just pass

Are we certain that all drivers are now doing if_media and no longer
using IFF_LINK1 for that purpose?

>   	/*
>   	 * Set up our ``Ethernet address'' to reflect the underlying
> ! 	 * physical interface's.
>   	 */
>   	ifa1 = ifnet_addrs[ifv->ifv_if.if_index - 1];
>   	ifa2 = ifnet_addrs[p->if_index - 1];
> --- 315,321 ----
  
>   	/*
>   	 * Set up our ``Ethernet address'' to reflect the underlying
> ! 	 * physical interfaces.
>   	 */

Grammar fault -- core dumped.

(The wording was correct as it was.)

>   		 * Set the interface MTU.
> + 		 * This is bogus. The underlying interface might support
> + 	 	 * jumbo frames.
>   		 */
>   		if (ifr->ifr_mtu > ETHERMTU) {
>   			error = EINVAL;

I belong to the religion which as that if the interface is doing
``jumbo frames'' than it's not doing ``Ethernet''.  There are all
sorts of crocks which were perpretrated to allow bridging of FDDI and
Ethernet, and I have no intention of supporting the same crocks here.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
wollman@lcs.mit.edu  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad Irschick


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903011633.LAA16808>