From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941801AbcLVRzG (ORCPT ); Thu, 22 Dec 2016 12:55:06 -0500 Received: from mail-io0-f173.google.com ([209.85.223.173]:33019 "EHLO mail-io0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756584AbcLVRzF (ORCPT ); Thu, 22 Dec 2016 12:55:05 -0500 MIME-Version: 1.0 In-Reply-To: <74e1e76d-40f6-db8e-74ac-90b0474d4e11@huawei.com> References: <1481802034-77729-1-git-send-email-chenweilong@huawei.com> <5c942aba-f7fb-ede6-b6a2-e591025f53a5@huawei.com> <74e1e76d-40f6-db8e-74ac-90b0474d4e11@huawei.com> From: Alexander Duyck Date: Thu, 22 Dec 2016 09:55:03 -0800 Message-ID: Subject: Re: [PATCH net-next] ixgbevf: fix 'Etherleak' in ixgbevf To: Kefeng Wang Cc: Weilong Chen , Jeff Kirsher , intel-wired-lan , Netdev , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Yes that is much more helpful. So looking at it things are being padded but the last 4 bytes always have this extra data in them. I've been trying to recreate the issue on an 82599 with an SR-IOV VF and I haven't been having much luck reproducing the problem. In your test environment is the 82599 connected directly to the Windows machine or are there any switches/routers/gateways/tunnels/vlans in between? I've tried several iterations but with the 82599 connected directly to another NIC I have I am not able to get it to produce the garbage padding you are seeing. It makes me wonder if there might be something that is manipulating the packets in between the two systems. For example if there was a VLAN being associated with the VF that is later stripped and then the packet handed raw to the test system it might explain what is introducing the extra padding and reason for pulling in the CRC, and your patch would mask the issue since it would push the minimum frame size with a VLAN to 68 instead of 64. - Alex On Wed, Dec 21, 2016 at 6:00 PM, Kefeng Wang wrote: > > > On 2016/12/21 10:20, Alexander Duyck wrote: >> I find it curious that only the last 4 bytes have data in them. I'm >> wondering if the NIC/driver in the Windows/Nessus system is >> interpreting the 4 byte CRC on the end of the frame as padding instead >> of stripping it. >> >> Is there any chance you could capture the entire frame instead of just >> the padding? Maybe you could run something like wireshark without >> enabling promiscuous mode on the VF and capture the frames it is >> trying to send and receive. What I want to verify is what the actual >> amount of padding is that is needed to get to 60 bytes and where the >> CRC should start. >> >> - Alex > > Here is the verbose output, is this useful? > Or we will try according to your advice, thanks, > > D:\Program Files\Tenable\Nessus>nasl.exe -aX -t 192.169.0.151 etherleak.nasl > -------------------------- > ---[ ICMP ]--- > 0x00: 45 00 00 1D 20 81 00 00 40 01 D7 F3 C0 A9 00 97 E... ...@....... > 0x10: C0 A9 00 82 00 00 87 FD 00 01 00 01 78 00 00 00 ............x... > 0x20: 00 00 00 00 00 00 00 00 00 00 98 E4 75 DF ............u. > -------------------------- > ---[ ICMP ]--- > 0x00: 45 00 00 1D 20 85 00 00 40 01 D7 EF C0 A9 00 97 E... ...@....... > 0x10: C0 A9 00 82 00 00 87 FD 00 01 00 01 78 00 00 00 ............x... > 0x20: 00 00 00 00 00 00 00 00 00 00 FB DA F8 13 .............. > ---[ ether1 ]--- > 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 98 E4 75 ...............u > 0x10: DF . > ---[ ether2 ]--- > 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 FB DA F8 ................ > 0x10: 13 . > > Padding observed in one frame : > > 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 98 E4 75 ...............u > 0x10: DF . > > Padding observed in another frame : > > 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 FB DA F8 ................ > 0x10: 13 > >