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]
Message-ID: <51C3527D.1030304@mentor.com>
Date:	Thu, 20 Jun 2013 20:05:33 +0100
From:	Jim Baxter <jim_baxter@...tor.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	<netdev@...r.kernel.org>
Subject: Re: VLAN driver question

On 19/06/13 17:33, Ben Hutchings wrote:
> On Wed, 2013-06-19 at 16:57 +0100, Jim Baxter wrote:
>> Thank you Ben, that is very helpful.
>>
>> On 18/06/13 15:41, Ben Hutchings wrote:
>>> On Mon, 2013-06-17 at 20:12 +0100, Jim Baxter wrote:
>>>> I have a network card that has a single flag to indicate if a received
>>>> packet contains a vlan packet.
>>>>
>>>> Can I use this to accelerate the kernels handling of the packet with
>>>> something like the following?
>>>>
>>>> /* Handle received VLAN packets */
>>>> if ((ndev->features & NETIF_F_HW_VLAN_CTAG_RX) && ebdp &&
>>>> 					(ebdp->cbd_esc &
>>>> 					BD_ENET_RX_VLAN)) {
>>>> 	/* Push and remove the vlan tag */
>>>> 	struct vlan_hdr *vlan_header;
>>>> 	u16 vlan_tag;
>>>> 	vlan_header = (struct vlan_hdr *) skb->data;
>>>> 	vlan_tag = ntohs(vlan_header->h_vlan_TCI);
>>>> 	__vlan_hwaccel_put_tag(skb, vlan_tag);
>>>> 	skb->len -= VLAN_HLEN;
>>>> 	skb->data += VLAN_HLEN;
>>>> 	vlan_set_encap_proto(skb, vlan_header);
>>>
>>> You have to move the Ethernet addresses forward as well.  Imagine this
>>> device is being bridged - the Ethernet header won't be regenerated, so
>>> it has to be immediately before the network header.
>>>
>> Unless I have misunderstood, the Ethernet header is already copied
>> across to the skb by the Driver I am editing with the lines:
>> 	skb_reserve(skb, NET_IP_ALIGN);
>> 	skb_put(skb, pkt_len - 4);	/* Make room */
>> 	skb_copy_to_linear_data(skb, data, pkt_len - 4);
>> 	skb->protocol = eth_type_trans(skb, ndev);
> 
> Right, but the copy and ether_type_trans() result in an skb like this:
> 
> -14 -8  -2   0   2    4
> |dst|src|8100|vid|type|payload...|
>              ^
> 
> After extracting the VLAN tag the skb looks like:
> 
> -18 -12 -6   -4  -2   0
> |dst|src|8100|vid|type|payload...|
>                       ^
> 
> If this packet is bridged, the 14 bytes before skb->data will be treated
> as the Ethernet header:
> 
> 0 2   8    10  12   14
> |x|src|8100|vid|type|payload...|
> ^
> 
> Then with the VLAN tag inserted;
> 
> 0 2   8    10  12   14  16   18
> |x|src|8100|vid|8100|vid|type|payload...|
> 
>> Thinking about it though I should actually use the flag from the driver
>> to create an skb of the size (pkt_len - 4 - VLAN_HLEN) and extract the
>> vlan header from data so it is not copied to the skb, does this sound
>> sensible?
> [...]
> 
> That would also work.
> 
> Ben.
> 

Thank you for that information, I have decided to extract the data
before copying the data into the skb->data structure.

This is the put of the packet showing my removal of the data correctly,
however the network is not receiving any data on the VLAN.

- data buffer from the Network card
ff ff ff ff ff ff 00 26 b9 d4 19 01 81 00 00 0a 08 06 00 01 08 00 06 04
00 01 00 26 b9 d4

- skb->data after I have only copied data to it and removed the vlan 4
octet header using skb_copy_to_linear_data and
skb_copy_to_linear_data_offset.
ff ff ff ff ff ff 00 26 b9 d4 19 01 08 06 00 01 08 00 06 04 00 01 00 26
b9 d4 19 01 c0 a8

- skb-data after eth_type_trans()
00 01 08 00 06 04 00 01 00 26 b9 d4 19 01 c0 a8 01 67 00 00 00 00 00 00
c0 a8 01 64 00 00

After this point I send the packet into the network stack with:
	__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlan_tag);

	napi_gro_receive(&fep->napi, skb);

Am I missing a kernel call or doing something wrong to cause the packet
to be rejected in the kernel?

Thank you for any help,
Jim

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ