cvs commit: src/sys/net if_vlan.c
cejkar at fit.vutbr.cz
Mon Jul 7 10:09:05 PDT 2003
Bill Paul wrote (2003/07/05):
> Modified files:
> sys/net if_vlan.c
> - In vlan_input(), we have to extract the 16-bit tag value from the
> received frame and use it to figure out which vlan interface gets
> the frame.
VLAN is determined just by 12-bit vlan identifier (VID) in the 16-bit tag
(802.1q, page 68, 22.214.171.124 VID format). The others are 3 priority bits
and 1 canonical format identifier bit (CFI), which all have to be masked
before VLAN identification.
> for (ifv = LIST_FIRST(&ifv_list); ifv != NULL;
> ifv = LIST_NEXT(ifv, ifv_list))
> if (ifp == ifv->ifv_p && tag == ifv->ifv_tag)
It seems that variable name "tag" is confusing and it should
be renamed to "vid", because you have to compare VIDs, not tags.
> In the case where the interface supports hardware VLAN tag
> extraction and calls VLAN_INPUT_TAG(), we do this:
> tag = *(u_int*)(mtag+1);
> But in the software emulation case, we do this
> tag = EVL_VLANOFTAG(ntohs(evl->evl_tag));
However for VLAN identification, you have to extract VID from tag
vid = EVL_VLANOFTAG(tag);
and compare VIDs.
> To see how this can be a problem, do something like
> ifconfig vlan0 vlan 12345 vlandev foo0 and observe the results.
12345 is an illegal VLAN number, the maximum allowed number is 4094
(or 4095, but it is reserved). The bigger problem is with arrived
packets with non-zero priority, where VLAN support in FreeBSD is
still broken - in the past just for cards with hardware VLAN support
(excluding em - see below), but now for almost all cards.
> I'm not quite sure what the right thing is to do here.
It seems that you had to miss my mail from February 27 2003 to you.
Here is relevant part of it (and please see mentioned PRs too):
Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpreg.h if_fxpvar.h
Bill Paul wrote (2003/02/26):
> Modified files:
> sys/dev/fxp if_fxp.c if_fxpreg.h if_fxpvar.h
> This chip has hardware VLAN support as well. I hope to enable
> support for this eventually.
Hello, are you really interested in hardware VLAN support? If so,
please look at kern/46405 - it seems that drivers with implemented
hardware VLAN support does not work correctly if there is packet
priority != 0. It has been fixed in em driver by Prafulla Deuskar
(kern/45907 and kern/46028), but according to sources it seems that
other drivers with hardware VLAN support still does not work.
There is function vlan_input_tag() with parameter "t" and I think that
it is expected to be "VLAN Tag" containing ID and Priority and drivers
do it in this way (except for em driver, which masks VLAN ID from VLAN
Tag thanks to fix from Prafulla). However, we think that it should be
fixed directly in vlan_input_tag() function and this function should
mask VLAN ID from VLAN Tag inside itself - but it does not do it.
Rudolf Cejka <cejkar at fit.vutbr.cz> http://www.fit.vutbr.cz/~cejkar
Brno University of Technology, Faculty of Information Technology
Bozetechova 2, 612 66 Brno, Czech Republic
More information about the cvs-all