netdev - RE: Gianfar : Drop a long frame

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 31 Jan 2013 15:13:36 +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


On 1/30/2013 6:27 PM, voncken wrote:
> -----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.
>

Ok, at fist glance it seems that the DEFAULT_RX_BUFFER_SIZE of 1536 bytes is
not enough to accommodate VLAN_HLEN.
Apparently, the reason why it works with rxvlan 'on' and it doesn't when set
to 'off' is because by changing the NETIF_F_HW_VLAN_* feature flags the
gfar_change_mtu() gets called, which in turn has the following
issue:
gfar_change_mtu():
...
	if (gfar_is_vlan_on(priv))
		frame_size += VLAN_HLEN;
...
where,
gfar_is_vlan_on():
{
	return (priv->ndev->features & NETIF_F_HW_VLAN_RX) ||
	       (priv->ndev->features & NETIF_F_HW_VLAN_TX); }

and it's odd that the rx_buffer_size is conditioned by the HW VLAN
acceleration feature being turned on or off.
But I'll have to run some tests too to confirm this.

Regards,
Claudiu

It's true. That work when rx is on, because the VLAN TAG is removed from
frame by eTSEC and the len frame is below 1536. 
In the mpc8315 Family reference manual rev 2, the table 19-160 indicates
that if  L bit is set, the data length includes the CRC. It seems the
gfar_change_mtu function must include the CRC length in frame len compute.

Best 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