When using 802.1q vlans, there are problems with the ethernet frames being to big after the 802.1q header has been added. There are kernel patches available for this problem, which can, AFAIK, be applied to the drivers without negative effects when not using 802.1q. I am using gentoo-sources - currently running 2.4.20-gentoo-r7 and the patches are not applied automatically, Maybe the patches could be added to the Gentoo-sources? They can be found (among others) on: http://www.bewley.net/linux/vlan/patches/ Just for clarity: I am not the developper of any of these patches. Reproducible: Always Steps to Reproduce: I have configured VLANs on a 3Com 3c905B card in the server. This card is connected to a 3Com switch, and the port it is connected to is configured for VLAN trunking. I do a ping from another machine (workstation) on the network. This machine is connected to a 'normal' port on the switch; this port is part of VLAN 1. So, what happens is: the 'ping' packet is sent by my workstation to the switch; the switch adds the 802.1q header and forwards it to the server. As long as the packets stay at or under 1468 bytes ICMP data (=1496 bytes ethernet) this goes fine, above that, it fails, because the driver of the 3Com card in the server throws away the packets that are bigger than 1500 bytes. Actual Results: bash-2.05b$ ping -M do -c 1 -s 1467 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 1467(1495) bytes of data. 1475 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=3.94 ms --- 192.168.1.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 3.942/3.942/3.942/0.000 ms bash-2.05b$ ping -M do -c 1 -s 1468 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 1468(1496) bytes of data. 1476 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=3.48 ms --- 192.168.1.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 3.482/3.482/3.482/0.000 ms bash-2.05b$ ping -M do -c 1 -s 1469 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 1469(1497) bytes of data. --- 192.168.1.1 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms Expected Results: Accept the packet. Workarounds: - Set MTU to 1496 on all machines on the LAN - Apply patches manually
Just an additional comment (I just ran into this problem again after recompiling a kernel and forgetting to add the patches): This problem makes a remote nfs-mount hang, which makes it extremely annoying...
Anyone take care of this already? (ie. apply necessary patches to gentoo-sources)
I just checked the code in 3c59x.c and it does not seem to have this patch installed. I have tried to apply the patch, but it doesn't work anymore. Here's a patch to fix that (this is a patch to the patch, just to make things complicated). I have not tested it yet, because my box takes a couple of hours to compile a kernel... but I have no reason to believe it does not. --- vlan-3c59x.patch.orig 2004-03-30 17:14:39.000000000 +0200 +++ vlan-3c59x.patch 2004-03-30 17:18:37.000000000 +0200 @@ -41,7 +41,7 @@ u16 intr_enable; @@ -844,6 +849,9 @@ - static int vortex_ioctl(struct net_device *dev, struct ifreq *rq, int cmd); static void vortex_tx_timeout(struct net_device *dev); static void acpi_set_WOL(struct net_device *dev); + static struct ethtool_ops vortex_ethtool_ops; +#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) +static void set_8021q_mode(struct net_device *dev, int enable);
Oops, forgot to mention in which version I had checked the code: 2.4.25-gentoo
Do these patches add functionality that can only be used with the vconfig rpm's that are also located at http://www.bewley.net/linux/vlan/? Do these patches apply against the vanilla kernel? I checked the site, and there doesn't seem ot be much activity.
These patches solve a problem with 802.1q VLAN's. The VLAN tag adds a couple of bytes to each frame (4). This means that a frame may grow bigger than the MTU + ethernet header. The ethernet drivers discard these frames, causing a very high packet loss. These patches modify the original kernel drivers so that it checks whether VLAN's are used on the interface, and if it does, it grows the maximum frame size with four bytes. As far as I can understand from the modified code, it should not add any problems for systems that are not using 802.1q VLAN's. The mentionned vconfig rpm's are also available in portage. I think the patches can apply to the vanilla kernel, but I use them on the Gentoo kernel. I had to make a small modification to the patch to make it work in 2.4.25-gentoo (because of an added line, see one of my previous comments). Please let me know if you need more information.
linux root # emerge -p vconfig These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] net-misc/vconfig-1.8
The code for these patches looks clean and done properly. livewire, what do you think? I checked the ebuild and it's pulling from your dev.gentoo.org site, so there's nothing really I can do. I have no problem with these patches, after the minor fix of course.
I would like to suggest these patches should be applied to the gentoo-dev-sources (too). The patches are now working in production (3c59x). Although it doesn't patch cleanly on the 2.6 series anymore (one of the prototypes, need to be set after reading the .rej file). After emerging the 2.6.5 kernel I will try to make a patch for 2.6.
Created attachment 28982 [details, diff] 3Com VLAN patch, patched The promised patch (Jeroen's patch probably), but done with a manual diff on the driver and the adapted driver. I didn't test the patch with 2.6.5 yet and I cannot verify this code works as promised. But from experience (2.6.4) I know that this solution is much better than changing all clients to a lower MTU :)
Created attachment 29492 [details, diff] 3c59x vlan patch first thing should be ignored, it is the reverse patch
is this going to get applied?
for 2.6? no way. for 2.4, there is no 2.4 gentoo kernel development happening, so I really doubt it...
I should be able to put the 2.4 patches into gentoo-sources since they don't seem too intrusive and the code looks good...
I don't think we need this bug anymore... upstream 2.6 seems to have this VLAN stuff anyway.
