From owner-freebsd-current Mon Mar 1 8:33:37 1999 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id C0B6B15247 for ; Mon, 1 Mar 1999 08:33:35 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id LAA16808; Mon, 1 Mar 1999 11:33:06 -0500 (EST) (envelope-from wollman) Date: Mon, 1 Mar 1999 11:33:06 -0500 (EST) From: Garrett Wollman Message-Id: <199903011633.LAA16808@khavrinen.lcs.mit.edu> To: Bill Paul Cc: current@FreeBSD.ORG Subject: Request for review: changes to if_vlan.c In-Reply-To: <199902280437.XAA26179@skynet.ctr.columbia.edu> References: <199902280437.XAA26179@skynet.ctr.columbia.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < 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