This prevent a variety of fun panics, and therefore fixes PR 12932, PR 17561,
and PR 18376...
XXX
...however this is most definitely a hack. The real problem here is that there
is no callback to notify a "client" interface like vlan when a "parent"
interface's status changes, and therefore the vlan interface is always
IFF_RUNNING. This allows packets to be queued on vlan interface at any time.
We can't simply leave the packets on the vlan interface, either, because there
is no callback to dequeue them. And last, since it's always IFF_RUNNING, if
we just *toss* the packets, we lose gratuitous ARPs and DAD packets.
"This needs work," but at least it no longer bleeds.
the tag before forwarding the packet, make sure the packet+tag is at least
68 bytes long.
This is necessary because our parent will only pad to 64 bytes (ETHER_MIN_LEN)
and some switches will not pad by themselves after deleting a tag.
(IFF_UP | IFF_BROADCAST | IFF_RUNNING | IFF_ALLMULTI | IFF_SIMPLEX)
Also, put the ifp->if_opackets++ at the rigth place so that the counter is
incremented even when the parent is OACTIVE.
Fix a bug in vlan_input where the ethernet src and dst addrs would not be
correct because we only memmove() only ifv->ifv_encaplen instead of
sizeof(struct ether_header).
- Add a macro to compute the max frame length based on Ethertype
and presence of FCS, and use it to validate the packet size
in ether_input().
- Add capabilites to struct ethercom, and allow hardware drivers
to specify that they can handle the larger hardware MTU that
VLANs require in order to strictly conform to 802.1Q.
- Make ether_ifdetach() clear out the link address and free all of
the Ethernet multicast structures.
Also, rearrange the VLAN driver itself in preparation to supporting
other hardware types, including FDDI (which has 802.1Q VLAN capability).
mycroft