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] [day] [month] [year] [list]
Message-ID: <CAJ2oMhL49ovpfUeXQeL6RayUENB62KtHXVwUDXZWPkRGYHQF6g@mail.gmail.com>
Date:	Mon, 2 May 2016 08:12:36 +0300
From:	Ran Shalit <ranshalit@...il.com>
To:	Peter PalĂșch <Peter.Paluch@....uniza.sk>
Cc:	netdev@...r.kernel.org, Alexander Duyck <alexander.duyck@...il.com>
Subject: Re: Q: How to disable vlan strip in Intel igb driver ?

On Sun, May 1, 2016 at 11:51 PM, Peter PalĂșch <Peter.Paluch@....uniza.sk> wrote:
> Hi Ran,
>
>
>> Alex,
>> I don't see rx-vlan-offload option in my ethtool. strange, maybe it is
>> not available in all ethtool versions ?
>
>
> According to my manpage for ethtool v4.5, the relevant -K option is
> "rxvlan".
>
>> Hi Peter,
>> Yes, I'm using AF_PACKET (I can't validate it now for 100%, but I
>> quite sure about it).
>
>
> Okay - but I assume that you are writing a userspace application, not a
> kernelspace driver or module, right?
>
>> I'm accessing the ethernet header, and it always gives me non extended
>> ethernet header (without vlan information).
>
>
> It seems that this behavior has been around for a long time, and is
> intentional. See the following thread for more information:
>
> http://www.spinics.net/lists/netdev/msg244668.html
>
> The only legit way of accessing VLAN tag info on an AF_PACKET socket I know
> about is by setting the PACKET_AUXDATA socket option, and reading the
> auxiliary data as a struct tpacket_auxdata using recvmsg().
>
> In addition, however, there seems to be a bug in the kernel in that the
> tp_vlan_tci member of the struct tpacket_auxdata is filled in only if the
> AF_PACKET socket is bound to htons(ETH_P_ALL). If the socket is bound to any
> other specific protocol, the tp_vlan_tci is set to 0. I have raised this
> issue recently in the following thread(s) but have not received a response
> yet:
>
> http://www.spinics.net/lists/netdev/msg372830.html
> http://www.spinics.net/lists/netdev/msg373112.html
>
>
>> I can see the vlan tag in vlan_tci field in sk_buff, but this is not
>> exactly what I need, I need the header AS-IS with the original
>> (extended) ethernet header.
>
>
> How are you accessing the vlan_tci field from your software?
>
> In any case, with AF_PACKET sockets, I am afraid you don't have much choice.
> Even libpcap reconstructs VLAN-tagged frames by reading the VLAN tag from an
> auxiliary structure and then re-inserting it into the frame, because the
> frame delivered through an AF_PACKET socket does not have the VLAN tag
> present anymore.
>

Hi Peter,

I have a patch (hook) in the igb (Intel) driver which reads the skb
buffer into our buffer, this is without using socket actually. ipstack
is not involved, so socket as
I mentioned before are not relevant (AF_PACKET not relevant).
the problem seems in the driver that the driver strip vlan information
(there is a lot of mention of strip and vlan in the igb driver, and I
tried many things, but still it always strip this information from the
data in the sk_buff.)
will ethtool assist in this case ? I don;t see any vlan option in my
ethtool. Does ethtool communicated with the driver and command it not
to strip the vlan info ?

Thanks,
Ran

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ