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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 31 Jan 2013 10:50:14 +0200
From:	Claudiu Manoil <claudiu.manoil@...escale.com>
To:	voncken <cedric.voncken@...sys.fr>
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




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