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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 30 Jan 2013 17:27:22 +0100
From:	"voncken" <cedric.voncken@...sys.fr>
To:	"'Claudiu Manoil'" <claudiu.manoil@...escale.com>
Cc:	<netdev@...r.kernel.org>
Subject: RE: Gianfar : Drop a long frame

-----Message d'origine-----
De : Claudiu Manoil [mailto:claudiu.manoil@...escale.com] 
Envoyé : mercredi 30 janvier 2013 16:56
À : voncken
Cc : netdev@...r.kernel.org
Objet : Re: Gianfar : Drop a long frame

On 1/30/2013 3:43 PM, voncken wrote:
> 	Hi Claudiu,
>
> 	I have a problem with the gianfar driver.
>
> 	My test conditions are:
> 		- Disable rxvlan hardware acceleration (ethtool -K ethx
rxvlan off)
> 		- Receive frame contains a VLAN tag and with a frame len set
to the 
> MTU (1500 bytes).
>
> 	In this condition, when I received a long frame the bdp->length is 
> set to 1538 bytes.
> 	I guess it is composed of:
> 		1500 bytes: L3 data bytes
> 		 + 14 bytes:  Ethernet header
> 		 + 4 bytes:  Vlan Tag header
> 		 + 8 bytes: FCB structure size GMAC_FCB_LEN
> 		 + 8 bytes: eTSEC padding
> 		 + 4 bytes: Frames CRC (FCS)
>
> 	The Maximum frame len is set to 1536 because the function 
> gfar_change_mtu does not integrate the FCS in the computed frame size.
> 	In this condition this frame is dropped with the test line 2792 
> function gfar_clean_rx_ring
> 		if (unlikely(!(bdp->status & RXBD_ERR) &&
> 				bdp->length > priv->rx_buffer_size))
> 			bdp->status = RXBD_LARGE;
> 	
> 	How I can receive this frame correctly?
> 	
> 	Best regards
>
> Cedric Voncken | R&d Engineer

Hi Cedric Voncken,
Is the 802.1Q support activated on the receiving host? (see
CONFIG_VLAN_8021Q)

Hi Claudiu, 

YEs the CONFIG_VLAN_8021Q is enable on the receiving host, that work
correctly if RXVLAN is set to on (ethtool -K ethx rxvlan off)
I try with the linux kernel 3.3.8.

Regards.



--
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

Powered by blists - more mailing lists