Hi,
VLAN-Tagging on Linux seems still to be problematic, despite the dot1q
patch being in the kernel since a few months. Problems arise when a
system running on an untagged switch port sends a frame using full MTU
to a system that runs VLAN tagging. The switch adds the VLAN tag to
the frame which then exceeds the MTU and is then dropped by the
receiving Linux system.
Googling for this reveals that it is thought that this is not a
hardware, but a software issue and all network cards running under
linux can be made to accept oversized frames.
For the tulip driver that we use, there are two patches available that
claim to make the card accept oversized frames. Since I am not an
experienced kernel programmer, I don't know which of these two patches
to use.
Both patches seem to tweak the MTU size by changing a few constants
and allocating a larger buffer. I am concerned that this will probably
not solve the problem in a clean way since the card will show MTU 1504
in the interface data, and application software will probably start
using the four additional bytes instead of leaving them free for the
VLAN tag.
This has been brought up on various mailing lists, but the threads
discussing this matter are usually quite short, with nobody really
knowledgeable caring to comment about this.
IMO, the clean way to do this would be to program the hardware to
receive larger frames, and to allocate the larger buffer, but to
refrain from reporting the larger MTU to higher layers, saving the
buffer space for the VLAN tag. Are patches in the works that can do
this?
OTOH, there are mailing list submissions in the archive that claim
that the tulip driver can be made to accept larger frames, thus
solving the VLAN problem without patches, by enabling support for
jumbo frames. Unfortunately, I can't find any docs how to enable that
feature.
I would appreciate any comments. Thanks in advance.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Replying to Marc Haber:
> Hi,
>
> VLAN-Tagging on Linux seems still to be problematic, despite the dot1q
> patch being in the kernel since a few months. Problems arise when a
> system running on an untagged switch port sends a frame using full MTU
> to a system that runs VLAN tagging. The switch adds the VLAN tag to
> the frame which then exceeds the MTU and is then dropped by the
> receiving Linux system.
You can take latest stable linux-stingr kernel from
bk://linux-stingr.bkbits.net/stable4
It contains (following) (rediffed) working tulip mtu patch :)
diff -urN linux-2.4.9-ac10-novlan/drivers/net/tulip/interrupt.c linux-2.4.9-ac10/drivers/net/tulip/interrupt.c
--- linux-2.4.9-ac10-novlan/drivers/net/tulip/interrupt.c Wed Jun 20 22:15:44 2001
+++ linux-2.4.9-ac10/drivers/net/tulip/interrupt.c Mon Sep 10 18:44:12 2001
@@ -128,8 +128,8 @@
dev->name, entry, status);
if (--rx_work_limit < 0)
break;
- if ((status & 0x38008300) != 0x0300) {
- if ((status & 0x38000300) != 0x0300) {
+ if ((status & (0x38000000 | RxDescFatalErr | RxWholePkt)) != RxWholePkt) {
+ if ((status & (0x38000000 | RxWholePkt)) != RxWholePkt) {
/* Ingore earlier buffers. */
if ((status & 0xffff) != 0x7fff) {
if (tulip_debug > 1)
@@ -155,10 +155,10 @@
struct sk_buff *skb;
#ifndef final_version
- if (pkt_len > 1518) {
+ if (pkt_len > 1522) {
printk(KERN_WARNING "%s: Bogus packet size of %d (%#x).\n",
dev->name, pkt_len, pkt_len);
- pkt_len = 1518;
+ pkt_len = 1522;
tp->stats.rx_length_errors++;
}
#endif
diff -urN linux-2.4.9-ac10-novlan/drivers/net/tulip/tulip.h linux-2.4.9-ac10/drivers/net/tulip/tulip.h
--- linux-2.4.9-ac10-novlan/drivers/net/tulip/tulip.h Wed Jun 20 22:19:02 2001
+++ linux-2.4.9-ac10/drivers/net/tulip/tulip.h Mon Sep 10 18:42:27 2001
@@ -186,7 +186,7 @@
enum desc_status_bits {
DescOwned = 0x80000000,
- RxDescFatalErr = 0x8000,
+ RxDescFatalErr = 0x4842,
RxWholePkt = 0x0300,
};
@@ -264,7 +264,7 @@
#define MEDIA_MASK 31
-#define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer. */
+#define PKT_BUF_SZ 1540 /* Size of each temporary Rx buffer. */
#define TULIP_MIN_CACHE_LINE 8 /* in units of 32-bit words */
diff -urN linux-2.4.9-ac10-novlan/drivers/net/tulip/tulip_core.c linux-2.4.9-ac10/drivers/net/tulip/tulip_core.c
--- linux-2.4.9-ac10-novlan/drivers/net/tulip/tulip_core.c Mon Sep 10 18:50:47 2001
+++ linux-2.4.9-ac10/drivers/net/tulip/tulip_core.c Mon Sep 10 18:39:59 2001
@@ -59,7 +59,7 @@
#if defined(__alpha__) || defined(__arm__) || defined(__hppa__) \
|| defined(__sparc_) || defined(__ia64__) \
|| defined(__sh__) || defined(__mips__)
-static int rx_copybreak = 1518;
+static int rx_copybreak = 1522;
#else
static int rx_copybreak = 100;
#endif
--
Paul P 'Stingray' Komkoff 'Greatest' Jr // (icq)23200764 // (irc)Spacebar
PPKJ1-RIPE // (smtp)[email protected] // (http)stingr.net // (pgp)0xA4B4ECA4
On Thu, Apr 11, 2002 at 07:23:27PM +0400, Paul P Komkoff Jr wrote:
> It contains (following) (rediffed) working tulip mtu patch :)
That patch solved my problem.
With that driver, the MTU still shows as 1500 bytes, while I thought
that patch would cause the MTU to go up to 1504 bytes.
Will this patch be in the mainstream kernel soon? Or could it have
negative effects?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany | lose things." Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature | How to make an American Quilt | Fax: *49 721 966 31 29
Replying to Marc Haber:
> Will this patch be in the mainstream kernel soon? Or could it have
> negative effects?
According to Jeff Garzik, MAINTAINER of tulip driver, negative effects are *unknown*
And probability of mainstream tulip being patched like this - too ...
:)))
--
Paul P 'Stingray' Komkoff 'Greatest' Jr // (icq)23200764 // (irc)Spacebar
PPKJ1-RIPE // (smtp)[email protected] // (http)stingr.net // (pgp)0xA4B4ECA4
Marc Haber wrote:
> On Thu, Apr 11, 2002 at 07:23:27PM +0400, Paul P Komkoff Jr wrote:
>
>>It contains (following) (rediffed) working tulip mtu patch :)
>>
>
> That patch solved my problem.
>
> With that driver, the MTU still shows as 1500 bytes, while I thought
> that patch would cause the MTU to go up to 1504 bytes.
The ethX MTU should remain 1500 to not break non-vlan traffic. Secretly,
though, the NIC should pass frames that are 4 bytes bigger.
> Will this patch be in the mainstream kernel soon? Or could it have
> negative effects?
I wonder if we could somehow make the changes a module option even
if Jeff won't allow it in by default....
Most other drivers have the same issues....
Ben
>
> Greetings
> Marc
>
>
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear