extracted from received frames, both in the IFCAP_VLAN_HWTAGGING case
and not. (Some drivers may already do this masking internally, but
doing it here doesn't hurt and insures consistency.)
- In vlan_ioctl(), don't let the user set a VLAN ID value with anything
besides the VLID bits set, otherwise we will have trouble matching
an interface in vlan_input() later.
PR: kern/46405
drivers "tag packets" with an m_tag and the input packet handling recognizes
such packets and does the right thing
o track the number of active vlans on an interface; this lets lots of places
only do vlan-specific processing when needed
o track changes to ether_ifdetach/ether_ifattach
o track bpf changes
o eliminate the use of M_PROTO1 for communicating to drivers about tagged
packets
o eliminate the use of IFF_LINK0 for drivers communicating to the vlan code
that they support h/w tagging; replaced by explicit interface capabilities
o add ifnet capabilities for h/w tagging and support of "large mtu's"
o use new interface capabilities to auto-configure use of large mtu's and h/w
tagging
o add support for proper handling of promiscuous mode
o document driver/vlan communication conventions
Reviewed by: many
Approved by: re
unit allocation with a bitmap in the generic layer. This
allows us to get rid of the duplicated rman code in every
clonable interface.
Reviewed by: brooks
Approved by: phk
is an application space macro and the applications are supposed to be free
to use it as they please (but cannot). This is consistant with the other
BSD's who made this change quite some time ago. More commits to come.
are configured, and/or associated with a parent device. If you
receive a frame for a VLAN that's not in the list, you walk off
the end of the list. Boom.
Submitted by: C. Stephen Gunn <csg@waterspout.com>
PR: 15291
work reliably yet (I've had panics), but it does seem to occasionally
be able to transmit and receive syntactically-correct packets.
Also fixes one of if_ethersubr.c's legion style bugs, and removes
the hostcache code from standard kernels---the code that depends on it
is not going to happen any time soon, I'm afraid.
