linux-kernel - e1000: Problem with "disable CRC stripping workaround" patch

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>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Jul 2006 17:11:08 +0100
From:	Mark McLoughlin <markmc@...hat.com>
To:	jesse.brandeburg@...el.com
Cc:	linux-kernel@...r.kernel.org, xen-devel@...ts.xensource.com,
	Herbert Xu <herbert@...dor.apana.org.au>
Subject: e1000: Problem with "disable CRC stripping workaround" patch

Hi Jesse,
	I just came across this:

  http://www.mail-archive.com/netdev@vger.kernel.org/msg14547.html

	I'm seeing a problem with this currently under Xen's bridging
configuration.

	Basically, with the patch, packets are being dropped at this point in
net/bridge/br_forward.c:

---
int br_dev_queue_push_xmit(struct sk_buff *skb)
{
        /* drop mtu oversized packets except gso */
	if (packet_length(skb) > skb->dev->mtu && !skb_is_gso(skb)) {
		kfree_skb(skb);
--

	What's happening that a 1500 byte packet comes in from e1000, onto the
bridge and is to be forwarded to a device whose mtu is 1500. Because the
CRC hasn't been stripped, skb->len is 1504 and the packet is dropped.

	One option is to fix this specific problem is to subtract the CRC
length from skb->len in e1000, another is to raise the MTU on the
receive side of Xen's loopback interface. I've attached a patch for the
latter, but I've no real opinion on which is more correct.

Cheers,
Mark.

View attachment "xen-netback-jumbo-mtu-on-vif.patch" of type "text/x-patch" (1364 bytes)