cvs commit: src/sys/net if_vlan.c

[Sam Leffler]

>> <<On Sat, 5 Jul 2003 20:24:25 -0700 (PDT), Bill Paul <wpaul at FreeBSD.org>
>> said:
>>
>> >     I'm not quite sure what the right thing is to do here. Neither the
>> >     vlan(4) nor ifconfig(8) man pages suggest which way to go. For now,
>> >     I've removed this use of EVL_VLANOFTAG() so that the tag will match
>> >     correctly in all cases. I will not get upset if somebody makes a
>> >     compelling argument for using EVL_VLANOFTAG() everywhere instead,
>> >     as long as the use is consistent.
>>
>> VLAN tags have only 12 bits.  Anything else is part of the 802.1p
>> encapsulation header (either the priority or the ``this packet was
>> translated from Token Ring'' bit).
>>
>> -GAWollman
>>
>
> Ok, based on this (and what others have said), it looks like the
> correct behavior is to mask off all but the VLAN ID bits in all cases
> in vlan_input(). This is easy enough to do. The only issue then is
> what to do about the fact that the user is currently allowed to set
> the non-VLAN ID bits with ifconfig(8). We can do one of two things:
>
> 1) Change vlan_input() to apply EVL_VLANOFTAG() to all incoming tags
>    (in both hardware and non-hardware tagging cases) and change the
>    vlan_ioctl() function to only accept vlan tags from 0 to 4095
>    and return EINVAL if the caller tries to set any of the other
>    bits. (Prevent user from shooting self in foot.)
>
> 2) Let the user set any bits, but always mask off the non-VLAN ID
>    bits in vlan_input(), i.e.:
>
> --- if_vlan.c.orig	Sat Jul  5 19:53:51 2003
> +++ if_vlan.c	Mon Jul  7 10:44:07 2003
> @@ -429,7 +429,8 @@
>
>  	for (ifv = LIST_FIRST(&ifv_list); ifv != NULL;
>  	    ifv = LIST_NEXT(ifv, ifv_list))
> -		if (ifp == ifv->ifv_p && tag == ifv->ifv_tag)
> +		if (ifp == ifv->ifv_p && EVL_VLANOFTAG(tag) ==
> +		    EVL_VLANOFTAG(ifv->ifv_tag))
>  			break;
>
>  	if (ifv == NULL || (ifv->ifv_if.if_flags & IFF_UP) == 0) {
>
> I am leaning towards option 1). Am I sane or not?

Go with 1).  I agree that users should be dealing only with the 12-bit id, 
not the priority bits.  But this still leaves the issue of honoring the 
priority bits on reception.

	Sam