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  linux-cve-announce  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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ