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.)