netdev - ucc_geth doesn't work properly with vlans enabled.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 27 Nov 2009 10:08:26 -0500
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Anton Vorontsov <avorontsov@...mvista.com>
Cc:	LKML <linux-kernel@...r.kernel.org>, netdev@...r.kernel.org,
	Len Sorensen <lsorense@...lub.uwaterloo.ca>
Subject: ucc_geth doesn't work properly with vlans enabled.

We just started using vlans on our powerpc platform, and we noticed that
we were getting dropped packets when using the vlan interfaces.
After a bit of debuging it turned out that dropping the MUT on the
client machine to 1496 made the problem go away, which was of course
also very suspicious.

So looking through the driver I found the max packet length is set to 1518
which of course is the right size for a 1500byte packet as long as it is
not vlan tagged.  The UCC happens to have support for recognizing vlan
tagged packets and dynamically increasing the allowed size in the vlan
tagged case by 4 bytes which is great if it works.  Well it turns out,
that feature works, but isn't actually enabled in the driver.  The code
to handle activating it is there, but there is no code anywhere to ever
set that parameter.

Specifically:

        if (ug_info->dynamicMaxFrameLength)
                remoder |= REMODER_DYNAMIC_MAX_FRAME_LENGTH;

This code works fine, but ug_info->dynamicMaxFrameLength is never touched
anywhere other than being memset to 0 initially as part of the struct.

So a simple hack of:

        if (ug_info->dynamicMaxFrameLength || 1)
                remoder |= REMODER_DYNAMIC_MAX_FRAME_LENGTH;

makes it work perfectly with vlans, but is obviously not the right way
to solve this.

What would be the right way to solve this?  What was the intent here I
wonder when it was written?  Certainly the current behaviour means vlans
can't be used on this driver.

-- 
Len Sorensen
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html