This file should be prepended to each time a release is made.
Date: March 24, 2002
Version: 1.6
Kernel Version: 2.4.14+
Changes: Removed 2.4 kernel patch from VLAN distribution..it's now in the
standard linux kernel. Other updates include vconfig changes
to fix some compile problems, and to enable cross-compiling to
ARM (this assumes you are using the Intrinsyc cross-compiler in
it's standard location).
Date: Oct 20, 2001
Version: 1.5
Kernel Version: 2.4.12-pre5
Changes:
Mostly added other peoples fixes and patches (thanks folks!)
Finally fixed mc-list leakage (Ard van Breemen)
Flush mc-list at vlan-destory (Ard van Breemen)
Add vconfig man page to distribution (Ard van Breemen)
Fix problem with /proc and renaming VLAN devices (af AT devcon D.T net)
Add relatively large change by Nick Eggelston that makes VLAN
devices more transparent to tools like tcpdump and other raw
packet snoopers. This will only be enabled when the REORDER_HDR
flag is set.
Date: August 16, 2001
Version: 1.4
Kernel Version: 2.4.9-pre4
Status: Should be stable, but a decent amount of rework went into
this one...
Changes:
Code should no longer require /proc interface in order to
get at the IOCTLs. The IOCTLs are now tied to sockets.
When using modules, it may auto-load now, too...
Fixed format string error in proc fs display.
Fixed crash bug relating to memory allocation with locks
held (we now use GF_ATOMIC).
hard_start_xmit will now grow the packet header if there
is not enough headroom. This may fix an MPLS-over-VLAN problem,
though the real solution is to make MPLS allocate
more headroom anyway...
vconfig was changed to use the new IOCTL API, and the old
vconfig WILL NOT WORK with this or any newer patches...
Date: August 5, 2001
Version: 1.0.3
Kernel Version: 2.4.7
Status: Should be stable, but a decent amount of rework went into
this one...
Changes:
Re-worked code to comply with linux network code gurus'
wishes. This included several boundary case fixes, including
some that could crash your kernel.
The default naming scheme is eth0.5 now, for VID == 5 on
eth0. Use vconfig to change the naming scheme if you want.
There were *NO* changes to the 2.2 series patch, and there
probably won't be any more changes to it, ever!
Date: April 16, 2001
Version: 1.0.1
Kernel Version: 2.2.18/19, 2.4.3-pre3
Status: Very similar to 1.0.0, should be relatively stable.
Changes:
Incorporated a fix for changing a MAC on a VLAN, it now
correctly sets PACKET_HOST.
Thanks to Martin Bokaemper for this one.
The 2.4 series patch should now compile as a module, thanks
to a tweak from someone who's mail I have lost! Anyway, 3
cheers to the un-named coder!
There were *NO* changes to the 2.2 series patch, though I did
verify that it seems to work fine with the 2.2.19 kernel.
Date: January 14, 2001
Version: 1.0.0
Kernel Version: 2.2.18, 2.4.0
Status: Fairly similar to 0.0.15, should be relatively stable.
Changes:
Really fixed (and tested) MAC change-ability. When you set the
MAC address on a VLAN, it will also attempt to set the underlying
device to PROMISCious mode (otherwise, the VLAN will not
receive any packets.)
Hashed-device lookup is disabled by default because some people
had trouble with the 'lo' device. Please feel free to re-enable by
editing the line in net/core/dev.
(search for #define BEN_FAST_DEV_LOOKUP).
vconfig should warn when creating VLAN 1, because that VLAN is
not compatible with many switches.
Date: December 31, 2000
Version: 0.0.15
Kernel Version: 2.2.18, 2.4.prerelease
Status: This one is pretty fresh..beware, especially the 2.4 patch.
Changes:
Merged most of Matti Aarnio's patches. This means no significant patch
to eth.c now, and will help port VLANs to non-ethernet devices
(ie ppp, TokenRing??).
Setting the MAC address should work now..I think it was broken before.
Miscellaneous code re-organization to make patches to existing files smaller.
Date: October 26, 2000
Version: 0.0.14
Kernel Version: 2.2.17, 2.4.pre9
Status: Seems stable.
Changes:
Removed vlan-space-per-machine, so vlan-space-per-NIC is mandatory now.
DHCP might work now, as I've added support for encapsulating regular ethernet
frames if they are sent to the vlan driver.
Fixed up the name/index hashing stuff to handle changing the name on a device.
Took out default VID & default priority, as their usefullness was in question,
and the code was broken anyway.
Date: October 11, 2000
Version: 0.0.13
Kernel Version: 2.2.17, 2.4.pre9
Status: BUSTED!! Don't use it.
Changes:
Added support for MULTICAST to the VLAN devices. Thanks to
Gleb & Co for most of that code.
Added the ability to set the MAC address on the VLAN. For now,
you'll either need to set your Ethernet NIC into PROMISC mode, or
maybe figure out some multi-cast ethernet address to set on the
NIC. This has not been tested well at all.
Added a hashed device-name lookup scheme. This greatly speeds
up ifconfig -a. I was able to run an ifconfig -a in 20 seconds on a
Celeron 500, with 4000 vlan devices configured!!
Added vlan_test.pl to help me find dumb bugs. Feel free to make this
much more powerful, and send the code back to me!
vconfig.c has been converted to C code now, instead of C++.
Thanks to MATHIEU.
Significantly cleaned up the code w/out decreasing any useful
functionality, I believe.
Removed the dhcp stuff from the VLAN distribution.
Date: August 27, 2000
Version: 0.0.12
Kernel Version: 2.2.16, 2.4.pre7
Status: This one turned out pretty stable, no known bugs.
Changes:
Added ability to re-order the VLAN packet so that it looks
like a real ethernet packet for the ingress pathway. This
should help DHCP and other programs that insist on reading
the raw buffer and then make assumptions about byte offsets.
I don't have a good way to test this fully, so consider it
experimental :) This behavior can be changed at run-time,
and is set on a per-VLAN basis. The default is NOT to reorder
the header, which has been the only behavior up untill this
point. The vconfig program can set/clear the flag, by using
a VLAN IOCTL. You can read the flag's value from the
/proc/net/vlan/vlan* files.
You can also set a default priority on a NON-VLAN device.
This priority will only be used when the default_VID for the
device is set as well. This priority won't be mapped anywhere,
just copied straight into the skb->priority. It is a uint16.
The 2.3 patch is now the 2.4 patch, and it has been tested
against 2.4.pre7.
Date: April 23, 2000
Version: 0.0.11
Kernel Version: 2.2.13 & 2.2.14, 2.3.99
Status: As of August 27, this seems like a very stable patch.
Changes:
Added real support for PRIORITY. Through IOCTL calls (see the
vconfig program), you can set explicit ingress and egress mappings
to/from the VLAN QOS bits and the sk_buff->priority field. This
is not tested very well, as I don't know much about how people really
use the priority field... Took out the round-robin aggretation that
went in in rls 0.10, as it was mainly just a hack, and doing link
aggregation at a lower level and then putting VLAN on top of that
virtual device probably makes more sense. The vconfig program
changed to support the new features..here's it's new usage:
Usage: add [interface-name] [vlan_id]
rem [vlan-name]
set_dflt [interface-name] [vlan_id]
add_port [port-name] [vlan_id]
rem_port [port-name] [vlan_id]
set_egress_map [vlan-name] [skb_priority] [vlan_qos]
set_ingress_map [vlan-name] [skb_priority] [vlan_qos]
set_name_type [name-type]
set_bind_mode [bind-type]
* The [interface-name] is the name of the ethernet card that hosts
the VLAN you are talking about.
* The port-name is the name of the physical interface that a VLAN
may be attached to.
* The vlan_id is the identifier (0-4095) of the VLAN you are operating on.
* skb_priority is the priority in the socket buffer (sk_buff).
* vlan_qos is the 3 bit priority in the VLAN header
* name-type: VLAN_PLUS_VID (vlan0005), VLAN_PLUS_VID_NO_PAD (vlan5),
DEV_PLUS_VID (eth0.0005), DEV_PLUS_VID_NO_PAD (eth0.5)
* bind-type: PER_DEVICE # Allows vlan 5 on eth0 and eth1 to be unique.
PER_KERNEL # Forces vlan 5 to be unique across all devices.
The 2.3 patches have been ported foward to 2.3.99, thanks to
Patrick for the vlanproc.c updates!
Date: February 26, 2000
Version: 0.0.10
Kernel Version: 2.2.13 & 2.2.14, 2.3.47
Status: Added several new features in the critical path...beware!
Changes:
Added support for PRIORITY. The way it works is that the lower
3 bits of the skb->priority are set into the PRIORITY field in
the VLAN header. No special handling is done with priority,
but it should be handled by other switches and such. This has
not been tested, but the default case (no priority in the skb)
seems to work at least.
The big change is that you can now aggregate several ethernet
ports in a single VLAN. The packets will be transmitted in a
round robin fashion. In order for this to work, you have
to change the MAC addresses on all cards to the same thing,
and put the cards in promiscious mode (because most drivers don't
__really__ honor the request to set the MAC all the way to
the NIC. This works with two different speed NICs, but I think
it will only be really useful if they are the same speed. Here
is how I set them up in my test environment:
ifdown eth1
ifconfig eth1 hw ether 00:40:05:41:00:5e # This is the MAC of eth0
ifup eth1
ifconfig eth1 promisc
/usr/local/bin/vconfig add eth0 5
/usr/local/bin/vconfig add_port eth1 5
ifconfig vlan0005 192.168.2.1
On my other machine, I have this:
ifdown eth1
ifconfig eth1 hw ether 00:48:54:66:68:68 # This is the MAC of eth0
ifup eth1
ifconfig eth1 promisc
/usr/local/bin/vconfig add eth0 5
/usr/local/bin/vconfig add_port eth1 5
ifconfig vlan0005 192.168.2.3
Note that there are now two patches, one for the 2.2 series,
and one for the 2.3 series.
Date: February 6, 2000
Version: 0.0.9
Kernel Version: 2.2.13 & 2.2.14
Status: Mostly solid. May be issues with adding/removing, but it
works at least most of the time.
Changes: Changed the way vlan names are created: They now have the
VID in the name. You can revert to the old behavior by
changing an #define in the 802_18/vlan.h file. Changed
the destruction process for vlans. Not sure if this fixed the
kernel lock problem I found while adding/removing VLAN devices,
and also hacking with DHCP, but the problem seemed to go away.
Added patch to dhcp to allow it to work with VLANs. However,
I don't grok DHCP as well as might be desired, so use at your
own risk!! Added some debugging code (you have to compile
it in if you need it)
Date: December 22, 1999
Version: 0.0.8
Kernel Version: 2.2.13+
Status: ARP seems to fail in certain cases (but not on my machines.)
Changes: Fixed compile warnings and a linking problem due to #ifdef's.
No major changes in functionality or performance.
Date: December 5, 1999
Version: 0.0.7
Kernel Version: 2.2.13+
Status: ARP seems to fail in certain cases (but not on my machines.)
Several (many?) ethernet drivers can't handle the extra 4 bytes
of VLAN, so the MTU on the network may have to be set to 1496,
or fix the ethernet drivers!!
Changes: Re-wrote the /proc code to never go above 4k buffers. This means
that each port now has it's own file entry. Fixed crash bug with
removing VLAN devices. Byte and pkt counters are now updated correctly,
and are found in the /proc/net/vlan/ file.
Date: October 20, 1999
Version: 0.0.6
Kernel Version: 2.2.10+
Status: ping -f still kills one of my machines, but it takes longer...and I'm
not sure if its the fault of the VLAN code, or maybe some hardware problem.
Changes: Coded around an extraneous skb alloc/free so that there should be no
extra buffer copying as compared to an ethernet interface, unless the
vlan device spans more than one interface. Put #ifdef around all printk
debugging calls, at least for non-control code (ie no more printk in the
critical paths.)
Date: October 19, 1999
Version: 0.0.6
Kernel Version: 2.2.10
Status: Ping & FTP work, ping -f kills it after some time...not sure why yet.
Changes: Got tcpdump working with VLAN pkts (use the -e option). Got basic VLAN
functionality working, though problems remain, including a KERNEL CRASH
that can be induced by ping -f on one of the vlan interfaces. My test
setup consists of two linux boxes, each running my modified kernel.
Since I have no third-party implementation to test against, it is likely
the code is not too right yet!!
Performance isn't all that great: Running a Cyrix 155 <-> a Cyrix 233,
connected through a 10bt hub, I get 910 Mbps on regular ethernet,
and only 650 Mbps on the VLAN device. This was using a 30 MB file.
Date: Long time ago.
Version: 0.0.3
Kernel Version: 2.2.2
Status: Definately broken, but lots of code in there!!
Changes: Initial partially functional release (not very functional.)