<<On Sat, 27 Feb 1999 23:37:10 -0500 (EST), Bill Paul
<wp...@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
woll...@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 majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
